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

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).

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.

... 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: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: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.

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: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".

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.