Links & Notes
//toomuchcode.blogspot.com/:Too Much Code]]:
- Programming and the Metaphorical Mind
- Haskell is cool but its code isn't very readable (same with other functional languages)
- Languages and the Lesser-Skilled Developer
- Bjarne Stroustrup quotation
- politics is a big decision maker in language choice
The problem is highly skilled developers are often forced to use the languages accessible to their less competent colleagues.
A language should encourage good code — but make quick and dirty code possible.
- on Ruby and Python: "Inexperienced developers can quickly get code working, and more advanced developers have access to powerful features drawn from the functional world."
- Building a Firewall Against Complexity
- it's nice to have abstractions, but we must deal with the leaky abstractions
Every variable added must be tracked with every other variable.
- We must either stop building complex software or "build airtight firewalls around complexity."
- Haskell builds a firewall with its functions-without-side-effects.
local impurity, but global purity
Can we live without state?
- Erlang's messaging-based model
- The Killer App
- We want to eliminate undefined behavior, such as that cause by race conditions. The problem is when such code succeeds, hiding the failure mode.
Steve Yeggie on
The Next Big Language (Javascript)
Paul Graham on
The Hundred Year Language
From
Bjarne Stroustrup:
The idea of programming as a semiskilled task, practiced by people with a few months' training, is dangeous. We wouldn't tolerate plumbers or accountants that poorly educrated. We don't have as an aim that architecture (of buildings) and engineering (of bridges and trains) should become more accessible to people with progressively less training. Indeed, one serious problem is that currently, too many software developers are undereducated and undertrained.
From
Philip Wadler (emphasis added):
Instead, experience shows that users will be drawn to a language if it lets them conveniently do something that otherwise is difficult to achieve. Like other new technologies, functional languages must seek their killer app.
In talking about the
Y combinator, Reginald Braithwaite makes a very insightful comment:
Others have suggested that learning Lisp is beneficial to your programming skills in its own right. That’s one good way to sharpen your saw. But I add to that an important caveat: to obtain the deepest benefit from learning a new language, you must learn to think in the new language, not just learn to translate your favourite programming language syntax and idioms into it.
At least, this drove my thoughts into
Sapir-Whorf territory. In response to:
figure out what you want to say before you figure out how to say it
I had the following thought:
To reconnect the "what" with the "how", I would say that if the two are separated by too many layers of abstraction, the "what" must be reformulated at a lower level of abstraction before the "how" becomes clear.
Key features
- code is easy to read
- Is this reasonable? Haskell isn't easy to read, at least for beginners.
- it must be usable by mediocre developers
- this is required for it to become widespread, which is required for most developers to be able to use it in their day jobs
- object literal notation, à la JSON
- minimal boiler-plate code
- from Too Much Code: has physical metaphors
- there must be a plethora of examples written well
- functional components
- complexity must be managed well
- namespaces are probably required
- how to keep the state-space manageable?
- there must be excellent library support with standard interfaces
- differences in memory management in C and differences in state management in Haskell are obstacles to this
- the .NET and Java platforms offer many libraries if one of their byte codes is used