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.

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.

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.