Depending on the task. I'd divide programming tasks into four general categories.On 21/05/14 15:37, Stefan Ram wrote:
It often makes sense to think in terms of programming paradigms rather
than programming languages. The way you design an algorithm in C and in
Haskell is likely to be significantly different, but the algorithm in C
and Pascal is likely to be very similar (both are imperative languages)
while the algorithm in Haskell and OCaml will be similar (both are
functional programming languages). In each case, however, the
beginnings of the design are the same - you start with pencil and paper,
or a whiteboard, with a combination of maths, natural language and lines
and arrows rather than any programming language.
1) trivial bit shuffling functions. Functions like strlen(), or even like sprint(), which
any programmer ought to be able to write if he puts in enough effort.
2) Non-trivial bit shuffling functions. E.g. an attack on the travelling salesman problem,
which you could approach in several ways, and it's not obvious which will be best.
3) low-level IO functions. These are often difficult to write, but it's a different type of
difficulty. The challenge is in understanding how the hardware is reacting and
synchronising with it in the right way.
4) Glue code. This is often called "business logic". The rules are complex and have to
be right, but there's no fundamental algorithmic complexity in them. it's case of
having an appropriate library of the other functions, and calling them at the right time.
The type of design you need varies depending on the task.