Make an RFC for Notebook mode in DrR or Jypyter. #100 https://github.com/racket/racket2-rfcs/issues/100
I posted it because it seems like notebook mode support is important in any new language. (Doubly so for LOP?)
Maybe it is not difficult for Racket? We have amazing GUI and plot libs, snips, eval and sandbox.
@spdegabrielle The bits and pieces are certainly there. Here is a screenshot from one of my abandoned projects.
If anyone wants to try it, open the file “racket-cas.rkt” in DrRacket and hit run. https://github.com/soegaard/bracket/blob/master/gui/racket-cas.rkt
Note: The CAS in the repo racket-cas is not used here. Unfortunate naming clash.
The left shows an editor (text%) in which the math boxes are snips.
@soegaard2 Thank you - I assumed that would be only math like wxmaxima and didn’t even think of it. (I think I’m wrong about wxmaxima too - I think you can use SBCL)
Here in Denmark there are 3 programs competing over being “the math program” for high school.
Maple: Which uses a notebook approach.
NSpire: Which divides the screen into a number of workshops. One could be a text editor with math boxes, another a plotting window, another a spread sheet.
WordMat: Which is a plugin for Word. It uses Maxima in the background.
Word(Mat) gives the best output.
NSpire has the best experimental features. If you redefined a value in one window, then plots and spreadsheets update in the other.
Maple has the most mathematical features, but has too many features for a beginning high school student.
@soegaard2 as far as the UI is concerned there seems to be a spectrum between the sequence of cells approach like jupyter notebook, and a more document centric approach where you can embed the cells in a document.
@soegaard2 is there a relationship between ? https://github.com/soegaard/bracket/blob/master/gui/racket-cas.rkt and https://github.com/soegaard/racket-cas
No.
Bracket (horrible name needs rebranding) was an attempt to write an nspire-inspired math program. It contains some numerical functions, an engine for algebraic expressions and a “gui”.
On the other hand, racket-cas was born from an experiment on rewriting the symbolic engine using match expanders.
Well, the gui was inspired by NSpire, but the CAS was inspire by Mathematica.
I need to look closer to see if (a) other types of code boxes can be extended to support #langs in addition to expressions? (b) it can be turned into a DrRacket Plugin?
@stefan.kruger has joined the channel
- If new futures is braking things but also provide some REAL advancements then they pay for themselves.
- If new futures brakes things and does not bring real improvements to the level that people will be willing to use this new futures instead of broken functional, than perhaps this is not an improvements at all.
- When something with nameit2 appears, nameit1 became MOMENTARILY obsolete. It is basic psychology, and common sense. Why I should invest my time to old technology? And when a lot of people asking this why, and actually not planning to invest, then why I should still use it in any sort?
- I just spend a year of my life learning Racket, and now I putted into perspective that all this knowledge can became obsolete in near future because parentheses is not mainstream enough? Is this the promised mature and stability? Or this is batteries?
- I am not pleased at all, I see the same concerns in other people. This is not what can be solved by maintaining legacy infrastructure. It is not a technical problem.
@nyakov13 I appreciate your concerns but I don’t think this is anything like perl or python 2->3 or java, or vb6->vbnet. parts of racket are still runnin mzscheme code https://github.com/racket/drracket/blob/master/drracket/drracket/private/tool-contract-language.rkt
python2 -> 3, Java language levels, and vb6 -> vbnet all had major difficulty because upgrading meant using a different VM. Racket2 will not require that.
@nyakov13 have you read Matthew Flatt’s original email about racket2? It clarifies that Racket2 will not be the ultimate name. I think it’s worth a read if you have time, since it seems like that email addresses some of your other concerns, too. Perhaps that addresses this comment: > 3. When something with nameit2 appears, nameit1 became MOMENTARILY obsolete. It is basic psychology, and common sense. Why I should invest my time to old technology? And when a lot of people asking this why, and actually not planning to invest, then why I should still use it in any sort?
Also, with Python2 and Python3 the plan was to deprecate Python2 from the start, yes? (For what it’s worth I can understand people’s frustration if they’re looking at it through that lens.)
Yes, that was the plan. I don’t think we’re in quite the same situation there either.
With regard to long term support for old codebases, I can relate a recent experience, which is that I have been porting the plt-scheme side of a 14 year old c++/scheme hybrid codebase that uses racketcgc because it was written before the module system existed. It runs on 7.4 after making a few changes for if -> when, () -> ’(), and a couple other things. We can’t use many of the fancy new features like modules because of how the FFI was written, but that has to do with the decisions that were made when developing the original c++/runtime interaction.
Since nearly all the fancy new racket functionality has has been added as libraries or #langs anyway
it seems to me that Racket is in a position where the only limitation if any is in the runtime itself (full unwind-protect support being one example of a runtime feature that schemes in general have struggled to implement), everything else is basically aesthetics around what features of the runtime you want to support in your language, #lang racket/base seems like it is going to remain virtually unchanged as it has for the past many years already
@ghoetker has joined the channel