Dip into concept programming

My two cents...

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.

Wow, didin't fully understand this article but...

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!

Softly, softly, catchee monkey....

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.

NullReferenceException

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.

Like everything else in computing

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

Hmm - literate programming anyone?

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

Stop fixating on poor metaphors!

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.

Bricks and mortar ...... as luddite as C and every bit as important

"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.

Concepts. What are they?

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