Thoughts on Programming Languages

Luke Breuer
2010-01-07 07:42 UTC

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 (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
    • named parameters
  • minimal boiler-plate code
  • from Too Much Code: has physical metaphors
  • there must be a plethora of examples written well
  • functional components
    • first class functions
  • 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
The Future of Programming Languages (PDC 2008)
@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 |x| for absolute value instead of abs(x). 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 (.Where(...).Select(...)), 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)
  • tuples
  • code-as-data
  • extensible query language, like LINQ
    • this would support list comprehensions