

Making one line of code do the work of 47 - techdog
http://asserttrue.blogspot.com/2009/03/making-one-line-of-code-do-work-of-47.html

======
tptacek
I've never liked this paper.

First, I quibble that the metrics are off: the "code ratio" ignores intrinsic
factors that alter the numbers, such as the overhead in a "scripting" language
for driving the interpreter and managing its resources.

Second, and more importantly, it posits that the role of a scripting language
is to automate and glue together systems code. History hasn't borne that
argument out. You can assert that every Python or Ruby extension is an example
of systems code offered by the interpreter for glueing, but architecturally I
can make the same claim about every kernel interface, device driver, and
chipset feature. The fact is that in 2009 high-level languages are the
principal programming environment; lots of apps get built without even
considering a "systems programming" environment.

Finally, what makes Osterhout's argument even more incoherent is the fact that
there's no real line of division between systems programming languages and
scripting languages. Feature for feature, Common Lisp and Python are both
"scripting" languages in Osterhout's definition. But Common Lisp is a fine
systems programming language (people build operating systems in it). He really
just seems to be building walls around the immaturity of specific interpreters
--- Tcl, in particular, which has always had one of the most primitive
execution environments.

There's no such thing as a "scripting language". They're all just programming
languages.

~~~
Zak
The C-based way of handling things has been, for some time to write a low-
level core in C and glue things together with a "scripting" language that's
written in C and provides good C interoperability.

The Lisp way, which seems to be getting more popular (e.g. PyPy, Clojure) is
to be high-level by default, but allow type annotations, unchecked math and
such low-level things to optimize code where the profiler tells you there are
problems. I think this way is objectively better, if only because the profiler
has more information at runtime than the programmer does while coding.

------
jwilliams
"47 lines into 1" invokes for me the idea of very specialised scripting
languages, that have been tooled for a specific task. You can do "start http
server", but can't parse a cookie for yourself.

Nothing wrong with this for sure - But, what I think is the holy grail is
taking 47 lines into _3_ \- with a language has the capability to let you do
that again, and again - (i.e. exponentially increasing the semantic power of
the language).

------
michael_dorfman
That's a classic paper, and well worth reading for those who haven't come
across it before.

