Re: Thoughts on Design


"Chris Burrows" <cfbsoftware@xxxxxxxxxxx> wrote in message
news:45a2fb68@xxxxxxxxxxxxxxxxxxxxxxxxx
"Dennis Landi" <nada@xxxxxxxx> wrote in message
news:45a2eeae$1@xxxxxxxxxxxxxxxxxxxxxxxxx

And... Some things, many things in fact, are complex by nature. In many
ways that is what we, software engineers, navigate. Complexity. Our
tools should help us, and they need not be (should not be) more complex
than absolutely necessary.


I agree 100%. Coincidentally I also did some holiday reading - a classic
paper which also stressed the importance of simplicity, especially where
the design of programming languages is concerned.

"Hints on Programming Language Design" by C.A.R. Hoare. This was written
in 1973 and still makes a lot of good sense today. Unfortunately many
language designers did not follow its principles.

"A programmer who fully understands his language can tackle more complex
tasks, and complete them quicker and
more satisfactorily than if he did not. In fact, a programmer's need for
an understanding of his language is so great, that it is almost impossible
to persuade him to change to a new one. No matter what the deficiencies of
his current language, he has learned to live with them; he has learned how
to mitigate their effects by discipline and documentation, and even to
take advantage of them in ways which would be impossible in a new and
cleaner language which avoided the deficiency. It therefore seems
especially necessary in the design of a new programming language, intended
to attract progrmers away from their current high level language, to
pursue the goal of simplicity to an
extreme, so that a programmer can readily learn and remember all its
features, can select the best facility for each of his purposes, can fully
understand the effects and consequences of each decision, and can then
concentrate the major part of his intellectual effort to understanding his
problem and his programs rather than his tool."

http://www.eecs.umich.edu/~bchandra/courses/papers/Hoare_Hints.pdf


Given the era that was written that's remarkable. Somehow I feel we,
humans, always see our universe with more or less than same level of
granularity, while the relative scale of the objects and symbols that
comprise our perception increase over time. In this regard, the complexity
we navigate as software engineers is fractal in nature.

-d


.

Relevant Pages

  • Re: object system...
    ... for that you need machine language. ... isn't even as fast as other systems programming languages. ... Stroustrup's stated design goal was to enable ... all manner of elegance or abstraction can be sacrificed for speed, ...
    (comp.object)
  • Re: DirectX in HLA
    ... I guess that you have a great knowledge of DirectX ... > understanding by looking at them in assembly language... ... > actually represents, really, is a means to "undo" the OOP so ... > is NOT an "OOPL" (object-orientated programming language), ...
    (comp.lang.asm.x86)
  • Re: DirectX in HLA
    ... I guess that you have a great knowledge of DirectX ... > understanding by looking at them in assembly language... ... > actually represents, really, is a means to "undo" the OOP so ... > is NOT an "OOPL" (object-orientated programming language), ...
    (alt.lang.asm)
  • Re: LSP and subtype
    ... What is the class of problems solvable using UML? ... the language of physics cannot describe. ... whatever paradigm equivalent to 2GL/3GL ... there is still a great need for reuse and generic programming. ...
    (comp.object)
  • Re: Why C Is Not My Favourite Programming Language
    ... If you decide afterall that C programming is just not your thing you ... > C has no string type. ... > compiler take care of the rest. ... Why does any normal language ...
    (comp.lang.c)