Re:Lisp after Python after Lisp
by danprager on Wednesday March 11, 2009 @05:48PM
(#512685)
Learning Scheme helped my Python by teaching me some new (to me) idioms, besides the first-class function stuff.
For example, it is natural in Scheme to declare a lot of local information, including local function definitions. These have the great advantage of knowing about variables within the local environment. So rather than declaring an external function with heaps of parameters to pass in local state, you just declare a local function which automatically gets access to the variables in the surrounding scope.
The same idiom works neatly in Python too, but didn't occur to me previously.
* * *
Also after learning Python and Scheme, Ruby felt a bit like a cross between the two, and quite comfortable.
Re:Lisp after Python after Lisp
by smanek on Thursday March 12, 2009 @06:10AM
(#513249)
Pretty much. The trick is that since scheme is a lisp-1 there is no need for a different special operator to signify you're declaring a local function instead of a local variable (a la the flet/let dichotomy).
Re:Lisp after Python after Lisp
by danprager on Thursday March 12, 2009 @05:22PM
(#514121)
Yes, in that case the inner function has access to the arguments of the outer function. But you can go deeper -- e.g. declaring an inner function inside code inside the out er function -- which also knows about the local variables in the outer function.
Or if you're only doing it once use a lambda (with the same advantages).
Re:Lisp after Python after Lisp
by danprager on Friday March 13, 2009 @01:13AM
(#514536)
Yes, these idioms would work in Javascript too.
I guess the point is that people are starting to discover that languages like Python and JS support these functional idioms quite nicely.
Remember when all the books on JS pretended that it was some kind of crippled cousin of Java (as the name suggests), rather than a Scheme-lite in Java-esque syntax (as its designer has opined).
Re:Lisp after Python after Lisp
by jamongkad on Friday March 13, 2009 @02:23AM
(#514583)
Haha yes, I do remember those times. Now that you've mentioned it another language that fits the description of a Scheme-lite in Java-esque syntax is Lua.
Re:Lisp after Python after Lisp
by jimbokun on Wednesday March 11, 2009 @04:35PM
(#512560)
"I don't know if there are programmers out there whose pseudo-language is functional. Maybe it's just human nature to think imperatively."
A lot of time it just kills me that "if" statements don't default to returning the true branch or false branch. You need the ternary conditional operator in Java and other C-derivatives, and in Python you need to resort to some hack with and/or precedence.
I'm also wondering if I should declare all variables final in Java, and only change that default if I really, really have to.
Re:Lisp after Python after Lisp
by bk on Wednesday March 11, 2009 @05:20PM
(#512645)
I guess that's why Ruby has been called an "acceptable lisp". I take "everything is an expression" so for granted by now, and it makes for beautiful, terse code.
The non-working python if statement/assignment example from the article works perfectly fine in Ruby. (No python/ruby flamewar please, that's really not the point)
Re:Lisp after Python after Lisp
by arohner on Wednesday March 11, 2009 @05:50PM
(#512689)
How about a ruby/lisp flamewar? :-) J/K.
In all seriousness though, I've recently moved to Clojure from Ruby. I'm not looking back. Clojure is significantly cleaner, faster, and has better libraries than Ruby.
Re:Lisp after Python after Lisp
by EliAndrewC on Wednesday March 11, 2009 @05:26PM
(#512653)
Actually I think the more common hack was
a = cond and x or y
which had the downside that if the second part (in this case x) evaluates to False then a ends up equal to y even through that's not what you were trying to do. Sometimes this is a problem and sometimes not, but it's been irrelevant for the past few years.
Re:Lisp after Python after Lisp
by jcausey on Wednesday March 11, 2009 @05:46PM
(#512682)
Very true. I've seen that hack before, but I guess I mentally settled on my first example (probably due to the irksome possibility of x=0\False).
Unfortunately, there were probably more hacks than our two examples. Thank goodness Guido (etc) settled on a real ternary semantic -- we were heading into Perl more-than-9000-ways-to-do-something territory!
For example, it is natural in Scheme to declare a lot of local information, including local function definitions. These have the great advantage of knowing about variables within the local environment. So rather than declaring an external function with heaps of parameters to pass in local state, you just declare a local function which automatically gets access to the variables in the surrounding scope.
The same idiom works neatly in Python too, but didn't occur to me previously.
* * *
Also after learning Python and Scheme, Ruby felt a bit like a cross between the two, and quite comfortable.
e.g.:
Or if you're only doing it once use a lambda (with the same advantages).
I guess the point is that people are starting to discover that languages like Python and JS support these functional idioms quite nicely.
Remember when all the books on JS pretended that it was some kind of crippled cousin of Java (as the name suggests), rather than a Scheme-lite in Java-esque syntax (as its designer has opined).
A lot of time it just kills me that "if" statements don't default to returning the true branch or false branch. You need the ternary conditional operator in Java and other C-derivatives, and in Python you need to resort to some hack with and/or precedence.
I'm also wondering if I should declare all variables final in Java, and only change that default if I really, really have to.
The non-working python if statement/assignment example from the article works perfectly fine in Ruby. (No python/ruby flamewar please, that's really not the point)
In all seriousness though, I've recently moved to Clojure from Ruby. I'm not looking back. Clojure is significantly cleaner, faster, and has better libraries than Ruby.
(x if cond else y) which is essentially (cond ? x : y)
a = ("False", "True")[condition]
It's a little fugly -- but if you know the basic semantics of Python, it's quite readable. It is nice that we have a proper ternary now, though.
Unfortunately, there were probably more hacks than our two examples. Thank goodness Guido (etc) settled on a real ternary semantic -- we were heading into Perl more-than-9000-ways-to-do-something territory!