5 ms·

Making one line of code do the work of 47

17 points by techdog 18y ago

michael_dorfman 18y ago
That's a classic paper, and well worth reading for those who haven't come across it before.
tptacek 18y ago
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 18y ago
  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.
- bayareaguy 18y ago
  building walls around the immaturity of specific interpreters That sounds like a good definition of scripting. At least that's what it always feels like to me when for one reason or another I have to implement more than I really want to in an environment lacking a set of abstractions or tools necessary for an elegent solution.
jwilliams 18y ago
"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).

17 points by techdog 18y ago

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

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 18y ago
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.
bayareaguy 18y ago
building walls around the immaturity of specific interpreters That sounds like a good definition of scripting. At least that's what it always feels like to me when for one reason or another I have to implement more than I really want to in an environment lacking a set of abstractions or tools necessary for an elegent solution.

jwilliams 18y ago

"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).