Slashdot Mirror
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?"
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).
... 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.
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...
Karma: Marginal (mostly due to the border around the website)
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 . . .
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.
The local variables employed and not_dead are not initialized and we may never even enter the loop. ;)
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.
...) in the last 20 years that decided this was just too hard, and eventually paid for it.
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,
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.
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.
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).
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.
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.
Someday we'll all be negroes
Why stop there? We need as many languages as we can get, especially in today's economy and job market.
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
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
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.
= 6543
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
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.
That's not too much different from C++: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!
[-- Trust the Monkey --]
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?!?
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.)
Table-ized A.I.
Man. Anybody else tired of keeping up?
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 :-)
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".
Stick Men
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.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I think Java is good. It fails at some points (this is by a person with 3+ years of professional Java experience): ...
.NET if necessary. Thus, you can target 3 platforms with an ease.
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
-- bailing out.
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.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
A powerful library, a clear syntax, flexible underlying models and a wide user base?
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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.
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 :-)
Stick Men