This reminded me of a tool that my college professor created many years ago called The World of the Actors [1]. He used in his class to teach Smalltalk and OOP.
I can't seem to be able to find the source, though.
Not just eyes, shit computer and phone screens. The worst screens have half the colors and a quarter the brightness (and relative contrast) of the best.
I'm actually having trouble with the contrast as well.
But I don't think the colours them selves are absolutely unusable together, I think the combination of the colours and the font weight/size is really the issue (although that could be less the case on a retina screen).
It also doesn't help that I'm viewing it on a older monitor with poor colour control (particularly with contrast).
If only there were any technology available to you, a software developer, that could render that text in a different color. Alas, your genuine desire to read it must go unfulfilled.
I mistrust a list that rates C++ as more concise than Common Lisp (in which one can create domain-specific languages), and Visual C++ as somehow 50% more concise than both.
>Smalltalk would score very low compared to today's languages.
Citation needed. Why would it "score very low compared to today's languages"? At best "today's languages" caught up with some things Smalltalk offered, but they still don't have the base model so succint and flexible, so it's just piles of sugar on top of algol.
Nice to see some Smalltalk examples although I'm heavily biased to terminal languages like Awk, Perl, and Python, I'd rather see something more like Pharo which I think makes more sense in the ST world. I hear a lot about the joys of ST, but Id like to see some short coding sessions to get the idea. Most demos I see are either "let's look at all the goodies like class inspector, debugger...etc", or "let's look at this example where I can't follow along as we're like 9 classes deep".
One problem GNU Smalltalk addresses for me is "getting started" because it mostly takes tooling out of the equation. Mostly because my experience was of normal install a new programming language and integrate it with my current tools hiccups. But there was not an entire alien landscape filled with many overlapping windows as with Pharo or Squeak. I can focus on learning the language and its semantics without orthogonal cognitive loads. I think this helps me more readily achieve flow.
Part of what made a sustained attempt at learning Smalltalk difficult for me was that traditional Smalltalk IDE's did not allow me to approach Smalltalk as just another programming language living in the same Turing tarpit as Awk or Perl or Python. Smalltalk IDE's make a set of design decisions that embody a particular philosophy regarding the "best way to use a computer" rather than "here is another way to use a computer." They are not the best way for me to use one.
That is, of course, by design. To me (I have been a professional Smalltalk for a while), GNU Smalltalk drops the essence of a traditional Smalltalk environment and while I was "hmm, interesting, maybe if I ever have a use for it I'll look at it", I never needed it. A Smalltalk IDE is an extremely powerful fool, and IMHO the most powerful tool we've invented so far. Having said that - I do think that Pharo and friends maybe should be more friendly to what I as a developer expect today from my tools: mostly keyboard-driven, no overlapping windows, etcetera.
I think there are two separate design issues. One is the architecture of the Smalltalk development environment in terms of displaying information about classes and objects and lists of related methods and the running system and so on. That's great and and powerful and entirely orthogonal to the WIMP interface and the particulars of the screen presentation.
I agree with you. This is a nice project but deeply interactive programming environments are the heart and soul of Smalltalk programming. Installing Pharo, and as you suggest following the interactive profStef tutorial is a good beginning.
I don't disagree that traditional Smalltalk programming environments offer some significant advantages. For me, they do not come along for free. The price is analogous to if Python could only be written using Vim or JavaScript in Sublime Text or Perl required switching between a driver and navigator every twenty to thirty minutes. In general there is a large degree of orthogonality between editor and language when it comes to ergonomics and cognitive load.
GNU Smalltalk has a default environment: Emacs. Online documentation is available. A REPL is available. Is it better? Depends on what the metric is. For me, it is because I only have to learn one thing: the Smalltalk language. I don't have to learn a new workflow right away. I can continue to use org-mode and babel and literate programming. I don't have to use a mouse. I can tile my windows. I can treat Smalltalk like just another programming language and switch between it and Lisp and Python and Ruby and Javascript and HTML and Bash all without a context switch at the editor level...e.g. I can change buffers and update a Smalltalk git repository with the same mechanism I use to update a Python repository. Sure, it is a tradeoff. And if I was working in a different environment, all the features of the Smalltalk IDE might easily be worth the compromises in exchange for their advantages.
In a way, I find it a bit like using Ruby but with a more formally consistent design philosophy...as one might expect when a language has a formal specification and a corporate pedigree.
Former (10 years or so) maintainer here, nice that someone is still using it.
Unfortunately, the lack of support for modern web APIs (starting from SSL) makes it a dead end for serious applications. But it is still useful to teach OOP in my opinion, the metaclass model strikes the right balance between simplicity and power; the only improvement to it might be traits, which in fact were first prototyped in Smalltalk.
This reminded me of a tool that my college professor created many years ago called The World of the Actors [1]. He used in his class to teach Smalltalk and OOP.
I can't seem to be able to find the source, though.
[1] https://pdfs.semanticscholar.org/4fb7/5b3cb8ef7adb36c0871931...