As Languages Evolve...

naph writes "It seems that as programming languages have developed there has been a steady increase in the level of abstraction they use. Early languages were all very low-level, but successive generations have become higher and higher. Is this trend going to continue, or do you think we've reached a kind of happy medium between power and abstraction? Would developers prefer higher level languages, or is the direct control of things good? I was just wondering what other developers out there thought of this."

Comments

IMO

[Tumbleweed]

The entire point of computers is to do things much faster than we can do them manually (or even make things possible that weren't before).

By making programming easier and faster with higher-level languages, this contributes to that goal.

There IS a trade-off in speed by doing things at such a high level versus, say, machine language, but considering the scope of most apps these days, it wouldn't be economically viable to create everything that way. Optimising certain bottle necks in low level languages is probably about the only common use programmers will have for low level stuff in the future, except for certain special cases or very small applications.

If you have a project that needs super-duper optimization, it might be better to concentrate on improving the compiler's optimization rather than writing your app in a low-level language. Keep in mind you have to maintain your code!

Languages become abstract on their own

[ajuda]

It seems to me that any language, be it Java, C++ or plain old C will become more abstract on their own as people begin to use libraries and reuse classes and methods. Once someone writes some basic classes, he will write classes which use those, and so on until the classes which he writes are many steps above the original class in abstraction.

Tools

[Trusty Penfold]

When it comes to languages, the answer is use the right tool for the job. Low level languages will always coexist with high level ones.

I really hope languages become more abstract

[Kevin Stevens]

As I recall from my software engineering class, programmers program at the same rate in lines of code regardless of the language (I believe IBM did the study in the 80's, but dont quote me on that). Therefore, programming languages SHOULD be more abstract to increase productivity. It also comes down to the "reinventing the wheel" factor. The more bug-free features/libraries we can stuff into a language, the more we can produce bug free code quicker. The only problem is of course that abstraction comes at the cost of speed. How much more enjoyable is it to program in java and not have to worry about cleaning up memory than say C or even assembly where everything is a battle. I dont know about you, but I would much rather type create_new_window() than worry about framebuffers and things of that nature. Hopefully this can be accomplished while keeping speed up and code bloat down

Re:Power comes from restraint

[gaj]

I disagree. Limiting the degrees of freedom does allow a programmer to concentrate on the problem they're trying to solve. To the degree that the language fits the problem domain, this is certainly a good thing. However, to say the constraints in and of themselves tend to increase expressiveness is patently absurd. Expressiveness comes from having language constructs that are a good fit to a) the problem domain and b) your ways of thinking.

In addition, Stroustrup was correct in saying that a language affects the ways you think about a problem. His language (C++) is certainly expressive, if terminally ugly and wart ridden.

In addition, I think that there are plenty of counter examples to your assertion. Python and Perl are both (relativily) young languages that allow many degrees of freedom. Further examples would be ocaml, which is also quite dynamic.

Understand the Economics of it

[Phouk]

"Higher abstraction" for a programming language means it's farther away from the requirements and constraints of the cpu, and closer to the problem domain.

cpu ------> abstraction ------> problem

As a result, the more abstract language is often less efficient for the computer to execute, but allows the programmer to describe the problem to the computer faster. That is, it makes him more productive, in the sense of...

productivity = features developed / times spent

Now,

• the amount of functionality expected of a program keeps rising and rising,
  
• the cost of spending additional cpu cycles on more abstraction keeps going down and down,
  
• programmer time stays at (very roughly) the same price.
  

As a result, the "sweet spot" in the tradeoff between programmer time and cpu cycles now is with more abstract languages than it was 10 years ago.
This is also why in the past the abstraction level of "mainstream" languages has steadily increased (machine language -> assembler -> macro assembler -> COBOL/FORTRAN -> modular/structured languages -> object-oriented languages).

This is also why I firmly believe the abstraction level will keep going up, through stuff like:

• stronger influence of functional abstractions on mainstream languages (e.g. having closures and higher-order functions)
  
• support for "stronger" abstractions through features such as design by contract, aspect-oriented programming, generics etc.
  

I also expect more new languages to have dynamic instead of static typing, which is also a way to attain higher programmer productivity (especially for refactoring) at the cost of compiler/runtime efficiency.

One more note: Before you argue against higher abstraction, please check if your line of reasoning could have been used as an argument for assembler and against higher-level languages. If so, maybe something is wrong with it...

Re:As long as the compiler is efficient...

[Directrix1]

Two words: Moore's Law. Even heavy abstraction will not keep up with the speed increases from that. And hardware is cheap. IT guys that program app servers aren't. Instead of paying an IT crew a lot of money to optimize a server you could just invest in more/better hardware. And size is not an issue any more as far as code size goes. The data most programs sift through is usually the only thing to consider as far as storage goes, since usually the data is so much larger than the program anyways.

Doesn't seem all that evolved to me...

[vsync64]

Early languages were all very low-level, but
successive generations have become higher and
higher.

I don't buy this. Explain why Common Lisp lets
me do this, for example:

(defparameter *settings-file-location*
(make-pathname :directory '(:absolute "etc" "monkey")
:name "settings"
:type "conf"))

(defun save-settings ()
(with-open-file (settings-file *settings-file-location*
:if-does-not-exist :create
:if-exists :rename
:direction :output)
(prin1 *settings*))

Java, 18 years later, requires code like the
following to approach the functionality of the
previous snippet:

/* We have to shove EVERYTHING into a class.
A singly-inherited one, no less. */
class Settings {
static File settingsFile = new File("etc" + File.separator +
"monkey" + File.separator +
"settings.conf");
// is static initialization order even guaranteed?
static File settingsFileBackup = new File(settingsFile.getName() +
".bak");

public void saveSettings() {
boolean backedUpSettings = false;

if (settingsFile.exists()) { // get the old one out of the way
settingsFile.renameTo(settingsFileBackup);
backedUpSettings = true;
}

FileOutputStream fow;
BufferedOutputStream bow;
try {
fow = new FileOutputStream(settingsFile);
bow = new BufferedOutputStream(fow);
dumpSettings(bow);
close(bow);
} catch (Exception e) {
if (bow && fow.getFD().valid()) {
close(bow); // file descriptors aren't garbage collected
}
// now put back the old file
if (backedUpSettings) {
settingsFileBackup.renameTo(settingsFile);
}
}
}
}

Note that this Java code loses on systems like
Mac OS, which store the file type somewhere
besides the filename.

Or how about Common Lisp's condition system,
which allows execution to actually continue
where it left off once an error is corrected?
What about MAPCAR, or DO and DO*? Heck, what
about first-class function objects?

Of course, try getting a job using Common Lisp,
or any other decently abstracted general-purpose
programming language today...

BTW, Slashdot inserted the spurious semicolons
in this post, not me.