Re^2: Nobody Expects the Agile Imposition (Part VI): Architecture

in reply to Re: Nobody Expects the Agile Imposition (Part VI): Architecture
in thread Nobody Expects the Agile Imposition (Part VI): Architecture

We say that we build, applications. But, is that definition changing before our eyes? If the only thing that you need to do anything is a web browser . . .

Well, speaking as someone who for a living writes things that happen in a web browser, the definition sure seems about the same. I have a pre-written cross-platform UI toolkit with a weak but usually sufficient set of control primitives... but the hard part of most applications isn't assembling the UI anyway.

I tend to believe that if the set of pre-written inter-pluggable primitives ever actually becomes rich enough to do all the stuff we "program" to achieve, all we'll have really done is just made a new programming language; it's not qualitatively different, and it's still going to require people with the same skill set as "paleoprogramming".

Comment on Re^2: Nobody Expects the Agile Imposition (Part VI): Architecture

Replies are listed 'Best First'.
Re^3: Nobody Expects the Agile Imposition (Part VI): Architecture by ELISHEVA (Prior) on Jan 24, 2011 at 19:58 UTC
I tend to believe that if the set of pre-written inter-pluggable primitives ever actually becomes rich enough to do all the stuff we "program" to achieve, all we'll have really done is just made a new programming language; I think that was one of the lessons of the 4GL (forth generation language) movement. Any toolkit sufficiently expressive to cover all of the client's business cases inevitably needed the full set of control flow statements. It quickly ceased being something just anyone could use and turned into something that required a programmer. What makes programming programming is not the units we work with - bits and bytes vs. complex objects. Rather it is the logic that binds them together into something useful. Once that logic begins to include conditionals, loops and the need to organize collection of data and functionality into discrete loosely coupled sub-systems or objects, it requires, as you say, "the same skill set as 'paleoprogramming'".	[reply]

Replies are listed 'Best First'.

Re^3: Nobody Expects the Agile Imposition (Part VI): Architecture
by ELISHEVA (Prior) on Jan 24, 2011 at 19:58 UTC

I tend to believe that if the set of pre-written inter-pluggable primitives ever actually becomes rich enough to do all the stuff we "program" to achieve, all we'll have really done is just made a new programming language;

I think that was one of the lessons of the 4GL (forth generation language) movement. Any toolkit sufficiently expressive to cover all of the client's business cases inevitably needed the full set of control flow statements. It quickly ceased being something just anyone could use and turned into something that required a programmer.

What makes programming programming is not the units we work with - bits and bytes vs. complex objects. Rather it is the logic that binds them together into something useful. Once that logic begins to include conditionals, loops and the need to organize collection of data and functionality into discrete loosely coupled sub-systems or objects, it requires, as you say, "the same skill set as 'paleoprogramming'".

[reply]

In Section Meditations