[goatlover]

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.

[buzzybee]

I believe Red[0] is closest along to practically realizing this concept by focusing on compositions of small languages, a premise Alan Kay also worked on with the STEPS project at VPRI[1].

The main thing that stops people from beelining down this path is the sheer quantity of yak-shaving involved. We're all impatient and have near-term goals, and glue-and-iterate gets us there without having to engage in a non-linear deconstruction and analysis of what's going on.

[0] http://www.red-lang.org/ [1] http://www.vpri.org/html/writings.php

[jnordwick]

Trying to find a short REAL Red example (not Hello World or here's how to show an alert), and I can't seem to find one. Can you help me out? Something that would help me understand what the language is like.

[throwaway7645]

The concept of Red is heavily based off of Carl Sassenrath's Rebol, only Red is both very high level and fully capable of low level programming as well. Rebol can show you the high level things possible with Red. It truly is amazing. Even though its kind of old now, I installed Rebol recently and was blown away by how much power I got with no installation. Red will be much the same and allow you to make miniscule native binaries.

[jk4930]

Look at Rebol 2 docs. Or try this (enough for me to get started): http://redprogramming.com/Getting%20Started.html

[oofoe]

Check out the REBOL examples on Rosetta code. I'm very fond of the "percent of image difference" one -- it's not large, but shows off some of the nice features like image handling and the fantastic REBOL GUI dialect. (Yes, I wrote it...)

[rjeli]

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)

[505]

(I am pleased you brought up Stephen W, and also that you asked us not to. That's all you'll get from me.)

[hardlianotion]

I would have called him the W-ster and respect parent's wishes

[TeMPOraL]

> (please, no one mention stephen)

Why? Does he come to every place that mentions his name, like that AI guy?

[rjeli]

Because any HN discussion that mentions the W-word will inevitably devolve into discussion of the controversial man

[stcredzero]

If you could marry up the advantages of text/files

Is that really such an advantage? What kind of advantage does having source code scattered in files have over Smalltalk's Change Log? The Change Log greatly simplifies having live code, and having a runtime environment where you could crash the system with a runtime change. Source code in text files complicates this. It's also a powerful development tool all by itself. What's more, it's just a clever use of a text file!

[goatlover]

I mean in being able to generate source code as text files at any point, or update from text files, since that's what programmers are used to, and there are so much of the tooling is built around that. You're not going to be putting an image on github.

[stcredzero]

I mean in being able to generate source code as text files at any point, or update from text files

It has been done many times. There was a Camp Smalltalk initiative to standardize such a mechanism back in the early 2000's. Anyone could code something up that does this for a particular dialect in a matter of minutes.

[Qwertious]

The way I see it, plaintext's advantage is much like the iPhone's stylus-less touchscreen - it's much more direct, and people deal with it much more intuitively as a result. Although I'm starting to think that it's more about not coupling the program and data file, and providing documentation (a comment-less plaintext XML file is often not much more useful than a binary file).

[derefr]

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."

[jacquesm]

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 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.

[derefr]

> Erlang lives mostly in text terminals.

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.

[jacquesm]

After long searching I've settled on python for hardware control, number crunching and ML stuff (it's really just wrappers around C libraries and GPU kernels) and Erlang for everything else. So far no regrets. I wasn't aware of that software, thank you for the pointer!

[jfoutz]

I've never used it seriously, but the bit pattern pattern constructs look really sweet. I don't write a lot of protocol code anymore. But I remember doing parsing badly on 10-100 bytes to figure out what a message meant. Websocket stuff would get a lot of help from that syntax.

[defined]

> your software is very likely a daemon on a headless server/cloud somewhere

This is true of every Erlang system I have developed, so, I concur.

[goatlover]

Then this could work for Elixir as well, which seems to be a little more approachable for the majority of programmers.

[defined]

I dispute that Erlang has a huge barrier to entry. Although there is a larger barrier than for, say, Python or Ruby, I feel that Erlang gets an undeservedly bad rap, especially given the ROI.

I am no genius, but I was able circa 2008 to develop a significant production system in Erlang, while learning Erlang on the job over a period of 3-4 months. I had never programmed in a functional language before (C++ was my forte). In 2008, the tooling and environment surrounding Erlang was far less supportive than it is today, so the barrier now should be lower.

If you want to talk about a huge barrier to entry (for me, anyway), it's the Great Wall of Haskell. I found it a great deal harder to learn Haskell. I have only written one small utility in it and still don't claim to know the language. And that's after using Erlang for many years.

Also, these days, Elixir is reputed to lower whatever barrier to entry there is for Erlang.

[hvidgaard]

Haskell is less about the "language" and more about the mindset. You simply have to program in a very different way, and that is hard to rewire your brain to do this. Once you learn Haskell, you will program different in other languages as well, simply because you think differently.

[gkya]

> circa 2008 to develop a significant production system in Erlang

Is that whatsapp by any chance? ;)

[defined]

Not nearly that significant! I wish!

[erikj]

As far as I know, Bret Victor is looking exactly into that, check out his talk "The Future of Programming": https://www.youtube.com/watch?v=IGMiCo2Ntsc

[noir_lord]

Check out https://en.wikipedia.org/wiki/Oberon_(operating_system)

It never caught on but it was an interesting path not taken in terms of what an operating system could be.

[billsix]

Open croquet http://www.opencobalt.net/