Pharo Smalltalk IDE as Visualizer: Mondrian in Action [video]
vimeo.com
vimeo.com
I would like to see larger adoption of Pharo in particular and immersive work environments in general.
In the 1980s I had a Lisp Machine with Smalltalk like visualization tools. As much as I appreciate modern languages and software stacks, I think that we have lost something. Even a good IDE like VisualStudio or IntelliJ have a "batch" processing feel to it: it takes a few seconds to rerun code and execution context is lost.
To some degree Emacs + Clojure is more interactive but the visualization tools are not as good as Pharo's.
I have spent time experimenting with the RTMondrian demos and this video will give me some incentive to write some code experiments. Really cool stuff.
That's from "Pharo By Example." Only, if you download Pharo today, the above description (and the illustration in the book's text) don't match the way Pharo works. As far as I can tell, Workspace is now called "Playground."
This is the problem with projects like this; and, believe me, I have been at least somewhat interested in Smalltalk for years. When I download something and come across the above by Page 3 or so, I just expect a lot of extra little frustrations that I don't need, and that turns me off to the rest of it. Smalltalk is different enough to begin with. I don't need extra aggravation.
update Spelling, grammar
It is not only Smalltalk, Lisp had a similar environment,whic was the Genesis of Lisp Machines.
Similarly you had Mesa/Cedar. Think of a similar dynamic environment developed in a system programming language with RC and a GC for cycle collection.
So now we have to reach for IDEs, INotebooks, Playgrounds and similar tools, keep on fighting on the adoption of safe languages for system programming, so that we can catch up with the past.
Unix is also a "dynamic" environment. You can compile and load in new code at runtime. You can inspect running processes. You have access to lots of system parameters via the file system API. And so on.
The C language might be the biggest part of the answer.
Even GNU had a vision of using C as a bootstrapping language for a Lisp environment. That's sort of the reality for heavy Emacs users... but mostly the idea has been abandoned, I guess.
Graphically based, the REPL uses the whole OS, developer culture embraced the debugger.
> Unix is also a "dynamic" environment. You can compile and load in new code at runtime. You can inspect running processes. You have access to lots of system parameters via the file system API. And so on.
It just looks similar in the surface, but when one used such a system it is quite poor.
My experience boils down to Oberon, which was Niklaus Wirth version of Mesa/Cedar.
Smaltalk Works, which allowed me to have a glipse of the original Smalltalk.
The way Powershell, .NET, COM and DLLs work together on Windows (even though it is still lacking).
My own research into Xerox PARC systems, as I keep hunting those papers.
So with all of this, what do I mean by only being similar on the surface?
Yes, UNIX CLI experience provides a way to work interactively, pipe data between programs, have them communicate between them (if one makes use of IPC) and a few other things.
Note that not all UNIX have something like /proc.
However it is all text based, even the UI.
The Xerox PARC systems were graphical, the REPL was graphical and could use inline data, think IPython/Playgrounds.
The OS and the REPL being the same language meant that the whole OS was available in the REPL. Since one was running as root on those workstations, you could literal control everything from the REPL.
Like find window X, select text, convert to bold, for example.
Having the same language also meant accessing any OS library was just an import away, no extra steps required.
Imagine having a graphical CLI, where you can write e.g. soname.func(a, b) without extra effort and doing FP data manipulation.
Actually there is a Xerox PARC paper where they research UNIX as dynamic programming environment.
https://archive.org/details/bitsavers_xeroxparctXNeedsATrueI...
Have been doing web, server and native since ever, depending on the employer or customer project, never liked the impedance mismatch between HTML, CSS and JavaScript.
The real reason was that Unix (which is written in C) runs way more efficiently on legacy hardware, orders of magnitudes faster than Smalltalk and Lisp, even on special Lisp hardware. Performance was really an issue in those days.
If Lisp and Smalltalk would have had modern PC power at their time then things likely would be very different today.
However, from those days I have in memory that the price difference between workstations wasn't that big. Maybe I don't recall that well.
Also JIT compiler research goes back to ways to improve Smalltalk.
The C99 specification is much more interesting than the K&R C of yore. And it still gives the programmer a close mapping between language and target hardware platform.
Pharo is super-awesome to work with and play in. However I won't be writing large simulations or ray tracing rendering systems in it any time soon. I'll have to wait another couple of decades before that becomes feasible.
Fortunately the FFI API in Pharo let you hook into C code fairly easily.
Modern Lisps, at least, are fast enough, albeit not often as fast as or faster than C.
However with CL and most of the popular "modern lisps" you're still stuck with allocating everything on the heap and having to compile in a GC into your image along with the rest of the ball of mud. You can get pretty fast code at run-time if you're mindful and precise... but it's still pretty hard to debug... and of course, incurs an overhead.
"Well we have the processor cycles now to make it feasible!"
Well... just barely. We tend to think people don't mind waiting thirty seconds for our browsers to load or seeing the beachball-of-doom when working on a large document... but I think that's pretty wrong.
What I am missing here in regards to the likes of Allegro Common Lisp, for example?
Never used them, hence the question.
uint32_t flags[100];
(defun form ()
(let ((xs (make-array 100 :element-type :unsigned-int)))
(declare (dynamic-extent xs)
...)))
I hope I didn't give the impression that lists were the only data-structure in CL; I use structs, arrays, and macros to manage structs-of-arrays, etc. Plenty more of course.
I do prefer to use CL but I end up spending more time in C/Python for reasons.
What I find interesting in lisp land are lisps that don't try to take over the whole system and whose principle design is to be small and fast. C has a large run-time library but you can compile programs without it if you're willing to write your own stuff. You don't have such control in the open source implementations I've used.
The open source CL implementations, afaik, still lack tree shakers to try and remove unused code from the image prologue before running the top-level. SBCL still produces a 25MB binary to print "Hello, world!" to the console... because you still have to compile in a GC, the entire CL library, the implementation's run-time, etc -- even if your code never uses it.
In any larger application you have to know your compiler and the special libraries well. GCC, CLANG, whatever...
SBCL is kind of large. Other open source Common Lisps create smaller applications: CLisp, CCL, ECL, ...
Some thought there was a use for delivery Common Lisp with or without GC. But it has not caught on widely. See for example Thinlisp, CLICC, mocl (derived from CLICC) and others. Those have compilers written in Common Lisp, which translated the code to static C. In case of Thinlisp without GC - its origin is in soft-realtime expert systems for process control. Thinlisp is probably not much used, but a related compiler (not publicly available) is still used for product development.
There were and still are inhouse delivery compilers.
Also specialized languages: You develop in a Common Lisp environment, but write in a special language. SubL, Stella, ... For example Cyc is written on top of SubL, which is derived from Common Lisp (and can be used inside Common Lisp) and the Cyc application then can run on top of C or Java.
When I write, 'modern Lisp' I mean 'modern implementation of Common Lisp,' since there is no Lisp but Common Lisp, and Kent Pitman is its editor:-)
SBCL, at least, provides some support for stack allocation, and I'd be surprised if Allegro and LispWorks don't.
Like I wrote, modern Lisps tend to be fast enough, albeit not as fast as would be perfect.
Then there's the obligatory mention of this guy who took it to the next level http://www.howardism.org/Technical/Emacs/new-window-manager....
Plan9 + ACME had an interesting 'editor/OS' integration, especially for the time, where you could highlight text, invoke a mouse click action, which would send it to a shell, and return the result on a new-line within your editor. Having everything exist as a file with an addressable file descriptor really made the platform powerful (too bad the licensing was horrible until recently). It's not homoiconic as a proper LISP-1 would be but still an interesting approach.
Here is an example:
https://youtu.be/rhN35bGvM8c?t=5998
This is notch (the creator of Minecraft) coding a game live for several hours. Notice that the game is constantly running in the background for the entire duration of the cast and it updates as soon as notch changes the code.
This is done with Eclipse and Java.
Which is fairly dynamic language itself... Try doing this with C - mybe with enough GDB-fu, but I'm not convinced.
I think you confused dynamic languages with dynamically typed ones.
By "dynamic", I meant "dynamically typed language". Java is certainly statically typed while Smalltalk is dynamically typed.
What's your definition of "dynamic" that makes you say Java is?
> Most dynamic languages are also dynamically typed, but not all are.
The concepts (both "dynamic language" and "dynamic typing") are not very precise, but, in general, a language may be called dynamic if it has eval, dynamic dispatch with something like "method_missing" or reflection (and this is what Java has).
Yeah, that's what I meant, sorry for the confusion.
> yet you are probably the first person I ever heard call Java "dynamic"
https://en.wikipedia.org/wiki/Dynamic_programming_language - see the "Examples" section.
As I said, "static" and "dynamic" concepts are not well-defined, and they're not binary, either. Most languages have some static and some dynamic components; some are closer to dynamic, and some closer to static end of the spectrum. Java sits somewhere in the middle, a bit more to the static side. It's much more dynamic than Haskell, and quite a bit more dynamic than C++ for example. On the other hand, if you compare it with Smalltalk, Self, Lua, Io and many other usual suspects it indeed looks static like a rock.