Hacker News new | ask | show | jobs
by js8 2023 days ago
There are more libraries for different things, but in the 90s, there was a quite a bit of commercial RAD application builders, and that went out of favor.

So while it is nontrivial to build a web, or any modern (network-connected) application today with 90s tools, I am not entirely convinced that building an application today is easier than it was in the 90s. If anything, I suspect we build more from scratch, or leveraging existing open-source, rather than use prefabricated and commercial RAD tools (which are, and always were, pretty expensive).

Edit: I guess what I want to say, if you compare writing actual "business logic", it is still about as difficult as it was in the 90s. We can do fancier things by leveraging libraries (sometimes included in the programming languages), but that's it. In fact I even suspect that people in the 90s were more productive in writing actual business logic, because there was less distractions from the fancy technology (such as web). And I have seen 30-40 year old applications that nobody wants to rewrite, because their complexity is so high that it would take a long time, and it's not clear to me it would take shorter time to develop them today than it used to.

2 comments

"I guess what I want to say, if you compare writing actual "business logic", it is still about as difficult as it was in the 90s. We can do fancier things by leveraging libraries (sometimes included in the programming languages), but that's it. In fact I even suspect that people in the 90s were more productive in writing actual business logic, because there was less distractions from the fancy technology (such as web)."

This has been my experience! I'm shocked whenever I need to automate some business process my organization alway starts at ground zero - what should the base technologies languages be? database server? authentication?

Seriously?!?! Why isn't there "workflow as a service" by now?

One simple example that I presented in the other comments: maps. I don't think we ever had (or that it was even possible in a non-networked/poorly networked world) commercial components for maps even remotely close to what services like Google Maps offer.

Similar thing for many tools and services we just take for granted these days (NLP, sentiment analysis, entire game engines, etc.).

The business logic was easier to write in 1990 because the scope was much smaller and the tools much more constrained. But our modern tools are 1000x more powerful, therefore harder to master, true.

I'm seeing that AutoRoute, which eventually became the basis of Microsoft Streets and Trips was first released in 1988.

It certainly didn't have real time traffic, and probably didn't have lane configuration information, or comprehensive business information, etc. But (from descriptions, not personal experience), it showed maps and did routing.

More complex mapping tasks are readily achievable now because more information is computerized and the demand is there, and the portable computing machinery to make it most useful is there.

> One simple example that I presented in the other comments: maps. I don't think we ever had (or that it was even possible in a non-networked/poorly networked world) commercial components for maps even remotely close to what services like Google Maps offer.

Maps are inherently nothing new, instead of a google search, I'd go to my local library and buy a physical map. No need for 3D rendered vector processing over an interconnected network.