[gavinpc]

You know, I also got my (official) start in an xBASE language (FoxPro), and while I am obsessed with the history of inventors like Englebart and his successors, those xBASE environments had more going for them than I tend to remember.

"Ordinary" people could use those tools to make useful things. We seem to have gone backwards from there.

What was different about those systems?

They were integrated usage environments. Batteries included. In FoxPro, you got:

    - built-in database
    - built-in documentation
    - built-in UI for editing data
    - built-in UI for editing schema
    - windowed environment (even in DOS)
    - oh yeah and a scripting language

This was first and foremost a usable environment immediately. "Development" was an advanced usage.

Emacs is this way. Smalltalk is this way. What they get is that programming languages are useless by themselves.

Contrast with now: the apps we build involve wiring together a database from here, a compiler from there, just figuring out how you're going to make pieces communicate and finally, you know, get something on the screen. Sure, there's an upside to composing systems a la carte. But the learning curve is far more prohibitive.

(Also, those xBASE systems just will not die. Just this morning I got an email question about a system that's been in service for 25 years now. How many of today's apps do you think will still be used (indeed, sold!) in 2043?)

[nicklaf]

Check out picolisp. It has a built-in database and can call existing C libraries and Java (using reflection) without any fuss.

Though apparently, it doesn't have lexical closures: https://news.ycombinator.com/item?id=16981170

[pjmlp]

You can still get close to this experience on Android, .NET, Java, Cocoa.

Because as you say, grammar and semantics (aka language) are not enough.

Hence why when I analyse how suitable a programming language is for a given project, I always consider the whole ecosystem, and not how easy it is do FP, immutability or whatever is cool this year.