Law of headlines applies to the headline giving me a command too, I've noticed.
Stop writing lambda expressions in Python
31–40 of 202 posts
Re: Stop writing lambda expressions in Python
#32all i could think of is "stop writing python". it seems to me that a lot of these problems are fundamental problems with python. i continue to not understand why anybody likes python the language. the fact that creating a function with lambda versus the normal way is different is bonkers. for example, in f# (and other sane languages), the following are identical: let test1 = fun x -> x * x let test2 x = x * x both re…
I'm not sure what you mean by the first half of your comment. Both def and lambda create functions, and quoting from the article "Lambda expressions are just a special syntax for making functions. They can only have one statement in them and they return the result of that statement automatically.".
def binds it to a name at the same time, which is remembered in the object (which AFAIK isn't really used for anything except maybe debugging tools), lambda returns an anonymous one. The resulting object can be passed around in both cases.
Re: Stop writing lambda expressions in Python
#33I'm sorry but this article is mostly not Scottish. Lambdas in Python are an old non-issue. They are what they are.
I like 'em because you can do "stupid python tricks" like Church numerals: https://en.wikipedia.org/wiki/Church_encoding
plus = lambda m: lambda n : lambda f: lambda x: m(f)(n(f)(x))
succ = lambda n: lambda f: lambda x: f(n(f)(x))
mult = lambda m: lambda n: lambda f: m(n(f))
exp = lambda m: lambda n: n(m)
c0 = lambda f: lambda x: x
c1 = lambda f: lambda x: f(x)
c2 = lambda f: lambda x: f(f(x))
c3 = lambda f: lambda x: f(f(f(x)))
c4 = plus(c1)(c3)
c5 = plus(c2)(c3)
c6 = plus(c1)(c5)
c7 = succ(c6)
c8 = succ(c7)
c9 = c3(succ)(c6)
c10 = mult(c2)(c5)
c11 = succ(c10)
c12 = mult(c3)(c4)
c64 = c3(c4)
c256 = exp(c2)(c8)Re: Stop writing lambda expressions in Python
#34all i could think of is "stop writing python". it seems to me that a lot of these problems are fundamental problems with python. i continue to not understand why anybody likes python the language. the fact that creating a function with lambda versus the normal way is different is bonkers. for example, in f# (and other sane languages), the following are identical: let test1 = fun x -> x * x let test2 x = x * x both re…
> i continue to not understand why anybody likes python the language Here are some reasons why I like it: It's cleaner to read because there aren't curly braces and semicolons cluttering up the code. It's cleaner to write because the expressions are simpler and look like something readable instead of line noise. It has a REPL, so it's easy to experiment. It doesn't force me to write boilerplate code, such as types fo…
f# (and also ocaml and sml) have all those and much more. they are much more consistent and principled in their design, which makes things simpler to understand.
for example, in all three languages above, expressions are much easier to understand because they always return a value. this makes code easier to reason about. this is not true in python.
the languages i mentioned do have static typing but they have type inference. so you get the best of both worlds. you do need to type annotate at some points to clarify things, but this isn't a problem as it documents to both the user and compiler.
given your above reasons, you owe it to yourself to learn an ml. there is the programming languages course on coursera by dan grossman, which uses sml in the first part, and the ocaml mooc just started where you still have time to register and complete it.
https://www.coursera.org/learn/programming-languages
https://www.fun-mooc.fr/courses/course-v1:parisdiderot+56002...
Re: Stop writing lambda expressions in Python
#35all i could think of is "stop writing python". it seems to me that a lot of these problems are fundamental problems with python. i continue to not understand why anybody likes python the language. the fact that creating a function with lambda versus the normal way is different is bonkers. for example, in f# (and other sane languages), the following are identical: let test1 = fun x -> x * x let test2 x = x * x both re…
Your examples don't seem that great, to be frank.
The lambda syntax isn't that different from the syntax for defining functions, unless you're referring to the fact that it's different than anonymous functions in other languages.
I don't find the inability to pass around operators to be a hindrance, but the fact that getting into python requires understanding all of these dunder or magic methods is another story.
However, on map, filter, & reduce, I agree with you completely.
One of the worst aspects of python is the extensive use of bad practices, and ignoring functional programming principles is one of the top offenses.
Re: Stop writing lambda expressions in Python
#36all i could think of is "stop writing python". it seems to me that a lot of these problems are fundamental problems with python. i continue to not understand why anybody likes python the language. the fact that creating a function with lambda versus the normal way is different is bonkers. for example, in f# (and other sane languages), the following are identical: let test1 = fun x -> x * x let test2 x = x * x both re…
> i continue to not understand why anybody likes python the language Here are some reasons why I like it: It's cleaner to read because there aren't curly braces and semicolons cluttering up the code. It's cleaner to write because the expressions are simpler and look like something readable instead of line noise. It has a REPL, so it's easy to experiment. It doesn't force me to write boilerplate code, such as types fo…
These are good reasons for why people might prefer python over other imperative languages, though basically all these points also apply to Haskell/OCaml/F#/etc., though some people would still say that a lot of things there look like line noise.
I think the GP's point was that functional languages give you similar benefits, but with more uniform and disciplined behavior of many language features. Why FP is not more widely used compared to imperative language is another topic though.
Re: Stop writing lambda expressions in Python
#37all i could think of is "stop writing python". it seems to me that a lot of these problems are fundamental problems with python. i continue to not understand why anybody likes python the language. the fact that creating a function with lambda versus the normal way is different is bonkers. for example, in f# (and other sane languages), the following are identical: let test1 = fun x -> x * x let test2 x = x * x both re…
I'm not sure what you mean by the first half of your comment. Both def and lambda create functions, and quoting from the article "Lambda expressions are just a special syntax for making functions. They can only have one statement in them and they return the result of that statement automatically.". def binds it to a name at the same time, which is remembered in the object (which AFAIK isn't really used for anything e…
it's because i am not that deeply familiar with python and the article is not clear itself on this. what is he complaining about then if they are identical in what's returned? is it simply because the REPL returns instead of the function name? why does the REPL do this? are they different in some subtle way?
the point was in something like f#, lambda creates a function which can then be bound to a name if you want. if you do so, this is identical to the "normal" function definition because that is really just syntactic sugar for creating lambda functions and then binding it to a name.
Re: Stop writing lambda expressions in Python
#38all i could think of is "stop writing python". it seems to me that a lot of these problems are fundamental problems with python. i continue to not understand why anybody likes python the language. the fact that creating a function with lambda versus the normal way is different is bonkers. for example, in f# (and other sane languages), the following are identical: let test1 = fun x -> x * x let test2 x = x * x both re…
Your examples don't seem that great, to be frank. The lambda syntax isn't that different from the syntax for defining functions, unless you're referring to the fact that it's different than anonymous functions in other languages. I don't find the inability to pass around operators to be a hindrance, but the fact that getting into python requires understanding all of these dunder or magic methods is another story. How…
> Your examples don't seem that great, to be frank.
they weren't intended to be great or mind blowing. they were just examples to make the point that in a good language, it's clear what is going on.
the operator thing is an extension of that. in f#, the "infixness" is just a syntax thing. the semantics is that they are functions and can be treated as such. it seems operators are something weird in python.
Re: Stop writing lambda expressions in Python
#39Earlier quoted context omitted.
In F#, can you ask a function object what its original name was? If so, what is the original name of "test1" and "test2" in your example? That's what python is doing and why the two are different. (I don't think a language should track that sort of thing, but that's a different story).
i am not for sure what you mean by "original name". the value of each of those function definitions are: val test1 : x:int -> int val test2 : x:int -> int you call them the same way, and they have the same type. a caller has no knowledge of how they were defined because it isn't important. they're identical.
> they're identical.
Does that mean that test1 == test2 will return true?
Personally, I have found it very useful for debugging that function objects in Python carry their name. That makes it much easier to find out where something is coming from.
Re: Stop writing lambda expressions in Python
#40The benefit of purely functional programming is that side effects can be managed explicitly and checked by the compiler, speeding up code refactors and making them safer. Using high order functions to save a few lines of code is not the big benefit of functional programming and is more a superficial feature more akin to syntax sugar. Same with list comprehensions. This seems to be the case in many hybrid languages th…
It seems like if you want the expressiveness of the simply typed lambda calculus, higher order functions are more than just syntactic sugar.