21–30 of 81 posts
I wonder what a Smalltalk-like environment would look like if had been developed in the 2000s instead of the 1970s. If you could marry up the advantages of text/files, live code, visual layouts, data visualization and perhaps machine learning in the future, maybe you could come up with a huge jump in productivity and being able to handle complexity.
Is it theoretically impossible to fit an interpreter for a dynamic programming language in the L1 cache of a modern chip? (I understand there are physical constraints that prohibit super low-latency memory lookups (of unconstrained size) in 0+epsilon time (where epsilon is small))
(or was that L2?)
may be doing just that right now in your x86 BIOS :)
https://news.ycombinator.com/item?id=8869150 for a HN discussion
I wonder what a Smalltalk-like environment would look like if had been developed in the 2000s instead of the 1970s. If you could marry up the advantages of text/files, live code, visual layouts, data visualization and perhaps machine learning in the future, maybe you could come up with a huge jump in productivity and being able to handle complexity.
Mathematica gets live code, data visualization, and ML, all with a lispy+tacit+functional syntax. I find it much more integrated and easy to use compared to Jupyter notebook, although it's near useless for anything imperative -- I find myself using Jupyter a lot these days to develop one-off scripts interactively. (please, no one mention stephen)
I wonder what a Smalltalk-like environment would look like if had been developed in the 2000s instead of the 1970s. If you could marry up the advantages of text/files, live code, visual layouts, data visualization and perhaps machine learning in the future, maybe you could come up with a huge jump in productivity and being able to handle complexity.
How about an Erlang unikernel with its relup functionality, running under a VM with the ability to hibernate to disk? That gives you nearly the same set of benefits as Smalltalk, without being nearly as "fossilized."
The graphical nature of the Smalltalk environment also really helped to make it accessible. Erlang lives mostly in text terminals.
I'm still not convinced of the 'image' mechanism, it's really nice to have implicit and automatic persistence but it glues the code so strongly to the data that it starts to hamper collaboration. Being able to easily pull a bunch of stuff from one machine to another and to integrate it with stuff that was already there is something that other programming languages have solved very well (together with DVCSs), Smalltalk seems a step backwards in that regard.
Though there are times I wished for an easy way to hibernate an entire session for later re-use.
This is a distinction I first learned about working in france years ago. Without any real basis I wondered whether it is their general more precise use of language which made it a more obvious distinction for a french person to make. At the time they were more or less synonyms for me, but since then have become very distinct especially when talking about software!
Is it theoretically impossible to fit an interpreter for a dynamic programming language in the L1 cache of a modern chip? (I understand there are physical constraints that prohibit super low-latency memory lookups (of unconstrained size) in 0+epsilon time (where epsilon is small))
I'm pretty sure Chuck Moore (yes, he's still around) would be able to fit the interpreter and an entire OS into the L1 cache with room to spare. Forth technically is an interpreter.
Alan Kay has had about a few decades to empirically demonstrate that "we" have willfully made it complicated. I don't believe he has done so.
Those are the one that come to mind when I think of simple and very powerful tools. There are many others. So I think Alan Kay and friends have demonstrated that we have made things complicated for dubious reasons.
Alan Kay has had about a few decades to empirically demonstrate that "we" have willfully made it complicated. I don't believe he has done so.
Earlier quoted context omitted.
How about an Erlang unikernel with its relup functionality, running under a VM with the ability to hibernate to disk? That gives you nearly the same set of benefits as Smalltalk, without being nearly as "fossilized."
But with a huge barrier to entry. Smalltalk is at least reasonably easy to grasp for people new to programming, Erlang not so much (though it is incredibly powerful). The graphical nature of the Smalltalk environment also really helped to make it accessible. Erlang lives mostly in text terminals. I'm still not convinced of the 'image' mechanism, it's really nice to have implicit and automatic persistence but it glues…
People (outside of Ericsson) just haven't bothered to take much advantage of Erlang's strengths. Erlang speaks network wire protocols very efficiently, so if you want graphical Erlang sessions, you just need to write Erlang applications that act as e.g. X11 clients. Which is what things like Erlang's own Observer application does, complete with the ability to use the graphics toolkit Tk. (Or, if you like, you could expose an HTTP server serving a web-app with live updates over a websocket, like https://github.com/shinyscorpion/wobserver. Or an VNC/RDP server. It's really all equivalent in the end.)
Unlike Smalltalk where the graphical capabilities are part of the local console framebuffer, Erlang's approach allows you to interact with a running Erlang node graphically irrespective of your locality to it—which is important, because, in the modern day, your software is very likely a daemon on a headless server/cloud somewhere.