Random Thread

[Raphael]

Unrelated: looking at a news website, a few minutes ago, I saw a photo where, at first, I could only see a bright glow against a dark background, so, at first, I assumed that it was about street riots or political unrest at night somewhere, or perhaps about a war or civil war. Then I looked closer at the photo and the headline it accompanied, and discovered that it showed a steel worker at work, and was there to illustrate a report about something related to the steel industry.

[alice]

Also note, I'm an architect at heart. If your codebase is such that it will be improved by the latest fad, it is probably poorly architected. Programmers are always interested in tools that turn design into scutwork, and then tools to automate the scutwork. An architect looks at ways to eliminate the scutwork.

(Excuse the rambling nature of this; it's late on Sunday night and I should be in bed. )

That's an interesting remark; it seems to suggest that there are Universal Language-Independent Principles Of Software Design which no advances in language features and processing power can affect in any way, or more cynically, "we don't need better and more powerful programming languages, just better designers". If your codebase is written in C in the best possible way, and someone notices that this new thing called C++ contains many features which would make the codebase a lot tougher and more durable, shouldn't you at least recognise that the new features enable a different and better approach than those hitherto known about?

[Man in Space]

I'm an architect at heart.

Duplex Construction Kit when?

[Raphael]

I'm an architect at heart.

Duplex Construction Kit when?

Would that be a book, or a physical collection of building tools?

[Man in Space]

I'm an architect at heart.

Duplex Construction Kit when?

Would that be a book, or a physical collection of building tools?

Yes. Materials too.

[Travis B.]

Also note, I'm an architect at heart. If your codebase is such that it will be improved by the latest fad, it is probably poorly architected. Programmers are always interested in tools that turn design into scutwork, and then tools to automate the scutwork. An architect looks at ways to eliminate the scutwork.

(Excuse the rambling nature of this; it's late on Sunday night and I should be in bed. )

That's an interesting remark; it seems to suggest that there are Universal Language-Independent Principles Of Software Design which no advances in language features and processing power can affect in any way, or more cynically, "we don't need better and more powerful programming languages, just better designers". If your codebase is written in C in the best possible way, and someone notices that this new thing called C++ contains many features which would make the codebase a lot tougher and more durable, shouldn't you at least recognise that the new features enable a different and better approach than those hitherto known about?

The thing though is that many computing fads have not amounted to fundamental changes that improve software development. Take C++ vis-à-vis C for instance -- C++ in the end is really just syntactic sugar for things that can be done just as well in C. It is not the paradigmatic change that, say, Haskell is with regard to C. Even Forth versus C is more of a paradigmatic change as Forth permits highly extensible interactive programming in a way that C does not.

[Lērisama]

If your codebase is written in C in the best possible way, and someone notices that this new thing called C++ contains many features which would make the codebase a lot tougher and more durable, shouldn't you at least recognise that the new features enable a different and better approach than those hitherto known about?

What is a good programming language feature but one that makes good code architecture easier/more readible/more performant etc.?

[zompist]

Also note, I'm an architect at heart. If your codebase is such that it will be improved by the latest fad, it is probably poorly architected. Programmers are always interested in tools that turn design into scutwork, and then tools to automate the scutwork. An architect looks at ways to eliminate the scutwork.

That's an interesting remark; it seems to suggest that there are Universal Language-Independent Principles Of Software Design which no
advances in language features and processing power can affect in any way,

Kind of— I certainly believe a good programmer can easily learn a new language; also that anything you can apply in a few days and learn pretty well in a month is not likely to dramatically improve your code. If you can't do system architecture— taking sometimes vague desires and requirements and turning them into a solid, tested, maintainable program— then changing languages will not help you. (Generic you, of course.)

I'll give an example. One basic task is to create a dialog box, following the expected UI. Handling of numeric fields and range checks etc. should be uniform. This occurs over and over in the program.

• The beginning programmer just writes code for each dialog, cutting and pasting most of it.
• The more experienced programmer writes functions for common sub-tasks, like validating input.
• The architect thinks about a single function that can take a table of parameters and put up the dialog.

All of these can work. But next year you have to sell the program in Europe (where the decimal point is a comma) or it's noticed that the dropdown menus don't work for users who don't have a mouse, or whatever. Option 1 requires changing and retesting the code for every single dialog box. Option 2 may or may not, depends on whether the functions cover the new features (answer: probably not). Option 3 should be easy to update as all dialogs work using the same code.

The problem with cut-and-paste coding is not what features the programming language has.

(I have to add: there are terrible architects and you have to have good taste and realism in what you abstract and how the information flow works. Horror stories available on request.)

or more cynically, "we don't need better and more powerful programming languages, just better designers". If your codebase is written in C in the best possible way, and someone notices that this new thing called C++ contains many features which would make the codebase a lot tougher and more durable, shouldn't you at least recognise that the new features enable a different and better approach than those hitherto known about?

Like every other nerd, I have opinions on languages. I like C# far more than C. I used to prefer Pascal to C, but few people agreed. Also: the real benefit (or drawback) to a language is probably what packages come with.

But people's enthusiasm for a language can obscure their judgment. 50 years after The Mythical Man-Month was published, people still fall for the second-system effect. E.g. at SPSS we had about a million lines of statistical code, all written in FORTRAN. Naturally newer coders wanted to redo it all in C.

Bad idea. Whatever horrible things you have in your product, it is working code. In fact the horrible things are often workarounds to bugs or contingencies that the junior developer never heard of. And statistical software cannot be, y'know, 90% right. At that time the company needed a Windows version pronto, it did not have two years to rewrite the code base to do the exact same thing it did already.

(If I recall, the eventual, sensible solution was to rewrite the routines one at a time. If I recall right, this was done by the statisticians themselves, not by the regular devs.)

[zompist]

(Maybe after the Trump administration degrades food quality enough, we'll have no choice but to use AI just to keep society running.)

We may all die from climate change, but at least it'll be sunny!!1!

[Ares Land]

I'm kind of surprised it was so different in Germany. I didn't feel lucky with my career-- I graduated in a recession, got burned by several mergers, and didn't luck out with a startup-to-sale payout. I have a CS degree, but many of my colleagues didn't; it felt you could get into the field from anywhere. But it was generally well paid and, in the early years, fun.

Probably a question of timing -- I graduated in 2006 and was really lucky; at the time IT professionals were in high demand while comparatively few students took CS degrees anymore.
Almost all my friends with STEM degrees ended up working in IT in one way or another.

Oh, let's see... object-oriented programming, XML, Agile, blockchain, AI. Mini-fads like: we used to use C now we use C++ now we use Java now we use Java Beans now we use C#. I don't even know the latest programming languages much less the frameworks.

Things are somehow more stable these days I think. Technological stacks revole around Java/Spring or C# or PHP/Symfony, and I think it's been these three for at least ten years.
Similarly frontend will use some godawful Javascript framework.
XML still comes up sometimes but mostly it's or JSON or YAML now.
Agile, and specifically Scrum looks like it's here to stay.

The last fads I remember were the metaverse, Kubernetes, blockchain and, oh god yes, AI.

Of course AI is supposed to be the next big thing for quite a few years now. My feeling is that it's kind of underwhelming. I've worked on a couple AI projects, but it hasn't really changed much about the way I work.

One important thing to note is that bubbles don't really burst anymore. That sort of thing happened in the comparatively saner days of 2001. Now, I mean, crypto is as high as ever, housing prices are still insanely high. I expect AI companies to keep on being valued insanely high.

[alice]

Also note, I'm an architect at heart. If your codebase is such that it will be improved by the latest fad, it is probably poorly architected. Programmers are always interested in tools that turn design into scutwork, and then tools to automate the scutwork. An architect looks at ways to eliminate the scutwork.

That's an interesting remark; it seems to suggest that there are Universal Language-Independent Principles Of Software Design which no
advances in language features and processing power can affect in any way,

Kind of— I certainly believe a good programmer can easily learn a new language; also that anything you can apply in a few days and learn pretty well in a month is not likely to dramatically improve your code. If you can't do system architecture— taking sometimes vague desires and requirements and turning them into a solid, tested, maintainable program— then changing languages will not help you. (Generic you, of course.)

Ah, alice is enlightened. You take a high-level language-independent view of the problem, and fight with the implementation language's support (or lack of it) for the features you really need to make it work I've been there too.

Good link, btw; it brought back many memories of Important New Technologies i never bothered to learn at the time, ilke XSLT and Hibernate. I feel vindicated

[zompist]

Things are somehow more stable these days I think. Technological stacks revole around Java/Spring or C# or PHP/Symfony, and I think it's been these three for at least ten years.
Similarly frontend will use some godawful Javascript framework.

The sad irony is that if I do some programming for myself these days, it's usually Javascript, because it's usually related to my websites.

I liked C#, but I probably wouldn't if people have to use its shitty SQL interface. They moved bits of SQL into the syntax in a way that completely removed the (scant) readability of SQL. Then you still had to write a naked SQL query to get the thing moving.

[Travis B.]

The only time I really had to deal with Important New Technologies was at my last job, where I did web development on QA software for aerospace applications. At my current job, which I've been at since late 2021, the closest thing to an "Important New Technology" I've had to deal with is already-decade-old versions of the C++ standard... And I don't miss my old job one bit.

[bradrn]

I liked C#, but I probably wouldn't if people have to use its shitty SQL interface. They moved bits of SQL into the syntax in a way that completely removed the (scant) readability of SQL. Then you still had to write a naked SQL query to get the thing moving.

LINQ is really its own thing: it’s not actually SQL in the first place (although databases are one of the things which implement LINQ methods). When I wrote C#, I remember using it a lot for general querying of all sorts of data structures. From a programming language perspective, it’s basically a half-baked implementation of monadic notation as found in e.g. Haskell.

[zompist]

I liked C#, but I probably wouldn't if people have to use its shitty SQL interface. They moved bits of SQL into the syntax in a way that completely removed the (scant) readability of SQL. Then you still had to write a naked SQL query to get the thing moving.

LINQ is really its own thing: it’s not actually SQL in the first place (although databases are one of the things which implement LINQ methods). When I wrote C#, I remember using it a lot for general querying of all sorts of data structures. From a programming language perspective, it’s basically a half-baked implementation of monadic notation as found in e.g. Haskell.

Yeah, LINQ. Here's my first frustrated experience with it, in 2009. And that was when I was reasonably adept at SQL. It was quite an achievement to make SQL far uglier.

[malloc]

Incidentally, what is the endgame for AI advocates regarding the average worker? Once they have succeeded in creating machines that carry out all physical and mental labor, the rest of us will find ourselves permanently unemployed and unemployable. That also means, though, that we can't buy any of the products their robots make. Do they just expect us to die out while also accepting radically reduced demand for everything?

[Travis B.]

Incidentally, what is the endgame for AI advocates regarding the average worker? Once they have succeeded in creating machines that carry out all physical and mental labor, the rest of us will find ourselves permanently unemployed and unemployable. That also means, though, that we can't buy any of the products their robots make. Do they just expect us to die out while also accepting radically reduced demand for everything?

AI is not going to replace human workers -- the AI companies can't even turn a profit at this point (unless they, e.g. Google or Microsoft, have their fingers in non-AI things)!

But anyways, let's not let the topic of AI take over this thread and get it locked too.

[bradrn]

I liked C#, but I probably wouldn't if people have to use its shitty SQL interface. They moved bits of SQL into the syntax in a way that completely removed the (scant) readability of SQL. Then you still had to write a naked SQL query to get the thing moving.

LINQ is really its own thing: it’s not actually SQL in the first place (although databases are one of the things which implement LINQ methods). When I wrote C#, I remember using it a lot for general querying of all sorts of data structures. From a programming language perspective, it’s basically a half-baked implementation of monadic notation as found in e.g. Haskell.

Yeah, LINQ. Here's my first frustrated experience with it, in 2009. And that was when I was reasonably adept at SQL. It was quite an achievement to make SQL far uglier.

Eh, I guess tastes differ… personally I’ve always found LINQ a great deal easier to comprehend and use than SQL.

[malloc]

AI is not going to replace human workers -- the AI companies can't even turn a profit at this point (unless they, e.g. Google or Microsoft, have their fingers in non-AI things)!

Sure but tech industry leaders believe it can replace us. I am just genuinely curious what they expect to happen once they've achieved their goals, even if such goals prove impossible in practice.

[rotting bones]

Sure but tech industry leaders believe it can replace us. I am just genuinely curious what they expect to happen once they've achieved their goals, even if such goals prove impossible in practice.

People who are primarily interested in turning a profit don't care as much about theory, even the most commonly accepted theories of their day. They are not the only ones. Many people believe theory needs to fit their practical goals. For some people, that practical goal is next quarter's profit.

---

To repeat myself, a better coding LLM than ChatGPT, CodeQwen, runs on my PC. Let's find out how many million times I have to repeat this point before it sinks in.

---

Regarding architecture, you understand that humanity doesn't care, right? What's wrong with the conservatives is that they set out Procrustean standards, and when humans inevitably refuse to abide by them, they start punishing people out of rage.

Architecting code is a good idea if you already know how to build a system and you want a stable implementation for production. Like I said before, most people code in more exploratory ways where they are not sure enough of the effects they want for architecture to be relevant yet. At that stage, you can use AI to help you rapidly prototype many different approaches until you find a satisfying combination.

That's not what many Vibe Coders do though. They use AI to push code into repos that no human understands. This can be one approach to coding, depending on your requirements, but everyone should know it's not software engineering.

---

Generally speaking, I distrust enlightenment and I like fads. The sillier, the better. The issue is not that LLMs are a joke but that they are being shoved down our throats by a coterie of narcissistic murder hobos.