Comment by jasim | Hacker News Reader

Comment by jasim | Hacker News Reader

Parent Full thread

This strikes a nerve.

I had the good fortune to be able to work with xBase languages (predominantly CA-Clipper) when I began programming. I made software for retail outlets: pos, inventory, accounts, all the jazz. The most memorable thing to me was the Phone Directory we shipped with it. It did one thing right: `set filter to cSearch $ upper( rtrim( ltrim( name + phone ) ) )`. This is a case-insensitive regex match over both name and phone. Customers used it all the time, and they held that db close to their hearts. It was 50 lines of code written in an afternoon and just worked ever after.

Creating a phone directory with that affordance is a lot of work today. However user interfaces are different today. 80s DOS text mode only had a keyboard input, a 16-color palette, 80 columns over 25 rows, and just text, text, text. Modern web UI is event-driven, has millions of colors, works across screen sizes, and is networked by default.

Though with this essential complexity, there is so much accidental complexity. It shouldn't be this hard to build software. The essence of a double-entry bookkeeping software 30 years ago is the same as one we build today. A new framework is probably not the answer. New languages (or old giants) and formal systems might be. Ballerina, Unison, Dark, Ur/Web, Elm, Reason and so on.

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?)

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.

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

There is also the point of familiarity. Those old cli apps were hard to learn but crazy fast. I recall much grumbling about replacing good, but hard to use tools with web pages back in the 90s. If someone spends a decade getting good at a system, they really hate it when the ui/ux changes. I think we’re a little quick to throw out crufty but well understood systems.

It also seems like most modern UX theory values discoverability and ease-of-first-time-use far more than ergonomics for everyday users. At my work the UX/design team often evaluate new features by putting people in front of them without telling them anything and expecting them to work everything out on their own (often while they're being watched). A lot of our product is something that our customers interact with many times per day, yet we don't spend 1% the time optimizing workflows for the people who know what's going on compared to what we do for first time users.

I keep regularly pointing out at work that the platform I'm building is basically dBase III+, with the form designer etc. There are improvements, of course - the networking etc. But at the core we're building a platform to let our internal users quickly build new forms and capture data that's pretty much about doing what the dBase form designer etc. did.

It's crazy to me that even the tools that are trying to capture this space today have not managed to beat the usability of that.

E.g. tools like Airtable are great as long as you're trying to do something simple, but then you hit their limits, and suddenly the step up in complexity to do what you need is too large. Whereas with tools like dBase you could start with "just" a database with the default entry, and the steps up to gradually build up to a full application were small in comparison.

It pains me a lot of the time to see people basically try to reinvent tools we had in the 80's and do it poorly because they're just not aware of the lessons of those systems.

Reply on news.ycombinator.com