Hacker News Reader

Comment by xp84 | Hacker News Reader

They actually knew how to code back then. I fancy myself someone who cares about performance and take a great effort to not do wasteful stupidity like those CSS animations for a decorative element, but compared to 80s programmers, I'm actually a complete fraud, because I do everything in interpreted languages that do 10,000 things behind the scenes for every line of code I write. I could never make an Atari computer or NES work.

There are of course a few who do, they all either work on embedded systems or making homebrew for retro computers. So much respect for that level of skill!

View on HN

I aspire to be one who cares about performance, but I would like to address:

"I do everything in interpreted languages that do 10,000 things behind the scenes for every line of code I write."

Is it even possible to create a modern website, or product, without this? How long would the development cycle take, if everything is to be written in C?

I'd wager that replicating a "minimalist styling" for a react-based website with a dozen or so components would take dozens of times longer to produce.

> How long would the development cycle take, if everything is to be written in C?

Once upon a time I worked on a website backed by C. Development times were not appreciably longer.

We had a in-house templating language for generating HTML (also written in C). That implementation got to the complexity point to where even the original devs did not want to touch it to add anything.

But in terms of add a new screen collecting fields x,y,z it was fine. This was a job board, allowing search, applications, saved resumes, bulk opening uploads, i.e. there was some real functionality there.

Interesting.

If this is the case, I do wonder why we do not see more of this.

Were you around for the original design phase? Why was C chosen? Did you and yours collect performance metrics to see if anything meaningful was gained?

I was not around for the original design. Plus this was very early in my career. It was also early web, around the year 2000.

The architecture involved a custom Apache httpd module to handle requests. That most likely drove the decision to use C.

The system was eventually rewritten in Python, after I had moved on.

I'm not aware of any performance metrics.

C on the modern web would terrify me. Devs are bad enough with interpreted languages, I can't imagine most of them using a language with a howitser sided footgun.

Yes we had a couple good issues in there.

In particular I remember one bug where a pointer to a local variable was returned by a function. It worked on our development environment which was apparently more forgiving than our production environment.

Why were they different? Because they were actual servers and the production one was the expensive DEC Alpha while the development server was something less expensive (my memory fails me as to the exact machine).

I didn't mean to suggest it would be practical to do the practical stuff people do today with Java, Ruby, Python etc -- web stuff or "app" stuff -- in say, 6502 assembly, or C. Just that doing a good job of the stuff contemporary to those in those languages (especially the 8-bit era stuff) is a tour de force in programming talent.

Necessity is the mother of invention!

Another way to look at it, is only those who could write very optimized code could get anything meaningful running on those machines. Hence all (?) software from far enough back was optimized down to death.

I'm personally grateful I've never had to wrangle hardware bugs into features and other such hacks one stumbles upon in anecdotes from those eras... even though there is a certain charm to it all.

Reply on news.ycombinator.com