Dhananjay Nene is a Consulting Software Programmer and Architect. Dhananjay is a DZone MVB and is not an employee of DZone and has posted 18 posts at DZone. You can read more from them at their website. View Full User Profile

Programming Languages Should be Simple (or My Ideal Programming Language)

  • submit to reddit

I am disappointed with many of the newer languages which I earlier thought showed great promise of making programming easier, quicker, and more robust. And it boils down to one thing. Simplicity in learning. Having gone through substantial amounts of programming in C, C++, Java and Python, my quest for the “next” programming language remains unfulfilled.

Why ?

Programming should be simple. And it should be accessible. And when I mean accessible I mean people with IQ of approximately 100 should be able to write programs. I am disappointed that many of the trends seem to raise either the minimum IQ or the training time required to gain competency. And while that helps a community of the super brilliant, it does not make a substantial difference to programming in general. It remains esoteric and does not stoop to touch everybody.

What ?

So what are the features of my preferred programming language :

  • JRE support: Should run on the JRE with Java interop. Thats the dominant well engineered platform that runs across all classes of desktops, servers and devices. Additional support for CLR is a bonus but not mandatory.
  • Simplicity: Should be fairly simple to read, learn and understand. Python is a good example. PHP is a great example (at a simpler class of problems). C++ and Scala not good examples.
  • Multi paradigm : Should support both OO and FP constructs. eg. Scala and Python. Half hearted support to functional programming as with python discouraged. Ditto with passionate support for objects with second class treatment for functions as in Java/Ruby.
  • Multi core compatible : Should have good constructs for leveraging multiple cores eg. erlang, scala, clojure and many others.
  • Type inferencing : (and I am a python programmer :) ). Good type inferencing coupled with on the fly non intrusive/disruptive compilations as with say the eclipse on the fly compiler or play framework. Three cheers for Scala. One reason I prefer type inferencing to dynamic typing is the much superior performance even while maintaining brevity and removing boilerplate.
  • Constructs that are natural to humans not mathematics : This is actually a sub point to Simplicity. The constructs should be consistent with the normal average non mathematically trained brains. 2 + 3 is much simpler to understand than (+ 2 3). Python rocks. Lisp / Clojure or for that matter brainfuck dont.
  • Closures and code blocks : Love ruby for this.

Is this a pipe dream ?

For the moment seems so. Do you know of a language which helps meet these requirements ?

And to be very clear (because there is a substantial risk of the same) – this is no flame bait or an opportunity to trigger language wars. It is meant to highlight two things

  1. There is no ideal language out there, and
  2. When designing languages – make them simple to learn and use. ie. for a given problem statement a good language is one which requires the minimum talent or training to solve the problem


From http://blog.dhananjaynene.com/2010/08/my-ideal-programming-language

Published at DZone with permission of Dhananjay Nene, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Shantanu Kumar replied on Fri, 2010/08/13 - 4:00am

You might be interested in Groovy++, or JRuby (or Mirah). If you give Clojure some patience you may find it's just as natural for humans as any other language.

Dhananjay Nene replied on Fri, 2010/08/13 - 4:11am in response to: Shantanu Kumar

Sure groovy or jruby (or for that matter python - my primary language) are far simpler than many others. But I haven't met the ideal combination yet - so I continue with python which amongst the existing stack, I am quite satisfied with.

Martin Wildam replied on Fri, 2010/08/13 - 6:18am

The next big language for me after Java is yet to be invented. Nothing that is currently around is really attracting me...

Arek Stryjski replied on Fri, 2010/08/13 - 8:03am

Maybe I'm wrong but normal people (users) don't think in OO or FP way. They think in procedural way and this is why Basic is simple.
Most programmers think in OO or FP way. This is why Scala is so difficult for everyone.

I think you ask for impossible.

The next language does not need to be simple, it must be easy to use. I mean easy for professionals.

All of us can read and write, but there is more then this to become journalist.
All of us learn arithmetic and logic at school, but there is no reason all of us should be programmers.
You don't need to be genius to become programmer or doctor. But it is normal to expect people to learn both professions for few years, and then learn more till the end of they caries.

Dhananjay Nene replied on Fri, 2010/08/13 - 8:30am in response to: Arek Stryjski


Perhaps I wasn't clear enough what I meant normal. I meant normal / average programmers. Not just the programmers who churn out algorithmic, distributed, highly available, majorly concurrent applications. But an average that is also inclusive of the programmers who churn out a very large number of simple bread and butter sometimes boring applications.  Basically an average across the entire community who requires their output to be either interpreted or compiled.

PHP at low levels of complexity and Python / Ruby at any levels are good examples of languages that I consider simple compared to a Scala, Clojure, Erlang, Haskell etc. Most certainly they are also simpler to learn than java (until one reaches areas such as metaprogramming). 

What I am looking out for is a language that reaches out and says I shall attempt to dumb myself down rather than require you to raise your intelligence. For better or for worse there was a language which was the single most popular language at one time which did that job quite well - Visual Basic. The race for Java's heir is still open. And there are some excellent languages competing for this slot. It is my opinion, that the one reason that is more important than all others, that this race still remains wide open is the matter of simplicity I discuss in the post.

Impossible ? I don't think so. And I really really hope not.

Diego Moita replied on Fri, 2010/08/13 - 10:30am

Lua fits 6 of your 7 requirements. Type inference is the only exception, but it already has a very good performance without it.

It has JRE support (through LuaJava, Kahlua, MochaLua and LuaJ) and CLR support (through LuaInterface), is even simpler than Python, is multi paradigm (it even has macros/metaprogramming, through MetaLua), is multi core compatible (through Lua Processes), has constructs more natural than C syntax and also has closures and code blocks.

Stephen Colebourne replied on Fri, 2010/08/13 - 10:48am

You've hit the nail on the head. Its the mainstream developers that need to be targetted.

The answer could well be Fantom, if the community would back it a little more, instead of pursuing the over-complex Scala. The rationale for the language is here. The discussion on how boring it is (and why that is good) is here.

Its a simple to read, simple to write, simple to learn language. Yet, it still tackles all the pain points. Nulls. Immutability. Shared state. Actors. Modularity. Build system. Crufty libraries. Java integration. It even has a killer feature - compilation to Javascript.

Take a look.You might be surprised!

Mike P(Okidoky) replied on Fri, 2010/08/13 - 11:57am in response to: Martin Wildam

Then someone like you could/should share what your vision of a better language is. People inspired by the current languages tend to just make more of the same. And that's not change we can believe in (lol). It'd be interesting to find out what someone not inspired by current languages would propose.

Josh Berry replied on Fri, 2010/08/13 - 1:05pm

Why wish for a language that is "simpler," instead of a better set of programmers?   Instead of making a language that has to hide a lot of higher level abstractions, I'd prefer one where I can get more benefit from learning the abstractions.

Dhananjay Nene replied on Fri, 2010/08/13 - 2:17pm in response to: Josh Berry


 Allow me to again quote the last line of my post :

When designing languages – make them simple to learn and use. ie. for a given problem statement a good language is one which requires the minimum talent or training to solve the problem

So I would imagine solving a more complex set of problems would perhaps need a slightly more specialised abstractions. Existing evidence leads me to believe there is a lot of difference in the talent level or training time required to solve a similar class of problems across different languages.

With regards to hiring a better set of programmers I agree with you that that is certainly an option. However thats like saying I will do business only with better behaved customers. Certainly many companies can afford to ensure that they hire the very best programmers and deal with the very best customers. At the end of the day many companies will have to deal with the rest. Similarly programming in the assumption of designing languages which require the very best programmers cannot wish away a large part of the programming community. It merely makes it harder for them and is likely to alienate them.

Josh Berry replied on Fri, 2010/08/13 - 3:49pm in response to: Dhananjay Nene

I get the idea behind what you are saying.... but I don't see how Scala doesn't fit that.  The simple cases in scala are VERY simple with very little surprise.   Plus, they are strongly (very strongly) typed, such that once you start scaling to tough problems, your small solutions typically scale with you.  :)

Nils Kilden-pedersen replied on Fri, 2010/08/13 - 4:11pm in response to: Arek Stryjski

 This is why Scala is so difficult for everyone.

I don't think Scala is difficult for everyone. Scala can be written very Java like and will work like Java with no surprises.

Sure, it has a functional component which some people find hard, but even Java 7 will get closures, with what some people think is a weird syntax.

Mike P(Okidoky) replied on Fri, 2010/08/13 - 4:26pm in response to: Nils Kilden-pedersen

Oh, but there is one nasty surprise. No proper break, and no continue. And if you bring it up, you'll get a bunch of stupid excuses.

Dhananjay Nene replied on Fri, 2010/08/13 - 4:45pm in response to: Josh Berry

Perhaps our mileages vary. But the impression I carried back from Scala was that it was a Swiss knife with a very large number of knives each of them slightly different from the others giving it tremendous capability and versatility. However it required one to understand lots of little nuances - a process that is likely to take some time to understand and then some to internalise.

With regards to typing - I'm afraid I'm equally comfortable with static and dynamic typing. So I'm unlikely to be convinced substantially by the static typing aspect. I really liked the brevity of most dynamically typed languages, but its Scala's type inference which did open my eyes to the fact that if one sought brevity, it could be had with static typing as well given type inferencing.

Nils Kilden-pedersen replied on Fri, 2010/08/13 - 6:22pm in response to: Mike P(Okidoky)

Oh, but there is one nasty surprise. No proper break, and no continue

By "surprise" I think of code that doesn't work the way you intended. Having no break and no continue does not fall in that category. You just code differently. I miss them too, but they're not essential.

Mike P(Okidoky) replied on Sat, 2010/08/14 - 12:11am in response to: Nils Kilden-pedersen

Another silly excuse. Break and continue are essential and I've seen the alternatives and they are awkward. Martin and people defending his decision are flat out WRONG.

Bruce Fancher replied on Sat, 2010/08/14 - 1:57pm

Constructs that are natural to humans not mathematics : This is actually a sub point to Simplicity. The constructs should be consistent with the normal average non mathematically trained brains. 2 + 3 is much simpler to understand than (+ 2 3). Python rocks. Lisp / Clojure or for that matter brainfuck dont.

If by "natural" you mean "instinctive," there's nothing natural about ordering symbols according to certain rules to represent abstract concepts and operations. Syntactical details such as the placement of operators or parentheses only seem "natural" to you because that's what you're used to. As the authors of The Joy of Clojure put it:

It's difficult to imagine that there is a strip of DNA allowing people to intuitively understand C-like syntax; instead only over time did the nuances become second nature. Over time the same will happen with you and Clojure, and the stress from the location of parenthesis will simply fade into oblivion.

Dhananjay Nene replied on Sun, 2010/08/15 - 12:37am in response to: Bruce Fancher

By natural I mean what people are used to. As an analogy people have attempted to put in place better keyboard layouts, allegedly far superior to the traditional QWERTY. These layouts probably have been far better - but QWERTY still rules. Changing habits is hard. And if you have to change habits over a large number of people, not every one of them deeply inspired to want to change them - its so much harder.

This is no reflection on the quality of the new keyboard layouts. Just a reflection on the fact that a large number of existing people are habitually used to supposedly flawed QWERTY layout, something thats just hard to wish away.

Liam Knox replied on Sun, 2010/08/15 - 2:39am in response to: Martin Wildam

Well said. Scala I thought was the closest but I think it is too far removed and complex compared Java to get the uptake.

Silvio Bierman replied on Sun, 2010/08/15 - 6:02am in response to: Mike P(Okidoky)

You are completely full of it. Both break and continue are far from essential. Languages like Algol60/68, Cobol, Fortran, Pascal, Modula, Basic and all functional languages including the highly regarded Haskell have existed just fine without them.
Only when Dennis Ritchie decided to create his own semi-assembly language for systems programming called C in 1972 did break and continue see the light. C++ and it's derivative Java (the JVM assembly language) inherited them.
Although many think that break, continue and disruptive return are bad programming constructs that break the single-entry/exit principle most people can live with them. You seem to be someone who can not live without them, since you keep bringing them up in all language related discussions.
They would serve little purpose in Scala since the only actual local loop construct available there is the plain while-loop (I hope you know that Scala has no equivalent for the C/java for-loop) but they could be added without breaking much. However, since nobody besides you thinks that the language is crippled without them nobody actually bothered, probably because idiomatic Scala codes contains little while loops (and usually for-comprehensions as well). I counted 17 for-comprehensions and 6-while loops in my current Scala project that contains ~350 Scala sources and ~11K lines of source. Instead of adding break/continue I would vote for removing return from Scala
I suspect you are a quite inexperienced and light-weight programmer who happens to be a loud-mouth. Your remarks are far from insightful and akin to a nagging spoiled brat. You have a very limited view on programming and insist on fitting every language into your tiny perspective.
Different programming languages do not exist to have alternative notations for the same imperative constructs, they exist to allow for different ways of expressing algorithms and concepts. But that is probably far beyond your comprehension.

Josh Berry replied on Mon, 2010/08/16 - 10:01am

My experience with scala, so far, has been that I can stick to just two features and have my "Java like" code reduced in complexity by a large order of magnitude. These features are:

  1. case classes
  2. No longer needing everything in a separate file

Sure, you can make some concise code with the other features. However, someone writing what is still essentially "idiomatic Java" taking advantage of those two features will suddenly find they are writing a whole lot less. More, they no longer get upset when they realized that they forgot to maintain their .equals and .hashcode methods. (Something that I am always shocked to see people usually just don't even realize doesn't work. It kills me that it takes so much boilerplate to have objects that "do the right thing" with sets and maps.)

As for the static versus dynamic. Testing is hard enough when you have to write everything. Learning to let the type system provide you with a rich set of tests from day one is incredibly hard to argue against.

p.s. I am going to just avoid the break/continue debate. It does amuse me that some folks seem to place so much importance on them. I've rarely used them, myself, so I'm not sure I have anything constructive to add to the debate.

Mike P(Okidoky) replied on Mon, 2010/08/16 - 12:16pm in response to: Silvio Bierman

One would think that in places like this, people wouldn't be resorting to childish demeaning condescending insults. Guess not.
Just to get a quick impression of how I'm not an "inexperienced lightweight programmer", I've developed complex software since the early 80's, and have extensively used assembler, C, C++, a few of my own interpreters and compilers, Java, bash, awk, php, and a ton of other stuff I can't think of right now.
I must be coding different type of things than you are.
Fact remains. When searching in a loop for something, there needs to be a way to cancel the remaining part of the loop, without making the code look all cluttered up or scattered. What on earth is so hard to understand about that? Show a reasonable example of an alternative of breaking out of a loop. And how about a loop with an inner loop? Can you do that in Scala without using a flag of sorts?
Same goes for continue.
When someone argues against the newly found anti break/continue religion, some people choose to get angry, instead of offering a reasonable explanation.
I found this: http://stackoverflow.com/questions/2742719/how-do-i-break-out-of-a-loop-in-scala
I like the "guard" feature, if only it would have stopped iterating. Perhaps a while in stead of an if... What about continue?

Silvio Bierman replied on Mon, 2010/08/16 - 6:11pm in response to: Mike P(Okidoky)

You invoked the demeaning response by repeatedly coming up with the same topic in threads where it does not belong. By now we know you think break and continue are essential programming constructs and Scala is a hampered language since it does not support them. I responded to this in another thread already. You not only find it necessary to repeatedly make your point but along with it be demeaning toward Martin Odersky for not jumping up and adding it right away because you think it important.
That is also why I doubted your experience. Such behaviour is not common among people who have been around for a while, have seen their share of tools and languages and have taken part in fruitful discussions with other professionals.
I did use to search in loops when I coded in Java and did use break and continue frequently. In fact, when talking about Java I would support your opinion that break and continue are useful albeit not essential (apart from the stupid case fall-through, of course).
In Scala the main reason why I (and people in general) have little desire for break and continue is that the collection classes are an integrated set of monads with all functionality needed to express operations in a terse, clear and efficient way without the use of loop constructs and other boiler-plate code. That combined with other languages constructs like pattern matching has allowed us to move on to a more high level style of programming.
There is nothing religious about it. On the contrary, I think you are being religious about your style of programming. As I said in another thread, if you want to program (nested) loops and break out of them from different points and in different ways, stick with Java. Perhaps Ruby would be even better since it offers even more loop/flow constructs. Be aware that after that you will probably be bashing Java for lacking redo and retry.
Do you know what single entry/single exit means? Do you know that break and continue and disruptive return are in conflict with that pattern? If so, what is your take on that? Was Wirth wrong? How does that translate to a language that emphasises on a functional programming style? Can you provide examples of common scenarios that can not be properly and efficiently handled with what the Scala collection library provides? Have you researched other languages (like functional ones) to see what these offer and have perhaps inspired the Scala designers?
If you would have added that to your cry for break and continue you might have received serious response. Since you did no such thing you where not taken seriously and mainly ignored. If you then decide to keep reposting your opinion in threads where it is out of place you should not be surprised when you receive slightly annoyed reactions.

Mike P(Okidoky) replied on Mon, 2010/08/16 - 10:20pm in response to: Silvio Bierman

Relying on your assumptions that there are concepts and paradigms I don't know, makes your argument/excuses weak and nonconstructive.
I prefer to focus on examples and real world scenarios. I'd like to know how you would code this in Scala:
void findFiles(File dir, Set<File> files)
  for (File file : dir.listFiles())
    if (file.startsWith("."))
    if (file.isFile())
      String name = file.getName();
      if (name.endsWith(".vim"))
      findFiles(file, files);

Silvio Bierman replied on Tue, 2010/08/17 - 1:40pm in response to: Mike P(Okidoky)

I did not assume you don't know them, I just asked if you did since they are relevant but you left them completely out of the discussion.
Your sample does not compile because File does not have a startsWith method so I assume you meant that the name of the file should not start with a ".".

First of all I think this is a typical example of bad use of continue. I would have written this in Java as follows:
void findFiles(File dir, Set<File> files)
  for (File file : dir.listFiles())
    if (!file.getName().startsWith("."))
        if (!file.isFile()) findFiles(file,files);
        else if (!file.getName().endsWith(".vim")) files.add(file);
I think this expresses the intention of the code much more clearly.

The naive Scala version would then be:
def findFiles1(dir : File,files : scala.collection.mutable.Set[File])
	for (f <- dir.listFiles if (!f.getName.startsWith(".")))
		if (!f.isFile) findFiles1(f,files)
		else if (!f.getName.endsWith(".vim")) files += f

I would prefer to write this as:
def findFiles2(dir : File,files : scala.collection.mutable.Set[File])
	val (fs,ds) = dir.listFiles.filter(!_.getName.startsWith(".")).partition(_.isFile)
	fs.filter(!_.getName.endsWith(".vim")).foreach(files += _)
	ds.foreach(d => findFiles2(d,files))

or even
def findFiles2(dir : File) : Seq[File] =
	val (files,dirs) = dir.listFiles.view.filter(!_.getName.startsWith(".")).partition(_.isFile)
	files.filter(!_.getName.endsWith(".vim")) ++ dirs.flatMap(findFiles2(_))

which is shorter and clearer though theoretically less efficient. In this case (as in most cases) I would consider the trade off to be positive.

Dhananjay Nene replied on Wed, 2010/08/18 - 2:38am in response to: Mike P(Okidoky)

I am actually unclear whats the big deal here. The same logic you wrote, rewritten in java itself again without using continue is


	void findFiles2(File dir, Set<File> files) {
for (File file : dir.listFiles()) {
if (! file.getName().startsWith(".")) {
if (file.isFile()) {
String name = file.getName();
if (!name.endsWith(".vim"))
} else {
findFiles(file, files);

Mike P(Okidoky) replied on Wed, 2010/08/18 - 8:13pm in response to: Silvio Bierman

You were lucky, because you were able to find a way to massage the code around where you were able to work away the break and continues. Now try the same again, pretending you can not work away the breaks and continues.
If you find it impossible to imagine that no code is possible where you can't work breaks and continues away, I can come with a better example.
I was hoping for a little more creative thought where you would work WITH me on this, and show me what Scala code would look like as is. I bet you're going to tell me that of course in Scala you'd do things differently and how one wouldn't be running into the problems I'm talking about. I think you're wrong, and I have the feeling that I'll be forced to have to come up with a better example.

Mike P(Okidoky) replied on Wed, 2010/08/18 - 8:41pm in response to: Dhananjay Nene

Don't focus on finding a way out by seeing a way to massage out the break/continues. Pretend the code is more complex and how the break/continues can't be moved around. Then what would the scala code look like?

Silvio Bierman replied on Thu, 2010/08/19 - 5:35am in response to: Mike P(Okidoky)

The point is that you should find a way out. Code should not become more complex or you have done a poor job at code design.

I can easily come up with code containing some goto statements that can't possibly be converted to a structured combination of while and if constructs without either a number of control variables or code repetition. That could be considered proof that goto is an essential language element but actually it proves I have created a really poorly structured piece of code.
History has shown that the existence of goto in earlier languages influenced the way programmers constructed their code because beginning programmers often found the goto abstraction easier to grasp than if/while/for etc. Once they became more skilled they where often more inclined to create bigger and more complex programs written in the same style than using the more abstract constructs.
After Dijkstra's plea for banning goto (and even before that) language designers mostly chose to drop the goto statement or at least publicly deprecate it. Currently, few think that goto should be reintroduced to the languages we use now and in the future.

Many people think break and continue are too much akin goto and think they have the same bad influence on programmers and the code they write. Your code example probably supports their case since it contains lots of inverted logic. Instead of writing "for each element E of container C that conforms to B do U" you prefer programming it the opposite way using the continue statement as the control structure to skip elements you don't need. I suspect that is a line of thinking heavily influenced by languages supporting a continue-like construct.

You may not like it or accept it but this is generally considered poor programming. You can not blame language designers for trying to influence the way people write code in their language. Neither can you blame them for considering your programming style to be one that should be discouraged. You are free to ignore these languages.

I am not saying I am a better programmer than you are as you have repeatedly claimed. I am just saying that I choose to learn from new languages by learning to understand why they where created that way. This has lead me to change the way I program constantly during the ~25 years I have been doing it. I went through Assembly, Algol 68, Pascal/Modula, C, C++, Java and Scala as my "main" programming language and have used numerous languages (among which Prolog, functional languages, Basic, Objective C) on the side. They all taught me something. I am merely suggesting you do the same instead of trying to fix languages to your needs.

Mike P(Okidoky) replied on Thu, 2010/08/19 - 10:53am in response to: Silvio Bierman

I've pointed out how there is the need for skipping the remainder of an iteration or all iterations. An example on my part was quickly answered by massaging the code around to make it Scala-able, avoiding break/continue altogether. Then when I suggested to imagine code that is more complex where you can't shuffle it around to avoid the break/continues, my suggestion is thrown on the goto pile, along with all the arguments against it.
While goto is, break and continue is NOT "poor programming". Not in the tiniest bit. It's very legit, elegant, normal, usable, and needed. Scala is not that different where it would be inappropriate to have it.
And if it is, give me a valid reason. If it would be interfering with functional aspects, explain it. So far, I'm not seeing any reason to not have break/continue. And this is not about fixing it to suit "my needs". I'm *SURE* others run into this exact same thing.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.