Well, Marco, I wonder how long it is since you looked?
Well, I think I went to work today.
Software tools are already emerging that substitute iteration and
interaction for sequential processes.
Sure, for certain limited domains, the actual engineering is done,
and there is a nice tool to customize that in several ways.
Useful? Certainly. Timesaver? sure. Potential to be universal? No way.
SQL Server for example has a "drag and drop" tool that allows processing
streams to be built in minutes.
I've used laboratory controlling software which was nice in a lot of ways
too. It was truely useful, productive and IMHO the most important,
it avoided a lot of errors.
But I would never claim that such a thing could be generalized and replace
software engineering. They are problem-domain specific solutions, nothing
more.
These same streams using procedural code would take days.
Sure. But that doesn't spell the end of procedural programming.
What's more, if you get it wrong you can simply go to a graphic interface
and change it.
I do that with sequential programming (Delphi) too. Tools for a specific
domain. It saves time (and equally important) makes the product somewhat
easier to maintain.
I have seen at least one Graphic design package that uses a
similar principle. Non computer literate designers can easily manipulate
these tools, interact with them, iterate their processes, until they
achieve what they want.
Within very simple, limited borders. There is not one such tool that
replaces general programming (regardless of which paradigm you use)
Programming knowledge is NOT a requirement.
It is. Those environments are extended using normal programming, tackling
large projects still needs skill.
Those tools are just that, extra tools. Pretty comparable to fancy
runtime (and later classes-) libraries. None of them spelled the end
of programming either.
Hmm, I think that is a good description. Some extra tools to aid software
development, and allow a _user_ some customization.
Currently, tools like this are in their infancy. In 15 years we can expect
significant improvement.
Well. Then exactly this is our point of disagreement. Please explain
why you think (and how do you envision that will happen) how you get
from domain-specific solutions (math,laboratory handling, db handling)
to general purpose programming.
This is also what annoyed me about your previous message. It is a message
of a believer. There is no reasoning behind it. You only "get" it when
you are a believer.
The computer skills of the Business are rising very rapidly.
IT skills in using their own applications. Not in programming and
customization. In that department it got worse, especially in companies with
highly skilled (non-IT) technical people.
In the old days any beta-sciences student or graduate could do some
general purpose programming, usually they learned it so they could
program calculations. Nowadays they use mathlab, which is
absolutely great, but combined with faster machines requires less
programming skill to achieve the same result.
Which is good for them, but not for the level of programming knowledge
in a company.
No, they're getting pretty wise to that one too...in fact, most of us are.
If that were the case, I wouldn't get +/- 50-100 spams a day.
It isn't enough just to provide a solution; it has to be an acceptable
solution.
That means using tools and methods the users are comfortable with.
I don't see why that would be the case? Its like a car mechanic who has to
fix a car with the tools an average person has in his house.
In 15 years they WON'T be comfortable with some old academic cobbling code
together for a solution... By then they will have bypassed the need for
coding and will be implementing their own solutions.
Amen
Still a little thin on reasons though.
That was the whole point of my argument. They are doing it already... More
and more Business departments are gaining enough computer literacy to
build their own systems using standard solutions like spreadsheets and
databases.
That kind of limited hobbying always has happened.
The last place I worked (a major utility in the Midlands of England) there
were more people in the Business with Computer Science degrees, than I had
on my IT staff.
Hmm. My former employer, which was IT related, had more chemists (including
me) than people with CS degrees.
There is no problem. I never suggested there was one. You can go ahead and
use procedural code for the rest of your natural life. (I intend to...). You
just won't make a lot of money at it. It'll become a "cottage industry" by
2020...<G>
A well. We have religious freedom
The process of iteration, as you would know if you had ever worked in a RAD
environment, does not require telepathy.
Very interesting. Why wouldn't I've worked in a RAD environment? Telepathy
again?
Your scorn is misplaced. Interaction and iteration enable HUMAN intelligence
to get in the loop, but does NOT require specific technical (i.e.
programming) skill.
While I think in retrospect that my tone might have been misplaced,
your second post confirmed my suspicious. You have a firm believe in
something, and really want to advocate that. However I don't find
much evidence, not even shallow ones.
Except maybe that one story of a business department full of people
with CS degree's. Now that's surprising that they were more likely
to get something working using minimal and standard tools
LOL! While I note that you are at a very reputable University (apparently
learning to use procedural code...)
I'm still honorary member of my former universities computer club.
I can assure you I have studied programming for the whole of my working
life (some 38 years - I started programming computers in 1965
What were YOU doing then <G>?) not behind
cloisters but in the real world.
Leaving aside your intended slight, I agree
that programming does require skill, but it was you who turned my statement
into a separation between programming as a skill and programming as an art.
I said that "Procedural Coding" is in decline. That includes the Language
and the Art...
Yet, except a firm believe that ordinary users with a few standarised
tools will replace them, you don't reveal much reasons.
I wonder why your response is so vitriolic?
I didn't set out to attack you.
I've been on news for over a decade now. And on Fidonet before that. While
trolling and wild speculation presented as "truth" might seem innocent to
you, it doesn't to me. It poisons a group, and creates an unequal position
for discussion.
The problem is that you don't have to justify yourself in 15 years if you
are totally wrong, like you would in a company. It is nearly anonymous, easy
and safe, yet it still does damage.
(and btw, keep in mind nearly medium-longterm IT forecasts have been wrong
till now)
As said before Maybe I was to harsh, yet I still stand behind the original
intentions behind that message.
Could you be a little sensitive to the truth of what I'm saying?
Please don't degrade to amateur psychology. It's seriously flawed enough
already.
The typical response of the student.
Again a belittling comment. Try to argue with something more substantial
arguments.
Are you saying that, without a
reference, you would question whether there is an accelerating rate of
change in computer technology?
No. I question if it goes in the direction that you say it is. So not
IF there will be change, just if it is going to be the change you proclaim.
OK, Alvin Toffler, Moore's Law, and the fact that I have to get a new
computer every 18 months...
Relates to programming how?
As for my knowledge of the Market place, I have worked in industry IT
services all my life. It is axiomatic to me that the Business needs are
accelerating and greater flexibility in response to changing and new
Markets is required in IT today than was the case even 5 years ago. I
don't need a text book to tell me this; my users are drumming it into me
every day... I can SEE the need for flexibility in system design and
implementation.
Sure, but you practically argue that this will replace software engineering.
Thank goodness there are tools and systems that are addressing this need.
(Client/Server, distributed networks, OOD and OOP are all paradigms that
are much more flexible than the traditional mainframe Waterfall
methodology, and coincidentally, none of them is tied to Procedural
Coding...)
We'll see. I consider OOP to be procedural programming too btw.
My figures are based on a real case. The Company concerned sold their IT and
leased it back. They did this when they had a bad year due to claims for
floods and droughts.
That's organisational detail.
It is interesting that in the "good" years they took no
action. Try telling a Board of Directors faced with a huge cash flow
requirement, that "Price is not the only point of competition". Even if
you're right (and I don't disagree with the statement) you will not help
your career...
Mine is practice too, everytime I argue on price, they come with "support"
(which they never use, and won't get), "security" (better large than
small company) etc.
award, with
Well, I always enjoyed the Hitchhikers Guide to the Galaxy, but I have never
been a troll. You have no idea who you are dealing with <G>.
One of the joys of usenet