Once again, somebody thinks that by whipping a new language out of their pants the ills of the world will be solved.

Get a grip above the waistline, sunshine!

A language is for a software project as concrete and steel are for a construction project. The language is supposed to be used to *implement* the concept, not to be the concept. The design is on the paper in both instances.

The reason why design methodologies aren't used (even the simplest of them!) is because too many programmers are too lazy to learn something new and *useful*. I have heard it too many times: "That takes work." Yeah, it does, and the rewards are significant. Personal effort and discipline aren't just their own reward, it pays off with a better product.

It sounds like it will be a bugger to debug by someone other than the original programmer. Concepts are extremely abstract and vary vastly between different people. It just sounds like a new way to introduce yet another level of obfuscation to code.

Interesting concept. It seems to have applied to Microsoft operating systems for quite some time. Now that Vista is here, we can see it in action.

when I read through his presentation, though he's certainly on the right track....

Simplify the language structure and syntax so that you can more easily use/develop/build the underlying concepts.

Kind of like good design patterns but without all the clutter that comes with implementing them in a language.

Then again I probably don't really grasp what he's going for but, anything for cleaner/lower noise to concept ratio!

This all sounds wonderfull. I wonder, in reality...

C is a simple lanuage, very few keywords, that type of thing, so mightbe more usefully, but wait, C does does not have "helper code" for todays requirements, no.

Andrew Moore, I agree and disagree: the point of working in a team means that you should have an understanding of what concept X means to the other guy, right? I work in a team and I can understand most others, but people struggle to get me sometimes (my fault).

Like all programming techniques and languages, this is another tool that might or might not work well depending on the job.

That article all sounded very alien or would it be artificial intelligence to use concepts for communications. Thanks for the feed, El Reg. And very spicy IT is too .... "Cette Source [sauce] de haute qualite est un melange de fruits, d'epices, et de vinaigre pur. Elle ne contient aucune matiere colorante ni preservative".

And I believe that HP is now in Dutch hands and you can be sure of something Innovative and entirely Appropriate from their Mutual IntelAIgents.........

As Past Grand Masters of Imperialist Great Games, it would only be natural for their Advanced IntelAIgents Virtual Defense forces to be HyperRadioProActive in NeuReal Fields of Intellectual Property Special Applications of Programming.

Big Brother and Endemol spreading their Wings 42 Fly Higher/Embed dDeeper? :-)

Nothing to see there, Move On now..... don't you Realise IT is AI Virtual Reality Trip for IntelAIgent Boffins rather than Ignorant Bozos...... but it is Open to All and All Sources and All Sauce. Well, you would expect nothing less from the Thinking which gives you AdulteRated XXXX Zones in which to Tickle your Fickle Fancy which is an Enlightening Dip exploring and destroying many Pre-Conceived Concepts.

Man what a visionary ! So software development hasn't fallen behind yet ? Funny that. I seem to remember that when the 32-bit 386 came out there still wasn't a compiler to develop 16-bit code for the 286. And it took ages to get a proper 32-bit compiler - especially in the absence of the Internet and easy downloads.

So software development got faster then ? Probably. Lots faster because doing a lot less checking. Which explains why we have all those buffer overflows and memory leaks - nobody knows how to do their checks anymore.

Now software development will be slowing down again ? And that is a bad thing, how ? Once upon a time you had to be an engineer to develop code. You painstakingly hunted down bug after bug, taking whole nights to understand just why the code crapped out when a certain condition was met in order to implement the right solution.

Nowadays, any teenager full of acne can start a social web site and code in a bunch of things off the top of his head (or rip off the code from his school project for profit), but if there is a crash, just file the memory dump and forget it.

Memory dump. Does anybody actually remember the days when UNDERSTANDING one was a requirement ?

Well, of course, software is slower than it was. It's also why we have so much software. New tools mean that you don't have to code in hex directly onto an EPROM or write in assembler for some obscure processor; you don't need to have the manual for the entire instruction set for a CPU beside you to write an application - and that's a good thing.

The tools have allowed us to become much more productive and produce much more complex software. It has also allowed every spotty teenager short on friends and every chancer with a background in support to claim that they're a developer and throw out code. That's fine as long as I don't have to use or maintain that code.

I agree with what someone posted a bit further up - we don't need new languages. With C++, Java, .NET, Lisp and one or two others we're pretty much covered. We need new methodologies to improve the way we work together. I think Agile development is pretty good for this, but it's not suited to every project.

I had a quick look at this concept programming, and I must say, from a superficial level, it looks very gimmicky. Plus I saw loads of keywords!

Let's just perfect that brain wave scanner to machine code compiler and then it'll be easy to get our concepts into code.

Now when did Knuth develop literate programming? Another day, another wheel, another label.

Done better by Knuth http://www-cs-faculty.stanford.edu/~knuth/lp.html

A software construction project is almost entirely unlike a building construction project, and the analogy between concrete and language is tenuous in the extreme.

Physical construction embodies the dichotomy between thought and substance. It makes perfect sense to distinguish between architectural drawings and the building itself because they do in fact exist on different substrates.

In software, the design and the implementation are both abstract entities, so any such distinction is artificial and arbitrary. That's not to say the distinction is useless - far from it, if we wish to use project management paradigms from the construction industry to guide us :p

The whole point of concept programming, as I understood it, was to allow the edge of distinction to be moved, which is much more difficult in proscriptive languages such as Java.

In other words, using more powerful languages *allows* you to stop fixating on languages, while using less powerful languages more-or-less forces you to.

So while I have sympathy for the view that new languages won't change the world, only a luddite is still programming in C.

Or not that new really.

Seriously though, if you took the .NET framework away from C# and the host of Java libraries (Swing etc) from Java, they wouldn't be much more use to anyone than good ole C++, or Ada.

Whizzy new languages are nice to have - C#'s lock and event specifiers are loverly, as is garbage collection, but the real power is in the .NET framework. I can code up complex applications very quickly on my own, because most of the work is being done by someone else's code, code that is likely to be considerably more bug free than my own.

I'd rather use an old fashioned language with a great framework than something cutting edge that requires me to write my own linked lists...

Maybe Concept Programming is brown and we'll all be wearing it next summer. Or maybe not. If it is useful, then no doubt some of the concepts will permeate into the mainstream. As long as it doesn't involve pair programming I'll give it a chance.

"A software construction project is almost entirely unlike a building construction project,..."

I would disagree with that and say ..... nay, even SHOUT.... that it is exactly like a building construction project.

Both start off with green field sites ie nothing and then deliver an Infrastructure which, depending on how well they have been constructed, in both workmanship and materials, will either stand the test of time and mature with usage or fail because of design or material faults.

And if you have a builder who can excel at every aspect of the build or who can recognise necessary third party skills to complement required Excellence from Inception through to Delivery and especially so whenever the Delivered Product is BetaTested against a critical Self Analysis to ensure the Highest of Industry Standards, you will have an Iconic Build.

I would also suggest, in the strongest possible terms, that new langauge is, and therefore will, change the world for the Better whenever IT is used to Better the World, rather than, as is so often the case, IT being used to cause and plant seeds for further Chaos and Destruction.

This idea of Concept Programming reminds me of an essay I had to write for my Philosophy module at Uni, "can concepts be described without using other concepts". And naturally the answer is 'no' because the whole thing become recursive as each term used to describe something is in itself a concept.

I think Concept Programming is liable to fall into the same trap. Whatever terms (i.e. language) you use to describe the problem, any resulting understanding of the problem will rely on other underlying concepts. This approach does not simplify the matter but invokes a kind of pedancy as each concept will need to be described in terms of other concepts for it to be understood. Object Oriented programming fell into this trap in the early days where programmers tried to decompose each object into its constituent part, ad infinitum. Talk about Analysis Paralysis!

What Dinechin fails to do is give any new method for converting the vague 'hand wavy' descriptions provided by the Marketing Dept. into concrete design detail in a way that entails zero time or effort (as is expected from most Project Managers). UML, for example, provides a very useful way of doing this but management usually refuse to sanction the months of preliminary analysis and design work involved when using it.

It is amazing how suprised managers are when you (try to) explain that complex software requires a large amount of thought and planning before you start turning the handle to churn out that fully functional and error free code that is expected.

Perhaps it would be more useful if one of these software gurus produced a mathematical model to show how software design expands expotentially as the number of requirements increase!

Rant over

FayeB

Regardless of whether or not it's been done before, I think a highly extensible language with a flexible notation is an interesting idea and might have (as the author suggests) a lot of benefit in that the syntax and semantics of the language can be structured around the problem that one is trying to solve.

However in a production environment, it poses a number of problems. If this idea is carried through to completion, for instance it means that the guy who comes along after a chunk of program is written to do maintenance is going to have to basically learn a whole new language that supports these concepts instead of being able to rely on prior knowledge of how the language behaves.

This dribble sounds just like all the other sales pitches for the newest silver bullet that will save the IT industry. Now, I may be wrong, but if I write a program (or system of programs) that have the functionality to support the concept for a project, then the code (be it C, C++, assembler, fortran, cobol, java, C#, etc) must also embrace the concept.

I read the article expecting the usual Computer Science giberish and the usual calling old ideas with new names.

But actually I was rather impressed. First of there is a real appreciation of what was good in C, Algol, Pascal and a serious attempt to hold on to the good stuff and improve it.

Also a serious look at what went wrong with the C++ Java etc.

The resulting XL language looks nice and whats more it looks usable.

The bit people seem to have trouble getting thier head around is the generics and the IMHO very wonderful "written as" syntax. But generics are a mine field anyway and the XL approach is definately better than the C++ or Java (C++ generic are unreadable and undebugable, my forst impresion of java genrerics is that you end up with more code than if you wrote a method for each signature!). And the "written as" is something completely new (at least to me!).

I expect all the Gerry Anderson fans are wating for release 5 of XL.