354 karma · joined September 26, 2008
What the author was saying about TCO was that, based on the fact that all our machines today use stacks, and not wanting to have programs that break(!), any implementations of lambda calculus on these machines must have TCO to allow as much of the lambda calculus as possible to be available in the programming language, lest you reject otherwise correct programs.
But make no mistake, Lisp[2] and functional programming languages ARE based on the lambda calculus. The article really did hit the nail on the head.
--
[1] "Lisp was originally created as a practical mathematical notation for computer programs, based on Alonzo Church's lambda calculus."
-- Wikipedia (http://en.wikipedia.org/wiki/Lisp_%28programming_language%29)
(and lots of other sources agree with this)
[2] Sorry to say it, but Lisp isn't the center of the Universe. It's a cool trick, but it isn't that great.
Edit: maybe its further away, but still worth thinking about.
With the added warning that your actions will have an effect on the voting and commenting behaviours of other hacker news readers in the long term, but this will mostly align well with the above affects.
Edit: I should add that most people upvote differently on Hacker News than they do on Reddit, because of the second effect whereby they might not necessarily think a comment is rude, but if it doesn't add anything to discussion they will downvote in the hope that the comments in the long run will be more helpful.
If you're trying to back up a friend, you're being way to obvious. This is definitely not overblown, taking credit for other people's work should be career changing and in the downwards direction.
*Edit: the change was really subtle too, go to 0:20 on the original
Here you go:
> I'd like to believe it's an accident, but it seems like if I demoed Google with the TED logo slapped on it and accidentally forgot to mention that someone else wrote the search engine.
> That's pretty unreadable for someone who doesn't know clojure.
The real reason for commenting was to show that it is readable and yes, providing the "readable" Python equivalent.
There are two points - firstly, Clojure is (or is becoming?) a lazy language and the list type is different, so no they are definitely not exactly the same.
This brings us to a broader point in that even if you were to have laziness in Python it still wouldn't matter because I'm not the only coder in the world and there are a lot of Pythonists like the author of the article who do it the Pythonic way, which as already hinted, I think is just braindead.
map(partial(reduce, +), partition(7, 7, daily))
Personally I'd be much much more happy to be using this code than the snippet in the article. In fact, I don't program Python regularly and it did take quite a while to figure out what was going on in the code.
weekly = [sum(daily[j:j+7]) for j in range(0, len(daily), 7)]
Now if you look back at the top snippet, its just normal function calls, so you can be happy to know what's going on after reading documentation for the names "partition" and "daily".
If you don't know what "map", "partial", "reduce" and "+" mean, sure you have to look up their documentation too, but they occur frequently enough that you can remember what they do after that.
The Clojure version is much more high level and less likely to introduce bugs.
Edit:
Oh and it should be said that "sum" is equivalent to partial(reduce, +) so I can now say:
map(sum, partition(7, 7, daily))
See? The code is just melting away before your eyes. Also note how I have literally no idea what either of the snippets do but am already happily changing one of them.
That's fine, but don't leave it as analysis done. twitvid.com is blatantly copying twitvid.io and that's wrong, end of story.
In the first point I was asking to be convinced that you can't have hygiene solely through the use of a package / module system and without needing multiple namespaces.
Although your workaround argument (for allowing variables to be shadowed) is convincing, in that case the package system wouldn't really be providing any safety at all and only the convention would be helping. I guess we can sum it up as CLers really don't see a problem at all, and Schemers require macros to be completely abstract.
Wands are a much better metaphor to make. Or perhaps, what if you had a magic brush that could at any time be extremely fine or large or anywhere in between depending on how you felt? That would be some brush, especially when you compare it to the many medium sized brushes which aren't so fine when you need them to be.
Okay, so maybe the metaphor is still stretching a bit, but these are no ordinary brushes; they are worth writing about.
(mac awhen (expr . body)
`(std.let it ,expr (std.if it (std.do ,@body))))
(define-macro (my-if a b c) `(std.if ,a ,b ,c))
(define (boo)
(let ((if list)) ; if is shadowed
(my-if 'x 'y 'z))) ; gives (std.if x y z)
(define (boo2)
(let ((std.if list)) ; error! cannot shadow module vars.
(my-if 'x 'y 'z)))
(ps. This ofcourse would not be limited to the languages std module but would also apply to any exported module symbols.)
Maybe its me, but I've found a lot more comments within the past fortnight or so grating on me than previously. Remarkably, every time I checked the submitter, they'd been on Hacker News for about a year and a half at least. And by grating I basically mean rude and unhelpful.
Edit: Seems that they are linking only to the site and not a pdf for RWH so it could well be legal :)
And to answer your post, I'd say that Clojure does give you what you need - it gives you the axioms, it gives you defmacro - the rest is history. All those other library functions you can think of in a more abstract sense ("George's problem"), and in the end these should be machine code no matter which HLL they were originally written in.
The Lisp way has always been very dynamic - you can change things, even when they're orbiting Mars, but Clojure is functional, you generally don't change things. So in that sense, Clojure is not a true Lisp, but only because it chooses a different set of trade-offs, and if you don't like that then its fine, but it doesn't make Clojure evil, just different.
I'm not doing any fancy compiler stuff - the target language is Haskell so that's all done for me.
*Edit: And I should probably say something about it :) Its an s-expression based language so it looks like a Lisp and you can use macros on it, it also reads by indentation if you want it to look like Python, and then the rest of it just comes from Haskell :)
Obviously I can't know it for sure, but my argument hinges on parallelism. Imperative programming isn't so well suited to parallelism as you probably know, and Python is sticking firmly to the imperative pseudo-code area of programming (which it does very well). Even for the scripting tasks I think in 10 years time it'll just be unacceptable to have so many cores under-utilised and functional languages make parallelism so much easier that it'll be a fairly easy choice to start coding a new project in those languages instead of Python. And then on top of this main argument, I'll just say you never know - I don't think people would have predicted the decline Perl has had to such a big degree (sure its not dead but its going that way). Python won't be here in 100 years (or 200, or 300..), I'm 100% sure. So I'm just arguing that the actual number of years left of Python is likely to be within 30 years. No-one knows the exact length, but my prediction is that its within that range.
> What makes Scheme and Haskell "long-term" languages?
They're just very simple and pure, and that's important for longevity because they aren't likely to be replaced in a kind of "major revision change" by a similar but better language, because they don't really need a big revision change, they're very good (or should I say "good enough") already. Python just doesn't so obviously provide the best language of its kind (dynamic, OOP, imperative) and is prone to be replaced by a different kind of language or a slightly different language of the same kind.
Both my answers are long enough that no doubt there'll be holes to pick in them. Eg. Should I have said "Scheme"? Well I don't think Scheme will ever make it big, but I do still think it'll be around in the long term to much the same degree it is now.
* By long term I meant at least 100 years for both Scheme and Haskell.
*Edit: That was a bit big, I'd like to correct it to "at least 30 years, and quite likely 100 years"
I'm not from the academic community and have never heard anyone else say it before, but have thought of Python this way for quite a while now and am pleasantly surprised to see I'm not alone.
Thats not me being snarky, its a very serious observation - you'd get laughed at for learning Basic today. I'm young and expect Python to die well before the end of my professional career, so I do invest my time in longer term languages such as Scheme and Haskell.