Links & Notes
From Too Much Code
- Part 1: Programming and the Metaphorical Mind
- Haskell is cool but its code isn't very readable (same with other functional languages)
- Part 2: 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."
- Part 3: 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
- Part 4: 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
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
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.
- 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
@20:00 Jeremy Siek
wants a language where one can arbitrarily extend language syntax. He claims libraries will sometimes introduce unintuitive ways to express simple ideas, like
for absolute value instead of
. Douglas Crockford
thinks that arbitrary syntax extension is bad. He notes that Forth
was designed specifically
to allow this and, while it has other issues, that doesn't work.
@23:20 Anders Hejlsberg
notes that the C# team did a "mind experiment" on this very topic when designing C# 3.0's LINQ functionality. Originally they just had fluent syntax (
), but people really wanted better syntax. In exploring general-purpose functionality for allowing such syntax additions, Anders notes that the semantics requirements of LINQ would prevent type-checkable hygenic macros from working. MS would have to open up the compilation process, expose the ASTs, allow people to plug in code anywhere — allowing them to do just about anything. Except
, evolving the language would be impossible, because the compilation process would be so exposed an intertwined with user extensions that evolving the language would break many language extensions. It is an unsolved problem.
@26:00 Gilad Bracha
notes that mainstream notation has a lot of noise that gets in the way of DSLs that are "a little different".
@42:50 Tools like Powerpoint and Word allow for manipulation of structured object, but programming languages (except for SmallTalk) involve manipulating strings. Anders thinks that strings are just the best option (based on history). Gilad mentions that all sorts of tools (diffing, source control) are good at dealing with text.
fundamental abilities (that can be elegantly expressed)
- functional programming
- state machines
- transactions (perhaps transactional memory)
- extensible query language, like LINQ
- this would support list comprehensions