gokr

You mean COLA etc? Yeah, pretty wild stuff. I admit I couldn't fully grasp it at the time (and most likely not now either!)

https://www.piumarta.com/software/cola/

Perhaps you are aware of who Alan Kay, Bret Victor, Ian etc are, but... anyway, I just wanted to chip in with some context for those who are not aware. Alan Kay led the creation and development of Smalltalk at Xerox PARC, thus creating the first real GUI introducing all the UX elements we today take for granted (windows, buttons etc - yes, the same that Steve Jobs got a demo of), establishing OOP (some would argue Simula was first, but Smalltalk took it 10x further) and much, much more. So his legacy in the world of computing is... legendary I would argue, just google him.

Now, Ian has done truly brilliant VM JIT work in the Smalltalk community and I suspect that Ian did a lot of the DSL related stuff in STEPS, like the TCPIP stack etc.

So this is not just some "random folks" :) and.. some of the most brilliant work comes when you are really not sure where you are going. The original Smalltalk work that gave us OOP and modern GUIs came from Alan's life long task of making computers usable by children in order to amplify education. Most would argue we are still struggling with that task ;) but at least we got a lot of other things out of it!

It all depends if you consider basically all non web GUIs developed the last 40 years or if you limit yourself to reactive web UIs developed the last few years. Tongue in cheek :)

Sure, reactive frameworks in js that mainly operate on the DOM/HTML/CSS stack may be very little OO, but Swift/Dart/Kotlin are OOP languages and Flutter for example, while using a reactive model, is still 100% OOP with Widget classes in a composition and so on.

"hated all around the world" sounds a bit harsh :) Sure, lots of people like "throwing hate" at it, but AFAICT it's mostly "bad use" that gets people riled up like insane deep inheritance or overly complicated frameworks. Also, it seems especially young guns feel cool by claiming FP is superior ;)

AFAIK OOP languages are still ruling the whole GUI space, which is reasonable since GUI was the main driving force behind it (see history of Smalltalk) and the domain is such an obvious candidate for composition of separate independent elements. What languages are primarily used for GUIs today? Java, C#, Swift, ObjC, C++, Dart, Kotlin ... and the list can probably be made much longer.

On the web ... well.

This is kinda funny. I wrote a "rebuttal" article back in 2009:

http://goran.krampe.se/2009/06/26/joe-is-wrong/

...and then I met Joe not long after and we also discussed this in fact. He then told me that he felt my article was fair (!) and that he had *changed his opinion on OO since writing that article*.

IIRC his exact words were something along the lines of "I did not understand OO when I wrote that article". Now... he also argued Erlang is in fact VERY OO, and in some ways he is correct, since its very focused around autonomous "parts" communicating solely via messages.

Finally, I haven't read all 162 comments here - but OO is not "bad" nor "the holy graal". There are different ways of doing programming, and its as simple as that. I can find joy in simple imperative coding as much as I can long for the days I was working in pure OO in Smalltalk. :)

Smalltalk is a family of dialects and implementations. Most of them are indeed compiled to bytecode which is then executed by a JIT VM. Most of them use the "image" concept where you are always in runtime like in a classic Lisp, and yes, the VM handles shape changes etc etc. But some Smalltalks actually have other characteristics, like non JIT or even compiling via C (Smalltalk/X does that I believe).

Hehe!

I have worked extensively with Smalltalk, I know it quite well and it's my favorite language. I made SqueakMap and several other packages for Squeak. Still, it's not as simple as it can/could be, especially not the meta model. Alan Kay himself has the same feelings AFAIK.

They = me. I suppose you did it when Spry was still called Ni?

The general idea was to leverage Nim's capabilities, either as implementing core parts of standard libraries in Nim (which is very easy to do) or possibly by partial compilation using the Nim meta programming mechanisms.

A lot of things including very good development speed, very good debugging capabilities, very good meta programming (making your own tools) etc. Try out Pharo.org for example.

Looking at my inspirations I would (take it with a grain of salt) say that Lisp and Forth are too simple, javascript is a mess (but with nice literal syntax for maps etc), Smalltalk is too complicated and Rebol is basically also a bit complicated and IMHO a bit of an oddball with some neat ideas. And Nim is a totally different beast.

The multiuser stuff etc, I am temporarily too focused on other things so Spry is at "a hold" right now. I would also like to fix more things in the language before proceeding.

The Smalltalk keyword syntax is a simple preprocessing in the parser so that `a at: 3 put: 5` turns into the AST of `a at:put: 3 5`. And yes, it's homoiconic.

Just as a sidenote, there is:

https://github.com/xyz32/boneIO

...and a while back I played too with:

https://github.com/gokr/ardunimo

Nim is quite perfect for these things since it compiles via C/C++ which makes it go anywhere.

I have been wanting to play with wrapping the ESP-IDF for Nim (using the excellent c2nim tool), but ... it appears to be a fairly hefty job. Although I am sure Araq could do it in no time :)

I am not sure how incomprehensible it is, but I can say that the c2nim wrapper tool is pretty darn good. Andreas (author of Nim) quickly wrapped all of Urho3d in Nim almost fully automated. So IMHO Nim is a great companion to C++ libraries.

Well, I agree that the article can annoy some people. But... as an avid Smalltalker with a LOT of experience with it - and a lot of experience with Javascript too (and tons of other languages) - there is a "truth" in here.

Smalltalk is immensely cleaner and gives you IMHO a much deeper more gratifying experience working in it. Yes, it's OO all the way, while Javascript is... well, not sure what to call it these days ;) A hodgepodge perhaps. But the real magic in Smalltalk is in the live environment.

It all boils down to the Right Tool for the Right Job. If you are looking for a really powerful tool for abstraction and working interactively with advanced domain models, often using meta capabilities - then Smalltalk totally rocks. The more advanced, the more it shines.

But of course Smalltalk has its negative sides too, and it depends on your specific use case. It's (if we consider the Cog VM which is the most common one) pretty fast, but comes short of V8. It can interoperate with other languages, but it's not as easy as in some other languages. It has a decent community, but not as large as Javascript/Python/Ruby. And so on.

But when your use case fits - it's really good. So my advice is learn many languages, it will make you a better developer, and its fun!

<promotion>Personally I am trying to evolve Smalltalk by merging it with ideas from Lisp, JavaScript and Rebol: sprylang.org</promotion>

A solid good enough reason is because it's fun!

But in the specific case of Nim - AFAIK there aren't that many languages around with a similar set of characteristics. For me the killer is the combination of GC (I am quite fine with not having to bother with memory management), readability, reasonable high levelness including closures etc, nice OO support, extremely good C and C++ interop and really good performance.

Although I don't know much about Clean and APL - I definitely agree with Forth, Smalltalk and LISP as being very elegant in their own three unique ways.

I am trying to combine aspects of those three in Spry (sprylang.org) creating a homoiconic (LISP), DSL friendly (Forth & Rebol) and natural smooth OO (Smalltalk) language.

But if you are simply looking for an existing well defined language (and not interested in helping creating one) - then I would probably point at CLOS (although I personally love Smalltalk). But... the future? <shamelessplug>Spry :)</shamelessplug>

Hmmm, I find this slightly misleading. It was a long time ago that the original Smalltalk creators were involved in Squeak (Dan Ingalls is the main developer, Alan Kay the visionary).

It should also be mentioned that Squeak (and Pharo too) was and still is VERY close to Smalltalk-80.

The Smalltalk mechanism (Squeak/Pharo) also uses generate and test, just FYI.

Well, when I talk about polymorphism I of course mean the ability in the language to create first class polymorphic constructs. Hardwired things like [1] doesn't count :)

Further, I had read the article [3] and it seems to me that he indeed "rejected" OO in large parts after having worked with Smalltalk. That's quite intriguing (or astounding!) to me - since I agree that most so called OOP languages misses a lot of the story when compared to Smalltalk.

Personally I find polymorphism and encapsulation together with strong abilities of abstraction to be the key aspects of OO and I have never found any language that captures these things better than Smalltalk.

At the same time I also find Rebol's focus on DSLs to be very interesting - and as many may know this was also a big part of Alan Kay's FONC project.

In Spry I want to combine both. In contrast to Carl I embrace the original ideas of OO as manifested in Smalltalk. However, I couldn't care less of a lot of the overcomplicated mess that so called other OOP languages have created since then, and I also think the beauty of Smalltalk can be captured differently, for example without classes.

It's not as evolved yet - but funcs pull in arguments via :x and can instead use :$x (I used ^ earlier, but switched to $) which will pull in that AST node (argument) without evaluating it first at the call site.

So it's a kind of quoting. I haven't pushed these things further yet, and frankly I am not that heavily into macros unless they are really needed. But obviously AST manipulation is easy in Spry.

I should mention that Spry uses all of () []{}. The () are reified as Paren as in Rebol which makes it useful in templating etc. {} are used to create Maps, like {x = 1} creates a Map with one kv pair.

But hardly important :) I may actually end up not needing the distinction, but if so, then I think a good convention on documenting funcs is needed. Well, needed anyway. :)

Spry does not have these builtin either, they are all functions. In fact, even assignment is, which makes Spry even more minimal then Smalltalk in this sense.

I know Smalltalk VERY well, and Spry is trying to experiment. I think polymorphic functions can be just as powerful as a class based model, even more so, and still feel similar. But i need to write examples to show it.

Also, Nim has very promising support for threads, threadpools, async stuff etc etc. And when I rewrite the Spry interpreter to be stackless I hope to be able to use a lot of those things too.

No, Spry is not at that point yet. Or at least I sure hope noone is! :)

What you describe (interesting syntax) is a way to declare argument names and Spry doesn't declare them. That's a discussion in itself of course, but right now it doesn't.

Well, Spry is much more Smalltalk than "only use Smalltalk syntax". But I have an entire article being written on that subject :)

And no, your description of how it works in Smalltalk is wrong - #to:do: is implemented in the receiver (1).

In Spry we are calling an infix function named to:do: and the only real difference to Smalltalk in this case is the fact that the dispatch of to:do: is not polymorphic. But as I described in other comments I am working on polymorphic functions as a way to reach similar abstraction levels.

Hey! Thanks. Not me who put it here on HN though :)

Regarding Nim - IMHO the main big pro is the fact that I can piggy back on the GC, use several of Nim's features (dynamic dispatch using methods for example), target all three of C/C++/js. And finally, I can use the very good C/C++ wrapping capabilities of Nim. As you may know wrapping C++ is ... very hard, but if you let Nim compile via C++ it works great.

I also find Nim very, very nice to work in.

And yeah, I hope Spry will show some interesting results of mixing Rebol/Red ideas with Smalltalk. And I do need to study Rebol/Red more. ;)