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.
I think I've read those essays, but the fact I can't remember explicitly doing so indicates that, frankly, they didn't do too well in terms of convincing me .. my position is based on 30 years of working day and night as a professional programmer, so maybe I'm quite biased, but it is an opinion I have formed and used successfully in training others in my team to get stuff done. It doesn't matter what language you use; what matters is that you are interested in using it to get the job done. If a language contains features that don't interest you, it won't be useful: period. Ultimately, all language features must be judged by the level of interest they incur, and how that interest is applied towards making something useful with the language.
That said, I'm perfectly aware of how wrong my argument can be, but like I said .. works so far ..
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.
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.
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.
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.
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.
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?
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.
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.
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."
14 comments
[ 3.2 ms ] story [ 22.2 ms ] threadThus 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.
That said, I'm perfectly aware of how wrong my argument can be, but like I said .. works so far ..
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.
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.
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.
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.
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?
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
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.
"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."