Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Historically a HLL is something like C, Fortran or Pascal and a VHLL is something like Ruby or Python. I am familiar with the terms 4GL, 5GL, DSL and LOP, and those who aren't should read Wikipedia for the definitions. I'm looking for UHLLs.

My question is: are there any computer languages out there which are another order of magnitude more productive, and is anyone working on them?

More productive means less authored code and less programmer time to achieve a result, less bugs and less debugging, closer conceptual link between code and requirements, less effort to modify and maintain.

The main domain that interests me is general-purpose business and consumer applications, with a GUI or browser front end, data persistence and connections to other systems such as printing and email. Other people might well focus elsewhere.

I recognise that some of those languages might be domain-specific, and that they might be little more than the configuration capability of a large and capable application. Excel spreadsheets fall into this category.

I recognise that some of those languages might appear general, but might still be narrow in scope and unsuited to many problems. For example, Matlab might not be a good choice for a program that deals mainly with user interaction and textual data.

I know some of the features that might be in a UHLL, by analogy with VHLL. I would expect to find one or more of the following (and feel free to add to the list):

  • A drawing of a GUI form IS the program for a GUI form
  • A table containing rows, columns and headers IS the program for a table in a database
  • Declarative logic says what should be done and when, with no IF statements
  • Operations on sets of data, with no FOR loops
  • Non-sequential execution eg data driven, pattern matching, tree walking

The motivation for the question is that I am increasingly fed up with the sheer hard work of translating relatively simple business requirements into large quantities of code to cater for what the computer wants or needs. The question is really about finding others out there who share my pain and are working on raising the level of languages and getting the computer to do more of the hard work. This was a major focus in the 1970s-80s, but is it still happening?

These are some suggested answers to my question, provided here to to summarise or enumerate languages I know about, and which in my view fall short.

There are many languages that are HLL or VHLL and contain individual features that belong to a higher level. I've used most of them (often badly). They include

  • Lisp, with its macros and ability to self-modify
  • Haskell, with data dependency and pattern matching
  • SQL, which deals in rows and tables
  • Rebol, which seems clever but I don't really get it
  • APL (and J), with its multi-dimensional arrays and ultra-compact operators
  • C# with LINQ
  • AWK/Perl/Python/Ruby with wonderful collections and regexes built in

These languages have too many low level features to be UHLL. The programmer still has to write many low level constructs for any useful program.

There are RAD/4GL packages. I've used some:

  • dBase/Foxpro
  • Dataflex/Powerflex (my product)
  • Access
  • PowerBuilder

And lots more I haven't used. Mostly the language is HLL at best but the package contains a framework and privileged connections between language and package so that applications can be built fast. I'm not sure why this approach ran out of steam, but in any case UHLL this is not.

There are raw frameworks/libraries. I've used a few:

  • Rails
  • Java awt and swing
  • .NET Windows Forms, WPF and ASP.NET.

These are currently the state of the art. They leave the programmer firmly trapped in the mire of the implementation language, dealing with complexity at every turn. This is not UHLL, but a UHLL might conceivably be built on top of one of these.

There are design tools, like UML and Rational's toolset, which I don't know well. As far as I can see they help articulate business requirements but can never replace the programming step. I don't want to eliminate programmers, just get more done per unit of time and effort.

So having eliminated all contenders I can think, I hope someone else can provide a better candidate.

Late Edit: I think I have an answer: Wolfram Language.

share|improve this question

closed as off-topic by gnat, GlenH7, GrandmasterB, MichaelT, Doc Brown Jan 23 '14 at 22:56

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking us to recommend a tool, library or favorite off-site resource are off-topic for Programmers as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it." – gnat, GrandmasterB, MichaelT
If this question can be reworded to fit the rules in the help center, please edit the question.

@Phoshi - the last three points are covered by SQL as well. Just not in a DWIM (do what I mean) manner. – kdgregory Jan 22 '14 at 14:27
A drawing of a GUI form IS the program for a GUI form Sure, but where is the code that handles button clicks, UI refreshes, etc...? Have you ever worked with Visual Studio's form designers? They still write code under the covers, but usually the developer never needs to look at it. They just develop the form "visually". Except for custom code like the bodies of event handlers... A table containing rows, columns and headers IS the program for a table in a database What about all the triggers, indices, and constraints on the database table? – FrustratedWithFormsDesigner Jan 22 '14 at 16:22
@FrustratedWithFormsDesigner: And yet you're... frustrated. – Robert Harvey Jan 22 '14 at 16:48
@RobertHarvey: Yes. But not as frustrated as if I had to write all the code myself. ;) – FrustratedWithFormsDesigner Jan 22 '14 at 17:18
What can be a higher level language (as in "the most abstract") than a DSL tailored for a particular problem domain? And, of course, there are some languages out there which had been designed specifically for building such DSLs efficiently. – SK-logic Jan 22 '14 at 19:30

6 Answers 6

Almost all the criteria you list are things already tried in 4GL / RAD tools like MS Access, Sybase Power Builder, Oracle Forms, Ruby-on-Rails (as a more modern specimen for Web Apps), and many more (see Wikipedia for a very long list of vendors). And indeed, translating relatively simple business requirements into some kind of program can be very quickly achieved with these tools. That's why most vendors of RAD tools advertise their products in a way that everyone should think they have already invented a UHLL in your sense.

The catch is, as soon as you leave the ground of requirements being "relatively simple", and as soon as you have to maintain and evolve programs written with these environments, you will notice that you easily reach the limits and notice the drawbacks of them, or that to implement requirements with them is in no way simpler than with any other "VHLL" you have in mind . IMHO there is a good chance that these kill any efficiency improvement you had in version 1.0 when going further to version 1.1, 1.2 and 1.3 of your program.

If you want to build software for complex requirements, you will need a complex programming environment. There is still no silver bullet, we had only gradually improvements over the years and not "the order of magnitude" in productivity with any current programming language over its predecessors (at least, for the last 30 years, which is approx. the time in the past when Brook's article was published).

share|improve this answer
+1 for relatively simple. Actual business logic tends to turn spaghetti very quickly. – Bobson Jan 22 '14 at 20:06
+1 for as soon as you leave the ground. To me they are often very much like "build a blog in 5 minutes (without writing code)!" type advertisements. Its great, until you have to implement something resembling a real program, and then suddenly what you thought should be a simple thing isn't. Maybe they are great and I just don't understand them - but the marketing makes it really hard to believe it isn't just a bigger mess the farther you go. – BrianDHall Jan 22 '14 at 22:38
Yes, I know. I've written code in most of those 4GLs and several others. The ones I've used do scale, but they do so because they contain an embedded not-very-good HLL, such as VBA. And the all have limits and, being closed products, you can't change those limits. Yes, Fred Brooks is right, so a UHLL would need a whole armoury of bullets. – david.pfx Jan 23 '14 at 6:01
I call this the "Dreamweaver effect". UHLLs are just ultra-leaky abstractions – Charles Salvia Jan 5 at 17:57

The highest level programming language that I know of is APL. It requires a special keyboard to represent all of the necessary symbols. Check out this video, in which the author writes a complete implementation of Conway's Game of Life in about seven minutes.

The real question, of course, is "is this practical?" Can I find enough APL programmers in the world to sustain a business this way? Will APL run on phones and tablets? Do I really need to buy all of my software developers new keyboards?

If you really want a productivity boost, your best bet is probably some Lisp variant. Clojure runs on the JVM, and has a .NET port. I say this because people have already done it; the Orbitz search engine runs on Lisp, and Paul Graham ran an entire business using Lisp, claiming that it gave him a significant advantage over his competitors (who were all using Java).

Do note that, the higher level your programming language is, the more removed it is from the actual hardware, and the more likely it is that you'll have performance problems. Unless you have really sophisticated compilers, you may still find yourself coding performance-critical portions of your application in more performant, lower-level languages from time to time.

And there is still the matter of having a critical mass of developers versed in the language. Despite all its warts, you will never have a problem finding a Java programmer.

Note that mainstream languages are still evolving. Linq was created for the specific purpose of making data-driven programming more declarative. Several new features were added to the C# language to make Linq work; all of them have to do with improving developer productivity.

Further Reading
Beating the Averages

share|improve this answer
Linq is an excellent example of the kind of code I mean. I love writing ifs and loops as whens and selects, all in a single line. Any other examples like that? – david.pfx Jan 23 '14 at 9:57
@david.pfx: C# is rather late to that party and I find it's syntax backwards (it uses SQL keywords, but the order is different where everybody else uses the SQL order and simpler keywords/symbols). The way they can compile it to SQL is however better than what most languages can do. – Jan Hudec Jan 23 '14 at 10:29
@david.pfx: Pretty much any functional language having list comprehensions can do what Linq does. – Robert Harvey Jan 23 '14 at 16:06

I think you've hinted a bit at a cross-over point that limits the existence of Ultra High Level languages - at some point we don't identify them as programming languages anymore.

The best example of this specific phenomena that I am aware of, and which is perhaps of great potential interest here, is Unified Modeling Language. Indeed, there are specific software application stacks that have been developed to specifically do what you are asking. It meets many of your requirements, but not necessarily in the way you are thinking. Still, it is extremely educational for this situation, as I have felt similarly and my experience (which follows) has changed the way I think about this problem.

I will personally here speak of IBM's Rational Software Architect, which is an attempt to really allow Ultra High Level development. The goal is that you are able to create the philosophical business concept as an object, such as an Actor or Class, give the entities attributes, define connections, define how information might flow through the system as it is being worked on, and do this all with a GUI.

You might for instance drag a DataStore object, an Actor, a form, a few relevant Classes (like Customer, etc), draw some connection lines between objects using graphs and such, and boom: when you are done you publish a working program. (this is obviously extremely simplified)

Indeed, what has been done is the formation of a complex GUI, a very thorough implementation/interpretation of UML, and then it compiles to Java/C#/VB code with full XML documents holding the UML graphing info, and they also implement/enable Round-Trip Engineering so you can go back and forth between Model and Code so you can control things at both a very high nose-bleed philosophical level and very low level platform-specific code.

It's everything you want, and more, and you give up nothing in the exchange! Right?

Why doesn't everyone use it?!?!

...well, see, that's the thing. What you actually end up with is a monolithic undertaking, everything involves a whole lot of moving parts and magic, everything is - or sometimes isn't - effected by a change in any of many different places (in the GUI, XML, lower level code, UML models which are themselves created/defined/maintained in many different model levels).

It's all really cool to play with, but it to put has an extremely high learning curve, is designed with multiple disciplines in mind, and you really have to treat it as an utterly new thing that allows little - very little - generalizability for other skills you already have.

And the bottom line is - even then, with millions upon millions poured into the project from dozens of companies and some very big names behind it, you still end up with C-style code at the executable layer which has to be edited directly at times, because some things just don't make the translation between Object Oriented Class Descriptions and UML down to programming/machine level, and the automation just can't quite complete.

My experience was that it was an incredibly complicated way to generate scaffolding. That is probably the cruelest thing I will ever say about such an immense technological undertaking, but that's what I got from it.

From the people in industry I've talked with, they sadly said the same thing. Their feeling was they did a lot of work creating documentation, countless diagrams, models, meetings, analysis, over months and months, and then they threw it all out and the development team just wrote the code for it and often just treated it as Yet Another Specification Binder (That No One Ever Reads Anymore). So now they just use Java and some special-purposes diagramming/visualization software, and Agile, and that's the end of that story.

Maybe this is unfair, and it works when you do it right. Maybe, but from consultants and professors I've talked with they claimed to have spent many hours in special multi-week development workshops working to learn the system, and going back for more training, and quite literally spending years to learn how to make it work and what goes where.

But maybe it's all programmers fault, that they just refuse to accept the system works so well and yet is nothing like computer programming at all. Maybe pure code programmers just resist having their jobs replaced, like the candle makers and weavers of old, and so refuse to just do their limited task of Implementation To Specification and this makes everyone else get so frustrated they throw it out and say bad things, and it Almost Was Perfect.

But...I think there may be some truth in that, yet I think mostly it just doesn't really work that well. I think it turns something that Isn't Really That Hard Most Of The Time (computer programming), and makes it even harder to the point that if it works it'd be great, but holy crap you have a long time with nothing to show for it to get there!

Maybe it would work only in an enterprise with thousand+man teams, and maybe we just aren't there yet.

I dunno.

However, a study of what is right, and wrong, with this approach to Ultra High Level Languages - and I think UML kind of needs to be included in such a consideration - really must consider things like Rational Software Architect, so as to avoid a potential fools errand.

Or maybe we just have to give it another 20-50 years of hard work. I am no longer optimistic that a programming language is the constraint, any more.

And if programming languages were the constraint before, that's why improvements gave us a potential order of magnitude improvement. If they aren't such a constraint any more, then any innovation is much more likely to be unable to provide such an order of improvement. But I can't tell the future! So I shall assume the rest is not "in the works", but certainly "too soon to tell".

share|improve this answer
Do you really think to eliminate coding? I see no prospect of business requirements being translated directly into code until computers are as smart as we are. – david.pfx Jan 23 '14 at 9:56
I've had the dubious pleasure of working with Rhapsody (I wonder why IBM bought another similar tool and have two similar sets of applications under the IBM Rational brand) and my experience from it is that it does not scale. Multiple people working on the same piece of code is a well studied and solved problem, but multiple people working on the same piece of UML just does not work. – Jan Hudec Jan 23 '14 at 10:40
'Why doesn't everyone use it?!?!" - because it produces bad results. This is a horse that has been flogged within an inch of its life. UML is a failure. – duffymo Jan 23 '14 at 11:33

I would expect that Lua, as used by game to script their quests and interfaces would meet this criteria. There's also similar domain specific languages (and map-builder utilities) used to allow level designers to quickly and easily say "when player talks to Bob, start Bob's Epic Quest".

I know of a few more esoteric languages that focus on moving code to describing what is going on, not how it's supposed to be done. Some focus on a very declarative, logic based approach. Some focus on reactive programming to do that. Some focus on actors to do that (especially for things that need to be parallelizable). Some focus on simply making the syntax more natural - with the assertion being that natural syntax leads to fewer bugs caused by translating between natural language and code.

None are really promising as far as producing an order of magnitude more productivity for the rank and file developer.

share|improve this answer
Wouldn't lua be better suited as the language for coding low level details, below the reach of the UHLL? – david.pfx Jan 23 '14 at 9:54

If you think about it for a while, higher level programming is basically being able to compose smaller parts that are readily available and proven. Up to the point where your program is very simple glue code of various libraries. Maybe the glue is a very expressive DSL. You can do this in about every programming language.

Personally, I'm more and more beginning to sense that the solution to composability is - contrary to what you may instinctively feel - not found in object-oriented programming. This paradigm, as well as imperative programming, provides too much freedom to programmers which in turn makes it too hard to write code that is easy to reuse.

Rather, I think that functional programming provides primitives which are much better suited for composability. Pure functional programming languages also do not allow you to define functions that have side-effects, which not only reduces bugs or facilitates spotting them, but also makes it easier to build on them (compose them to a bigger system).

If functional programming interests you, you may have a look at modern functional languages like Haskell. I think that the Parsec module provides a nice high level DSL (it's called a combinator library in functional jargon) to parsing. There are also functional reactive programming frameworks for Haskell that allow you to build powerful GUI's with a few lines of code.

share|improve this answer
-1 for answering a "yes/no" question without saying either yes or no. (And ignoring the specific vocabulary in the OP's question.) – DougM Jan 22 '14 at 22:53
Actually, I think this is right. The UHLL is not for implementing features that already exist, but combining them in ways that are too hard to think about at the lower level. Do you know any? Haskell is not it. – david.pfx Jan 23 '14 at 9:53
Thank you for your positive response. I was actually just thinking about deleting the answer, as I agree with DougM. I wasn't suggesting that Haskell itself is it, rather I think that using combinator libraries in functional programming languages (like Haskell) are the way to combine ready made components. – masida Jan 23 '14 at 11:18

I think REBOL may fit all of your criteria. You can make relatively sophisticated GUI apps in several lines of code - however its "speciality" is DSL creation.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.