On 03/07/2010 08:25 AM, Stephen Davies wrote:
> There is an interesting discussion on /. with the above topic.
>
> http://developers.slashdot.org/comments.pl?sid=1573922
>
> as someone who started out using Punched Cards& Paper Tape (but I bow
> down in age to John Lewis)
> and who has programmed in Fortran, Algol, Coral 66, Basic, Ada, Cobol,
> Java, C, Pascal, HTML, CSS etc., plus a whole shed load of machine code
> & embedded software (e.g. ITV Teletext Service Oracle's Subtitling
> Keyboard) many of the comments about the dumbing down, the use of
> frameworks and the like really ring a lot of bells.
>
These seems to me like the typical "in my day" rants.
I think there is any problem with programming as such, simply the
choices that management make.
The biggest cost of a large software project is the on-going
maintenance. For any reasonably large project the cost of fixing bugs
and maintaining the existing code. Because of this frameworks are often
chosen because they can dramatically reduce this cost. People work with
a framework they know and understand. The common bugs get fixed early
and everyone gets the fix (rather than having to track down a memory
leek from 5 separate people's bad linked list implementations, for example).
However those advantages come with a cost, usually in a lack of
flexibility and a cost in performance and cost size.
The problem comes is that people don't recognise that there are
trade-off's, they use a framework and expect to perform better than
writing their own highly specialised implementation. For example, if you
are writing an application on top of a database, using an abstracted ORM
layer will probably make it easier and faster to write the code, and
probably make it easier to maintain. It will also make it easier to
support different database back ends. However it is going to be slower
compared with hand optimised SQL for a specific target database. This is
a trade off a development team has to be aware of and analyse.
As always I am a fan of the best tool for the job.
Writing a JEE application server on top of a database writing in Java is
not the best thing to use for running the internals of a digital watch.
Equally using hand coded x86 assembler to write a huge complex piece of
business software which deals with complex inter-company interactions
and has a rich web based UI is not a good idea either.
There is "no one size fits all" approach to programming. The sooner
people realise that and pick appropriate solutions for the job, rather
than picking a solution because they like the sound of the buzz words
and bludgeoning it to fit, the better.
