Live data from Hacker News

My 1992 view of the problems of computer programming in 1992

blog.plover.com

51–56 of 56 posts

Re: My 1992 view of the problems of computer programming in 1992

#51
post #43
post #31

> Computer programming is still a black art. It's less than fifty years old, and nobody is very good at it yet. We can make better tools than we know how to use. I don't think this has changed much at all since 1992. Now you can say that it's less than 90 years old, and nobody is very good at it yet. And most of our profession has already given up on getting any better at it because a machine can spit out code that c…

It sounds like excuses I hear from junior devs that don’t want to take time to learn existing frameworks and systems. Juniors just label anything that requires putting effort to understand as „bad”. There was insane growth in junior dev numbers last 3 decades. It is not like „no one knows”, it is more like there is much more people who don’t know.

Even the best programmers in the world write a lot of bugs. Yes, there's a spectrum, but on the whole we're not particularly good at writing code as a species. We still do it though because it turns out that even buggy code can be useful.

Compared to building basically anything else in the world, we genuinely are pretty bad collectively at building software. Even the smart seniors.

Re: My 1992 view of the problems of computer programming in 1992

#52
post #51
post #43

Earlier quoted context omitted.

It sounds like excuses I hear from junior devs that don’t want to take time to learn existing frameworks and systems. Juniors just label anything that requires putting effort to understand as „bad”. There was insane growth in junior dev numbers last 3 decades. It is not like „no one knows”, it is more like there is much more people who don’t know.

Even the best programmers in the world write a lot of bugs. Yes, there's a spectrum, but on the whole we're not particularly good at writing code as a species. We still do it though because it turns out that even buggy code can be useful. Compared to building basically anything else in the world, we genuinely are pretty bad collectively at building software. Even the smart seniors.

You have any stats on that or just the feeling?

I find that a lot of flaws are ignored in for example physical structures because they don’t even know. Take construction inspector and walk with him through five buildings. Let me know if he left any building without pointing out any flaws.

Doctors, a lot of stuff is „let’s try this and see how if it gets better”.

Taking complexity of software and limited budget - we as industry are much much better in building anything. We have better tools and better practices.

Business people are mostly running around like chickens without head, can’t even bother to learn how to use Excel properly.

We have GIT, whole testing approach from unit to integration, team organization etc.

Most of the world runs on software as is now and it works and there is much more software in the world than any other structures we built as a species.

Bonus watching material:

https://www.youtube.com/watch?v=RhdlBHHimeM

Re: My 1992 view of the problems of computer programming in 1992

#53
post #31

> Computer programming is still a black art. It's less than fifty years old, and nobody is very good at it yet. We can make better tools than we know how to use. I don't think this has changed much at all since 1992. Now you can say that it's less than 90 years old, and nobody is very good at it yet. And most of our profession has already given up on getting any better at it because a machine can spit out code that c…

I disagree. I think that after 1992, we got memory safe languages that brought a meaningful improvement to the status quo. And after 2015, we've got low-level memory safe languages (Rust, as the major example. There are others, more experimental.) The average programmer doesn't get better – if anything, we might be getting worse, because the tools allow us to, and the capitalist reality doesn't optimize for great pro…

I agree that there has been progress, but if you look at really mature fields and look at the transformations they've been through and the level of understanding that the highest level practitioners have, and compare it to computer programming... I think we were at maybe 2-3% in 1992 and we're maybe up to 7-9% now?

We're still in the alchemy stages. Real masters can do nuclear chemistry.

Another way to look at it: there have been a lot of arguments on this website about whether or not LLMs are conscious. I think they obviously aren't, but I don't think there's anything special about human brains vs computer chips that means that conscious computers is impossible.

I think a "very good" computer programmer should be able to program consciousness. Not program something like an LLM that trains itself into consciousness, the actual process itself.

We are nowhere close.

Re: My 1992 view of the problems of computer programming in 1992

#54
post #31

> Computer programming is still a black art. It's less than fifty years old, and nobody is very good at it yet. We can make better tools than we know how to use. I don't think this has changed much at all since 1992. Now you can say that it's less than 90 years old, and nobody is very good at it yet. And most of our profession has already given up on getting any better at it because a machine can spit out code that c…

One of the reasons I was so interesting to find this thing I had written was that things had (in some ways) changed so little in thirty years.

Today I was re-reading Donald Knuth's 1974 paper “Structured Programming with go to Statements” where he says:

“At the present time I think we are on the verge of discovering at last what program- ming languages should really be like. … My dream is that by 1984 we will see a consensus developing for a really good programming language (or, more likely, a coherent family of languages).”

Hoo boy, was he ever wrong.

Re: My 1992 view of the problems of computer programming in 1992

#55
post #15

How did we get so much better at writing compilers? Was it a better understanding of how to make syntax trees with ADTs etc?

I think significant improvements are - not writing compilers in assembly - not requiring overlays - knowing how previous compilers produced fast code (Web search doesn’t give me conclusive answers, but that Fortran compiler may have been the first to do loop unrolling and common subexpression elimination) - having way more memory, CPU and disk available - possibly: spending less time looking at optimizations. I expec…

I think you left out an important technical advance: A theory of parsing was developed, parsing was systematized, and automatic parser generators were developed.

Parsing in 1992 was very much a solved problem. In 1974, writing a parser was still hard.

Re: My 1992 view of the problems of computer programming in 1992

#56
post #49

AI propaganda crew hasn't rolled on yet today; not seeing the "it's different now, code is cheap/free with AI" messaging yet. 80% of the cost is maintenance, and all software dies so there will always be work to do.

> and all software dies Can you elaborate?

That is to say that (practically) all software has a finite utility timeframe. So it's a lot like an organism in that way in that it 'dies' when it is no longer useful.
Post reply on HN