

What do you believe about Programming Languages (that you can't prove (yet))? - zzkt
http://lambda-the-ultimate.org/node/1439

======
Hexstream
There's a quote in that thread that says something I've come to strongly
believe over time:

"Just to pick a single thing on the list, it takes at least as much time to
analyze what a system is doing under debug. In other words, after you write
the code, you spend at least as much time wondering what the system is
actually doing, even if the code is nearly all correct.

Starting about three years ago, I started telling folks you not only had to
write code that runs correctly, you also must provide some kind of support to
see whether code is running correctly. Even if there are no bugs, some
emergent effect at runtime will puzzle you, and a long time can be consumed by
tracing the cause and effect back to appropriate roots. When you work on a
team with several other folks, after the first agonizing bug shows up, you can
spend a lot of time proving your part of the system does exactly what
expected, and didn't play a role in the observed chaos.

Lately I seem to spend most of my time in forensic system analysis as a local
coroner for other folks' code fatalities. I never had an ambition to be a code
coroner.

It would be enormously helpful if a language -- and not just one particular
development environment -- had explicit support for generating evidence of
what and how a system actually got from one point to another."

~~~
eru
Pure functional programming should be a good start for such a system. At least
states are explicit (and usually relatively simple) there.

------
tezza
I cannot jump back into my 23 y/o mind but my 32 y/o mind firmly believes with
experience as proof ::

Simple solutions are Best.

XML is evil and should never have been released

Reading your _own_ old code is hard, for the _love of G-d_ please make it
simple

And so most controversially ::

\- Try to minimize the intricacy of any lamda-ultimate code you write. Y
Combinator[1] with closures is great now... 6 months you won't be able to
remember it.

\- If at all possible invoke lisp / functional heart within an easy to follow
procedural harness.

\------

[1] <http://en.wikipedia.org/wiki/Y_combinator> not PGs company of the same
name

~~~
jamesbritt
"XML is evil and should never have been released"

Wow. Most loathing of XML seems to come from the misuse of XML. For example,
defining application config files.

On the other hand, the number of robust parsers and relative ease of
understanding of at least essential XML (let's skip the parts tied to doctypes
for now) opened up a world of Web services.

Granted, BigCo and friends came along and tried to taser that with WS-* and
the like, but the cat was out of the bag.

Nowadays folks may refer json to xml, but that's just building on the ideas
kick-started by those devilish pointy brackets.

To stay on topic: What do I believe about programming languages, but cannot
prove: That simple, well-intended languages will inevitably be misapplied.
This misapplication will create headaches and heartbreak for people, and the
language will be blamed for these woes as if it was meant (and thus poorly
designed) for those uses along.

------
silentbicycle
Clear code is better than clever code.

------
torpor
That in terms of 'effort -> usefulness', they are all 'flat' - i.e. generally
equal in terms of usefulness and the effort required to attain some form of
use. There are no single words that are more powerful or more significant than
others - and all languages merely contain a collection of 'favoured words of a
flavour', which as a whole don't really represent a greater or lesser degree
of effort in regards to learning to use them. The thesis is this: All words
are equally difficult or hard to learn and use.

Thus the effort required to use Assembly is equal to the effort required to
use C or Python, with more or less equal boundaries in terms of the number of
words and terms you will learn for any particular language. You can take two
days to learn nothing but one language, and another two days to learn nothing
but another language; the degree to which the progress of both of these
periods is 'equal' is driven not by the words or language features themselves,
but instead by _your personal interest_.

The average assembly programmer has to construct a taxonomy as equal in terms
of effort as that of a Python programmer.

Now, bare with me here, because while I truly believe that 'all languages are
flat', it is also a 'truism' that "personal interest drives the peaks in the
effort curve".

That is to say, if you're not interested in Assembly, but you are interested
in Python, it is your interest - not language features - that will be what
drives the peaks and shallows in terms of the 'effort graph' in learning
either Python or Assembly. This is not a function of the _language_ , but
instead of personal interest. I don't believe there are, for example "stupid
people who can never learn Assembly and therefore must learn Python while
there are 'more intelligent' people who easily become more proficient in
Assembly" .. instead it is: "this person could learn either language, but
their personal interest inclines them towards one over the other".

All languages are equal. Not all interests are equal. The degree of interest
in a language drives its effectiveness in usage over that of another language.

~~~
asciilifeform
I'd like to see you rewrite the Mathematica code I write every week - in
assembler (on any architecture) in less than a year.

I believe you're missing the entire point of programming languages.

> All languages are equal

Only in the mathematical sense. In exactly the same sense that a pile of small
rocks ( _calculi_ \- where the word _calculation_ came from) is equivalent in
processing power to a Pentium.

~~~
gonk
I think the point is, if one were interested enough to do so, writing Assembly
language code that 'does better' than Mathematica on tricky maths problems
would - eventually - get as easy for one to do, as it is for you to use
Mathematica.

~~~
asciilifeform
I don't buy this for a minute.

No matter what your mental horsepower, a high-level language will allow you to
accomplish more with a given amount of effort.

You are essentially arguing that tools don't matter, that a steam shovel
ultimately offers no improvement over brute strength. Several millenia of
human history beg to differ.

~~~
torpor
Words are not steam shovels. Steam shovels require a _great_ deal of energy
and effort to use properly.

Words, on the other hand, require very, very little energy to be useful. That
is the point - the effort and energy required to learn what "(void
_)func(void_ );" is useful for is equivalent to the energy required to learn
what "jmp %ax" is useful for ..

You cannot compare word-working with hard working. Words are flat - they all
require a similar environment in order to function, namely that of a fertile
mind and the interest to watch them grow in the name of usage.

~~~
asciilifeform
I tried to think of something to say, but all that came out is: _Not even
wrong._

I _really_ wish that it were somehow possible to force you to walk the walk
and code only in assembler for the rest of your life. If all programming
languages are truly equivalent, just why would this fate be so terrible?

