Designing And Building A New Pragmatic Language

ctrimble writes "A bunch of folks on the pragprog Yahoo! Group have banded together to design and implement a 'pragmatic' programming language. Ostensibly, the language is informed by the principles in Hunt and Thomas's well-received book, The Pragmatic Programmer: From Journeyman to Master but the purpose of the language is to help ease some of the pain of development and bridge the impedance mismatch between the academic aspects of a programming language and the discipline of software engineering. The design is still very much in flux. If you're a programmer, this might be a language you'll be using in a few years (or earlier). This is your chance to get in on the ground floor. What kind of features do you want the language to have? What are your PL pain points? Where could this language do better than existing languages?"

Comments

what is a pragmatic language?

[Anonymous Coward]

In my mind, Perl is the ultimate pragmatic language. Quick and easy with little attention paid to consistency and orthogonality. I.e., not a "theoretical" language.

I haven't read this book and I can't find any info at those links. What is a "pragmatic language" and why don't any existing languages meet the definition?

Re:what is a pragmatic language?

[turgid]

with little attention paid to consistency and orthogonality

No, that just makes is clumsy, quirky, difficult to read and difficult to write.

A "pragmatic" language would be one with little or no "red tape", with sensible defaults, clean syntax, easily optimised, portable, easily extended, consistent, orthogonal and easy to learn. It should be difficult to "shoot yourself in the foot."

In my mind, PERL has its place : scripting. Serious application development should be done is somehting more "pragmatic".

Re:what is a pragmatic language?

[Anonymous Coward]

You don't program much, do you. Oh, in Pascal? Now it all becomes clear.

Re:what is a pragmatic language?

[turgid]

I've programmed in BASIC (several dialects), FORTH, FORTRAN-77, C (K&R and ANSI), C++, Pascal (Borland TP 7.0), Modula-2, Z80 assembler, 8086 assembler, 80386 assembler, Java and bash.

I started coding when I was 8 years old.

My day job involves a lot of shell scripting, Makefiles and the very odd bit of Java and C.

For pleasure, in my own time, code in C.

I have found C to be the most pragmatic language I've tried so far, closely followed by Turbo Pascal (I can't comment on Delphi, I stopped using Windows PCs then).

FORTRAN is completely un-pragmatic. Like the example of PERL given above, it has a terrbile syntax and is inconsistent and unforgiving of errors.

At the other end of the scale I've tried is Modula-2. This language is un-pragmatic in a different way. It is very orthogonal, rigid and comprehensive. Unfortunately there is so much red tape involved in writing code in this language it is very frustrating.

C and Pascal (not straight Pascal though) represent a happy medium. I've looked at C++ over the years, read books on it, looked at people's code and tried to write my own, but it's all Greek to me. It is fiendishly complicated.

Now, FORTH.... don't get me started on FORTH :-)

Re:what is a pragmatic language?

[xteddy]

> For pleasure, in my own time, code in C.

You should have told us, that you are a masochist...

Re:what is a pragmatic language?

[turgid]

Actually, I only use C and a convenient wrapper for my SIMD assembler programming :-)

make the case....

[demian031]

they should explain why ruby, python, perl, basic, java is bad.

they should come up with some good improvements for a specific language.

the world doesn't need an entirely new language. (we already have python).

Re:make the case....

[Dr. Photo]

The world doesn't need another entirely new language, because we already have C++.

Agreed. I certainly wouldn't wish another C++ on the world. :-)

Already done

[keesh]

I believe it's called Ruby. Incidentally, Hunt and Thomas also wrote the Ruby Book, where they say Ruby is pretty much what they had in mind when they wrote Pragmatic Programmer:

As Pragmatic Programmers we've tried many, many languages in our search for tools to make our lives easier, for tools to help us do our jobs better. Until now, though, we'd always been frustrated by the languages we were using.

Re:Already done

[DogIsMyCoprocessor]

Ruby gives a strange impression. It combines some of Perl's choices (magic variables, regular expressions as part of the syntax rather than as a library, and variable prefixes that look like line noise) with stealing some nice stuff from Smalltalk, and oddly, using end as a block delimiter. It comes across as baroque, not beautiful.

A pragmatic language should have mature class libraries. (That's pragmatic, isn't it?) Ruby doesn't.

Re:Already done

[Anonymous Coward]

A pragmatic language should have mature class libraries
Ruby does have mature class libraries. And the end is only if you use begin, you can use {} if you prefer.

Re:Already done

[Arandir]

A pragmatic language should have mature class libraries.

Libraries should not be a part of the language. There is a use for small minimal standard libraries, just to aid in portability, but please keep the language small by keeping the libraries out. There is a distinction that must be made between syntax and semantics, and useful routines that other people have made.

Libraries as part of a language seem to be an interpreted language kind of thing, because it makes absolutely no sense to put them in a compiler. But they're not to hard to include in a runtime environment. That means they will still be there taking up resources even if you don't use them. In C/C++ you don't have to use any of the standard libaries if you don't want to. Maybe you want to use Dinkumware instead of glibc. Or maybe Qt instead of GTK+. Or roll your own mini-libc for an embedded device.

Moving libraries into the language is like moving web servers, web browsers, office suites and solitaire games into the kernel. Some people will think it's cool, but others will wonder why they can no longer fit a bootdisk onto a 1.44Mb floppy.

50% of the people out there will vehemently disagree with me. The other 50% will think I'm right. This is just an opinion.

Re:Already done

[Hawkins]

It should be noted that some of this Perlesque is deliberate, and that much of it is simply syntax sugar on top of objects. The regexps, for example, are actually Regexp objects, and as such can be extended or inherited just as any other object would. matz decided to include the /regexp/ construct to aid those who were used to it. As for the $_, $&, and its cousins, if you don't like the look of those you can include the English mixin in the standard library that allows you to say things like $LAST_READ_LINE and $MATCH.

I have to agree on the variable prefixes. @instance and @@class variables are hard on the eyes, but other than that you don't have to append anything to the beginning of a variable. lowerCase variables are local, Uppercase are constants or classes. If you're using globals in an OO language, may Dog have mercy on your soul.

And as for the libraries, check out raa.ruby-lang.org. Many there, more being developed all the time.

_dave

Re:Already done

[swdunlop]

Mark me down as disagreeing. A mature class library is a key feature from the standpoint of these "pragmatic programmers" Reinventing the wheel is not a great way to get your application out the door. This doesn't mean you need to build your libraries into the interpreter directly, you can dynamically load them in a modular fashion, like Perl, Python, Ruby, and most other modern interpreters do.

Re:Already done

[Randolpho]

And the end is only if you use begin, you can use {} if you prefer.

Really? That's good. Every Ruby example I've ever seen had begin/end; it looked so nasty that it kept me from looking further. If it allows for multiple means of creating a code block, that's a good thing, allowing people with different styles of coding to code in the same language. It'd be nice if it did python-style whitespace indentation as well.

Of course, I expect the purists to flame me, but thankfully I've got this +5 Cloak of Retardation to protect me.

Well, they *told* me the word "flame" is implied....

Re:Already done

[kwerle]

Sign up another disagree. I don't want to have to write a stack, queue, or quicksort - I did that in college. I don't want to write another http socket client, I did that at the end of last decade.

Moving libraries into the language is like moving web servers, web browsers, office suites and solitaire games into the kernel. Some people will think it's cool, but others will wonder why they can no longer fit a bootdisk onto a 1.44Mb floppy.

People who want 1.44Mb boot floppies should:
1. Buy a real computer - one without a damn floppy.
2. Invest in some kind of IO that supports CD booting.
3. Write their damn kernel in C - that's all the language is good for (IMO)

Re:Already done

[p3d0]

Libraries should not be a part of the language.

I disagree. Perhaps I'm just unclear what you mean by "part of the language", but it seems clear to me that a pragmatic language must have a substantial standard library, or people won't use it.

Libraries as part of a language seem to be an interpreted language kind of thing, because it makes absolutely no sense to put them in a compiler.

Better tell that to the people who wrote javac.

Re:Already done

[Anonymous Brave Guy]

1. Buy a real computer - one without a damn floppy.

Real people don't buy a computer, they buy the parts and build it themselves. That way, you can ignore the floppy issue completely...

Of course, real people also feel no pain when vendor X claims the instability is due to vendor B's component and vice versa. ;-)

Re:Already done

[Arandir]

Translation of what you said:

"People who want 1.44Mb boot floppies should:
1. Are old farts who can't handle technology.
2. Should find a corner to die in.
3. Must do what I tell them to do, dammit!"

Translation of what I meant:

If you can't fit a kernel into one and half megabytes, perhaps it's getting to big. I don't care about floppies or CDROMs or USB boot devices. But I do care about systems that aren't necessarily your typical gamer's desktop.

Re:Already done

[kwerle]

Translation of what you said:

Let me help translate from kwerle to common - it can be tricky.

Keep up with the times.

There's no reason to write another lightweight language (the topic at hand) - we have C for that. If you're going to roll another language, it should probably be feature-rich and have good libraries.

I took the 1.44M boot floppy to be kind of an analogy, so I latched on to it. Just as any new language should be feature rich, any new OS should also be feature rich. Unless you're writing an OS for a lightswitch, you should probably enjoy the features of today's hardware - to wit, lots of space and processor speed.

The same is true of languages.

If you're writing an OS for a lightswich, use C. It's low on features and lightweight.

Re:Already done

[Arandir]

But why should we be stuck with C forever? Isn't there room for another mid level language suitable for systems programming? Something like a more advanced C, or a cleaned up C++?

I do try to keep up with the times. it's hard though. I came from the world where you only had 64Kb of RAM. You made every byte count. But nowadays the trend seems to be "make the user upgrade." I've got a 1.4GHz Pentium and Java still runs like a sick dog on it. I'm going to be purchasing a new system next week, but dammit it's obsolete before I've even bought it!

Re:Already done

[kwerle]

But why should we be stuck with C forever? Isn't there room for another mid level language suitable for systems programming?

I don't think so. If you want more than C, get better libraries. Anything "more" in the language adds overhead...

Something like a more advanced C, or a cleaned up C++?

C++ is a mess and always will be. Use Objective-C. It's a great language. But don't write kernels with it - it's got about a 10% message overhead because it supports introspection.

I do try to keep up with the times. it's hard though. I came from the world where you only had 64Kb of RAM. You made every byte count.

Me too, but we got a IIe with the 64K upgrade for a total of 128K.

But nowadays the trend seems to be "make the user upgrade."

Why not - machines are cheap. Especially cheap machines (intel).

I've got a 1.4GHz Pentium and Java still runs like a sick dog on it. I'm going to be purchasing a new system next week, but dammit it's obsolete before I've even bought it!

I'm guessing you know what your doing, so you have at least 512M RAM.

Maybe it's time to change platforms. I've got a 600Mhz iBook coming up on 2 years old, and java ain't lightning, but it's better than a sick dog...

Re:Already done

[Ian Bicking]

If you're using globals in an OO language, may Dog have mercy on your soul.

While I've seen a lot of abuse of globals (any PHP piece code being a good example), I think being purely anti-global is a little too strong.

Global variables should hold global data. Global data does exist. I don't know about the specific case of Ruby, but in Smalltalk (which is obviously the inspiration for Ruby's semantics) all uppercase variables are global, which conveniently includes classes, as classes are first-class objects that are used globally. Singletons are another common example of a global, though sometimes that is hidden behind the facade of syntax. Class variables are also globals, just globals in a more specific namespace.

Anyway, I often use globals. When the global is of a specific class people would call it a singleton, or maybe a constant, but it's still a global. But when it's not a constant, which includes classes with non-contant class variables, it's usually a cache of some sort, or a primitive data store, built with the expectation of concurrency.

[It's convenient in Python, and maybe Ruby for all I know, that globals are still local to their module, so the problem of globals being difficult to track is avoided.]

Re:Already done

[xteddy]

You both seem to confuse things. If you want to create a codeblock you can use

3.times { puts "Ruby rulez!" }

or

3.times do puts "Ruby rulez!" end

It's a question of personal style which you prefer, opinions differ here.

You have to use a begin...end block if you try to catch expceptions.

begin
content = Net::HTTP.get('slashdot.org', '/')
rescue SocketError => e
STDERR.puts "Caught: #{e.class} #{e}"
ensure
STDOUT.puts "Done."
end

If you extract a begin..end block into a separate method later you can just drop the begin and use def..end instead. Ruby is really a pragmatic language it minimizes changes if you refactor your code: it's amazing.

def get_slashdot
Net::HTTP.get('slashdot.org', '/')
rescue SocketError => e
STDERR.puts "Caught: #{e.class} #{e}"
ensure
STDOUT.puts "Done."
end

content = get_slashdot

I have translated a lot of Perl scripts to Ruby and usually they became much shorter and at the same time more readable. (I don't think that was the case because I suck as a perl programmer... ;)

Re:Already done

[xteddy]

In Ruby there are global variables (starting with $) and constants (first letter is uppercase). The difference is that globals are global for the whole script and can be modified from anywhere.

That way it's easy to redirect STDOUT temporarily:
$stdout = File.new("output.txt", "w")
puts "output"
$stdout = STDOUT

Constants are subject to namespaces (defined by classes and modules):

module A
C = 'A'
end

module B
C = 'B'
end

A::C # => "A"
B::C # => "C"

Like in Smalltalk classes are objects (actually classes are modules and modules are objects), so it's possible to create a class by calling:

klass = Class.new

and then start adding methods to it:

klass.class_eval do
def foo; "foo"; end
end

klass.new.foo # => "foo"

class Klass
# ...
end

is essentially syntactic sugar for writing

Klass = Class.new

which assigns a new class to the constant A. You can also assign values to already defined constants (but will have to suffer a warning).

Re:Already done

[William Tanksley]

For a cleaned-up C, try Oberon.

It's very nice.

-Billy (coding in C++ at work :-)

After thinking about it...

[Nice2Cats]

... they only thing I can think of that would be missing is a compiler to turn Python into machine code, and I'm sure somebody is working on that.

Re:After thinking about it...

[slackergod]

There's pyrex, a variant of python for writing lowlevel c-code w/o going into C.

And there's also pysco, a specializing compiler, which generates machine code for python, and gets dramatic speed ups.

Re:After thinking about it...

[pnatural]

And don't forget PyPy, of which the author of psyco is also a member. If any of these three projects will bear the fruit of a python-machine code compiler, it's PyPy.

Re:After thinking about it...

[Anonymous Coward]

And don't forget Bubb Rubb, who has the flows.

Need more information...

[phraktyl]

I'm going to have to see at least 3 years of Apocalypses and Exegesis before I can make an informed decision about this language...

Wish list

[jbrandon]

Strong typing: I'm tired of seeing casting errors at runtime.

Metacode/macros: Sometimes I would like things done at compile time, especially if they have to do with types.

Overloading: Can be implemented with a decent macro system.

OO/functional: So many languages miss one. So few have both (Eiffel, O'Caml)

So many languages are so close, especially ones w/ active user communities, like perl and C++. They're just not there yet . . .

Re:Wish list

[Anonymous Coward]

Can't you do these things with LISP?

Re:Wish list

[jbrandon]

Lisp's "optional strong typing" is fundamnetally broken. Strongly typed polymorphism is particularly wrong, and object classes as types is barely working.

Re:Wish List

[smishra]

You are talking about OCaml. To your list I would like to add large set of high level standard libraries This is the only prerequisite that prevents me from using Ocaml in most of my work. R

Re:Wish List

[Anonymous Brave Guy]

The language MUST have these things built in: associate arrays, regular expressions, iterators, introspection, "here" documents, both static and dynamicly sized arrays.

Your description (and your example) look as though you like Perl, but find it mildly lacking in a few areas. Am I close?

Re:Wish List

[haystor]

The language you are looking for is Common Lisp.

Interactive, interpreted and native all coexist together. You can redeine functions on the fly. Its like having the full access of a good debugger and getting to use it on live code.

It can be made to be database savvy. As an example, some code I wrote just the other day:

(tran
(withdraw from-account amount)
(deposit to-account amount))

the tran function wasn't part of the language. I added that in 6 lines of code. Just try adding something like that to Java so that it looks like:
tran {
withdraw();
deposit();
}

Lisp is not dead yet, its still out there making a quiet few very happy.

Re:Wish List

[bwt]

I will check into OCaml. I know that on Bagley's Language Shootout, it scored comparable to C in speed, but it is obviously a much more modern language.

As to the standard libararies, I went back and forth on this. At some point you have to accept that if the language designer makes a good core language, that the community will arrive and handle ever expanding libraries. You can't "design" the community, so I left that off. Obviously it's desirable.

If OCaml would be your ideal language but for limited standard libraries, then you should treat this as an "itch" and scratch it by adding a library or two.

Re:Wish List

[bwt]

I do like perl, but I was not think of perl when I wrote that. Actually, the language "environment" that is closest to all of my desires amond those I have worked with is the duo of Jython and Java.

I would criticize this duo in several ways: why are they such different syntax? Also, in the big picture, when you compare to C and Pascal, Java is slow. I know there are native compilers like gcj, but they are an afterthought.

Re:Wish List

[Ian Bicking]

People talk Ocaml up a lot, but if it was so great why doesn't it have good libraries? Other languages have built good libraries of code in the same amount of time Ocaml has had to do so. I suspect that Ocaml might be too insular, thus hindering the use of external code.

Re:Wish list

[Junks Jerzey]

Strong typing: I'm tired of seeing casting errors at runtime.

If your goal is to be pragmatic, then strong typing is not something you want. There is getting to be more evidence that strong typing is a red herring. The people who insist on it get all hot and bothered by languages that don't have strong typing, but it sure isn't keeping other people from being super productive in Python (for example).

Here's a good read.

Re:Wish list

[jbrandon]

There are three main arguments against static typing:

1. Writing types is as (or more) error prone than letting the compiler fail on a cast.
Ans: Non-sequiter. See ML - I don't have to write types.

2. I need flexibility to change the type expected in client code without changing core code.
Ans: This is mostly answered by #1, but I ask the following to prove a point: how come nobody ever has an example where this is actually useful? Why is it that this is almost completely theorietical? Could it perhaps be that it is answered by OO.

3. Pythoners are productive
Ans: python's primitives and libraries are incredibly rich. I'm all for that, but it casts serious doubts on the validity of the assertion that static typing is no good.

3

Re:Wish list

[Junks Jerzey]

1. Writing types is as (or more) error prone than letting the compiler fail on a cast.
Ans: Non-sequiter. See ML - I don't have to write types.

You obviously don't know ML. You have to specifically name the constructors for user-defined types. That's essentially the same as having to "write types."

3. Pythoners are productive
Ans: python's primitives and libraries are incredibly rich. I'm all for that, but it casts serious doubts on the validity of the assertion that static typing is no good.

What it means is that you obviously don't need static typing in order to be very productive. It begs the question "So exactly what does one need static typing for?"

Re:Wish list

[jbrandon]

You obviously don't know ML. You have to specifically name the constructors for user-defined types. That's essentially the same as having to "write types."

I was thinking of the Caml variant, for which type deduction exists for many kinds of user-defined types. In fact, O'Caml comes very close to implementing "only-by-need" type specification, where leaving ot type information WILL lead to nasty errors in more dynamicly typed languages

In any case, no matter how wrong I am about whatever ML compiler/variant you use, type deduction is VERY good nowadays, and almost invisible (in uncompiled code) in many cases.

What it means is that you obviously don't need static typing in order to be very productive.

That's not my claim. My claim is that static typing increases productivity, all other things being equal, not that static typing is necessary for productivity.

Yes pythoners are productive. I just think they would be more so were python staticly typed.

Re:Wish list

[Junks Jerzey]

Yes pythoners are productive. I just think they would be more so were python staticly typed.

But you don't have any real basis for this, other than your opinion. From your use of the term "pythoners," I'd guess that you don't have extensive experience with the language, so you're really just trying to foist your views on a language community that you're not a part of. Go back and read the Bruce Eckel article I posted a link to in my original reply.

Re:Wish List

[smishra]

It depends on the kind of system you are building.

If you are building a small system and need a couple of libraries it makes sense to use a great language and write the couple of libraries yourself.

If you are building a largish system with many dependencies you may be better off with an inferior language but with large parts of the system prefabricated as standard libraries.

Re:Wish list

[jbrandon]

And now, no response as I answer all of the arguments Eckel makes. Come on, show us what you're made of!

Pragmatic License

[rossy]

Definition of pragmatic
1: concerned with practical matters;
2: of or concerning the theory of pragmatism
3: guided by practical experience and observation rather than theory;
extern int work(); extern int go_home(); main (argc,argv[]) { int employed; int not_dead; while ( employed && not_dead ) { employed = work(); not_dead = go_home(); }

Re:Pragmatic License

[nicware]

The local variables employed and not_dead are not initialized and we may never even enter the loop. ;)

Re:Pragmatic License

[Unordained]

i'm also not seeing type information on argc and argv, and neither is used (at least a compiler warning) ... also bad style (but correct syntax) using an int as an implied boolean ...

and what about retirement, dang it?

Strong emphasis from a GUI standpoint.

[xagon7]

We have PLENTY of generic memory moving, scriptable, and interpreted languages that can all perform the same command line batch processing.

I think we need a language that not only performs those operations but is built with Cross-platform GUI design in mind. I don't know HOW or even it it is simply another part of the standard libraries, but I think you you REALLY want you rlanguage to be successful it should be able to hook into existing GUI APIs and/or implement its own with ease and consistancy. If anything a strong enphasis of a GUI library is a must have.

Delphi (MAYBE VB) is the closest thing I have seen that allows this. Yes I know the "language" is object pascal, but the IDE allows for quick and semi-graceful GUI design.

In addition to that if you could implement a pointerless environment with automatic garbage in a FAST way it would be helpful...but allowing for manual overrides if necessary.

Let the elitist flames begin.

Re:Strong emphasis from a GUI standpoint.

[pbox]

You should try wxWindows + Python.

Pyhton: pointerless, automtic garbage coll, vary FAST if using psycho.

wxWindows: portable, yet platform optimized. Very good tools for design.

Re:Strong emphasis from a GUI standpoint.

[Arandir]

I think we need a language that not only performs those operations but is built with Cross-platform GUI design in mind.

But the real question will be, "Whose GUI?" It would be a real bummer if Microsoft got involved in the language committee, and everyone had to use something of theirs.

A better way is to *support* some common GUI constructs, such as signal/slots (callbacks) and events.

Re:Strong emphasis from a GUI standpoint.

[xagon7]

Will do, thanks!

I was wondering about a good GUI system for Python. I need to get up to speed on it it looks great.

Re:Strong emphasis from a GUI standpoint.

[Anonymous Coward]

...(MAYBE VB) is the closest thing I have seen that allows this.

I have considered deeply what you said here, and have carefully formulated my reply:

Noooooooooooooooo!

Re:Strong emphasis from a GUI standpoint.

[DavidNWelton]

Tcl/Tk does what you want, even though it's cool to put it down because it's not the latest thing.

Re:Strong emphasis from a GUI standpoint.

[Haeleth]

The language used by Delphi is called Delphi; it was renamed from Object Pascal some time ago when Borland found out about Apple's inferiorlanguage of that name. As a language it's actually not as bad as its Pascal ancestry would suggest; it has classes, multiple inheritance, typecasts, function and method overloading, and most of the other features of C++ that C++ programmers like to bash Pascal for not having. It has numerous mature libraries. Oh, and some elements (notably strings and dynamic arrays) are garbage-collected.

It compiles in milliseconds, with dependencies handled automatically. No makefiles, no five-minute build cycles a la GCC. C++Builder combines most of these features with C++, if the Pascal bit really offends you.

The two major problems are that it ISN'T cross-platform - Win32 and x86/Linux aren't good enough - and it's unfree in all senses.

For GUI prototyping, and in-house database applications, I know nothing to match it.

Re:Strong emphasis from a GUI standpoint.

[LWATCDR]

I have not played with it yet but I am very hopeful about it. The one down side to wxWindows+Python, Ruby, Perl, Tck/Tl, Java, and even .NET are the large runtimes they require. It is a shame but not every system out there has a good java runtime installed or .net framework. I would really like a native compile option. It would be really nice if I could just hand an EXE file to someone. The problem is not so bad for Java. I just use install anywhere and it installs the JVM.

Re:Strong emphasis from a GUI standpoint.

[GnuVince]

Quote bu xagon7: I think we need a language that not only performs those operations but is built with Cross-platform GUI design in mind. I don't know HOW or even it it is simply another part of the standard libraries, but I think you you REALLY want you rlanguage to be successful it should be able to hook into existing GUI APIs and/or implement its own with ease and consistancy. If anything a strong enphasis of a GUI library is a must have.

If you don't care too much for native GUI widgets, you can check out Squeak. It's very easy and very fun to build GUI's with Morphic and it's very well integrated

Re:Strong emphasis from a GUI standpoint.

[pbox]

Psyco is a very interesting concept for Python. It compiles python bytecode to native, but it is not JIT, rather it takes the code, analyzes it and compiles several versions, of which the optimal one is going to be chosen at runtime. You really need to check it out. It promises about 40% speedup on random py code, but about 400% speedup on algorhytmic code (that counts for scientific apps). that is almost as fast as the equivalent C code. His motto is "High-level languages are faster than low-level ones!"

Pyrex is also interesting, where you can use C concepts within Python. And the project Weave allows you to directly write C code into Pyhton. With careful design you can convert about 5-15% of your code to C and have an app that runs as fast as a C one, with about 20% of the development time.

Re:Strong emphasis from a GUI standpoint.

[pbox]

Here are some pointers:

Python: www.python.org
wxPython: www.wxpython.org
wxWindows (only if you want to roll your own wxPython): www.wxwindows.org
Psyco: psyco.sourceforge.net
Weave: www.scipy.org/site_content/weave
Pyrex: www.cosc.canterbury.ac.nz/~greg/python/Pyrex/
Num Py: numpy.sourceforge.net

Good luck.

Re:Strong emphasis from a GUI standpoint.

[LWATCDR]

Speed is not that big if an issue for many apps. Ease of deployment is. The big problem with java apps is not really the speed of the program. It is how long it takes to start. Why? because you have to load the JVM. The other problem with Java apps comes from having to load install the JVM if you do not have one already. The Microsoft JVM is so out of date as to be usless. There are not real problems for in house applications. But if you want a comercial app or on that is free to download it can be.

Re:Strong emphasis from a GUI standpoint.

[Ian Bicking]

You forgot PythonCard, for a somewhat easier/higher level/more visual way to do GUI programming (built ontop of wxPython).

The other links you give are mostly if you want to improve the performance of your application, which usually isn't a problem. The beginning Python programmer shouldn't look at those unless they have determined empirically that they really need those tools. (Unless you are interfacing C libraries, try Pyrex, or if you know that you will be doing heavy math, where you'd use NumPy or Weave)

... and for God's sake get it right this time!

[crmartin]

First thing: read Tony Hoare's critique of Ada. (CAR Hoare, Hints on Programming Language Design, 1978). All the current common languages are way too complex.

Second, make sure the language has a formal semantics from the start. This semantics needs to include concurrency and how it works. I can think of half a dozen languages (Ada, C++, Java, ...) in the last 20 years that decided this was just too hard, and eventually paid for it.

Third, make sure that the notation either explicitly uses files, or is completely independent of files. Probably the most annoying aspect of Java is that the package structure implicitly depends on a directory hierarchy (but some OS's don't have hierarchic file systemss) but doesn't deal with package structure in anything like the way hierarchic file systems do (what does 'import java.*.event' mean?)

Fourth, write a lot of sample programs, and test each with experienced programmers, saying 'what does this program do?' If the programmer doesn't get it approximately right, rethink the syntax.

Re:... and for God's sake get it right this time!

[WolfWithoutAClause]

This semantics needs to include concurrency and how it works. I can think of half a dozen languages (Ada, C++, Java, ...) in the last 20 years that decided this was just too hard, and eventually paid for it.

Do you know of any language or system that got this right?

Re:... and for God's sake get it right this time!

[martinde]

> Do you know of any language or system that got this right?

Well, VHDL, the hardware description language, has a formal semantics defined (in a book written by some friends of mine.) It also addresses concurrently explicitly in the standard, which is nice.

It's far from a useful general purpose programming language though.

Re:... and for God's sake get it right this time!

[crmartin]

Sadly, not offhand. But a significant step toward getting it right is by defining a semantics -- which is a step that Ada missed out on (at least in the original Ada, I've not had the moral strength to learn much about Ada95) and a weakness of Java as well.

Re:... and for God's sake get it right this time!

[crmartin]

Oh, just in case I misuinderstood -- there are languages which get a lot of the details right -- eg, Occam makes a pretty good job of defining a semantics for a limited model of concurrency based on Hoare's Communicating Sequential Processes.

Re: ... and for God's sake get it right this time!

[Black Parrot]

> First thing: read Tony Hoare's critique of Ada. (CAR Hoare, Hints on Programming Language Design, 1978). All the current common languages are way too complex.

I thought it was in his 1981 speech, but either way notice that he commented on the language before it was complete (1983). However, I understand that the language was simplified somewhat between the time of his remarks and the time it came out of the oven, possibly as a direct result of his comments.

> This semantics needs to include concurrency and how it works. I can think of half a dozen languages (Ada, C++, Java, ...) in the last 20 years that decided this was just too hard, and eventually paid for it.

Concurrency as in multitasking/multithreading? It's really easy in Ada, and it works quite well everywhere I've used it.

As an aside, it's quite apparent that the evolution of the C family of languages (C, C++, Java, C#) is converging on a language very like Ada, except unfortunately as a kludgepile rather than a clean design.

Just my opinion.

Re:... and for God's sake get it right this time!

[AtrN]

Occam did reasonably well at CSP things (Rob Pike's newsqueak did it better however) but fails at almost everything else.

I recall Inmos stating "We want to make occam the FORTRAN of parallel processing." My reply was "You have." (ref. to lack of data structuring other than fixed sized arrays).

It wasn't until the hacked up occam 2.5 that it got some better programming language features.

Re:... and for God's sake get it right this time!

[blancolioni]

First thing: read Tony Hoare's critique of Ada. (CAR Hoare, Hints on Programming Language Design, 1978). All the current common languages are way too complex.

1978? Ada wasn't standardised until 1983, though it was essentially complete by 1980. Hoare has had much nicer things to say since then.

Second, make sure the language has a formal semantics from the start. This semantics needs to include concurrency and how it works. I can think of half a dozen languages (Ada, C++, Java, ...) in the last 20 years that decided this was just too hard, and eventually paid for it.

Ada has this. Built-in concurrency, and carefully defined semantics.

Third, make sure that the notation either explicitly uses files, or is completely independent of files.

Oooh, Ada again. I think you secretly love this language which you were bagging earlier.

Fourth, write a lot of sample programs, and test each with experienced programmers, saying 'what does this program do?'

Ada is notoriously easy to understand.

Re:... and for God's sake get it right this time!

[jmb-d]

what does 'import java.*.event' mean?

According to the compiler, it means a syntax error:

foo.java:1: ';' expected
import java.*.event;
^
1 error

Re: ... and for God's sake get it right this time!

[crmartin]

I thought it was in his 1981 speech, ....

The cite could be wrong -- I was scrounging quickly on the net. In fact, thinking about it, it's almost certainly wrong, because the paper came out when I was in grad school, and I started in '83.

Concurrency as in multitasking/multithreading? It's really easy in Ada, and it works quite well everywhere I've used it.

The problem isn't that it works badly, necessarily -- it's that it doesn't work the same way everywhere. At least as of Ada 83, the semantics of a task were't the same from machine to machine. Made it a real bear to reason about the behavior of an Ada program.

Re:... and for God's sake get it right this time!

[crmartin]

Yes, exactly. But why? Since it looks so much like a path name (and represents a pathname to the compiler), why doesn't it do the same thing as ls foo/*/CVS, say?

Re:... and for God's sake get it right this time!

[crmartin]

Sorry, I didn't mean to give the impression I was particularly against Ada. I was very much on Ada's side, starting with Strawman. But it had some real flaws in the 83 version, which were mostly the result of specific weakenings of the semantics to make sure everyone liked it. The one that annoyed me most was task/rendezvous, which didn't (sorry) define the behavior of tasks at all well. In fact, a program could pass the Ada test suite if it didn't implement task concurrently at all, as I recall.

Ada 95 improved that a good bit -- I was involved slightly with the Ada 9x stuff, and one of the things we were struggling with was getting some things well-defined that previously weren't well defined. But part of the reason Ada95 was 12 years after Ada83 is that, having let it get out in the 83 form, it was really difficult to strengthen those expectations, because it would break existing code.

It's a lot easier to make sure to think these things out first try.

Re:... and for God's sake get it right this time!

[jmb-d]

Since it looks so much like a path name (and represents a pathname to the compiler)

Close.

It represents a namespace to the compiler.

To the JVM, it represents a path to a particular class (or set of classes if you use the * notation). That path can be found in either the directories or the .jar files in your CLASSPATH.

why doesn't it do the same thing as ls foo/*/CVS

Isn't it the shell that does the expansion of the * (as opposed to ls)?

An import statement serves the purpose of declaring a namespace, so that you can just refer to WindowAdapter, rather than java.awt.event.WindowAdapter within your code. By using

import java.awt.event.*;

you can refer to ANY class within the java.awt.event package by its basename.

The only time you run into problems is if you want to use a classname that exists in more than one package, such as Date, which exists in both the java.util and java.sql packages. In that case, you can't say

import java.sql.Date;
import java.util.Date;
...
Date d = new Date;

because the compiler won't know which one you want.

Re:... and for God's sake get it right this time!

[crmartin]

You're missing the point in a couple of ways.

First, unfortunately, the package name does not represent just a name space to the compiler. javac as distributed by Sun, and every other implementation of Java I'm aware of (with the exception of the late lamented Visual Age for Java), requires the package naming structure to correspond 1-1 with a path tree structure.

You're misunderstanding the namespace notion a bit though: If I import java.util.Date, I'm not adding a namespace, I'm adding a name to my current namespace or scope. import java.util.* might be thought of as importing a name space, or at least adding a collection of fully qualified names to the current name space. But if we see a wildcarded import that way, why shouldn't import java.*.Date bring both names into the name space? (Answer: because they'd still have to be referred to by fully-qualified names. But then, since there is no difference, why make it a syntax error?)

The point here is that Java purports to construct a hierarchically-organized namespace, but doesn't actually do so. (Thought experiment: what's the effective difference between import com.foo.bar.* and import com-foo-bar.*? Ans: none except that you don't have to have a directory tree four deep for your sources.)

Oh, and as far as your ls point: don't try to teach Grandma to suck eggs, son.

Re:... and for God's sake get it right this time!

[Tablizer]

This semantics needs to include concurrency and how it works.

As a database fan, I say farm concurrency off to the database (perhaps a local lite one if need be). Databases already have all kinds of currency control, so why reinvent that all in a language? Just launch separate processes and let them all communicate via the database.

True, my niche is business software and not systems software nor weather prediction, so the needs of my niche may be different. But, that is the problem with one-size-fits-all languages anyhow. Each domain has different needs and priorities.

Re:... and for God's sake get it right this time!

[Anonymous Coward]

The compiler can query for specific package+class names, but the package hierarchy can't be exhaustively searched. Otherwise implementing URLClassLoader would be impossible--you can't ask a Web server "which paths contain Date.class?" (unless it happens to be one of the few that support WebDAV). Your proposal would have javac require that all classfiles be stored on a searchable filesystem (a serious nuisance) just to extend a construct that is best avoided anyway.

Re:... and for God's sake get it right this time!

[crmartin]

... and we therefore discover that the semantics of import are tightly coupled to the notion of a hierarchical file system -- which was the point, wasn't it?

Re:... and for God's sake get it right this time!

[crmartin]

As a database fan, I say farm concurrency off to the database...

But, as someone or other undoubtedly said, quis custodiet ipsos databases? Someone has to write the damned things.

(Plus, there are a lot of things other than databases which need concurrency control, eg, an operating system kernel.)

Re:... and for God's sake get it right this time!

[Anonymous Coward]

The only sematics of import are "classes I name might be found in this package." Package names are usually written hierarchially because we understand that way of representing a taxonomy, but there platform doesn't mandate any hierarchial relationship between classes in separate packages, no matter what the package names are. You certainly aren't required to store your source in a hierarchy, though it can be convenient (because javac can guess where the source for a missing classfile might be found, and recursively compile it).

That's why "import java.util.*" is implemented but "import java.*.Date" is not--javac may be using a classloader for which "find any Date class in any package whose name begins with java" is impossible, because storing classes in files in a hierarchy isn't required.

Re:... and for God's sake get it right this time!

[Tablizer]

But, as someone or other undoubtedly said, quis custodiet ipsos databases? Someone has to write the damned things.

Yes, but I was generally talking about a specific niche.

Re:... and for God's sake get it right this time!

[crmartin]

Oh, come on, this is silly. If the name space is in any way visible to the compiler, then matching the regular expression 'java.*Date' is not significantly harder than 'java\.util\..*' -- and if the name space is not visible to the compiler, then no import scheme will work.

Re:... and for God's sake get it right this time!

[Anonymous Coward]

javac can't rely on an exhaustive list of package or class names to search against--with backends like URLClassLoader that information simply doesn't exist. All javac can do is check against a finite list of imported packages until it finds the right one: "is there a java.lang.Date? no? how about java.util.Date?"

Re:... and for God's sake get it right this time!

[twalk]

VHDL & verilog both have serious concurrency problems. As an engineer you have to either A) design a system without any potential fundamental concurrency problems, or B) write your design without these problems from your knowledge of how both the simulator and sythesis tool will handle that section of code.

The problem is that synthesis of these languages has different assumptions than the simulation. This is like having a version of C++ that runs differently in the debugger than it does compilied (and sometimes that even happens...).

Take a look at Handel-C.

Re:... and for God's sake get it right this time!

[martinde]

The semantics of concurrency are well defined for VHDL simulation (as long as you're sane and avoid global shared variables, although those are fixed in the 200x LRM as well.) Of course, even with well-defined semantics you can implement systems with deadlocks and race conditions, and VHDL doesn't have high-level primitives like monitors to help you deal sanely with some of the issues.

And you're right that for synthesis there are whole rats-nests of tool-specific issues. The state of HDL synthesis is quite disappointing and seems to have ground to a halt.

I have no experience with Verilog but what I have heard agrees with your assertions very well. I'll check out Handel-C sometime.

Not interpreted! Make it compile!

[pjack76]

Am I the only one who misses compilers? It would be nice to be able to write a native app that required no more overhead than the operating system libraries. An application that I could distribute without informing people that they need to install an elaborate execution engine first. (And anyway, there are so many good interpreted languages these days that I don't think we need another).

Also, minimize the feature set provided by the language; provide a small set of flexible features, like macros (the ability to alter the parse trees manually at compile-time). I don't like C because I have to keep track of a thousand different concepts to understand its code.

Also, a strong standard library for things like strings and sorting, so I don't have eight million choices.

Re:Not interpreted! Make it compile!

[Arandir]

Ditto! As a systems programmer, I have a definite need for compiled languages, as well as interpreted scripts. But it seems that everyone is all gungho over interpreted or byte-code languages.

I think it would be really cool to have a Ruby compiler. But I suppose it would end up like the gcj compiler, and not give you much of a benefit because of the runtime overhead.

Re:Not interpreted! Make it compile!

[brlewis]

The only reason C can compile and then just run with "operating system libraries" is that your operating system always has C libraries. If your OS always came with PLT Scheme libraries by default, you could just distribute PLT executables, etc.

Re:Not interpreted! Make it compile!

[cyberlync]

I am one of the core group creating this and we agree.

We are going to try to supply multiple backends, one or more of which will compile to native code. We already have suggestions in place to target C-- and GCC as backends.

Re:Not interpreted! Make it compile!

[Anonymous Coward]

Sounds like you want Forth.

Re:Not interpreted! Make it compile!

[istartedi]

Better yet, it should do both!

Interpretation has fantastic potential for real-time "what happens if I change this line" type stuff because an interpreter can cull large portions of the program. Of course, this issue will eventually be rendered moot by storage that works as fast as memory, allowing recompiles to happen in less than 1/24th of a second for all but the largest programs. If recompiles happen that quickly, you get a suitable "frame rate" and the algorithmic advantage of the interpreter is overcome by brute force.

So, if forced to choose, build only the compiler because technological progress will eventually moot the interpreter.

An interesting side note: I've been told that when gcc was designed, existing C compilers wouldn't run on smaller computers because they created parse-trees in memory. gcc was more memory efficient, which enabled it to run on more humble machines. However, the design of gcc is more difficult to modify and doesn't easily produce optimized code. These days, storing a parse-tree in memory is no problem for anybody. Whether this is true about gcc or not, it illustrates an important point: If you choose a design without considering where technology will be in the future, you could get hog-tied to code that was designed to overcome a temporary problem.

Oh, and the guy with the other thread who was talking about GUIs? Make sure you can easily write a visual builder using the API. Then, make sure you can load the code for the visual builder into the visual builder. In other words, write a self-building visual builder. That would rock!

Self-compiling is considered the acid test for a compiler. It should be likewise for a visual builder.

Re:Not interpreted! Make it compile!

[Anonymous Coward]

Aren't there Ruby compilers? I have no idea if they work or work well, but I know I've see them...

Lisp

[Zach Garner]

Just give me Lisp with some syntactic sugar, a nicely standardized interpreter and library, and a wxWindows port.

Re:Lisp

[dtolton]

I totally second that. I've become really fascinated with Lisp through reading Paul Graham's web site. It's interesting to note that his views seem to be widely held by many respected computer scientists. Lisp may be difficult to read compared to a standard imperative language, but the power and flexibility it offers are unparalleled IMO.

Since my company will *never* standardize on Lisp, it looks like we are going to standardize on Python, which isn't as powerful but is certainly more readeable for the masses. I will say that Python is very impressive, it is very cleanly designed, extrememly powerful and amazingly fast.

Re:Lisp

[pfannenschmied]

For a decent Lisp-Python comparison check out Peter Norvig's page. It's intended for Lisp programmers coming to Python, but seems to also help a bit for those travelling in the other direction.

Re:Lisp

[Ian Bicking]

Hmm... Dylan? Rebol? (Rebol = Logo = Lisp)

What about a graphical language

[Anonymous Coward]

I'm not sure we need another text based language ( ok, I'm not actually a programmer - just dabble a bit ). But isn't it about time we had a graphical language. After all, most software designs do utilise graphs of data types and flows - UML?. Not sure how it would work, or how it could be more than a glorified flow chart. But it may end up being easier to program debug etc. After all - a pictures worth a thousand works.

Re:What about a graphical language

[crmartin]

I actually did my PhD and Masters' work with the idea originally being to develop a visual or direct-manipulation (see Ben Schneiderman's stuff if you don't know the term) programming environment. You know what happened? I went to Fred Brooks' original "No Silver Bullet" presentation (see the paper to see the details) and found that I couldn't manage to refute his arguments. (I hate it when that happens. :-)

The basic argument is this: are the complexities of notation (language, whatever) essential or accidental aspects of the difficulties in programming? Brooks' argument is that the notation is an accidental issue -- that you can't gain, say, an order of magnitude improvement by chaning notation alone.

This is clearly not 100 percent true 100 percent of the time -- "drawing" a GUI with something like Powerbuilder, Eclipse, or JBuilder is clearly a lot more effective than coding it, even with EMACS. On the other hand, in real industrial development, actual coding is only about 15 percent of the total time and cost invested -- so no matter how wonderful the language is, it can't possibly account for more than about a 15 percent improvement.

Re:What about a graphical language

[Jerf]

"drawing" a GUI with something like Powerbuilder, Eclipse, or JBuilder is clearly a lot more effective than coding it, even with EMACS.

Is it? I've started coding my GUIs largely by hand and I can make them sing and dance in ways that users love, and forms-based builders can't even think about approaching. It's only more effective for highly static GUI panels, and the reality is nearly nothing should be static, it should be getting generated from external, easy-manipulable data sources. The forms builders afford (in the user-interface sense) poor and lazy (in a bad way) design.

Just a thought to add to the pile. ;-)

Re:What about a graphical language

[Josh Booth]

...notation is an accidental issue -- that you can't gain, say, an order of magnitude improvement by chaning notation alone.

Sort of like how things are added to C like dynamically typed object oriented programming (GObject), namespaces (by prefixing functions with a namespace), generic lists, hash tables, UTF-8 string manipulation, etc (GLib), arbitrary precision math (GMP). They are added not by syntax, which may make things somewhat simpler, but not significantly so.

typedef struct {
int bar;
} Foo

Foo *foo_new(void);
Foo *foo_copy(Foo *);
void foo_delete(Foo *);

void foo_set_bar(Foo *, int bar);
int foo_get_bar(Foo *);

That's not too much different from C++:

class Foo {

public:
Foo();
Foo(const Foo &);
~Foo();

void setBar(int);
int getBar();

private:
int bar;
};

Re:What about a graphical language

[crmartin]

That's my experience too: I tend to draw the early versions, especially when you have to twiddle it a lot for the customer, and then re-code it by hand afterwards to get it to, as you say, sing and dance.

But most UIs have great chunks that are pretty static.

Re:What about a graphical language

[GnuVince]

I think you should check out this video. It's a part of a presentation Alan Kay gave at an O'Reilly conference. He demonstrates the power of Squeak with a simple example: he draws a car and steering wheel. Next, using only his mouse he makes the car go forward and turn accordingly to the heading of the wheel. Now, maybe not much advanced stuff can be done with eToys (I don't know, I write code myself in Squeak), but I think it's a road worth exploring. I mean, he just takes properties of the steering, drags them into a method of the car and it's all very easy and natural.

Anyway, check it out, maybe that's the beginning of something you dream of. Be sure to get a copy of Squeak to experiment too, it's a whole lot of fun (despite what some C/C++ people might say)

Re:What about a graphical language

[Zirnike]

Well, what I found in the article is fairly short (maybe there's more under a different heading, but I just couldn't read the whole thing). But I would think that if it were approached differently than as a flow chart, it might be useful.

For example, you'd want it to be OO. You can make each object easy enough on a separate page. Define an 'interface', inheritance, etc. as 'plug-in' shapes. For example, maybe a triangle... Then it could plug into whatever uses it. If you need to use an interface, tell it to, and the 'shape' of the object changes to give you a place to plug in the other object. If you need to create that object, then color it the same way, so color would be a 'created by/creator of' indicator (perhaps darker shades being higher in the 'chain'...). A third indicator could be border type...

The global variables you would need to plug in would be 'held' in an independent object, and connected to objects that need to use them. But if you 'focus' on the global object, you could see where the data is used (and if you use arrows, you could tell where it is modified as well... point the head at the object if it receives the data but doesn't update it, and at the global object if the other one does update the value)

Sure, it wouldn't be useful for anything beyond low-middle complexity programs, but it would make simple programs easier for low level coders (like me, I'll admit... I could use someone teaching me how to use Python or something (I've got basic knowledge of BASIC, Pascal, FORTRAN, and rudimentary C)). And I THINK it might be able to be used as a code browser for any OO program... I sort of 'designed' it in a way that it would work for Java. So you could see the real code for it, even if you used the graphical interface to build it.

I was thinking about the idea based on the graphical web browsing things that have been popping up. Click on a node, and the focus shifts to what connects directly to that node with the stuff connected to those 'fading out' into the distance, etc.

I think it's doable, but I'm not sure it would be useful to serious coders except for certain specific types of debugging. On the other hand, the world isn't made up of all serious coders...

Re:What about a graphical language

[crmartin]

You're on a good couple of points here.

Let's consider serious programming first: I think Brooks' points really make excellent sense for things like kernel programming, building high-performance application servers, etc -- real systems progamming. The issues here are just not that it takes too long to express the idea in code -- the problem is figuring out the freakin' answer. (And take as read the rant about how just because programmers write code, it doesn't mean everyone who writes code is really a programmer.)

On the other hand, visual programming of various sorts, specialized to a particular problem domain, is a major advantage, and your example of spreadsheets is a perfect one. I used to maintain a program for making quick changes and test runs on a balance sheet. It was many many lines of APL, and it worked pretty well (and if I had just made a single conceptual step, I would have invented the spreadsheet. Damn.)

Now, these applications are built, in minutes, by people who would never think they were programming at all. All by using what Ben Shneiderman calls a "direct manipulation" interface. But what they are effectively doing is programming.

Give me every feature and make it fast.

[Pyromage]

Every language feature has use. Pointers, references, pointers to pointers, pointers to functions, reflection, OO, templates, multiple inheritance, interfaces, enforced contracts, garbage collection, manual resource management, virtual machine, native execution.

All these features have uses. There is always 5 cases for every single one where it's *much* easier to implement while using it.

Now abandon backwards compatibility and think up reasonable syntax. I don't know if it's possible to do an elegant language with all that, but if it is, I think we should have one. Every other language lacks some of the above features. I would like to see a langauge that really had everything.

Re:Give me every feature and make it fast.

[Jerf]

I don't know if it's possible to do an elegant language with all that, but if it is, I think we should have one. Every other language lacks some of the above features. I would like to see a langauge that really had everything.

It's not. Seriously. The closest thing to what you mentioned is C++, with some external libraries added for things like garbage collection.

A lot of your features collide. Having pointers and references makes it very difficult for the GC, and you can typically get into situations where the GC is lost. (Unless by "pointers" you mean what is called "smart pointers" in C++, which will slow down you down). Having manual resource management and automatic GC is asking for pain. Enforced contracts + templates + multiple inheritance + interfaces (esp. as interfaces are a hack around Java not having multiple inheritance!) is asking for pain; I can't even imagine the syntax.

Virtual machine + native execution is almost, but not quite contradictory; the best way to accomplish that is to blur the distinction which we've already got. Is Java + JIT, or C# + JIT, running in a virtual machine or natively? Basically, the answer is "yes".

Remember that every language feature interacts with every other one and necessarily complicates the language. Like I said, C++ is the closest thing to meeting everything on that list, and it's notoriously complex... and it's not because they "like" it that way, it's because it has to be. Throwing more stuff on top of it won't help.

"Perfection is not acheived when there is nothing left to add, but when there is nothing left to take away." The art of langauge design right now is not to throw the kitchen sink in, but to figure out what features we truly need to get the job done well, and which features afford (in the user interface sense) bad designs.

Re:Give me every feature and make it fast.

[renoX]

> Enforced contracts + templates + multiple inheritance

Eiffel has all these feature with a nice syntax.
Eiffle do not have interface, but I don't see the difference between interfaces and abstract virtual base classes, when you have multiple inheritence.

Apparently, it is quite possible to have both GC and manual memory management: C# have it..
I like the idea of having GC by default (secure and easy to use) and still being able to manage memory "by hand" if there is a need.

Oh and I disagree that C++ *has* to be that complex: Eiffel has multiple-inheritence, templates,etc.. and its syntax is very nice..

Re:Give me every feature and make it fast.

[Anonymous Brave Guy]

Eiffel has multiple-inheritence, templates,etc.. and its syntax is very nice..

!!like_hell_it_is

j/k

Re:Give me every feature and make it fast.

[renoX]

I'm not sure if you're agreeing or desagreeing with me.

Yes to create a new object you use !! in Eiffel, it could be better true but still its syntax is far more elegant than C++, no?

I think that the best syntax to create an object is in Limbo (a script language in Plan9), you can say:
var_name: type_name; as in Pascal but you can also say other_var := var_name; which is equivalent to say other_var: type_name; other_var = var_name;

Nice, no? This way when you change the type of var_name, you change also the type of other_var..

Re:Give me every feature and make it fast.

[William Tanksley]

Eiffel is nice, but it's contravariant. Ew. Sather gets this right.

And, as a bonus, Sather has a NICE inheritance system -- any class can be used as though it were an interface, and you can import functionality from any class without exposing its interface to others. This makes writing delegates enormously easier (and also just plain makes sense).

-Billy

Re:Give me every feature and make it fast.

[Procyon101]

A smart pointer with no functionality is just as fast as a dumb pointer in C++ as the redirects are taken care of at compile time. Speed hits in smart pointers only come from added funtionality you put into the smart pointer.

i've leart one thing ...

[sir_cello]

that there is no "one language", there are multiple languages for multiple purposes, and the boundaries between languages are often blurred (just like everything else in life).

in addition to making your case (as stated by other poster), also
- what particular context/problem are you trying to solve;
- what are the specific characteristics and issues in that context/problem;
- how does your new language provide a better solution than other solutions;
- how does your new language stand up on theoretical issues (looking at the science of design of languages themselves)

if there's an existing well used language that is "close" to what you want, and such language has quite a following/momentum, then can you try to adapt/evolve it rather than creating a dud language that goes nowhere (a waste of time for everyone). do you really need a new language, or do you need to help educate on the use of an existing language (i.e. are you more about process than product).

Re:i've leart one thing ...

[Anonymous Brave Guy]

Damn, where are my mod points when I need them?

This post has hit the mark exactly. You can't create a good solution until you understand the problem, and different problems require different solutions.

My Wish List....

[Tsali]

- Strongly typed. Or weakly typed, but have a smart compiler that could figure out what you mean. (Java/.NET)

- Generic design patterns that you could "plug" into via some sort of object and run from there.
(Sorta future Java/.Net, but more ambitious).

- *Simple* GUI classes included to get a GUI up and running (old VB). Facade pattern to get under the hood and hit native libraries if need be. (SWT, perhaps, but that's a stretch)

- A GUI library that reads XML definitions either at design/run time as well. (Mozilla)

- No monster corporation owning it. (Python and other OSS!)

- Braces (Java/C#) - optional Python :-)

- A language that *forces* refactorings, i.e., you can only have four temp variables per subroutine, loops that can only span so many lines, etc.

- With/End With syntax (although, again, if you refactor properly, you don't really need this).

- Checked exceptions (Java).

- Centralized error handling (no language really does that natively - .NET is a hack for WinForms and you could probably sneak it in Java, but there should be something that easily catches everything).

- Did I mention OOP? That *has* to be there.

- Allow for global spaces. Singleton/Borg patterns are messy. Sometimes you just want to declare the damn thing and be done with it.

Would I want speed for all this? It almost doesn't matter because we have chips that are nearing Mach 3.

There's my list. When the language is done, let me know and I'll shell out (or sell out) for it.

Re:My Wish List....

[Tablizer]

Strongly typed. Or weakly typed, but have a smart compiler that could figure out what you mean.....

When languages get that smart, we progably will not need programmers anymore.

Re:My Wish List....

[vbweenie]

GHC (Glasgow Haskell Compiler) does type inference just fine. Not that this makes programming in Haskell that much easier...

Re:My Wish List....

[stonecypher]

Other than forcing refactorings, which seems silly to me (some things cannot be refactored to four functions; why set arbitrary limits?) you seem to be talking about Delphi.

Maybe Oz

[Szplug]

though Oz is a bit wilder than most mainstream languages.

Get the book free while you can; it's gotten high praise, a real treat for getting a wide view of different styles of computer programming. It compares favorably with SICS.

Re:Maybe Oz

[crmartin]

BTW, I just downloaded Mozart/Oz and am building it as we speak. Looks fascinating. Thanks.

Just one language?

[Skeme]

Why stop there? We need as many languages as we can get, especially in today's economy and job market.

Re:Just one language?

[Anonymous Coward]

Why stop there? We need as many languages as we can get, especially in today's economy and job market.

Like one with Indian key-words?

Re:Just one language?

[blibbleblobble]

"Why stop there? We need as many languages as we can get"

Three Rippers for the Java-kings compiling on-the-fly,
Seven for the Mac-lords in their cases of gemstone,
Nine for Mortal Windows doomed to die,
One for the Dark Lord on his dark throne
In the Land of POSIX where the Programmers lie.
One Ripper to rule them all, One Ripper to cut them,
One Ripper to encode them all and in the darkness tag them
In the Land of POSIX where the Programmers lie.

There are plenty of great languages not being used

[soft_guy]

What's the point of designing a better programming language when I have to use C++ anyway if I want to work.

Dylan and Objective-C are examples of really good languages not widely used for commercial development, unless you are a Mac programmer doing cocoa with Obj-C. (I have recently been lucky enough to be writing code using Objective-C++ for a living!)

C++ is not the best language in the world, but its not terrible and I've been able to consistantly find work doing C and C++.

patterns not really possible in language

[Jerf]

Generic design patterns that you could "plug" into via some sort of object and run from there.

For what it's worth, either you can trivially do that now (like Singleton), or it's effectively impossible (like MVC). IIRC, "the" Patterns book explicitly disclaims the possibility of this, because they're just too high-level.

As a concrete for-instance, Python has first class support for "Iterators". But they are very specific iterators, and there's a discussion going on right now in the newsgroup about a slightly different sort of iterator, one that you could tell was empty. The type of "iterator" Python natively supports can't do that (it's a minimal commitment iterator, meant to be used in situations where you may not know whether the iterator is empty until you try it, and I've used this property before), yet that doesn't make it the One True Iterator; there's a place for iterators that know they are empty, or can be rewound, etc.

If that's the kind of support you want, you can have it, but that's not really full Pattern support, more like Pattern-inspired features.

I'll refrain from most of my other criticisms since they are matters of taste... oh hell, Bruce-Eckel-on-checked-exceptions-I'd-kill-myself- if-I-had-to-use-them. *gasp* sorry, had to toss that one in. ;-)

Re:patterns not really possible in language

[Tsali]

Everyone has a different wish list, and most of mine was fiction.... I was trying to be - you know - pragmatic. :-)

Wish List

[bwt]

I'd like a language that could run in three different modes: interactive interpreted form, highly portable runtime form, and full natvie speed optimized form. Give me common syntax for each and let them interact. For example, if you want to, you can use Jython to script java code. If you need something to be really fact, you write it in C and us the native interface. Why do I have to learn three syntaxes for this? OK, Jython is dynamically type and Java is statically typed.

Give me both OO abstraction and powerful bit-twiddling capabilities. If I want a 29 bit variable type, dammit I want a 29 bit variable type. Give it to me and let me do all kinds of low level stuff like shift three bits and mask it and treat the first 3 bytes as a unit. Then let me encapsilate that in an object oriented lock box.

The language MUST have these things built in: associate arrays, regular expressions, iterators, introspection, "here" documents, both static and dynamicly sized arrays.

The language should be database savy. This means implicit SQL cursors (like in SQLJ or PL/SQL) so that I can say something like

DBI_DRIVER.set(driver)
DBI_DRIVER.login(dbname, user, passwd)
for current_employee in {{
select emp_name, salary, start_date
from employee
where dept_no = $department }}
do
{{update employee set salary = salary + $accounting.calulate_bonus}}
end"

I agree, but..

[SiMac]

I agree; we need something that's designed from scratch to compile. However, we do have a few options already. Most notably, there's perlcc, which compiles Perl into C code and then compiles that into machine code.

So long as it compiles in to object code.

[AxelTorvalds]

I was just marvelling at the new Mandrake compiler RPMs and how they now have C, C++, Objective-C, Ada(95), Fortran, Java and Pascal all supported in there. Very cool. I don't know why, I haven't coded a line of Pascal in over 10 years but it just feels right having a pascal compiler sitting around. There are some programs that are amazingly easy to read and write in pascal... I never seemed to have stack or buffer overflows in pascal..

I've thought about this a bunch over the last few years. IBM has the PL series of languages. PL/S and PL/X were deamed "strategic" and as such they were never standardized outside IBM, yet IBM continued and still continues to use them for different tasks. There are reams of code written in them and REXX, another IBMism. Lucent has a dozen languages for their own use. Modula-3 started as a DEC thing before is was kind of opened to the world (damn beautiful language I might add, if only more people used it and DECpaq-Hewlet relicensed the gcc front-end code so we could integrate it..) MS has their BASICs and now C#. And numerous other companies have found it either advantageous or some engineer got it in his head that it was a good idea for them to produce their own custom langauge and that they could produce apps in it faster than by using off the shelf components. To some degree I think it's true, you'd be surprised at some of the REXX that holds the world together. I've kind of thought that it was time for an OpenSource language of sorts, there is perl, python, ruby and others but something that can be compiled in to real high performance object code and something that helps us solve the problems we run in to.

I'll tell you what I think would be killer, in my rambling sort of way. Syntax is key just because people are picky about it, something java like would be great. Make it a front-end to gcc, this gives it a sense of credibility and support and a great optimizer and platform support. Build it so it can easily link with C code. Give it bounds checking and type checking. I thinking it will be very C like for the most part; have that light weight feel to it where you can see the opcodes that the compiler is going to produce as you write in it. Give it objects and classes, but make it light weight on the syntax, building new classes in java requires a new file, doing it in C++ can be feel like lifting the titanic some times because it's proper to add headers as well as implementations. Then with the standard class library, it needs some fundamental object classes like strings (I can't believe how long it was for a standard C++ string class to exist, i've use about a dozen different ones prior...) and sockets (make OpenSSL as close to a boolean flag as you reasonably can...) probably some others I'm not thinking of at the moment. Keep them lean and mean like they are in C but beef up the areas of weekness. Some sort of regular expression engine should be available also.

For example, strcpy shouldn't exist or there should be some kind of type checking to verify that the inputs are indeed strings and it allocates memory. memcpy is missing several arguments, notably the source and destination sizes. I can probably list dozens of C and C++ problems are aren't language issues so much as library issues that have realworld impact and cause real problems. Now the first class objects that are passed in to strcpy or memcpy (whatever they get called in this new language) could have the missing pieces of information or the API can be built to support it. Basically, I'm suggesting that we add the few instructions it takes to do bounds checking, it's simple code to add to a c compiler. Let's get rid of buffer overflows as much as we reasonably can with the under lying language. Now if you want to do tricky shit with pointers then so be it but if you use standard language constructs (functions will have in and in-out parameters like the C++ & qualifier.) then you should be pretty safe from buffer overflows. With good type checking and such w

Re:So long as it compiles in to object code.

[bstanton0101]

How often have software patches been released to fix a buffer overload? It seems like every other week! A language which has built-in bounds checking, maybe by declaring arrays in a special way, would be great. Command-line programs are a dinosaur. We need a language that displays windows, buttons, text, drop-down dialogs, etc. that aren't tied to Win32, or GTK, or Qt.

The 100 year language

[t482]

I think that Alan Kay was way ahead of his time - getting kids to program. I think much like the spreadsheet revolutionized office work by allowing dynamic analysis of data the next big language will be one that is simple enough to allow average office workers to speed up and automate their own work. Abstraction is key.

VBA is being used currently for a lot of that work - but it is truly horrible. Wharton has started teaching its MBA students Python.

Check out what Paul Graham has to say about programming languages in 100 years (basically they won't change much).
http://www.paulgraham.com/hundred.html
And Artima had a discussion on this topic, "After Java and C# - what is next?". http://www.artima.com/weblogs/viewpost.jsp?thread= 6543

Re:The 100 year language

[zero_offset]

VBA is being used currently for a lot of that work - but it is truly horrible.

VBA is isn't horrible. It's the MS Office object models that are pure cluster fucks.

However, what's truly horrible is the code that those same self-taught average office works write. I didn't get the impression that was their target, but if it was, they'd have their work cut out for them.

In my experience, the average office worker's explorations of VBA always follow the same path... they discover it and play with it... they build something useful with it... the useful thing is shared with other workers... it becomes a critical business tool... it fails miserably (possibly causing lots of confusion and/or costing a lot of money)... then it's thrown over the fence to IT for an emergency-fix... What does it do? "We don't know, we just have to run it every morning. It was written by that guy who quit last year. It worked until yesterday."

If these pragmatic-language guys ever decide to tackle the non-professional-programmer experience, they REALLY have their work cut out for them -- and not even the best language in the world can solve the problem of a really badly-designed object model.

Re:The 100 year language

[crmartin]

VBA is isn't horrible.

Yes it is.

Re:The 100 year language

[Tablizer]

think much like the spreadsheet revolutionized office work by allowing dynamic analysis of data the next big language will be one that is simple enough to allow average office workers to speed up and automate their own work. Abstraction is key.

I disagree. Abstraction just confuses newbies. Lotus-123 macros were the closest I ever saw to self-taught programming on a wide scale, and it was because workers could gradually add to their existing knowledge of spreadsheets rather than start over. Also, 123 macros were based on keystroke conventions that spreadsheet formulas already used. The key is leveraging existing knowledge and incrimental learning based on existing knowledge of a tool.

(And indeed MS Excell VBA killed that trend.)

No Need I Just Released What You Need.

[monk]

I offer as the pragmatic language of the future, Toadskin. It's all you need. It has all the power of BrainF**k and all the friendliness of Forth. So let's get those HR systems ported folks!

Re:No Need I Just Released What You Need.

[Anonymous Coward]

This looks like it supports extraneous non-whitespace characters. Too verbose for me...

Re:No Need I Just Released What You Need.

[monk]

You'll appreciate whitespace and colorForth then. ;)

My PL pains

[Tom7]

The worst missing features in most programming languages that I sometimes have to use:

- lack of sum types. Languages have long offered conjunctions (structs in C, tuples in python). Disjunctions are equally useful. (With it, a function could return one of two possible types. The overuse of 'null' as "the other pointer" in C/C++/Java accounts for a tiny corner of the possibilities here.)

- lack of higher-order, nested functions. You can do so so much with functions once they are first-class in your language. All this stuff about iterators over containers in Java and "I want SQL built into my language so I can say for each employee in query do" is subsumed by map/fold operations and higher order functions, for starters.

- lack of safety. Man, I sure hate tracking down memory corruption bugs, and I sure hate it when there's an exploitable security hole in my or someone else's code because of them.

I already have languages with these features and more, so I don't need recommendations. But if your new sparkling language doesn't have these features... then what are you doing?!?

Re:My PL pains

[tigersha]

Ah yes, 15 votes for you. Sum types are the greatest. They sumsube enumerators too (as in Color := Red | Blue | Green) which is another moan in Java.

Sum types also take care of the crap where a numeric type is used to idicate some value or -1 to indicate an absence of value and things like that. Something like x := Found Int | Notfound.

Re:My PL pains

[Tom7]

Indeed. With sum types you can get rid of the dreaded null pointer -- you have "real" pointer types, and then you have "optional" types like you mention with Found/NotFound. Now, not only does it force a check before using the potentially "null" pointer, but once you check it you know it really points to some object and you don't ever need to check again. It's painfully obvious once you've programmed like that, but somehow people continue to miss out on this feature because, I guess, it was never in C.

Taking it a step further, recursive sum types like in SML can be used to define recursive data types like lists and trees, and then pattern match against them. That's so nice compared to the way you'd do it in Java or C++.

Re:My PL pains

[Anonymous Brave Guy]

Taking it a step further, recursive sum types like in SML can be used to define recursive data types like lists and trees, and then pattern match against them. That's so nice compared to the way you'd do it in Java or C++.

Isn't it funny how, eventually, you can usually rely on good concepts to drift down from theoretically strong languages into the practical tools?

Andrei Alexandrescu, known in the C++ world for the miracles he performs with templates in his library code (a subject about which he literally wrote the book), produced an article on what he termed "discriminated unions" for the C/C++ Users Journal a few months back. It made quite an interesting read.

You can actually do quite a lot of the good stuff with C++, but somehow it's always a bit like Microsoft trying to force OO concepts into Visual Basic.Net: the general idea is there, but it never has quite the power or elegance of the original that you'd find in a language that was actually good at it.

Oh, for a language with the flexibility and strengths of C++, but also the sum types, pattern matching, closures and first order functions of ML and the text processing tools from Perl... :-)

Re:There are plenty of great languages not being u

[Anonymous Coward]

No, C++ is in fact terrible.

Holy War

[Tablizer]

I have been in a jillion language and paradigm wars over the years, (Itsa hobby of mine :-) I have come to conclude that many aspects of programming and languages are purely subjective. What floats your boat may sink mine and visa versa. People process symbols and patterns differently in their head. There is no one right language.

It also seems that committee-designed languages usually fail because they compromise so much that they don't "sing" to any one group. You need a fan-base to get a language to take off. But, this also means catering it to specific mental types.

That being said, I have documented a bunch of potential scripting language features and give justification for my favorites in the list:


http://www.geocities.com/tablizer/langopts.htm

You may not agree with my decisions, but there is plenty food for thought for anybody researching and collecting lists of language options and alternatives. (I don't cover staticly-typed languages because I don't really like them.)

Enough already?

[Fastball]

I don't want to learn any more languages. Are new languages necessary, or can existing languages be extended to meet our needs? Personally, I'd rather it be the latter, but then I'm a thirty year old burnout.

Man. Anybody else tired of keeping up?

Could be hard...

[DarkDust]

It's sad, but I believe this will fail horribly. The past has shown that "committee" languages don't succeed (or at least only in some niches, like Ada).

In my experience systems (like PL, applications or even OS's) are best when designed by just a small group of people: not too few and too many (I guess four to six people is a good value). Too few (just one or two) tends to include just the exclusive view of thing from the designer, while too many just makes a great mess since it's hard for a group of people to settle on one point.

Another thing I learned while reading some of the stuff about C and its history on dmr's homepage is that languages which are defined first and implemented later often hold some promises in the form of "in theory this should be very elegant and nice, but it turns out to be annoying or very, very hard to implement".

dmr also said one of the reasons C succeeded was because it was created to fit a need, not to make a point or as demonstration. So if there is need for some features then this project might succeed, but I don't see any striking needs any more, there is already a PL for almost every problem out there (and interestingly nearly every PL out there is very strong/elegant in solving certain problems but fails horribly in others).

But nonetheless I wish the people participating in this project all the best, if they would come up with an interesting, useful and beautiful language that would make an improvement to the PL world this would be a very cool thing :-)

Re:Could be hard...

[cyberlync]

I am one of the people deeply involved in this project and so far there are two people directly involved with the design. There is a third handling administration and a few others working on documention. The community comments and provides suggestions. Thats hardly a big commitee.

On top of this the project is progressing rapidly. It may not ever take off, but it has been fun doing it and thats worth while to me.

Re:Could be hard...

[DarkDust]

I am one of the people deeply involved in this project and so far there are two people directly involved with the design. There is a third handling administration and a few others working on documention. The community comments and provides suggestions. Thats hardly a big commitee.

Then you are soon to aproach the number of people I consider the healthiest for such a project, which is Good Thing(tm). Make sure not to exceed about six people directly involved with the design ;-)

On top of this the project is progressing rapidly. It may not ever take off, but it has been fun doing it and thats worth while to me.

Yes, I know the learning-factor from such projects is enormous and is alone justifaction enough to start any software project... one hardly learns by just reading other people's code.

Common Lisp?

[Anonymous Coward]

Argh. Stop it already, Common Lisp already exists!

The role of libraries

[Anonymous Brave Guy]

I think I understand where you're coming from, and I agree with the principle, although I don't entirely agree with exactly what you've said.

I think the issue of how libraries are handled is crucial to the success of a modern programming language, as numerous success stories and famous failures can testify. Here are a few random thoughts; how do they match up with yours?

Firstly, I agree that it is best to keep a small "kernel" standard library. This library should be very well designed, with as much thought put into it as the language itself. In particular, it must be readily extensible by other libraries without being overcomplicated. If you like, it should provide a framework for doing common programming tasks, without filling in too many specific cases.

However, I don't think it's either easy or desirable to separate libraries completely from the language itself (as in syntax, grammar, etc). Your own comment about C++ is wrong, for example: you cannot ignore the standard library completely, because certain language operations (such as a failed dynamic_cast on a reference type) result in behaviour that needs library support (throwing an exception of a type defined by the standard library).

Now, you could get around that by creating new standard types for such cases, but do they really belong in the formal grammar of the language, alongside normal exception behaviour but distinct from it? The point is, from a programmer's perspective, it doesn't matter whether that exception type is in the library or the language. It should function identically, offer the same interface, exhibit the same behaviour, either way. It shouldn't matter whether my string type is part of the language or part of the library; it should just work.

The same goes, to a lesser degree, for other libraries. Once I've decided to use a library (or part of it), that extra functionality should just be there. I shouldn't have to care where it came from, and the only time I should have to know it's in a library is when I'm identifying the functionality I want to use. The syntax, style and function should be just like any other feature of the pure language and its standard library.

As a final point, while I believe the standard and portable library should be compact and highly flexible, it's obvious that having a widely recognised and comprehensive library of commonly used functionality is advantageous. Look at the success of Java, for example; although many of its standard libraries suck compared to alternatives for other languages, or even replacements available for Java, that doesn't matter to many Java programmers, because they're good enough. OTOH, this results in suboptimal code due to laziness and/or lack of knowledge of alternatives on the part of many Java developers.

The solution to this, IMHO, is to follow the path set by Perl (CPAN), TeX (CTAN), etc. The sponsors of the language -- commercial or community -- should provide a well-known and recognised central repository, into which contributers can add their own offerings. Better yet, adopt a genuine community review process, such as the C++ Boost community has, to force higher standards within the libraries in the repository.

So, in my ideal little world, a language would have a structure such that libraries and language were indistinguishable except where identification is concerned (basically just a matter of how to specify which libraries are desired, and naming conventions to prevent clashes between them). The language should come with a standard library that provides really common features (basic math functions and string handling, for example) in flexible frameworks on which other libraries can build. The bulk of library functionality shouldn't be standard -- that's too invasive and too limiting -- but ideally should be collected in a central repository of peer-reviewed offerings, with simple, standard and widely known conventions for using those libraries in programs. This way, no-one uses substandard code by default, but you still have the comprehensive functionality base there when you want it.

Re:The role of libraries

[Arandir]

We probably don't disagree as much as you would think.

I like libraries, don't get me wrong. I use them all the time. But there are times when you don't have the luxury of lugging along a mandatory library. Most people on Slashdot seem to be making the assumption that every system in the world is a PC. This is simply not the case. When you are working on an embedded device with 2MB of flash memory, you can't afford a 3MB runtime.

I don't have a problem per se with standard libraries. But I do have a problem with standard libraries that are mandatory. Can you imagine having to lug around all of CPAN as a runtime for Perl? Of course not!

Give me the libaries! But don't force me to carry them if I don't use them. Keep them separate.

Re:The role of libraries

[Anonymous Brave Guy]

Oh, I expect we don't disagree very much at all. :-)

I thought your original point was probably that it was important to keep the required part of the library small. (I've worked in instrument control and embedded markets myself, so I'm all too aware of the limitations there, and their size relative to the desktop PC apps market.) From your second comment, I can see that I got the right idea about your point of view.

Keeping the optional libraries separate from the core is exactly what I would want to see, hence the suggestion of a limited "kernel library" to provide bare essentials and a framework for more, while delegating more extensive functionality to some sort of centralised repository where you can find it if you need it. This approach has worked spectacularly well for a couple of things (Perl and (La)TeX being the first two that came to mind) and strikes me as a much better way forward than the monolithic beast that is Java's standard library.

Re:The role of libraries

[OeLeWaPpErKe]

I think you're describing c++.

Contrary to what you're saying, you don't need the standard library for anything. You could, for example use any C library instead.

C++ has a vast amount of libraries. A structure is missing tho, which is a good point.

Another downside of C++ is the requirement of recompiling when you change only very small parts (this can be greatly reduced by experienced programmers, but I rarely see anyone actually do that)

I don't see where you're calling the standard c++ library too limiting. The first thing starter programmers complain about it the apparent complexity. The second complaint is that it is too limited (in fact that's why qt/mfc/gtkmm have so much success). The stl is not limiting at all. In fact I reimplemented the iostreams (iostream and sstream headers) myself in very little code for an irc bot (so you could channel "hey oelewapperke" endl;) and for real-time interthread communication. I've since been convinced the stl can be adapted to do anything.

Frameworks written in C++ can be both extremely limiting, and VERY open. Written by an experienced programmer, the same library is useful for guiding a robot and to calculate the next payroll. Think stl, think boost, think sigc++, ACE, TAO, and the list keeps going on.

Another point I'd like to raise : a problem with building "standard" math functions is that there are a lot of different ways to evaluate expressions (symbolic, which can do more, lazy, which also can express more, but not quite as much as symbolic, and imperative, which leaves all the complexity in the programmer's hand)

Re:The role of libraries

[Anonymous Brave Guy]

Yes, I was in part describing C++, because I think it's a good example of a library that gets some things right, but some things spectacularly wrong. In particular, it shows where trying to keep an artificial separation between language and library breaks down.

Incidentally, I stand by my claim that you do need the standard library in C++ on occasions such as I mentioned. It interacts with language features such as dynamic_cast and the new operator. Sure, you can use printf instead of cout (and who'd blame you? ;-)) but that wasn't my point. There are subtle, intricate interactions there, and there will be similar interactions in any other language with similar features. Trying to keep them separate simply doesn't gain you anything worthwhile, IMHO.

As for limitations in the standard C++ library, here are a few that come immediately to mind.

• The I/O streams library forces the structure of output strings into code by using the << operator. Unfortunately, while that gains a little theoretical flexibility, it also makes for hideously unreadable code. Worse, it means that when you translate your application into a foreign language with different word order conventions, you have to rewrite that code, instead of just changing a formatting string stored somewhere. Most translation agencies don't want to touch your code and would much rather process a simple text file with the strings arriving in one language and being sent back suitably adjusted in another. Java, C# and others support this much better.
• The string class is infamous for its "designed by committee" nature. In particular, it was designed to support copy-on-write and reference counting semantics, which have subsequently been shown to be unsafe in a C++ environment. A better solution, offering both a constant string and a mutable string type, would do much more to improve both flexibility and performance, and again this is a technique found in many other mainstream languages today.
• The STL has some good ideas, but isn't perfect by any means. There's a thread just starting on comp.std.c++ right now about why it doesn't support a native "range" concept rather than using (pairs of) iterators for everything.
• Much of the real usefulness of the STL is destroyed by the lack of adequate function objects to bind things together in the standard library at present. Fortunately, the heroes over at Boost have been working hard on this, and some much better solutions will hopefully find their way into standard C++ next revision. For now, however, the standard algorithms are crippled.
• Concurrency? What concurrency?
• File system support? What file system support?

My biggest problem with standard C++, particularly its library, is that it looks far more complex than it actually is. You don't (or shouldn't) need 400+ pages to define a language, even formally. You don't (or shouldn't) need a similar number just to define a library that provides little more than some basic I/O, basic data structures and algorithms, basic maths and basic text processing.

The complaints that C++ is too complicated and too limited are both justified, in their way. A new language with a new library would do well to learn from both the successes and failures that C++ has had in its lifetime.

Models and implementations

[Anonymous Brave Guy]

I agree entirely with you (and Brooks) that syntax is just a means to an end. What's important is the underlying models behind that syntax. Today's models -- be they procedural, OO, functional or whatever -- lend themselves pretty well to textual representation. You could perhaps advance things a little with graphical representations, but I suspect the place for that sort of thing is in better development tools, rather than the definition of the language/environment itself.

The interesting question about graphical or new development environments is whether they'll make it practical to use more advanced underlying models that don't lend themselves readily to a textual representation. I've come across examples of this sort of thing at various points in my programming travels -- the concepts of interfaces, polymorphism of various sorts, modularity and access control come to mind as things that are inadequately represented by most of today's textual languages -- but never anything substantial enough to justify a shift to a radically different representation.

Haskell or Lisp

[Anonymous Coward]

What could any programmer want that isn't already in Common Lisp or Haskell?

Re:Haskell or Lisp

[Anonymous Brave Guy]

What could any programmer want that isn't already in Common Lisp or Haskell?

A powerful library, a clear syntax, flexible underlying models and a wide user base?

Re:Haskell or Lisp

[jacobm]

I'm not sure what implementing a brand-new language would help with points one and four. As for points two and three, if you think Haskell's syntax is unclear or Common Lisp's underlying model isn't flexible, you're clearly insane. :P

Re:Haskell or Lisp

[Anonymous Coward]

if you think Haskell's syntax is unclear or Common Lisp's underlying model isn't flexible, you're clearly insane.

I would like to see the function name moved to the left of the parenthesis instead of inside. It improves readability IMO and better fits with what people are used to.

Re:Haskell or Lisp

[Anonymous Coward]

And I think the / should go \ in the unix filesystem. It improves readability IMO and better fits with what people are used to.

Seriously though, it takes about 5 minutes to get used to the lisp syntax, and once you do, you realise it's that way because it means the syntax for function calls is the same as the syntax for everything else. Lisp syntax is truly trivial, and I love the way you never need to worry about it beyond maybe counting parens if you're in a sucky editor (top tip: just keep a running tally) It means you can just write your code, without having to figure out where the fuck a stupid ; is supposed to go, or whether the precedence order means that you need to put more parens in you expression, because everything in lisp is an expression with the same syntax. Syntax just gets in the way of coding, in my experience.

Re:Haskell or Lisp

[Anonymous Coward]

Erm, moving the function name to the left of the brackets would kind of remove the whole point - it's a List Processor, remember? Besides, only people with chronic exposure to languages in the Algol family are unable to get used to it ;)

Re:Haskell or Lisp

[aerique]

and better fits with what people are used to.

Strange, I'm used to seeing the function name as the first thing inside the parenthesis.

My thoughts

[DimGeo]

I think Java is good. It fails at some points (this is by a person with 3+ years of professional Java experience):
1) No convenient way to call methods by name. Takes quite a few try-catch constructs, etc. What about this snippet:
Object x = ...
call someMethod(a, b, c, d) at x;
or something. Ok, it may throw any necessary exceptions.
2) No standard way to access DBs. JDBC is a pain. It works, but with lots of workarounds for different dbs. One must implement class loaders, selecting the driver at runtime is terrible, parsing the CREATE statements to replace the data types is way out of bounds.
3) Terrible with memory management, especially the GUI stuff. There just HAS to be some efficient way to deal with this. Maybe mix GC with ref count + explicit delete statement, which zeros all references to the object (possible with the current Sun JVM implementation, because the references are one step further).
4) No way collect a few threads, name them an "application", then kill them off. Oh, there is, but you have to worry about bizarre deadlocks resulting from unsent notifications, etc.
5) The localization is a PAIN. You must write properties files, compare locales, etc. i.e. do all the work by hand. And there is always the temptation to hardcode a string in a hurry.
6) Nothing really to force you to avoid deadlocks. Some ideas : throw exceptions when deadlock is reached, etc.

I love the idea of OSGI (my company, ProSyst, is a lead vendor of the OSGI framework). The idea is simple : jar files, called bundles, export and import packages, and register services (objects implementing interfaces both the user and the exporter have access to). Problems : no way to completely kill off (safely) any threads the bundle might have started when it is uninstalled.

Some suggestions about the new language:

1) Add call-by-name.
2) DB support. I saw one message before this one which was very well thought out, and was on this subject.
3) Add ref counts and explicit delete-s to the GC
4) Borrow ideas from OSGI - easy plugins, services, etc. Runtime load/unload of components. Runtime SAFE kill-off of entire bundles. Kill their threads, close their files, free their memory. This is done (sort of - the memory freeing comes to mind) with win32 dlls, but no way to do it in Java
5) Add localization support. For example, some library class which loads the appropriate string tables according to the locale (the easiest solution)
6) Two ideas here : 1) force the monitor objects to be declared beforehand, and assign priorities. If someone tries to lock these objects out-of-order, throw exceptions. 2) throw exceptions when a deadlock is reached.

more things to think about:
- realtime support. Threads which cannot allocate memory, and can only use static memory.
- good cross-platform gui. Swing is a great idea, I mean its programming interface, no the terrible self dead-locking, ugly implementation. Having platform-dependent look and feel (I *mean* native look and feel, not some "lightweight" blown-out implementation, which slows down to a crawl at the simplest operations). See previous thoughts about deadlocks.

And about templates : I do not care, really (oh, the horror). Typecasts are not a problem, when you only have one or two types of objects in the same collection. I even prefer there not to be such.

Now, about the platform:
How about have the language compile to C or Java (make it an option). Then, make an option to disable the garbage collector (impossible for Java, but a valid options for C). If you compile to C, make sure you use a serious GC, not a conservative one which treats all your data as pointers. Use a Java-like type system. This can even compile to .NET if necessary. Thus, you can target 3 platforms with an ease.

-- bailing out.

Re:My thoughts

[tigersha]

Call by Name = very bad in a procedural language.

*My* Wish List....

[Anonymous Brave Guy]

A language with sound underlying models, with simple implementation, which helps me do what I want rather than telling me what I want to do, and which has no dependence on today's buzzwords.

I think I'd hate your language. :-)

Keeping up just sounds hard -- it isn't really

[Anonymous Brave Guy]

Man. Anybody else tired of keeping up?

I think the problem today is that everything seems to be moving on much faster than it actually is.

Quite a few years ago, I learned to program in C and x86 assembler. They were useful at the time, and I learned a lot about structured programming and such while using them.

Several years later, I learned C++, and encountered OO for the first time.

At university, I discovered things like Java and ML. ML was new and interesting, but at the time Java was just underpowered C++ with a heavyweight standard library, and to a large extent it still is. That was when I realised that many "advances" that come along "at breakneck speed" aren't really any different to what you've already got.

For several years at the start of my professional career, I relied on little more than standard C++ and a few very common libraries (MFC, mainly, and some in-house things). I didn't need any more.

After a while, I got the feeling I was stagnating, and since I wanted to do a few things that weren't convenient with the C++, I went out and learned some more.

In the past couple of years, I've learned to generate HTML with XML/XLT, I've learned to write scripts in Perl, I've learned about server side scripting and CGI, I've learned to use MySQL, and recently I've put it all together and written a pretty solid bulletin board web site for a club I help run. And this was just with a few hours now and then out of curiosity; the day job writing back-end C++ without much whizz still pays the rent.

I guess my point is that three years ago, CGI, MySQL, Perl, XML and all the rest were just buzzwords to me. Everywhere you looked on the Internet, there were millions of pages of tutorials, mostly very bad ones, and people telling you it was the next great thing, radically different to all that's gone before, etc. You know what? I learned the basics of each of these things inside of a day, once I actually sat down, did some real homework to track down a decent tutorial and got on with it. None of this stuff is hard. Just find useful info -- which often still comes on paper, or in the form of docs from the tool provider for high calibre things like Perl, MySQL or Apache, and not from random glitzy web sites and magazines -- and do some reading.

I reckon if you have a general knowledge of programming in procedural, OO and functional styles, a bit of experience with database design and SQL, a bit of web savvy and familiarity with mark-up, and some general knowledge of modern computers, you can learn any of the buzzword technologies in a week, maybe even a day. They're really not very clever at all; the reason they're buzzwords is that stupid people talk them up to make them sound clever.

Keep the faith; if you've got solid basics -- as any old-timer in this industry probably does -- you're never far behind the lead edge if you choose to catch up. The only people who claim everything is advancing at lightspeed all the time are marketroids selling new buzzwords, and impressionable kids too new to the business to know any better. The rest of us can well afford to relax, keep an eye on new developments now and then, and simply learn whatever tools we need to do what we want to do, if and when we need them.

Re:Keeping up just sounds hard -- it isn't really

[GlassHeart]

if you've got solid basics -- as any old-timer in this industry probably does -- you're never far behind the lead edge if you choose to catch up.

It's not just personally catching up that's the problem. New languages may be easy to learn, but they each still take some time to master. You can write Fortran in any language, and a lot of mistakes (it's easy to understand the concept of OO, it's quite another skill to come up with a appropriate and scalable object model for a complex new project) are made along the way. On the individual level, it's probably worthwhile to make these mistakes. However, it may not have been worthwhile to your company to keep switching languages and making buggy products.

Re:Keeping up just sounds hard -- it isn't really

[Anonymous Brave Guy]

New languages may be easy to learn, but they each still take some time to master.

You're right, of course. But there's very little that's so new and different that an experienced programmer couldn't pick up the basics quickly, enough to decide if the tool was more useful to them than what they already knew. If it is, then they can invest more time in really getting to know it.

On the individual level, it's probably worthwhile to make these mistakes. However, it may not have been worthwhile to your company to keep switching languages and making buggy products.

Again, I agree with you, but I don't see why this is a problem. Companies rarely need to keep up with the bleading edge, for the reasons I've given: there's little out there that's so new and improved as to justify investing in learning that rather than improving your abilities with the tools you already use.

I was about to write that it's an evolutionary process rather than a revolutionary one, when I realised that actually, a lot of these new developments really do just go around in circles. I wonder how many more times we have to reinvent LISP, ML, Eiffel or C before we realise that for all their idiosyncracies, languages like these have the goods, and all the C#s and Visual Basics and Pythons in the world are really just popular but ultimately insignificant steps along the way to reaching them?

How about procedural XML?

[BigGerman]

I keep thinking about a language where definitions (objects, classes) and procedural logic (functions/method calls) would be expressed in XML.
XML schema might come in handy.
Such language will be exclusively machine readable and WRITABLE. Imagine the possibilities.
If someone wants to run with this idea, I want 10%.

Re:How about procedural XML?

[Anonymous Coward]

It's a bad idea, and one that many have had before.

Re:How about procedural XML?

[Anonymous Brave Guy]

I take it you've never suffered writing and debugging a complex XSLT set-up on a deadline, then? ;-)

Mark-up languages should be used for mark-up. Programming languages should be used for programming. Many people have suggested swapping these over; many more have tried and found it doesn't work.

Re:How about procedural XML?

[ctrimble]

SXML & SXLT. It's Scheme with XML. True, it's not procedural, but it's a programming language. Oleg Kiselov wrote it. http://okmij.org/ftp/Scheme/SXML.html

Re:How about procedural XML?

[BigGerman]

Right, no argument there.
But dont' you think sometimes that the programmic language constructs are "mark-up" for your ideas?
And there is native similarity between how we structure code ("begin block; do something; exception handler; end block;") and structure of an XML doc?
Besides, ideally such language will almost never be manipulated by hand.

Re: veiws of a heretic

[shadowpuppy]

1. Languages should be complex. Life is complex. Since a large chunk of programming relates to life in some way it's nice to have a language which can handle the nuances easily.

2. I think programming languages should be allowed to evolve for a bit. Write some programs in it befor you lock it down. Invite your friends to use it. Then you'll know what sucks and needs changing. Concurrency will progably find a way to hurt you no matter what. It makes things messy. Expect pain... be suprised when it doens't come.

3. Hierachies are ok but "file" notation should be avoided if you care about portability. Remember, DOS uses '\'; Unix uses '/'; other things use otherthings. Pick something simple an deligate the problem to the compiler.

4. Yeah running it by experienced programmers is probably a good idea. You may want to run it by inexperienced programmers also.

Re: veiws of a heretic

[crmartin]

1. Languages should be complex. Life is complex.

I kinda was hoping for something that wasn't as much of a pain in the ass as the rest of my life.

Whole freakin' thread about Oz ..

[Szplug]

I didn't realize it had been the subject of an article here already.

Make it TYPEable

[mhotas]

Of course READability is important; but what about writability (and in particular, typeability)? Specifically, anything which avoids the use of the Shift key or multi key combos. Maybe what I really want is a programmer's keyboard which allows underscores, parens and major operators to be available without an awkward vulcan nerve pinch.

Re:Make it TYPEable

[Anonymous Brave Guy]

Ultimately, while being easy to write does confer a small advantage, being easy to read is much more significant. As the oft-quoted motto reminds us, code is only written once, whereas it's likely to be read many times. A vanishingly small amount of a developer's time is spent typing. Most is spent in design, testing, documenting and such rather than programming, and even of what I'd call programming, only a tiny fraction of the time is spent pressing keys on a keyboard.

Machines aren't that cheap

[yerricde]

Why not - machines are cheap. Especially cheap machines (intel).

I can sell an optimized program for an existing machine for $40, or I can sell a faster computer plus a less-optimized program for $400. What is the customer more likely to buy?

Re:Machines aren't that cheap

[kwerle]

I can sell an optimized program for an existing machine for $40, or I can sell a faster computer plus a less-optimized program for $400. What is the customer more likely to buy?

I don't think this instantaneous view of the market is a healthy one. If you plan on staying in business for some years (say 5), then I'd say they are very likely to go for the upgrade combo - maybe not this year, but sooner or later. If you're only planning on staying in business for the next month, you'd better go with something optimized for a few years ago.

What's more, in the wintel world, M$ applies constant upgrade pressure. Both in terms of hardware needed to run their latest windows release and in terms of the fact that it's generally easier to buy a new machine with the current OS installed than it is to upgrade an existing machine. Think of them as co-marketers for the $440 combo...

Re:Machines aren't that cheap

[yerricde]

If you're only planning on staying in business for the next month, you'd better go with something optimized for a few years ago.

Exactly. I plan to work in video games, and a game can be no longer new after a couple months.

Agreed

[turgid]

And here's the evidence to back it up.

IMNSHO

[jo42]

In my not so humble opinion, we should go back to basics. Or, at least, teach them:

- Assembler, with cycle counting and all that gnarly stuff.

- C, with emphasis on pointers and structures.

If you don't agree with me, then go stuff yourself sideways up the wazoo of a 3GHz P4 and stop running any OS - because that is what it is written in.

Modular Languages

[Vagary]

Some of the people at my school (Queen's) came up with a language many years ago called Turing. It was designed to be an educational replacement for Pascal and so had a straight-forward syntax, etc. So that it would be suitable for both lower- and higher-level courses it supposedly is designed so that language features can be added as modules.

I haven't really looked into it (just told about it by one of the designers of Turing), but this seems like a really good way to satisfy people like you, especially since some of those features are mutually exclusive as other posters have suggested.

I've heard things about Lua being modular -- anyone know more?

Obsolete Patterns

[Vagary]

Many pattern critics point out that some of the Gang of Four Design Patterns are ways of adding features from some languages to Java (or other OO languages that are lacking?). There is even a paper out there (don't ask me, ask Google) that goes through the list and finds that a significant percentage are trivial in functional languages. So I propose a language design principle: create a language that makes as many popular patterns trivial/obsolete as possible.

If its a common enough occurence to be worth including in a book on patterns, then it's common enough to design for. Programmers learning the language will feel joy because rather than figuring out how to translate their memorised patterns into the new language, they will be able to forget them completely. And since you can't just stick a solve_pattern_foo keyword in the language, I believe that designing the language to solve these problems will have a side-effect of making it very powerful and expressive.

Re:Wish list, or why not use free strong typing

[jbrandon]

Go back and read the Bruce Eckel article I posted a link to in my original reply.

Sigh. I did. Here are his substantive arguments, in order:

• Duck typing is good: ''Languages like Ruby, Smalltalk and Python put the loosest possible constraints on types, and evaluate types only if they have to. That is, you can send any message to any object, and the language only cares that the object can accept the message - - it doesn't require that the object be a particular type, as Java and C++ do.'' and ''Since command(pet) only cares that it can send the speak() message to its argument, I've removed the base class Pet, and even added a totally non-pet class called Bob which happens to have a speak() method, so it also works in the command(pet) function. At this point, a strong, statically-typed language would be sputtering with rage,''
  

  Ans: irrelevant, OCaml has duck typing, but is strongly typed. C++ also has duck typing for template instantiations. The last quote is utter bullshit, since both O'Caml and C++ handle that with aplomb.
  

• Programmers indicating types is bad: ''Argument types and return types? Let the language sort it out! ''
  

  Ans: Type inferen, see previous posts
  

• Python is cool: Indentation is meaningful, not everything is an object, built in cool data types and control constructs (for x in y)
  

  Ans: clearly irrelevant to the typing debate
  

• ''To claim that the strong, static type checking constraints in C++, Java, or C# will prevent you from writing broken programs is clearly an illusion.''
  

  Ans: good, cuase I ain't claimin' that.
  

• ''In fact, what we need is Strong testing, not strong typing.''
  

  Ans: Why not BOTH?
  

• ''And because I can get a Python program up and running in far less time than it takes you to write the equivalent C++/Java/C# program, I can start running the real tests sooner''
  

  Ans: He forgot the if: IF python is faster to code in. I can grant that writing python is faster than writing in staticly typed languages without type inference or great libraries, BUT I'M NOT.
  

Essentially he argues that static typing is not such a great test. I argue that it's one less thing I have to write unit tests for. His answer is that writing all those types takes programmer time, and my answer is inference.

He never says static typing is bad, he says non-duck typing is bad, and static typing isnt worth the tradeoff of more programmer keyboard time. My answer is to include duck typing and avoid the keyboard time with inference.

How's this, let's NOT make it with a C-ish syntax

[DrMorpheus]

I'm so fucking SICK of that monstrosity C! It is not the pinaccle of programming syntax. Let's make the syntax like Pascal or anything else besides C!!