Language Design: More or less flexible in the future

Question

There seems to be a fundamental split among programmers on how new general-purpose languages should be designed. In one camp you have those who think new languages should be more disciplined, stricter, simpler, etc. than old ones and should focus on making it harder to shoot yourself in the foot, even if this means giving up some expressiveness. On the other, you have people who think that the main focus should be on making languages more powerful and adding better abstractions, even if it means more complexity or more opportunities to screw up. Where do you stand on this issue and why?

Answer 1

It depends what the language is for.

If the language is for learning, casual scripting, etc., I would say that it should be designed to not allow oneself to shoot oneself in the foot.

If the language is designed for professional use, allowing high levels of optimization and customization... hell, just make it a boot with a gun built in. The ability to get close to the hardware and optimization means that you'll have the opportunity to vaporize your toes.

Answer 2

More strict.

I don't think expressiveness is linked to strictness. It might just take more typing, but whos care about source code size if its clearer.

Programming gets no respect. They think anybody with knowledge of the syntax can develop software. This leads to people shooting themselves in the foot a lot.

To migrate this, languages need to be more strict. Ideally its so strict that the vast majority of errors can be caught by the compiler.

For example, Joel wants code-style to be fixed within the syntax. I agree with this fully, in fact I would go one further say there should be no complex expressions either!

What I mean is, this is illegal:

p.setLocation(Math.min(getWidth() - viewRect.width, p.x), Math.min(getHeight() - viewRect.height, p.y));

The syntax/code-style of my language would force you to break this down to:

x = Math.min(getWidth() - viewRect.width, p.x);
y = Math.min(getHeight() - viewRect.height, p.y);
p.setLocation(x, y);

I haven't detailed the rules, but you get the idea.

Answer 3

What's wrong with wanting both? But I challenge your premise: it is not just about the flexibility or discipline of next language, it is about the entire development environment.

• I want both flexibility or discipline when it suits me, and I want it in the same language--the same development environment.
• I want to brainstorm and prototype rapidly with a team using the code equivalent of handwaving for all the perfunctory bits.
• I want a development environment that allows multi-user collaboration in real-time and with remote programmers and a language that makes sense for that kind of collaboration. At this stage, code details are secondary to design details and a language and editing environment that accommodates this part of the process, yet retains these design details for the maintenance cycle would be an extraordinary tool.
• I want a development environment and underlying language so well-suited to collaboration that a team lead would never consider having any sort of team meeting without the development tools front and center. This would require an editor that keeps notes, diagrams, hyperlinks and doodles with hiding options for all.
• I want a graphical big picture of the system that allows the team to drill down to any line of code or underlying assembly. As we move into terra incognito and have to hammer down the details, the I'd want to selectively turn off hand-holding as needed.
• I want to browse the full history of the file within the editor if I choose. Source control, bug tracking, the testing rig, and release procedures need to be fully integrated as part of the editor, and build environment. I'm not talking about just some toolbar icons that launch a separate app like any current environment. I don't want my screen cluttered with a bunch of buttons for the sake of calling that "integrated".

That's where I stand. Why? If you can't guess yet, I am in a maintenance cycle on a huge legacy project (over a million lines of code). The team is mostly new and unfamiliar with the code. What scant design docs exist are at least six years out of date. A large minority of the code was written by brilliant people that assumed they would be the only ones to work on this baby. Ever seen code written by geniuses in those conditions? I'd prefer to maintain code written by average coders that were worried they'd lose their job if they wrote code like the brilliant coders. The rest of the code was written by not-quite-geniuses that emulated the genius style, but without the genius effectiveness.

So as this project dies a slow death and I ponder the next big project, what do I care about the details of the next language? It will either get the job done or it won't. That is quickly discovered and corrected. The details of the language are secondary to the overall life-cycle any decent sized project. Once the project gets deployed, brittleness sets in and changes become harder. That's rarely the fault of the language, but a symptom of the culture of the project--a large portion of which is affected by the limitations of the IDE. Where and when flexibility of the language and environment really matters begins in the prototype phases, and continually increases as the project grows through debug, release, and then maintenance. But the development environments we have all seem to be focused more on creating new code and not preserving and improving old code. It is no wonder that so many companies, just as mine is doing now, decide to kill the lumbering behemoth project and re-write them from scratch.

Answer 4

There is absolutely no contradiction between making a language powerful and offering good abstractions and preventing people from shooting themself in the foot, actually both can be realized only together.

"Powerful" does not mean that a statement should require as few characters as possible to write it down, but that the features exist that are most useful, are well-integrated and have a clear, obvious and well-defined semantics. E. g. often-used data types like strings, enumeration types, arrays and sets should be part of the language because only then can the compiler do strict checks and generate really good code for it and only then can libraries make use of them. The language should also be defined in a way that enables the compiler to generate range checks and overflow checks, where appropriate. You'd be surprised how many erros like this are found when a development environment is used that supports this.

There are "powerful" features that can make a program difficult to understand, e.g. higher-order functions (functions that take functions as parameters, possibly across several levels). But these are rarely required, execpt in functional languages that are mostly academic.

And abstraction means real abstraction, real encapsulation that makes objects or modules unbreakable from outside of them. Not the C/C++ way where an erronous pointer can cause crashes or, even worse, malfunction at a totally different place of the application.

Answer 5

I don't know what the languages will be. But I am quite sure about that we will have more and more new languages designed for different specific purpose.

In long terms, you need to use multi-languages to do a single task. That will bring you less flexible, because even module will have it own limit.