Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My 1992 view of the problems of computer programming in 1992

blog.plover.com

Post reply on HN
Print view View original

41–50 of 56 posts

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

#41

Post by GolDDranks »

miyoji wrote: 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 programs or programmers but for more money.

But, at least, the tools are way better than in 1992, and I think we, as a collective profession, have learned a thing or two.

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

#42

Post by mackeye »

KptMarchewa wrote: post #5

The definition of "passable compiler" in 1992 must have been very different from what it is today; while third year students write interpreters and compilers, nobody would call them useful or passable.

for advanced undergrads, the university of michigan (i'm speaking from my own experience here) has a course progression of (1) programming languages for 1st year grad students, (2) compilers for undergraduates, (3) compiler optimization for 1st year grad students. the expectation is that you can write a fast implementation of a simple language (~scheme) on your own, and you have the knowledge to write a simple optimizing compiler for e.g. c89/99 if you were to take it on as a longer project. any compiler written in a semester probably doesn't have enough manpower to be optimized to a point of usefulness, and you'll learn some things only via implementation struggles, but you'll have the capability to try, search for literature to get unstuck, etc. which is cool!

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

#43

Post by ozim »

miyoji wrote: 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.

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

#44

Post by anthk »

GolDDranks wrote: post #41
miyoji wrote: 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…

We had memory safe languages before 1992.

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

#45

Post by ch_123 »

epc wrote: post #16
ch_123 wrote: post #12

I agree with the overall point of the article, but I feel compelled to be _that guy_ and point out that most of IBM's systems programming involved various dialects of PL/I, not Fortran, and they went through a bunch of different iterations on those compilers and their code generators.

Was going to make a similar comment…most systems programming was in PL/S or PL/X on 370/390 architecture (regardless of the O/S). AIX and OS/2 were mostly in C. AS/400 in RPG. There were some oddball programs in APL. And thousands of internal "tools" in Rexx.

> AS/400 in RPG

Aside from a few utilities, relatively little of OS/400 was written in RPG. Originally, most of it was written in two different dialects of PL/I. Some Modula-2 was added into the mix, and most of the lower levels were rewritten in C++ when they switched to PPC processors.

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

#46

Post by KptMarchewa »

mackeye wrote: post #42
KptMarchewa wrote: post #5

The definition of "passable compiler" in 1992 must have been very different from what it is today; while third year students write interpreters and compilers, nobody would call them useful or passable.

for advanced undergrads, the university of michigan (i'm speaking from my own experience here) has a course progression of (1) programming languages for 1st year grad students, (2) compilers for undergraduates, (3) compiler optimization for 1st year grad students. the expectation is that you can write a fast implementation of a simple language (~scheme) on your own, and you have the knowledge to write a simple optimi…

Very similar at University of Warsaw, at least couple of years ago.

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

#47

Post by GolDDranks »

anthk wrote: post #44
GolDDranks wrote: post #41

Earlier quoted context omitted.

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…

We had memory safe languages before 1992.

Indeed, I realized I had my timeline a bit off after posting that. Of course, we have Lisp ca. 1960. (Pascal appeared 1970, but I don't think that's widely considered memory-safe. ML 1973, and that never got a widespread industry use.)

What I mean is: we had memory safe system-implementation languages in wide spread production use only after/around the times of the publication of that memo; importantly, Java.

We had memory-safe experimental programming languages, and scripting languages before that. And of course, around those times, hardware was fast enough that you could start implementing systems with scripting languages (Perl, Python, Ruby, JavaScript)

And the bit I want to correct is, of course, the point is if they are actually used. In that sense, I'd correct the introduction of Rust around 2023-2026 in actual, wide-spread use.

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

#48

Post by Shellban »

IAmBroom wrote: post #19
Jtsummers wrote: post #9

Earlier quoted context omitted.

This submission was made two days earlier than the one you linked to, it just came back through the second chance pool. Not a dupe.

Both are duplicates of each other. One was submitted earlier. The other reached the front page earlier.

[dead]

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

#49

Post by lnrd »

dwoldrich wrote: post #32

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?

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

#50

Post by shakna »

IAmBroom wrote: post #18
shakna wrote: post #6

Fortran H was faster than the fastest punchcard feeder of the time. That bottleneck is unfortunately long gone, without the same magnitude of improvement on the other side. (Physical limits, amazing optimisations, etc.) Last time I was working with CCE, I was looking at blistering runtime speeds, but six or seven hour compiles. Huge codebase (40mil+ LoC), and the optimisations were great, but not exactly a fantastic…

> That bottleneck is unfortunately long gone ? You are pro-bottleneck?

I'm disappointed it disappeared without the other side of the equation showing the same scale of improvement. Understandable reasons why it didn't happen, but disappointing.
Post reply on HN