Hacker News Reader

> "Ah, those were the days! TP v4, v5, v6... i'd graduated to C by the time 7 came out."

Mee too, and it is painful to realize how much ahead of its time the IDE was. I am talking about the TUI version and yet:

- It already supported a dual monitor setup - one monitor for the IDE, one for the app - live debugging was a charm.

- The debugger had everything current debuggers have, but it was fully IDE integrated - no messin' with GDB or JDWP.

- The context sensitive help was the best, I never encountered a better one. I think a large part of it was that it really was context sensitive and it tried to solve the problem at hand, regardless if it was caused by the IDE or the language.

>i'd graduated to C by the time 7 came out.

I've never seen C as an improvement. Macros encourage all too clever code that's impossible to parse at first glance. The string handling is horrible. The fact that there are multiple contradictory ways to express pointers.

The only thing holding Free Pascal/Lazarus back is the documentation. There's no way to work on a small part of it, Wiki style, so it's always going to be an albatross. The auto-generated descriptions of variables used in library function calls just don't work as proper documentation.

On the plus side, it's fast and has all of the linking built in. You can stuff gigabytes of binary in strings and never have to allocate anything. It does object oriented stuff, generics, is strongly typed. It can spit out code for almost any platform, including WASM, Android, etc.

I was about to offer them my condolences for the downgrade :P

> the rise (read as: shoving-down-our-throats) of AI/machine learning will hurt the collective ability to code

You sound like Socrates lamenting that the invention of writing is hurting people's collective ability to think, since their brains no longer need to hold many things simultaneously.

> ... writing is hurting people's collective ability to think

There's a tremendous difference between writing and having someone else write for you.

In its ideal form, an AI can do all the conventional non-innovative writing so you can free up the time to do the truly innovative writing.

That said the current crop of AI isn't that and is overhyped.

That's the theory, but in practice if you are a capable developer you'll spend a lot of time fixing the AI generated code. And the other practice is that a lot of novice developers will try and use AI to code, then bother others to fix it if it doesn't work. They will rely on AI and not bother to increase their own skills.

I may be a luddite about it but I'm also not entirely wrong. That said, I'm sure the same was said about code generators and other features introduced by IDEs, like syntax highlighting.

You are missing the point. I was talking about theory, not practice. I said very clearly that the current crop of AIs can't live up to their hype.

heh... IMO AI often works better when you ask it "how do/can I?" instead of "do this for me!"

> all the while ignoring that such usage actively keeps them from improving their own coding skills

That's an opinion not a fact backed by any data.

In fact it feels like "you hurt your hacking skills by using an IDE rather than a simple text editor, or higher level language than assembly, or managing your memory manually rather than using GCs".

Also, maybe coding skills will become more and more irrelevant for most developers the same way knowing how memory or CPUs work is largely irrelevant for all but a tiny part of the industry.

In fact, if AI assistants will keep getting better, the best skills to have will be ability to direct those assistants and overseeing their output while meeting business and product needs.

> That's an opinion not a fact backed by any data.

It's a well-demonstrated fact that, for the overwhelmingly large majority of people (mainly those without eidetic memory), copying someone else's answers, rather than coming up with them by applying one's own problem-solving skills, hurts one's ability to advance their own related knowledge/skills. There's a _reason_ we're taught not to cheat in school.

> the same way knowing how memory or CPUs work is largely irrelevant for all but a tiny part of the industry.

This is not true. A large part of the industry just _thinks_ these things aren't relevant to them and that's why we have such terrible software everywhere.

I don't buy this, at all.

In my industry experience software is slow because:

- time to market is overwhelmingly more important than performance so the pressure is to have something that works, not something that works smoothly. You can fix performance or bugs later (Notion is an easy example of such evolution).

- the industry keeps being largely understaffed so finding resources to allocate to performance is hard

- most of the industry is managed by people that are neither good at product nor tech, but think they understand products and tech

The point is that if you understand how the high-level code you write gets translated to what runs on the actual CPU and memory then you write more performant high-level code by default the first time round. So you can get to market just as quickly. Doesn't mean there's not more speed or memory optimizations you can make later but you just raise the bar generally.

please make a general simple example of how knowing memory and cpu applies to overwhelming majority of people out there glueing APIs together.

I'm not ignoring your request, but I need to think about it a little as my day to day work isn't just pasting together APIs. If the only thing an engineer is allowed to do is paste together a fixed set of APIs then they may well be completely limited.

Knowing how the underlying system - CPU ram network db - works is the difference between using an ORM or SQL query to do SELECT * FROM db across the network, and filtering it locally with program code, and using a WHERE clause in the SQL, a pattern I've fixed for multiple startups.