|
UberJumper posted:
Has he devised some sort of weird parallel of currying that only works in the imperative world?
|
# ? Jan 26, 2010 05:50 |
|
|
# ? May 30, 2024 14:04 |
|
UberJumper posted:
What does this even do? The lambda parameters aren't used anywhere, so the imports are pointless. e: Jonnty posted:Has he devised some sort of weird parallel of currying that only works in the imperative world? This looks like it's supposed to simulate lazy evaluation, not currying, unless there's something really weird going on elsewhere. TOO SCSI FOR MY CAT fucked around with this message at 06:00 on Jan 26, 2010 |
# ? Jan 26, 2010 05:58 |
|
Janin posted:What does this even do? The lambda parameters aren't used anywhere, so the imports are pointless. Oops! I actually copied the broken one, here is the correct one that was checked in: code:
It works.. i kinda like it but... UberJumper fucked around with this message at 06:26 on Jan 26, 2010 |
# ? Jan 26, 2010 06:06 |
|
WTF does he create the parameter, how is __import__("poo poo").create() any worse than that disaster.
|
# ? Jan 26, 2010 06:21 |
|
He probably thinks it only gets evaluated once.
|
# ? Jan 26, 2010 06:24 |
|
UberJumper posted:I only noticed this, because i am partially using some common modules, and saw that. His argument was "I dont want to create 2 line functions!" I bet this guy's mind will be blown when he figures out how return values work.
|
# ? Jan 26, 2010 07:39 |
|
UberJumper posted:Oops! I actually copied the broken one, here is the correct one that was checked in: There ought to be a competency test and license requirement for using lambda... code:
|
# ? Jan 26, 2010 07:50 |
|
Janin posted:There ought to be a competency test and license requirement for using lambda... Pretty sure this is sufficient: code:
Avenging Dentist fucked around with this message at 08:09 on Jan 26, 2010 |
# ? Jan 26, 2010 08:06 |
|
This is why Python can't have nice things.
|
# ? Jan 26, 2010 14:50 |
|
Zombywuf posted:This is why Python can't have nice things. I think this code is essentially the argument people use against Java getting closures. It's pretty convincing, I have to admit.
|
# ? Jan 26, 2010 15:19 |
|
If someone being dumb is a convincing argument to you, then this thread is an argument against any language getting any feature.
|
# ? Jan 26, 2010 15:44 |
|
Mustach posted:If someone being dumb is a convincing argument to you, then this thread is an argument against any language getting any feature. Eh, that's going a bit far. I definitely think the population of programmers that "write" Java for a living contains an abundant amount of people that would "[be] dumb" with closures. Looks like Python is getting there too. Popularity brings morons. In droves.
|
# ? Jan 26, 2010 18:40 |
|
TRex EaterofCars posted:Eh, that's going a bit far. I definitely think the population of programmers that "write" Java for a living contains an abundant amount of people that would "[be] dumb" with closures. Looks like Python is getting there too. Popularity brings morons. In droves. Python was deliberately created for morons^Wbeginners.
|
# ? Jan 26, 2010 19:22 |
|
The Python manual just says (or used to say, haven't checked in a while) that the lambda keyword is similar to the one used in functional languages. That's all. I took that to mean "if you don't know what this is you don't need to use it"
|
# ? Jan 26, 2010 19:51 |
|
The two features I dislike the most in .NET 3.5 are lambda expressions and the return of the dreaded var. Yes, I know the compiler can work it out. I'm not as smart as the compiler. If I'm looking at your code, there's a good chance there's something wrong with it. Please make my life a bit easier. At least they gave us automatic properties to make up for it.
|
# ? Jan 27, 2010 00:07 |
|
Milotic posted:The two features I dislike the most in .NET 3.5 are lambda expressions and the return of the dreaded var. Yes, I know the compiler can work it out. I'm not as smart as the compiler. If I'm looking at your code, there's a good chance there's something wrong with it. Please make my life a bit easier. 1. Lambda expressions are amazing, especially when dealing with dispatching stuff between worker threads and the UI thread. 2. I agree, var blows. It might not be a problem if you're the one writing the code, but when I'm trying to read it...
|
# ? Jan 27, 2010 05:30 |
|
What would you consider to be the pathological case for type inference? The normal auto i = map_of_vectors_of_strings_or_whatever.begin(); and var foo = new Bar::Baz<Fred>(...); stuff seems pretty unobjectionable
|
# ? Jan 27, 2010 05:44 |
|
Ugg boots posted:2. I agree, var blows. It might not be a problem if you're the one writing the code, but when I'm trying to read it... Yes, I too hate things that make generic programming easier and less verbose.
|
# ? Jan 27, 2010 05:45 |
|
Avenging Dentist posted:Yes, I too hate things that make generic programming easier and less verbose. PHP makes generic programming easier and less verbose...
|
# ? Jan 27, 2010 05:48 |
|
PHP doesn't support generic programming at all...
|
# ? Jan 27, 2010 05:52 |
|
rt4 posted:PHP makes generic programming easier and less verbose... Ah yes, the fallacy of division. (And perhaps more importantly, equivocation.) Avenging Dentist fucked around with this message at 06:01 on Jan 27, 2010 |
# ? Jan 27, 2010 05:56 |
|
I know this is really minor ...code:
|
# ? Jan 27, 2010 14:29 |
|
Avenging Dentist posted:Yes, I too hate things that make generic programming easier and less verbose. Right, but that's not what we are complaining about. This is: code:
|
# ? Jan 27, 2010 15:36 |
|
jarito posted:Right, but that's not what we are complaining about. This is: You could use dynamic in C# 4.0, but dynamic and var are two different concepts. edit: And var in C# has absolutely nothing to do with weak/strong typing.
|
# ? Jan 27, 2010 15:46 |
|
jarito posted:Right, but that's not what we are complaining about. This is: <insert uncompilable code in an attempt to support a fabricated complaint>
|
# ? Jan 27, 2010 16:00 |
|
Ok, listen up, folks. var doesn't make C# weakly typed. Do you write your code like this: code:
code:
P.S. Anybody who doesn't know their functions' return types is really a crabby dumb babby who sucks the teet of autocomplete.
|
# ? Jan 27, 2010 16:10 |
|
jarito posted:Right, but that's not what we are complaining about. This is: It is you. You are the horror who codes. By your logic, the type inference in Haskell also makes it weakly typed.
|
# ? Jan 27, 2010 18:28 |
|
jarito posted:Using var where the typing information is unneeded is fine, but it gives idiots a crutch to turn C# into a weakly typed language, which it is not. These guys disagree. C# Reference posted:Beginning in Visual C# 3.0, variables that are declared at method scope can have an implicit type var. An implicitly typed local variable is strongly typed just as if you had declared the type yourself, but the compiler determines the type.
|
# ? Jan 27, 2010 18:56 |
|
The real coding horror is not knowing the difference between strong/weak typing and static/dynamic typing.
|
# ? Jan 27, 2010 20:54 |
|
The problem I have with var is that it binds to the strictest return type of a method/constructor, which tends to discourage polymorphism and hence hinder refactoring. I can appreciate lambda expressions and extension methods speed up the initial developer's output, but it stinks for other people who look at your code.
|
# ? Jan 27, 2010 21:37 |
|
king_kilr posted:The real coding horror is not knowing the difference between strong/weak typing and static/dynamic typing. var is neither weak nor dynamic.
|
# ? Jan 27, 2010 22:37 |
|
Type inferencing is magic.
|
# ? Jan 27, 2010 22:39 |
|
Milotic posted:The problem I have with var is that it binds to the strictest return type of a method/constructor, which tends to discourage polymorphism and hence hinder refactoring. edit: In what way does it do either of those two things? dwazegek fucked around with this message at 22:55 on Jan 27, 2010 |
# ? Jan 27, 2010 22:52 |
|
Milotic posted:I can appreciate lambda expressions and extension methods speed up the initial developer's output, but it stinks for other people who look at your code. (I'm assuming we're making the definition of lambda elastic enough to include a Java-like "anonymous class" which I don't think closes over its containing block)
|
# ? Jan 27, 2010 22:59 |
|
dwazegek posted:
I'm assuming he's talking about a scenario where a function returns MySpecialListType<string> but the caller only really wants/needs an IEnumerable<string>. Since var only exists in local scope I don't imagine it's really any trouble to fix it.
|
# ? Jan 27, 2010 23:42 |
|
Free Bees posted:I'm assuming he's talking about a scenario where a function returns MySpecialListType<string> but the caller only really wants/needs an IEnumerable<string>. Since var only exists in local scope I don't imagine it's really any trouble to fix it. Why does this matter? Presumably if the variable is later passed to a procedure that accepts IEnumerable, its type will be inferred to be IEnumerable, right?
|
# ? Jan 27, 2010 23:51 |
|
And even if it's inferred as MySpecialListType<string> this doesn't pose a problem unless MySpecialListType doesn't implement IEnumerable
|
# ? Jan 27, 2010 23:55 |
|
It's only an issue when you start writing procedures which accept that implicitly defined variable - many code completion tools and whatnot (I think resharper will, will have to try it tomorrow), will create a method that uses the specific type, rather than something more abstract. If you explicitly declare it as an IEnumerable, it won't. It's a fairly weak argument, and depends on your coding style/whether you use code completion stuff. Also, I guess var causes more headaches when it comes to arrays. An array of objects is not the supertype of an array of strings (say), so I think it's best to be explicit when declaring an array.
|
# ? Jan 28, 2010 01:21 |
|
If a variable's (or function's return value's) type is inferred as ArrayList instead of List, users of the variable/function can write code which only works with ArrayList; thus you get implicit dependencies on some type which was meant to be purely an internal implementation detail. In practice I doubt this is a serious concern; I find it's very rarely useful to swap implementation types without making other structural/semantic changes that require client code to be updated anyway.
|
# ? Jan 28, 2010 01:30 |
|
|
# ? May 30, 2024 14:04 |
|
Lambdas are awesome, I can't imagine why anyone would think otherwise. The alternative is the old 2.0 anonymous delegate syntax which was ugly as hell and hard to read. Unless you've been in bracket land your entire programming career, lambdas read very naturally. var I can understand because it can make code harder to read at a glance. Yeah weakly-typed languages aren't inherently harder to read than strongly-typed languages but when you run into what looks like weak typing in the middle of strongly-typed code it forces you to put on the breaks. Having said that its usage in limited areas (like foreach loops on some complicated enumeration or linq expression results) it does make the code more compact without sacrificing too much clarity. dynamic scares me. Everyone who *thinks* var introduces weak-typing is gonna fuckin' love dynamic.
|
# ? Jan 28, 2010 06:27 |