Lazycoder

With regards to point #4, I’ve always been somewhat irked that compilers don’t have an “interactive mode”; that is, certain errors can be corrected by the user during the compile/link process rather than waiting for the full build to fail before fixing the errors. I called it a “mode” because I think there are good cases for finishing the failed build as it happens now. But when you’re doing interactive development? Compiler should prompt for a fix (perhaps with a few reasonable automatic options?) when it hits an issue.

Aren’t 5 and 6 mutually exclusive? Refactoring design patterns into the language results in more syntax. I agree with Mike – better to have a language that the developer can grow themselves.

On compilation speed: I guess you haven’t dealt much with builds that take hours, and not just because there’s so much code – but rather because there’s so much functionality. It’s also easy enough to get into a situation in C++ where you get an exponential blowup in compilation time when modifying a single line in a single file merely because of poor dependency structuring, and the general crappiness of include files and flat typeless symbol linkers from the 70′s as module mechanisms.

#1 Typing is needed to build large systems to communicate invariants between different teams, and to document the data structures. I can live with typeless method declarations; document the data structures and I can infer the operations.

#5 Mike Moore above missed the point saying that design patterns are a sign of a weak language. Yes: if a design pattern emerges, the language should be factored so that it is part of the language. That doesn’t necessarily mean the language grows like topsy, contra Paul Batum, but rather that the elements become more general, more abstract and thereby more expressive so they encapsulate the pattern.

Patterns emerge as software engineering matures as a discipline. Unit testing didn’t have the emphasis 20 years ago as it does now. Programs were smaller then, testing software at inter-module boundaries was less important as whole program testing was more feasible.

But I have to say that your quoted rant is way, way off base on at least 30% of its points. For some:

– programming languages are for *programmers* — not compilers and compiler-writers

Guess what? Programming languages designed for people (i.e. like a human language, i.e. like Perl, or god forbid COBOL) suck horribly. Having a simple syntax that can easily be unambiguously parsed is important for both programmers and tool writers. When programmers can understand the syntax rules in the same way the compiler sees them, they can fix syntax errors easily. When the parsing gets too clever, multiple implementations will disagree and programmers will have to rope in experts to figure it all out. This has been happening to C++ for some time.

– most programming involves schlepping a few but complex data types between different string representations

Perhaps if you’re doing web programming. But then much of web programming can only loosely be described as such, and is more often “scriptable templating” or somesuch.

– less stupid line-noise syntax and punctuation, people

“Line noise”, i.e. concise notation, is very important for increasing the information density of code. Notation does act like a jargon barrier limiting entry, but it greatly improves productivity when you’re familiar with it. Mathematicians don’t invent notations for nothing – the right notation makes all the difference in the world for increasing clarity of expression.

The opposite of line noise is COBOL. ADD YEARS TO AGE is certainly line-noise light, but is not noticeably better than age += years, to my eyes.

– programmers have become plumbers and documentation-archaeologists mostly, which is sad and uninteresting

This is called code reuse, and has been the holy grail of software development productivity for many, many years. Examine a small set of Java or .NET programs. Compare and contrast with a small set of C programs, with respect to the amount of functionality and the proportion of third-party code used.

The fact is that in the olden days, when you didn’t have to consult documentation, you (a) had less open source, so less libraries to use (and plumb, and dig through in the archaeology sense), (b) you didn’t have web access, so you couldn’t search for code that already did what you’re going to write (and thus plumb etc.) and (c) you were writing code for a puny pathetic machine which could do barely anything at all in the first place, such that the maximum amount of functionality you could cram in was limited by hardware.

Software engineers are so much more productive today precisely because they are plumbing code together. All web applications are plumbed together – they pull in the DOM of their browser, scripting engines, the browser itself, the networking stack, the OS windowing system, the OS hardware virtualization, etc. etc. In the good old days of no documentation and no plumbing, you’d have to DO ALL THAT YOURSELF. It’s not where you want to go back to.

– until you make the everyday, “simple” things simple, it will
continue to be a dark art practiced by fewer and fewer

If you include web programming, the PHP and JS mavens of the world, there are more programmers than ever before, and it has *never* been easier. Never ever ever.

Hm. Perhaps that’s somewhat more than 30% complete and utter uninformed nonsense.

Simplest example: C# event callbacks growing into anonymous methods in 2.0, and into lambdas in 3.0.

Lambdas absent the expression tree functionality is the same feature as anonymous methods, but with type inference. It makes a big difference though in how easy it is to write monadic code.

The other half of the feature, the delegate itself, is the thing which has grown in power. Functionally delegate types haven’t really changed (don’t mind variance), but their power has – they can refer to more things.

It’s true that most non-Lisp level languages don’t have a syntax plastic enough to reduce down to more fundamental primitives as those primitives grow in power. You could say I’m arguing for a macro system, or a pluggable compiler.

Another angle: patterns are a recurring shape of object (or type, if you like) graphs. When a language gains a new expressive feature, such as lambdas or blocks, especially dynamic languages with metaprogramming capabilities, such patterns can be coded as libraries, rather than requiring mechanical implementation by the programmer. As such the number of “patterns” that show up as visible artefacts, i.e. code written by some poor programmer following a cookbook, decrease at a rate which is superlinear with respect to power of language features.

@Barry
The problem I have with your example of C# lambdas is that they are not an example of a design pattern being “factored” into a language. They’re a known programming construct that plenty of other programming languages have – a critical component for many of them!

When you argue that expressive features such as lambdas allow more patterns to be encapsulated into libraries, you are suddenly agreeing with me! My original point was that if you put a small, sufficiently powerful set of features into a language to start with, then design patterns do not need to be factored into the language – they can be encapsulated into libraries.

Well… I agree with the general idea of this post: It’s nearly 2010 and we’re still doing things like in 1970. But why should we still use a language to make programms? Isn’t it there, that the problem is ? I mean at the beginning of the programming era, there were only text screens, so typing things (programms) was some kind of natural solution. Then windows, icons and mousses made their way in (mac? next?), it vastly improved the way we deal with the os, but the programming process didnt change. Now we have high quality displays / icons / 3D, hd pictures, we could really create something that would allow us to perform the same kind of things that a “programming language” could do. A program would like something like a big 3D object with fractal dimension (the more you zoom, the more detail about each part, until you reach a subfunction). I’ve seen some experimental projects like this. Let’s hope some day, someone will try to make a 3D version of eclipse or visual studio, that would be a crazy fun start.

1) I really want string typing. Do not agree. It’s not good or bad, it’s a matter of taste… But we have to admit that most big project use staticaly typed languages. Maybe there is a reason.

2) Contracts would be nice feature. You can have it with “plugins”… And anyway a good IDE can include anything you want in your build steps. It’s already available if you prefer.

3) Don’t know, sorry.

4) IDe offer already that (in JAVA for exemple), but because import is added to the code, I am sure of the package really used. So i prefer that.

5) Depend of the pattern. The problem of patterns, it that there is thousand of thems and they are dependant of implemation,
architecture, language, plaform… Many of them become useless a few years later and tend to make people all do the same thing. But many times, this thing is not that right.

Ok you can incluse listener pattern into the language, but even. How will you implement it ? Each listener is called in a different thread in // ? Or one after another ? What do you do if an exception occurs ? Let it brake the listener mechanisn or forward the even to subsequent listeners anyway ?.

One thing about pattern is that you can’t implement them identicaly each time. That why they are pattern and not juste one piece of code in a library. Exact implementation, usage and all is depend of context, real need and all. So it’s very difficult to add a pattern to a language and do it nicely.

6) C & Javascript are exemple of pocket language… and assembler too. I do not see as a feature. Natural language is at the opposite a very deep language, but you can express so many thing with a few words… And C and javascript are typically complex language to use, control and master.

Compilation speed : it all depend of your needs. Fast compilator allow real time check of error in editor, full rebuild of project very fast and all. Because in our company compilation is too long, we have many problem when deploying software… It cost days and days finding bugs and all.