3 ms·

I don't understand why languages like these are not mainstream. Why are we stuck with blindly editing text files and waiting for compilation that restarts the w

by vlaaad 7y ago

I don't understand why languages like these are not mainstream. Why are we stuck with blindly editing text files and waiting for compilation that restarts the whole world? Why state of the art is a REPL where immediate feedback is limited to printed text with all the actual values barely reachable?

jolmg 7y ago
> Why are we stuck with blindly editing text files It's inherently more portable and composable. > waiting for compilation There are many languages that are interpreted that are mainstream. > that restarts the whole world You can program in mainstream languages without restarting the world. See skewer-mode[1] for example, for programming in javascript without restarting/refreshing. You can change top-level definitions and send them to override the previous definitions. You can do this with any language that allows overriding functions at runtime, IOW late-binding languages with an eval function, like python and ruby. This way of programming is probably very non-mainstream, though. The reason why it's not more popular is probably because most of us are working with programs that take little to no time to restart and get to the same state. Restarting ensures that whatever state we see in the program is reachable with the current state of the source code. > Why state of the art is a REPL where immediate feedback is limited to printed text with all the actual values barely reachable? Again, because that's inherently more portable and composable. What do you mean they "actual values [are] barely reachable"? You can access anything via any REPL I can think of. [1] https://github.com/skeeto/skewer-mode https://github.com/skeeto/skewer-mode
pavlov 7y ago
It often feels like the mainstream computer industry did a single dip into PARC, took the ideas that could be reasonably implemented on a 1982 Motorola 68k in assembly and Pascal with minimal RAM, and forgot about everything else. Soon thereafter PCs became obsessed with being either Unix or VMS, and over time that created a harsh immune response to the influence of Smalltalk/Self because it's such a different paradigm.
projektfu 7y ago
For one thing, Self was barely fast enough to work with on reasonable hardware of the day. If you don't mind 100ms+ latency on every click and keypress, it's fine. I found it frustratingly slow, so I guess I'm pretty latency sensitive. Perhaps it's zippier now on today's fancy hardware. Smalltalk (e.g. VisualWorks) felt much faster even though it was rendering components itself. Probably a mixture of optimization of common cases that was missing in Self and certain advanced compilation/interpretation tricks that were also missing. VisualAge felt slower. If you used VisualAge for Java you also were using the Smalltalk UI. (That is, until Micro Edition). Squeak using Morphic was pretty slow in its original non-jit mode but the Smalltalk-80 UI was fast (and quite different from how you expect things to work.)

by vlaaad 7y ago

jolmg 7y ago

> Why are we stuck with blindly editing text files It's inherently more portable and composable. > waiting for compilation There are many languages that are interpreted that are mainstream. > that restarts the whole world You can program in mainstream languages without restarting the world. See skewer-mode[1] for example, for programming in javascript without restarting/refreshing. You can change top-level definitions and send them to override the previous definitions. You can do this with any language that allows overriding functions at runtime, IOW late-binding languages with an eval function, like python and ruby. This way of programming is probably very non-mainstream, though. The reason why it's not more popular is probably because most of us are working with programs that take little to no time to restart and get to the same state. Restarting ensures that whatever state we see in the program is reachable with the current state of the source code. > Why state of the art is a REPL where immediate feedback is limited to printed text with all the actual values barely reachable? Again, because that's inherently more portable and composable. What do you mean they "actual values [are] barely reachable"? You can access anything via any REPL I can think of. [1] https://github.com/skeeto/skewer-mode https://github.com/skeeto/skewer-mode

pavlov 7y ago

It often feels like the mainstream computer industry did a single dip into PARC, took the ideas that could be reasonably implemented on a 1982 Motorola 68k in assembly and Pascal with minimal RAM, and forgot about everything else. Soon thereafter PCs became obsessed with being either Unix or VMS, and over time that created a harsh immune response to the influence of Smalltalk/Self because it's such a different paradigm.

projektfu 7y ago

For one thing, Self was barely fast enough to work with on reasonable hardware of the day. If you don't mind 100ms+ latency on every click and keypress, it's fine. I found it frustratingly slow, so I guess I'm pretty latency sensitive. Perhaps it's zippier now on today's fancy hardware. Smalltalk (e.g. VisualWorks) felt much faster even though it was rendering components itself. Probably a mixture of optimization of common cases that was missing in Self and certain advanced compilation/interpretation tricks that were also missing. VisualAge felt slower. If you used VisualAge for Java you also were using the Smalltalk UI. (That is, until Micro Edition). Squeak using Morphic was pretty slow in its original non-jit mode but the Smalltalk-80 UI was fast (and quite different from how you expect things to work.)