Hacker News new | ask | show | jobs
by kvb 4636 days ago
See Felleisen's "On the Expressive Power of Programming Languages"[1] for one formalization that differs from conciseness. Essentially, Turing complete languages can express the same programs at the very coarse "whole program" level, but the paper advocates taking a more local view to assess expressiveness (e.g. what programs in L1 can you write in L2 without having to do a whole program transformation). See also Neal Gafter's related commentary[2] (in the context of the various proposals for closures in Java).

[1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.51.4...

[2] http://gafter.blogspot.com/2007/03/on-expressive-power-of-pr...

1 comments

One doesn't have to look far before he finds a fatal flaw in the commentary. Particularly this:

"In my mind, a language construct is expressive if it enables you to write (and use) an API that can't be written (and used) without the construct." - Neil Gafter

Once more, there is no such construct. All APIs can be written and consumed without language support. Otherwise, Boost would not have had all the new C++ goodies (as an add-on library) before they became part of the language itself. And, of course, one can always put the 'human compiler' to work to produce boilerplate that would be produced by the compiler if the language in question supported the feature in question (if there isn't an add-on library providing the feature in question). One can always do this but the discriminating one tries to avoid it and instead chooses 'expressive' (i.e., conciseness-facilitating) languages. [In the case of closures in Java, one [human-compiler] would merely use one-off interfaces or anonymous classes].

I will take a look at the other links but I gave up on the commentary after seeing such a blatant falsehood.

C++ has features like operator overloading that make faking lambdas via Boost feasible. And even Java has anonymous inner classes that allow a rather ugly local transformation somewhat akin to closures. But if you removed that feature, then you'd need a non-local transformation to fake them.
You apparently didn't read all of my comment as I mentioned Java's anonymous inner classes being used to fake lambdas near the end. And, the point remains, given any TC language L, all possible language features for all possible languages are implementable within L itself. It doesn't matter if L has operator overloading or not; only that it be TC.