Summary
I am conducting a survey to find out what it would take for a new programming language to impress people.

Advertisement

The grand release of the "new and improved" Heron language is set for September 1st. I want to make as big of a splash as possible, so my question is, what would it take for the language to impress you?

Two aspects of a new language are required to impress me. One concerns the language itself - it must be multi-paradigm. Something like Mozart-Oz: functional, OO, dataflow, distributed, constraint-based, all in one. Particularly dataflow (ie Erlang). I think the time has come for a mainstream dataflow language.

But, no new language can really impress me enough to convert me without outstanding tool support. This is why I'm still a Java programmer in my spare time. The tools, with refactoring and compile-time checking are indespensible in a large project. I quail at the thought of maintaining 100,000 lines of Python code, even though the syntax is so much nicer. Mozart-Oz is even worse than that, and I can't imagine using it for anything other than toy projects currently. I will never willingly give up tools like Eclipse/IDEA/Netbeans, just for a little syntactic sugar, or some funky built-in language power.

Haven't we done the "impressive language" thing to death? What about unimpressive languages? Languages made powerful by removing features. Sure, the limit points are Self and Lisp but there's a lot of interesting ground between here and there. See the Io language, for example.

The main question for any langauge is "why?". The language has to solve a problem that current languages don't solve or don't solve well.

From the website, Heron's "why" seems to be C++ is badly broken. I agree that it is. So, this could be a compelling case for Heron. The next step is to get a community of people to agree that Heron answers this question. Until then, unfortunately, Heron (or any language) is just a toy.

I like statically typed languages, but think a lot more could be done with type inference. I'd like to go further, and have types specified without reference to hardware - for example, give them value ranges instead. I think it's good practice to spend a thought as to whether your variable's values will actually fit, but it's far too easy to skip that if you just assume "int" is always big enough. Granted, I've used systems with a type system like that, and someone somewhere usually declares a generic "int" type, but I think a lot of that would go away if you could also specify type ranges in terms of number of bits as a syntactic sugar for value ranges. If you're happy declaring a lot of int:32 variables, at least this way you can later change them to int:48 if it turns out you need a bigger one, and all the other int:32 declarations are unaffected.

I'd like to see all values support units attributes. Almost all values measure some actual thing, not just metres or degrees, but pixels, record count, ASCII or Unicode values, and so on. You can almost always attach a units attibute (which could be compound, such as miles/hour). This would probably catch a whole new class of type errors, and if conversion rules are given, would make a lot of math much more seamless. It would not need to be a static type, it could be dynamic as well. Sun's Fortress language seems to support this to a degree.

I think languages which need external files or command strings to program certain things, such as object-relational mapping schemes, or XPath queries, or rule processing engines (possibly GUI definition languages, though there's a partial case for those), are a symptom that there's something fundamentally broken with language support in that area. This shows up a lot in statically typed languages, though I think there are programming strategies that could reduce that a lot, if they were explored. However, dynamic language also suffer a bit - look at the handling of regular expressions in some of them.

Still, it seems only C++ has explored trying to bridge that gap, with its template system. Unfortunately it's power and flexibility leads to confusion, as you can no longer tell if << means shift left, write to output, or format hard drive.

In short, I think I'd like to see a language which has the ability to map language constructs to external concepts in an integrated and natural way, but that didn't disguise itself as part of the language itself - that is, you could tell what it was doing from looking at it. The metadata annotations in C# and Java 5 might be a step in the right direction, but are far from being more than a start. The meta-programming layer would definitely have a syntax distinct from the programming layer.

Finally, I'd like the visual representation, including punctuation, keywords, and so on, to be completely unrelated to its storage format. The editor would present the language according to a programmers defined preferences for syntax and formatting. The thing that would horrify most programmers is the idea that the source is not human readable, but that doesn't mean unrecoverable - a default syntax could be used for storage, or something XML based. However, it would be stored without formatting, so even the most dedicated programmers would prefer to view and edit it with an editor.

This is not really very strange. Everyone uses word processors, which present the document in a format completely different from what's stored in the file. And usually gives a number of formatting and viewing options. And web browsers give users the ability to magnify all text or scale images, change width and height, even block some things from being displayed (banners or popup ads). And most code editors today colour the text, even though you won't find this colour information stored anywhere in the source code file. This would solve all formatting wars, as every programmer sees exactly what they want to (editor wars would increase to compensate).

Having a decent refactoring IDE right out of the box would be impressive. Making multi-threaded code easy to unit-test would be impressive. Built-in persistence that scales, has a nice query language, and handles schema changes well would be impressive.

-No hoops: most languages quickly acquire features to support dicey features and legacy foolishness in the language. Hoops the programmer has to jump through to perpetuate bad decisions made in the past.-It should be easier to program common, small tasks correctly rather than incorrectly. C is a great example. You -can- program using checked buffers in C, but it's -easier- to code without checking the length of buffers. C++ doesn't change this with the string class; it merely makes it less inconvenient to do it correctly.-Intelligent support for additional tools. I'd -love- to see a language that supports an -intelligent- preprocessor. In spite of all the features added to C++ (const, inline, templates), the dumb-as-dirt C preprocessor is still indispensable, and still mangles code as effectively as ever.-Intelligent linkage. Damn it, linking the object code is -not- an afterthought. Linkage should be specified in the language, it should be intelligent, so that name mangling is not needed, and it should be under the programmers control.-It should be fully scoped, and scope should be completely under the control of the end developer. Nothing should -have- to be in the global namespace if I don't want it to be, and if some nitwit writes a library that tries to stuff junk in the global namespace, I should be able to import that library within a namespace I define, to correct the problem when I use the library.-It should not require silly and pointless coding overhead, like Java defining main in a class. Objects are great, but there is still a place for classless, procedural code. There is no good reason to warp coding styles; see hoops comment above.-It should be unambiguous and promote clear coding habits. Nothing like obfuscated C or typical Perl.-It should not hamstring the programmer in order to make things safe. I ought to be able to link to or interface with other libraries without dropping down to C to write a wrapper. It ought to support write system-dependent code clearly and in a language standard way, rather than prohibiting it entirely.

It may seem like this is triggered by discontent with C and C++, but my annoyance is with most languages right now.

I'm not sure why people think it's such a big deal that the favorite, one-line "Hello, World" program in Java is 8 lines long. Big deal. We have a lot of languages that have concentrated on reducing lines of code and making the simple program simple. Here's a nice simple Groovy script:

"Hello, World"

There, simple enough? But who cares? I think we've got lots of languages that make writing simple code very simple - if you're looking to write an educational program or some example code in a book, you've got a good half-dozen terse languages to choose from.

But, if you are writing a 3-million line monster that truly must do some difficult things, then you want a language that gives you power. That can scale up and still be comprehendable and maintainable. Distributed programming is still harder than it should be, and full of pitfalls. Can a language help with that? Maybe. I bet a platform + language (like Java is) can help. Multi-threaded programming is a must, and virtually all of us are using C-style threading languages. After learning about dataflow languages, I'm curious to know how they could simplify our multi-threaded programming.

I just don't think we need more simple. Simple is simple, and that's probably the biggest reason we have so much of that. Smart, complex, hard is hard, yet so worth it. Let's have a language that really let's us work effectively with really difficult problems.

I think a programming language should try as hard as possible not to mix incompatible concepts. You can't have it all, and fortunately, you don't need it all. Although there is a place in my heart for nearly every language I have used, I currently use two for 90% of my work: Python for easy-to-code GUIless scripts with very readible syntax, and Java for large projects and a nice IDE because the slowdown as the project grows is practically zero if done right. C/C++, in my heart, only fills the gap of handling really fast operations, because otherwise, it is a painful mess in terms of syntax. Perl too. Both these languages "mix incompatible concepts". I think that TMTOWTDI that perl boasts is really its biggest flaw.

I can't answer the question this entry poses with all of it pertaining to Heron. I need to take Heron's goals in consideration. So, for Heron, I would be impressed to see mechanisms actively in place that would encourage developers to not reuse code. In fact, the best test is to ask a random person to code something simple, and look at how elegant it is found to be. You could tackle various aspects of the code as well with this method, such as threading, errors, and other trouble points in other languages.

I'd love to also see a language that an IDE could take full advantage of. The IDE could make conceptual links between parts of code, and determine as much as possible about the code without actually running. I find, in Java for example, that knowing where my bugs are as I am typing infinitely rewarding, since it gives me more brainpower to focus on other things (such as how what I am coding fits into the big picture).

Also, simple syntax is another great thing. The best test for this is the following: how small can you make a code tokenizer? The less rules there are to code in, the faster the language can be learned. Python, for example, has one of the best handles on arrays with their tuples, lists and dictionaries. But after making the language easy to learn, one must make it easy to code in. There is no sense in seriously considering a language that is all XML if it isn't a GUI-only language. XML may be fairly easy to parse, but it requires so many characters to do even the simplest thing, such as addition, without cheating and just typing "1+1" instead of something like, say, "1<plus/>1" (though, to be truely XML, it would look more like this: "<sum><item>1</item><item>1</item></sum>").

To return to what I was saying before, the best short-term thing a person can do is to have people learn your specification, and have them code an application for you. They'll ask you questions along the way, have some complaints as they're coding, and you'll have the code at the end which will all factor in to understand the language from a users perspective. You could then go into some corrective measures.

The best long-term thing one can do though is look on sourceforge after the language is really being used, look at the code, and see if there are any lessons to be learned. I am proud of PHP for making great leaps between changes of major versions. I won't elaborate too much on backwards compatibility, since it is a topic of great debate, but to have a language that is backwards compatible from version 1 is suicide.

1. painless interoperability with other languages: C in particular, Objective-C, C++, Python, Java, Ruby, SQL, etc. Objects in this new language should be able to use and/or be proxies for objects in other languages. The language should be usable for shared libraries, plugins, device-drivers, and so on, as well as applications and scripting.

2. support for threads and inter-thread / inter-process communication. Java had "synchronized" but that wasn't enough (and maybe not even the right thing to have). Cocoa's Distributed Objects turn out to be fairly easily used for both inter-thread / inter-process communication, and Cocoa also has support for other ways of synchronous/asynchronous communication, but much of Apple's Cocoa isn't thread-safe. Make it easy to use operating-system threads. Also, make it easy for a programmer to set up a million thread-like objects that don't harm each other and which don't thrash a CPU to death.

3. garbage collection. Look to modern Smalltalk environments for how to do it right. Be able to turn it off for specific objects, etc.

4. work with programmer's weaknesses: many programmers forget to initialize local and member variables... make it easy to init them to a good value, and default to initializing them a zero, null, or default-constructor. Also put in warnings for some other common problems.

5. avoid other language/system weaknesses: learn from common problems areas in Java for example: classpath and class-loaders.

6. consider Objective-C's "message-eating null" -- many people who've never used it expect it to cause problems, but it actually makes programming easier and simpler. Only very rarely do you need to check if a variable is null... and you never get "Null Pointer Exceptions" halting your program.

7. and while you're at it, create a debugger that understands objects: let me set breakpoints on ONE specific object: any methods (or any methods that I select) called on that object break into the debugger. Let me add logging of all state-changes to an object, or class of objects, while I'm in the debugger, without writing any code. If I set a break point on a method, let me specify which classes that applies to, if the method is inherited by more than one class. Let me browse all instances of a class (or all classes), and optionally find out where each one was created.

I also am currently most interested in java and python although I have a special spot in my heart for perl and c/c++.I think a truly impressive feat would be to create a language that would be as easy to create quick programs in as it is in python but have the scalability of java. Perhaps a switch on the interpreter/compiler that optional checks for strong typing ("python.exe -strict"). Or perhaps there would be a parser that one could run python code through and the output would be static typed code. (like java) Then you could build libraries of solid, easily maintainable code and still do quick and easy jobs. We may get there with jython.