The best qualities of high- and low-level languages

Jr-Captain Posts : 18 Join date : 2009-06-30 Age : 36

Writing good software is hard. I have spent more time being stumped by
writing software than by anything else I've done. Of course, some
parts are harder than others, and no programmer can think all day
about the hard problems, so it's natural to end up puttering around
with some easy parts while waiting for inspiration on the hard parts.

Some programs have natural easy parts. User interface or web-based
programs can absorb an infinite amount of tinkering with layout,
fonts, colors, etc. However, UI layout isn't very intellectually
stimulating. Programmers like having tractable, programming-type
problems with actual practical benefits to work on when they're out of
big ideas, and I think that this need is one of the reasons for
success of low-level languages like C++ over more powerful and
abstract languages like Ocaml, Lisp, Perl, or Python.

A well-written program in an abstract language like Ocaml or Lisp has
the quality of an elegant mathematical proof: beautiful and concise,
but you can't change anything without breaking it. Most programs in
C++ are more like an elaborate model train layout, supporting endless
tinkering without actually stopping the train from going 'round.

Thomas Edison said that genius is 1% inspiration and 99% perspiration.
A corollary is that inspiration rarely comes more than a few percent
of the time anyway. If you were inventing mechanical or electrical
things like Edison you'd inevitably spend a lot of your time building
prototypes or doing other satisfying "perspiration" work. Writing
software in a sufficiently high level languages removes so much of the
perspiration that you find inspiration to be the limiting reagent, and
this is painful.

C++ provides almost limitless opportunity for easy tinkering, for
example: organizing class interfaces into public, private, and
protected sections with friend class relationships; moving code
between corresponding .cc and .h files to get more or less inlining;
tweaking Makefiles and header dependencies for fast compilation;
searching for memory leaks, and a hundred others. None of these are
really necessary to get the program written, but they keep one's
fingers and part of one's brain busy while mulling over the hard
problems. They are a kind of mental puzzle or strategy game you play
against the compiler.

On one hand, needing something to tinker with seems like a poor reason
to use a clumsy low-level language. Get a Rubik's cube! Invent
anagrams! Read a book! If programming is what you like best, have a
separate program in a low-level language (assembler, if need be) to
absorb your futzing, and write the real program in a high-level
language.

On the other hand, tinkering with the software may be the best thing
to do while waiting for inspiration. If you're a serious hacker, you'd
rather be programming than playing games or reading. You could work on
another program, but you'll run into hard parts there and brain cells
will be taken away from solving the real problem. Tinkering with the
code has the virtue of keeping the software present in your mind.
Scanning through dusty parts of the code may uncover a latent bug, or
provide inspiration relevant to the hard problem. You might do some
useful optimization.

The ideal language would let you write functionality quickly and
concisely like a high-level language, but let you tinker and optimize
to your heart's content. To support these two goals, it needs to read
two separate sets of source code: a high-level part and an optional
low-level part that guides compiler optimizations. Some languages
support optional declarations already. For example, Common Lisp lets
you declare that a variable will be of a certain type so the compiler
can optimize for that case. However, Lisp's declarations go in the
main body of the code, bloating it with irrelevant chatter and making
it harder to change.

Writing declarations must be low-risk, challenging without being too
difficult, and useful. To make aggressive large-scale optimizations,
compilers must be able to prove things about the code such as that
function arguments are of particular types. This is very hard in
general, but the declarations would serve as the outline of a proof
that the compiler only needs to verify. Working on them would force
constant thinking about data flows through the code, and would
probably help find bugs and be a good source of inspiration. Because
the declarations outline a proof that the compiler must verify, it
will be impossible to break the code by adding wrong declarations. And
if you change the high-level code in a way which invalidates some
declarations, the system will continue to work, but you'll have a
large list of compiler diagnostics to sort through and resolve next
time you're stumped.

Separating the two parts is the key to combining the good qualities of
high- and low-level languages. The high-level part to be clean,
concise, and easily changed. The low-level part can absorb plenty of
perspiration and can help make the code run very fast.

I'm thinking about actually writing such a language, but I haven't
gotten far yet.

google_protectAndRun("ads_core.google_render_ad", google_handleError, google_render_ad);

Kudos for such interesting piece of knowledge for someone i know, im not surprise... Really! Such expectations,... like the part that we can configure the code on how the low and high level, compiler and interpreter should deepen the interest of writing codes. But nevertless, on top of that, each programmer has its own interest on how he or she interprets the programming in both program, Like what you emphasize.... there should be a foundation in understanding in low level before proceeding to high-level, we must have more concern on building it with scratch, concentrate more on the feeling of perspiration rather than easy construction. There is no such easy or novice nor expert in such codes when it comes on writing them, in fact it starts with the simple basic concepts of pressure and critical thinking. In my view that is the best way on dealing with the number of codes.
For most programmer, wants to employ the full potential of a hybrid language, like C++, in which it contains both procedural and object oriented features, requires a gradual refinement in programming skills from a procedural to an object orientation with step.

» High and Low Context