J
Vladimir E. Zyubin:
> >> A programming language changing the way of thinking the problem
> >> demands is not worth learning.
The original is "A language that doesn't affect the way you think about programming, is not worth knowing", and it was Alan J. Perlis that said it.
Dan L. Pierson:
> > Ah, but "the way of thinking the problem demands" may not be obvious.
> > "If all you have is a hammer, all problems tend to look like nails."
Vladimir Zyubin:
> 1. Yes. The way may not be obvious. And one of the first steps of the
> development process ought to be to define the right way...
For that to be possible, though, you have to be familiar with a variety of ways.
> 2. ... it allows the developers to realize: they have to change the
> hammer for screwdriver...
Alas! one can only do that if one is familiar with both. For otherwise you will not know of screwdrivers, and even if you do use one, you will hold it by the wrong end to pound the screw in.
> > Learning languages that force you to change how you look at problems
> > gives you more options in the future no matter what problem/tool set
> > you're faced with.
> There are _thousands_ programming languages... most of them demands a
> specific way of thinking...
Actually, not really - there are thousands of programming languages, but only a few paradigms. A well-chosen half a dozen to a dozen languages
should give you a fairly broad view.
- structured imperative (C / Pascal / etc)
- imperative - assembly language (short program only)
- imperative - stack-based (Forth)
- object-oriented (not sure what to recommend here)
- functional (Haskell)
- logic (Mercury)
A working knowledge of database theory (incl. SQL) is good, because then you'll know when to stop inventing baroque data structures and just dump it all into PostgreSQL. Similarly for crypto, security, reliability etc.
Round it out with a passing familiarity with the widespread languages (C, FORTRAN, COBOL, C++, LISP, Prolog).
Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
> >> A programming language changing the way of thinking the problem
> >> demands is not worth learning.
The original is "A language that doesn't affect the way you think about programming, is not worth knowing", and it was Alan J. Perlis that said it.
Dan L. Pierson:
> > Ah, but "the way of thinking the problem demands" may not be obvious.
> > "If all you have is a hammer, all problems tend to look like nails."
Vladimir Zyubin:
> 1. Yes. The way may not be obvious. And one of the first steps of the
> development process ought to be to define the right way...
For that to be possible, though, you have to be familiar with a variety of ways.
> 2. ... it allows the developers to realize: they have to change the
> hammer for screwdriver...
Alas! one can only do that if one is familiar with both. For otherwise you will not know of screwdrivers, and even if you do use one, you will hold it by the wrong end to pound the screw in.
> > Learning languages that force you to change how you look at problems
> > gives you more options in the future no matter what problem/tool set
> > you're faced with.
> There are _thousands_ programming languages... most of them demands a
> specific way of thinking...
Actually, not really - there are thousands of programming languages, but only a few paradigms. A well-chosen half a dozen to a dozen languages
should give you a fairly broad view.
- structured imperative (C / Pascal / etc)
- imperative - assembly language (short program only)
- imperative - stack-based (Forth)
- object-oriented (not sure what to recommend here)
- functional (Haskell)
- logic (Mercury)
A working knowledge of database theory (incl. SQL) is good, because then you'll know when to stop inventing baroque data structures and just dump it all into PostgreSQL. Similarly for crypto, security, reliability etc.
Round it out with a passing familiarity with the widespread languages (C, FORTRAN, COBOL, C++, LISP, Prolog).
Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
