Worse then Go



  • What happens when you tell Web 2.0 developers to make their own language? Why, you get the "beautiful" CoffeeScript, filled with such niceties such as syntax that makes Perl look sane:

    eat food for food in foods when food isnt 'chocolate'

    Function definition syntax created by somebody obsessed with lambdas.

    cube   = (x) -> square(x) * x

    Loose expressions becoming return statements.

    grade = (student) ->
      if student.excellentWork
        "A+"
      else if student.okayStuff
        if student.triedHard then "B" else "B-"
      else
        "C"
    

    From the "PHP's worst bits are a good idea", raw expressions in strings:

    sentence = "#{ 22 / 7 } is a decent approximation of π"

    and it uses it's own fucking build system instead of using something like make and it's billed as a JavaScript replacement (even compiling to JavaScript!) but no niceties for DOM so you still need jQuery if you want to use it with a browser.

    But, it does have one feature that makes totally web 2.0. Markdown integration! As if it needed the worst thing to happen to the web since vendor prefixes integrated into the compiler.

    And yes, Morbs, arrays are 0-based.



  • Meh. Pretty standard stuff nowdays. Implicit returns are even concidered good practice (in Scala for example). I also see nothing wrong with function definition. The first example I find ugly, but still pretty common.



  • I remember hoping this would turn out to be a quickly-forgotten fad when it was first announced. Instead it's achieved that middle-of-the-road kind of traction where it'll never take over the world, but still lingers on with a large enough userbase to thrive somewhat. Such a shame. I think it's been helped a lot by its inclusion in Rails, as a lot of Rails users just do whatever DHH tells them to do because Rails Is Omakase.

    What's surprising about Coffeescript is the sheer number of developers who are willing to be so public about their refusal to just use Javascript correctly. Yes, JS is an awkward language, but retreating into a fucking transpiler smacks of the kind of weak-willed learning aversion that is the hallmark of the mediocre developer. "I give up, just make it look like Ruby", it seems to say.

    Gotta agree with veggen about implicit returns though. One of the many reasons I like implicit returns is that they seem to encourage developers to write more of the kind of short 1-3 line methods that we should be writing in all languages.


  • Discourse touched me in a no-no place

    @MiffTheFox said:

    From the "PHP's worst bits are a good idea", raw expressions in strings:

    sentence = "#{ 22 / 7 } is a decent approximation of π"
    As long as the raw expressions are just in literals, they're not too bad. (Well, except that they tend to encourage bad behavior in generation of things like SQL and XML.) Raw expressions in arbitrary strings would be bad. Stunningly bad. So bad that I really don't believe that any language designer would be quite that stupid; after all, such idiocy would make writing a compiler or interpreter much more difficult, so the Attraction Of Stupid would actually be countered by general programmer laziness.


  • @veggen said:

    Pretty standard stuff nowdays.

    That doesn't mean it's not dumb. In fact, it probably increases the chances..

    @veggen said:

    Implicit returns are even concidered good practice (in Scala for example).

    Dear God.



  • @GNU Pepper said:

    One of the many reasons I like implicit returns is that they seem to encourage developers to write more of the kind of short 1-3 line methods that we should be writing in all languages.

    Please explain your reasoning for thinking this.



  • My manager wanted to use this and I had to push back because the main reason people are moving to it is because they don't really get JS. It is one of those things that look like a good idea on paper e.g. cleaner syntax, less typing, but those are the only advantages of using CoffeeScript.

    Microsoft have released something a lot more sensible than CoffeeScript which is TypeScript, but because it is from Microsoft the web hipsters probably won't pay any attention.

    I personally don't like things like jade, markdown etc. Because they bloody error out if you spacing is incorrect or some other such sillyness and tbh after about 5 minutes with working with them I wanted to strangle whoever thought it was a good idea

    Templating languages like mustache and ejs have the right idea, keep markup as markup and have placeholders for values. It pretty straight forward to understand.



  • @lucas said:

    I personally don't like things like jade, markdown etc. Because they bloody error out if you spacing is incorrect or some other such sillyness and tbh after about 5 minutes with working with them I wanted to strangle whoever thought it was a good idea

    My biggest problem with Markdown is how the link syntax makes absolutely no sense. If I ever had to implement it, I'd make it so the URL and text are interchangeable and it doesn't care whether you use square brackets or parens.



  • @GNU Pepper said:

    Gotta agree with veggen about implicit returns though. One of the many reasons I like implicit returns is that they seem to encourage developers to write more of the kind of short 1-3 line methods that we should be writing in all languages.

    What do you do when you call a function that returns a value (like any jQuery DOM manipulation function) but you want to treat it like it returned void? It looks like in Coffeescript the equivalent of calling $("#loading").show(); would return from the function then and there before you actually started doing what you were throwing up the loading screen for.



  • @MiffTheFox said:

    Loose expressions becoming return statements.
    That's the only sane part to me, but then again, I was raised on ALGOL-68, where a semicolon is treated as an operator that returns the value of the second operand.



  • Don't you ever forget Cool

    Instead of having arrays, the standard library has a class called ArrayAny.

    Comparing to null with == crashes your program with a null pointer dereference.

    The +, -, *, and / operators allocate memory in the reference compiler.

    There are no statements. No return. if is an expression.

    There is no && or || operator. Nest those ifs!

    Arithmetic overflow halts your program.



  • @Ben L. said:

    Don't you ever forget Cool

    That "language" can actually be excluded. From the document you linked:

    Cool is a small language that can be implemented in a one semester course.

    That means it's meant to be simplistic as a requirement, and the rest can be attributed to that, even if they might look like WTFs.

    Besides, can't you write a function which implements the && operator? (I didn't read through the manual, just quickly skimmed it.)



  • @MiffTheFox said:

    Loose expressions becoming return statements.

    grade = (student) ->
      if student.excellentWork
        "A+"
      else if student.okayStuff
        if student.triedHard then "B" else "B-"
      else
        "C"
    

     

    Wait... so does an if statement require a "then" or not?

     



  •  @MiffTheFox said:

    @GNU Pepper said:
    Gotta agree with veggen about implicit returns though. One of the many reasons I like implicit returns is that they seem to encourage developers to write more of the kind of short 1-3 line methods that we should be writing in all languages.

    What do you do when you call a function that returns a value (like any jQuery DOM manipulation function) but you want to treat it like it returned void? It looks like in Coffeescript the equivalent of calling $("#loading").show(); would return from the function then and there before you actually started doing what you were throwing up the loading screen for.

    That behavior makes no sense. Why would you even think it does that.

    And it doesn't, by the way. Implicit return is only for the last expression that's executed in the function.



  • @Mason Wheeler said:

    @MiffTheFox said:

    Loose expressions becoming return statements.

    grade = (student) ->
      if student.excellentWork
        "A+"
      else if student.okayStuff
        if student.triedHard then "B" else "B-"
      else
        "C"
    

     

    Wait... so does an if statement require a "then" or not?

     

    Only if the body of the if is going to be on the same line. Whitespace is significant in CS like Python.



  • @Arnavion said:

    And it doesn't, by the way. Implicit return is only for the last expression that's executed in the function.

    Which is why it blows: you can't return in the middle of the function. Instead you have to have a bunch of nested if/else blocks. Blegh.



  • @Arnavion said:

    Only if the body of the if is going to be on the same line. Whitespace is significant in CS like Python.

    I love that they made whitespace significant, and then flushed it all down the toilet by letting you stuff statements on the same line as an if. Seriously, why do languages allow this shit? Or allowing single-line if statements to not have braces? That's bad coding style virtually everywhere I've ever worked, and yet new languages still include this broken-ass C shit. Fuck.



  • @morbiuswilters said:

    @Arnavion said:
    Only if the body of the if is going to be on the same line. Whitespace is significant in CS like Python.

    I love that they made whitespace significant, and then flushed it all down the toilet by letting you stuff statements on the same line as an if. Seriously, why do languages allow this shit? Or allowing single-line if statements to not have braces? That's bad coding style virtually everywhere I've ever worked, and yet new languages still include this broken-ass C shit. Fuck.

    You'll be glad to find out that Go requires braces around the bodies of all if/else/for/switch/select statements.



  • @Ben L. said:

    You'll be glad to find out that Go requires braces around the bodies of all if/else/for/switch/select statements.

    A stopped clock is right two times a day. Three times when DST ends and it's stopped between 0100 and 0159, inclusive.



  • @lucas said:

    My manager wanted to use this and I had to push back because the main reason people are moving to it is because they don't really get JS. It is one of those things that look like a good idea on paper e.g. cleaner syntax, less typing, but those are the only advantages of using CoffeeScript.

    Microsoft have released something a lot more sensible than CoffeeScript which is TypeScript, but because it is from Microsoft the web hipsters probably won't pay any attention.

    I personally don't like things like jade, markdown etc. Because they bloody error out if you spacing is incorrect or some other such sillyness and tbh after about 5 minutes with working with them I wanted to strangle whoever thought it was a good idea

    Templating languages like mustache and ejs have the right idea, keep markup as markup and have placeholders for values. It pretty straight forward to understand.

    I converted a hobby project from JS to CS (and then to Go, I have a mental note to make a rant about that on this forum) and I quite like it. JS is a great language and all but it does get pretty verbose, especially for closures which are such a core feature of the language. In contrast, the function syntax in CS is almost the same as C# lambdas. And because whitespace is significant, there aren't any braces. I don't remember exactly, but converting from JS to CS reduced the size of the code (bytes, not lines) by 60%.

    I did consider TS, and static analysis is indeed a nice feature to have, but I didn't see any other benefits over CS and CS does have greatly reduced typing, so I stuck with CS. But TS is definitely a good concept.

    Both CS and TS have the horrible class "feature" which doesn't have real private members, so I stick to using regular functions either way.

    The CS _compilers_ have some problems, though. The first one has weird unclear messages sometimes (think C++), and the rewrite is better but isn't complete yet and fails on some code styles that the first one doesn't.



  • @morbiuswilters said:

    @Arnavion said:
    And it doesn't, by the way. Implicit return is only for the last expression that's executed in the function.

    Which is why it blows: you can't return in the middle of the function. Instead you have to have a bunch of nested if/else blocks. Blegh.

    You can. CS still has a return keyword.



  • @Arnavion said:

    JS is a great language and all but it does get pretty verbose, especially for closures which are such a core feature of the language.

    JS is one of the least verbose languages I've ever used.

    @Arnavion said:

    I don't remember exactly, but converting from JS to CS reduced the size of the code (bytes, not lines) by 60%.

    Why does this matter? Are you typing it all by hand? Don't you have an IDE to do autocomplete and stuff?

    I don't get this obsession with terseness. "Hey, let's all write in perl and then nobody will ever be able to read code again!"



  • @Arnavion said:

    You can. CS still has a return keyword.

    Dammit, I really walked into that one. Yeah, that definitely makes the implicit returns less dumb. I still don't like it, though. I don't like any "implicit" features, like semicolon insertion.. shudder



  • @morbiuswilters said:

    @Arnavion said:
    JS is a great language and all but it does get pretty verbose, especially for closures which are such a core feature of the language.

    JS is one of the least verbose languages I've ever used.

    @Arnavion said:

    I don't remember exactly, but converting from JS to CS reduced the size of the code (bytes, not lines) by 60%.

    Why does this matter? Are you typing it all by hand? Don't you have an IDE to do autocomplete and stuff?

    I don't get this obsession with terseness. "Hey, let's all write in perl and then nobody will ever be able to read code again!"

    It's not just verbosity of writing but also verbosity of reading. Surely you agree that C#'s lambdas are less verbose than VB's?

    x => x * x    vs    Function(x) Return x * x (I'm fuzzy on my VB)

    It's the same difference in CS vs JS

    x -> x * x    vs    function(x) { return x * x; }

    The latter conveys the same information with less fluff. This is especially true since JS's list comprehensions multiply this problem.

    var roots = arr.filter(function (x) { return x > 0; }).map(function (x) { return Math.sqrt(x); });

    vs

    roots = Math.sqrt(x) for x in arr if x > 0

    Also, while I didn't have an IDE for JS and CS, I do in fact use IDEs for my day job and am not one of those "Vim is an IDE" people.



  • @Arnavion said:

    The latter conveys the same information with less fluff. This is especially true since JS's list comprehensions multiply this problem.

    var roots = arr.filter(function (x) { return x > 0; }).map(function (x) { return Math.sqrt(x); });

    vs

    roots = Math.sqrt(x) for x in arr if x > 0

    shrug I like the JS way. It seems fine to me. Plus, it's very easy to modify. How do you add a breakpoint to the "roots = Math.sqrt(x) for x in arr if x > 0" CS?



  •  @morbiuswilters said:

    @Arnavion said:

    The latter conveys the same information with less fluff. This is especially true since JS's list comprehensions multiply this problem.

    var roots = arr.filter(function (x) { return x > 0; }).map(function (x) { return Math.sqrt(x); });

    vs

    roots = Math.sqrt(x) for x in arr if x > 0

    shrug I like the JS way. It seems fine to me. Plus, it's very easy to modify. How do you add a breakpoint to the "roots = Math.sqrt(x) for x in arr if x > 0" CS?

    Of course, you can say I cheated by using CS's special list comprehension syntax. With lambdas it would be

    roots = arr.filter(x -> x > 0).map(x -> Math.sqrt(x))

    which I still think is less verbose than the JS. This version would allow you to set a breakpoint.

     

    This does remind me of one misfeature of CS. Paraentheses around function arguments are optional, and omitting them is even encouraged, true Ruby-style. This means the idiomatic way to write the above lambda version would in fact be

    roots = (arr.filter x -> x > 0).map x -> Math.sqrt(x)

    Notice how func(arg1, arg2) becomes (func arg1 arg2).

    var result = func1(arg1, func2(arg2, arg3), arg4);

    would become

    result = func1 arg1, (func2 arg2, arg3), arg4

    It looks like a half-mix of LISP and Ruby and I'm not convinced I like it. Writing it the JS way is still supported though, so while you can avoid it in your own code, you might still see it in someone else's.


  • Considered Harmful

    @morbiuswilters said:

    @Arnavion said:

    The latter conveys the same information with less fluff. This is especially true since JS's list comprehensions multiply this problem.

    var roots = arr.filter(function (x) { return x > 0; }).map(function (x) { return Math.sqrt(x); });

    vs

    roots = Math.sqrt(x) for x in arr if x > 0

    shrug I like the JS way. It seems fine to me. Plus, it's very easy to modify. How do you add a breakpoint to the "roots = Math.sqrt(x) for x in arr if x > 0" CS?


    That's a good point. I can get a lot done quickly with a single "line" of LINQ in C# (actually a long chain of method calls with lambdas) but god damn if I need to step into it with a debugger I lose all that saved time tenfold.



  • @morbiuswilters said:

    @Arnavion said:

    The latter conveys the same information with less fluff. This is especially true since JS's list comprehensions multiply this problem.

    var roots = arr.filter(function (x) { return x > 0; }).map(function (x) { return Math.sqrt(x); });

    vs

    roots = Math.sqrt(x) for x in arr if x > 0

    shrug I like the JS way. It seems fine to me. Plus, it's very easy to modify. How do you add a breakpoint to the "roots = Math.sqrt(x) for x in arr if x > 0" CS?

    "breakpoint? What's that?" - everybody involved with Coffeescript design



  • If I wrote 1-3 line methods, their names & params would be 2500 characters long to compensate.



  • @Arnavion said:

    @morbiuswilters said:

    I don't get this obsession with terseness. "Hey, let's all write in perl and then nobody will ever be able to read code again!"

    It's not just verbosity of writing but also verbosity of reading. Surely you agree that C#'s lambdas are less verbose than VB's?

    x => x * x    vs    Function(x) Return x * x (I'm fuzzy on my VB)

    Agreed.  I don't agree that that's a bad thing.  Anyone can look at the VB version and see exactly what's going on: it's a function that takes a parameter (x) and returns the square of X.  The C# version, true to the legacy of the C family, is just incomprehensible operator soup.  (Who in the world came up with "=>" anyway?!?)  It's not so bad when it's a trivial little example like this, but when you start getting into real code, readability deteriorates fast.

    Verbosity is your friend when reading code.  It provides context that tends to be a lot harder for a human being to automagically infer than a compiler.

    It's the same difference in CS vs JS

    x -> x * x    vs    function(x) { return x * x; }

    The latter conveys the same information with less fluff syntactic context.

    FTFY

    This is especially true since JS's list comprehensions multiply this problem.

    var roots = arr.filter(function (x) { return x > 0; }).map(function (x) { return Math.sqrt(x); });

    vs

    roots = Math.sqrt(x) for x in arr if x > 0

    Umm... that doesn't look like a list comprehension to me.  That looks like "JS doesn't have list comprehensions, so here's how you fake it in JS, and here's an apples-to-oranges strawman that really only shows that having declarative comprehensions is easier to read than not having them."

     



  • @blakeyrat said:

    "breakpoint? What's that?" - everybody involved with Coffeescript design

    The sad truth is, it probably went something like this:

    CS dev 1: Hey, I just realized this new language we created doesn't have any good way to debug it.

    CS dev 2: Darn. Well, debugging is an "advanced feature". We'll just release it now, so we can get lots of links from Hacker News and Reddit and shit, then we'll worry about implementing "advanced features".

    [both high-five. five months pass and, contrary to the expectations of its creators, people are actually using CS]

    CS user: Hey, why can't I use a debugger in your language?

    CS dev 1: Shut up! A debugger is a crutch! CS is a new paradigm, they said so on Hacker News!!



  • @Mason Wheeler said:

    The latter conveys the same information with less fluff syntactic context.

    I think you meant semantic context.


  • Considered Harmful

    @morbiuswilters said:

    A debugger CoffeeScript is a crutch!



  • Perhaps blakey, morbs and Mason Wheeler missed my previous post.

    I admitted I was cheating by comparing JS's not-really-a-list-comprehension with CS's list comprehension, so I posted a version that didn't use CS's list comprehension syntax.

    You *can* put breakpoints in CS. Heck, in the worst case, you can put a breakpoint in the generated JS, because CS's list comprehensions do get compiled to for loops and if blocks in JS.

     

    @Mason Wheeler said:

    Agreed.  I don't agree that that's a bad thing.  Anyone can look at the VB version and see exactly what's going on: it's a function that takes a parameter (x) and returns the square of X.  The C# version, true to the legacy of the C family, is just incomprehensible operator soup.  (Who in the world came up with "=>" anyway?!?)  It's not so bad when it's a trivial little example like this, but when you start getting into real code, readability deteriorates fast.

    Verbosity is your friend when reading code.  It provides context that tends to be a lot harder for a human being to automagically infer than a compiler.

    It's the same difference in CS vs JS

    x -> x * x    vs    function(x) { return x * x; }

    The latter conveys the same information with less fluff syntactic context.

    FTFY

    I'm primarily a C# and JS dev, so I might be biased, but I've never come across a developer who thinks C#'s lambdas are operator soup.



  • @Arnavion said:

    You can put breakpoints in CS. Heck, in the worst case, you can put a breakpoint in the generated JS, because CS's list comprehensions do get compiled to for loops and if blocks in JS.

    Of course you can put breakpoints in. Duh. That doesn't make it debuggable.

    I have this problem constantly when using the D3.js library on web visualizations: the thing's completely obtuse. It's utterly un-debug-able. The errors are meaningless and happen 324,023 lines away from their direct cause. It's a nightmare to develop with.

    Brilliant when it works, but a nightmare when it doesn't.


  • Considered Harmful

    @Arnavion said:

    I'm primarily a C# and JS dev, so I might be biased, but I've never come across a developer who thinks C#'s lambdas are operator soup.

    Much like HTML can be abused to create tag soup, C# lambdas can be abused to create operator soup.



  • I thought Coffeescript was a decent enough thing, but yeah I agree. Learn JS properly, don't just create a Rubyscript (or Pythonscript, or whatever bastardization it's supposed to be) that sits over JavaScript. I had this issue with a lot of things when I was trying to learn Rails; you'd look for advice on how to do X and find post after post by the Rails cognoscenti that basically said "X is too hard, so Joe Railsguy wrote the Hamfish library that makes it easy to do X! Everyone should be using Hamfish!". This happened quite a few times and eventually I said screw it because it was just an never-ending laundry list of new things that the Rails community was jumping behind to make everything easier.

    I don't mind pure JavaScript once you get the hang of its quirks.



  • @Arnavion said:

    You can put breakpoints in CS.

    Really, in what tool?

    @Arnavion said:

    Heck, in the worst case, you can put a breakpoint in the generated JS, because CS's list comprehensions do get compiled to for loops and if blocks in JS.

    You know, the problem with breakpoints in JS was always that you could just open the code you'd written and move to the line of the function you wanted to analyze. Thank God CS added another layer of indirection in there.



  • @ObiWayneKenobi said:

    I had this issue with a lot of things when I was trying to learn Rails; you'd look for advice on how to do X and find post after post by the Rails cognoscenti that basically said "X is too hard, so Joe Railsguy wrote the Hamfish library that makes it easy to do X! Everyone should be using Hamfish!".

    Rails is a cult, but without the demented orgies or cool mass suicides.



  • @morbiuswilters said:

    @ObiWayneKenobi said:
    I had this issue with a lot of things when I was trying to learn Rails; you'd look for advice on how to do X and find post after post by the Rails cognoscenti that basically said "X is too hard, so Joe Railsguy wrote the Hamfish library that makes it easy to do X! Everyone should be using Hamfish!".

    Rails is a cult, but without the demented orgies or cool mass suicides.

    So it's a religion?



  • @GNU Pepper said:

    What's surprising about Coffeescript is the sheer number of developers who are willing to be so public about their refusal to just use Javascript correctly. Yes, JS is an awkward language, but retreating into a fucking transpiler smacks of the kind of weak-willed learning aversion that is the hallmark of the mediocre developer. "I give up, just make it look like Ruby", it seems to say.

    Actually, Dart makes large projects in javascript finally sane. And it'll probably run native in an upcoming Chrome release, but fall back to trans-compiled javascript in all the other browsers.



  • @Ben L. said:

    There are no statements. No return. if is an expression. ... Arithmetic overflow halts your program.
    That's all completely valid language design. I'd even call it sound. Expression-based languages are like that. And arithmetic overflow should either halts your program or it produces a not so easily described state, usually referred to as "wrong". Now I know you can abuse overflow, but for those case, there should be an operator called "add and fuck whatever doesn't fit in 4 bytes", like this: a _^_ b.Feel free to implement it.



  • @realmerlyn said:

    Actually, Dart makes large projects in javascript finally sane. And it'll probably run native in an upcoming Chrome release, but fall back to trans-compiled javascript in all the other browsers.
    First, large JS projecs are never sane. Second: another thing that runs native in Chrome but not anywhere else? Which step of Google's total world domination scheme is this? Nr 12?



  • @Ben L. said:

    @morbiuswilters said:
    @ObiWayneKenobi said:
    I had this issue with a lot of things when I was trying to learn Rails; you'd look for advice on how to do X and find post after post by the Rails cognoscenti that basically said "X is too hard, so Joe Railsguy wrote the Hamfish library that makes it easy to do X! Everyone should be using Hamfish!".

    Rails is a cult, but without the demented orgies or cool mass suicides.

    So it's a religion?

    No, all the cool religions have demented orgies; just look at Jim Bakker.



  • @TGV said:

    And arithmetic overflow should either halts your program...

    +1


  • Considered Harmful

    @TGV said:

    Now I know you can abuse overflow, but for those case, there should be an operator called "add and fuck whatever doesn't fit in 4 bytes", like this: a ^ b.

    C# has it. It's called unchecked.



  • @morbiuswilters said:

    @Arnavion said:
    You *can* put breakpoints in CS.

    Really, in what tool?

    For node.js - In the usual way, using node debug ... breakpoint("filename.coffee", lineNumber);

    In the browser - I honestly have no idea. CS has an excuse for this that since its generated JS is quite close to what you would've typed by hand, it is easy for the programmer to make a mental source map from source CS to generated JS. It is not ideal of course.

    The rewrite of the CS compiler that I mentioned earlier intends to (or already does, I'm not sure) support sourcemaps, so you could debug CS in the browser using Firebug or Chrome's devtools.

    @morbiuswilters said:

    @Arnavion said:
    Heck, in the worst case, you can put a breakpoint in the generated JS, because CS's list comprehensions do get compiled to for loops and if blocks in JS.

    You know, the problem with breakpoints in JS was always that you could just open the code you'd written and move to the line of the function you wanted to analyze. Thank God CS added another layer of indirection in there.

    Yes, I agree debugging without sourcemaps is a pain.



  • @joe.edwards said:

    @Arnavion said:
    I'm primarily a C# and JS dev, so I might be biased, but I've never come across a developer who thinks C#'s lambdas are operator soup.
    Much like HTML can be abused to create tag soup, C# lambdas can be abused to create operator soup.

    That's why you have code reviews and style policies.

    Besides, if you think x => x * x is an example of operator soup (you said so yourself), then I don't think there's any example of C# lambdas that you'd consider not soup, since that's as simple a lambda as it gets.


  • Considered Harmful

    @Arnavion said:

    x => x * x is an example of operator soup (you said so yourself)

    Wait, when did I say this? AFAIK this is the first time I've opined on the issue.



  • @joe.edwards said:

    @Arnavion said:
    x => x * x is an example of operator soup (you said so yourself)

    Wait, when did I say this? AFAIK this is the first time I've opined on the issue.

    Terribly sorry. I meant that Mason Wheeler said that himself.


Log in to reply