[xj9]

If we can eliminate software engineering as a profession our work will be done. There will be nothing left for humans to do, because at that point we will have invented a General AI.

Up until that point, software engineering will be a well paid job. I really don't understand this attitude that everyone should be a programmer or that programming should be easy. It isn't easy. Obviously, we should remove unnecessary friction from the process, but framing your thoughts precisely takes discipline. Building maintainable systems takes practice and understanding. It takes years of study and work to become a good engineer.

I definitely think people should be exposed to programming in school, but we study physics and chemistry there too and nobody expects everyone to be a physicist or chemical engineer. Specialization is a good thing.

That said, I'm down to compete with whatever you people think can replace me. I love a good challenge.

[chongli]

nobody expects everyone to be a physicist or chemical engineer. Specialization is a good thing.

The difference with software engineers is that they have the power to build their own tools; physicists and chemical engineers largely don't, unless they themselves are also software engineers. You aren't going to use knowledge of chemistry to build general software but you can always find a use for software engineering in any domain. This puts it in the same category as literacy and mathematics, rather than strictly being a specialization pursued toward its own end.

[xj9]

Don't quote me out of context

I definitely think people should be exposed to programming in school, but we study physics and chemistry there too and nobody expects everyone to be a physicist or chemical engineer. Specialization is a good thing.

I am saying that people should be taught programming in school, like literacy and mathematics, but that doing so is not going to prepare students to make production-grade software. We need actual engineers for that.

[darkmighty]

It's not unthinkable that a language, by design, facilitates or enforces precise definitions.

As a far-fetched example, think of Lego. You can't "fail to compile" your Lego bricks. You have a finite selection of bricks (all clearly visible and usually available within arm's reach), and your job is to just lay one at a time. Given any brick, it's "obvious" to a human how it fits with other bricks. The worst you can do is essentially create a crappy Lego design. As you noted going from a rough thought of

"Uhm I want to build a Dragon of about this size..."

to a finished build requires a powerful AI. But we don't need to go that far to be better than

"Place $brick1 in p=(32,17) at orientation o=(0,pi); place $brick2 in p=(38,15) at o=(-pi,0); ..."

The rigidity of the bricks inherently prevent you from overlapping them, but not the above declaration :)

[xj9]

Not at all. Good tools are very important, and we shouldn't stop working to make them better. What I disagree with is the idea that good enough tools can replace engineers without them becoming General AIs. Until we get to that point, there will be systems that need to be built that only professionals are qualified to work on. I'm not saying that we need licensing boards or any of that nonsense, just that nobody is going to merge poorly constructed code into an important project.

[darkmighty]

I don't think it was implied good enough tools can replace qualified engineers. But I feel sometimes engineers don't realize that tools can not only be valuable for beginners (itself worthwhile, imo) but actually make experienced professionals more reliable (less error-prone) and work faster.

Taking the Lego analogy further, even if I, an experienced Lego builder, can construct a set entirely in my head, and write a correct assembly script, building it physically is likely faster and certainly less error-prone.

Those kinds of goals are hard to achieve with software (especially considering what we have is already pretty good!), but I think they're a worthy pursuit.

Examples of language/interface design that seem strictly beneficial: (regardless of experience or project)

- Showing the result of [valid] code changes as soon as possible (a feedback problem);

- Disallowing invalid expressions (a consistency problem);

- Displaying relevant components (functions, libraries, APIs, variables, etc) (a visibility problem);

- Bringing documentation closer to code (making functionality obvious)

Eve tries to tackle some of those challenges, especially the documentation problem and the visibility problem.

Solving those issues can both improve productivity and bring more people into programming.

[xj9]

Okay, but who is your customer, the engineer or the layperson? At a certain point, our needs are going to pull in separate directions. Simple is good, but certain problems have a baseline of complexity that can't be eliminated. Who are you planning to side with?

[taeric]

You would be surprised how non obvious Legos actually are to people not familiar with them already.

This is akin to thinking doors are intrinsically intuitive. There is actually a ton of training that kids go through for that "intuition."