91–100 of 143 posts
Some of the conclusions are inconsistent. For example, Ruby got canned mainly for having a heavyweight framework, since he wants to write everything from scratch. What keeps one from doing that in Ruby? Ruby does not depend on Rails. His complaint about different versions and implementations is a red herring. Lisp is not immune from this.
There are different implementations, of course. But the the multiple version problem was worked out over a decade ago.
Earlier quoted context omitted.
I'm not disagreeing, but to be fair, "common lisp" is often referred to as "lisp" or "CL". So the phrase is good for (down)trends, but not for comparisons.
True, I should have shortened it to just lisp. Here we go: http://www.google.com/trends?q=perl%2C+python%2C+ruby%2C+lis... Yep, still noise.
Jeff Ruby asks OJ to leave business
Ruby on Rails 2.0 Released
JFK Documents Include Reported Ruby, Oswald Conversation
23-foot python found basking in sun
Former Olympic champion Ruby dies in climbing fall
Monty Python reunite
Only one of those is related to programming.
That's what the nonlocal keyword is for.
Earlier quoted context omitted.
I am not the OP, but I have a problem with Rails and alternatives: there does not seem to be a viable alternative to ActiveRecord around? I looked into DataMapper (I think that was it's name) which initially looked great. But then I could not find any information on how to use transactions, and also received no answers on the newsgroup. I guess I should have read the source, but I gave up at that point. Since I hate…
ActiveRecord is a small part of Rails. Lots of people use Rails without using ActiveRecord. See http://whitepages.com for an example.
"The completely broken implementation of closures." That's what the nonlocal keyword is for.
I just switched to Lua during the Python 2 to 3 transition, and I haven't looked back. Real closures and tail calls, no GIL, a vastly more tasteful design, a dead-simple C API, and the whole shebang is a tenth the size of Python.
Earlier quoted context omitted.
I have a longer comment here that argues the opposite: list-comprehensions are only a syntactic pun or two away from set-builder notation, which is a higher level-of-abstraction (it declaratively states what it is) than map+filter (which specify a procedure to generate it, albeit at higher level of abstraction than a for-loop). If you can put together a nontrivial usage of map+filter with at least three source collec…
Using do-notation is probably cheating, but what do you think of this? (in Haskell): do { w We're trading horizontal space for vertical space. I think it's much clearer than either list comprehensions or plain map/filters. It's the best of both worlds.
If eg I edited it to be:
do { l Earlier quoted context omitted.
ActiveRecord is a small part of Rails. Lots of people use Rails without using ActiveRecord. See http://whitepages.com for an example.
I know, but how much is left of Rails without ActiveRecord? I think validations and forms depend on it.
Forms and validations don't depend on ActiveRecord at all in edge rails.
The fact that he proposed removing map, reduce, filter, and lambda from Python 3. In the case of map and filter, is there any compelling reason to use either of those instead of list comprehensions or generator expressions?
I like lambda because it allows anonymous functions-- functions that can be defined on the fly (dynamically) and then thrown away. IMO, it's generally bad form for a program to be dynamically creating named functions, filling the namespace. Also, I like map and filter because they aren't just functions in the procedural sense but combinators: you can pass them around, using them as arguments and returning them. It's…
That's what inner functions are for. This isn't the best example, but you get the idea:
def foo(mylist):
def n_to_the_n(n):
if n > 1:
return n**n
return 1
return [n_to_the_n(i) for i in mylist]Did you really choose Lisp over alternatives? Before learning CL I was a fairly decent, C, C++ and Perl programmer. Did assembly, Pascal, TCL and Awk. Up to that point, I always had to pause a for a minute when starting a new project/script, think about its scope, and choose a language based on the necessary performance, development speed, expressiveness, available libraries, etc. (and whether whoever was going to re…
Come on, man. If you're doing something worthwhile, it likely takes 2-3 months (if you're lucky) to just understand the problem. Common Lisp is an amazing language and development environment, but it won't help you actually solve the problem any faster, only to implement the solution. No silver bullets and all. I love Common Lisp, but the whole "code this in a weekend" thing has got to stop. Good software takes a dam…
As a recent example, I find Clojure's REPL to be invaluable when wrapping my head around Java libraries. The features of a Lisp make sketching and exploring easier, and that's part of understanding the problem.
I forget the exact quote, but it's something like "I never learned to see properly until I tried to draw". Pertinent.
Earlier quoted context omitted.
> Python's list comprehension is much more readable than using map/filter/reduce - at least for Python programmers For simple cases, yes. But I wouldn't say [each for each in [expensive_call(x) for x in seq] if cond(each)] is more readable than filter(cond, map(expensive_call, seq)) at least for functional-thinking minds. The level of thinking in abstract is different here. Now the problem is, some people see Python…
At first, I thought "wow, Python generator expressions are really ugly nested". This is especially true after working with C#3/Linq because query expressions have natural places for line breaks and read in a more consistent order. Later, I ran into some cases where I wanted a multi-line lambda. And my thought was "aaragh134!#?!" Then, a weird thing happened. I started making a conscious effort to follow PEP 8. 79 col…