3 ms·

>First-class functions, lambdas, and closures are mostly unheard of in the top 20 programming languages. Aside from JS, you're pretty much out of luck. PHP, Pe

by dmux 4y ago

>First-class functions, lambdas, and closures are mostly unheard of in the top 20 programming languages. Aside from JS, you're pretty much out of luck. PHP, Perl and Swift all have first-class functions, lambdas and closures although I'd agree that that's not "most." This is probably getting too much into semantics, but aren't functions in JS just objects themselves? ;) >People stress about "writing unit tests" because technically correct types doesn't mean your program actually works. In my time writing JS vs TS, I've seldom found that type errors were the problem aside from making the type checker happy. Most errors are in what the code actually does or does not do. The instant feedback from the entire system is far superior to unit tests because it can catch things that your unit tests might not be testing for. I don't think having a "live" system like CL precludes the need for unit tests. Sure, it's beneficial to be able to play around with code right away, but unless you're planning on manually running through the same tests again and again, how do you know you've not introduced a regression at some point?

hajile 4y ago
> PHP, Perl and Swift all have first-class functions, lambdas and closures although I'd agree that that's not "most." This is probably getting too much into semantics, but aren't functions in JS just objects themselves? ;) Perl does have closures, but does not have lambdas as I recall (only subroutines) plus, but I didn't think it was particularly popular today. Dart and Swift do have all three of these things, but they also aren't particularly popular outside their niche mobile domain (or outside OSX in the case of Swift). Python has first-class functions and closures, but the lambdas are nerfed into near uselessness. PHP has a Closure class, but you must manually populate this class with whatever things you want to save. This is hardly what would commonly be accepted as a closure. > I don't think having a "live" system like CL precludes the need for unit tests. Sure, it's beneficial to be able to play around with code right away, but unless you're planning on manually running through the same tests again and again, how do you know you've not introduced a regression at some point? You are quite correct. Unit tests are still required, but the coverage you get when running stuff manually is still usually better for the same reason that a person clicking buttons on your UI will find tons of issues your unit tests overlooked. By running your new code inside of the whole system, you are also integration testing on the fly. I'd also add that it is possible to use some of your setup state for unit tests later.
- draegtun 4y ago
  Perl does have lambdas... my $double = sub {$_[0] * 2}; $double->(5);
mikelevins 4y ago
No, you're right; just because you can test something at once doesn't mean you shouldn't automate repeated tests. The thing is, though, not all tests are worth automating. I generally start work by sketching out a strawman representation of what I think I'm doing, then interrogating it interactively to find out how reality differs from my naive understanding. As my understanding improves, I refine the representation incrementally and interactively, and refine the interrogations right along with it. You can think of those interrogations as embryonic APIs and interactive unit tests, but most are not worth formalizing. They're ephemeral. The details they're interrogating are likely to change beyond recognition in a short time until discovery reveals the real shape of things. Once the real shape starts to emerge from the lump of clay, the representation turns into actual data structures and the interrogations turn into actual APIs and formal tests. I probably spend more time testing than in any other single activity while working in Lisp. I test pretty much every single expression interactively as soon as it's written, because it's so quick and effortless to do so. But most of those tests are not worth formalizing. Many of them will be executed one time and then never again. Others will be useful long enough to earn a temporary home in a source file for a while. The formalized unit and integration tests are the ones that have survived iteration, that are connected to structures and APIs that have survived and developed into something real. And that's the process, pretty much: rough sketch; interactive experimentation to discover what it really ought to be; formalization of discovered features (including tests that are worth automating).

by dmux 4y ago

hajile 4y ago

> PHP, Perl and Swift all have first-class functions, lambdas and closures although I'd agree that that's not "most." This is probably getting too much into semantics, but aren't functions in JS just objects themselves? ;) Perl does have closures, but does not have lambdas as I recall (only subroutines) plus, but I didn't think it was particularly popular today. Dart and Swift do have all three of these things, but they also aren't particularly popular outside their niche mobile domain (or outside OSX in the case of Swift). Python has first-class functions and closures, but the lambdas are nerfed into near uselessness. PHP has a Closure class, but you must manually populate this class with whatever things you want to save. This is hardly what would commonly be accepted as a closure. > I don't think having a "live" system like CL precludes the need for unit tests. Sure, it's beneficial to be able to play around with code right away, but unless you're planning on manually running through the same tests again and again, how do you know you've not introduced a regression at some point? You are quite correct. Unit tests are still required, but the coverage you get when running stuff manually is still usually better for the same reason that a person clicking buttons on your UI will find tons of issues your unit tests overlooked. By running your new code inside of the whole system, you are also integration testing on the fly. I'd also add that it is possible to use some of your setup state for unit tests later.

draegtun 4y ago
Perl does have lambdas... my $double = sub {$_[0] * 2}; $double->(5);

mikelevins 4y ago

No, you're right; just because you can test something at once doesn't mean you shouldn't automate repeated tests. The thing is, though, not all tests are worth automating. I generally start work by sketching out a strawman representation of what I think I'm doing, then interrogating it interactively to find out how reality differs from my naive understanding. As my understanding improves, I refine the representation incrementally and interactively, and refine the interrogations right along with it. You can think of those interrogations as embryonic APIs and interactive unit tests, but most are not worth formalizing. They're ephemeral. The details they're interrogating are likely to change beyond recognition in a short time until discovery reveals the real shape of things. Once the real shape starts to emerge from the lump of clay, the representation turns into actual data structures and the interrogations turn into actual APIs and formal tests. I probably spend more time testing than in any other single activity while working in Lisp. I test pretty much every single expression interactively as soon as it's written, because it's so quick and effortless to do so. But most of those tests are not worth formalizing. Many of them will be executed one time and then never again. Others will be useful long enough to earn a temporary home in a source file for a while. The formalized unit and integration tests are the ones that have survived iteration, that are connected to structures and APIs that have survived and developed into something real. And that's the process, pretty much: rough sketch; interactive experimentation to discover what it really ought to be; formalization of discovered features (including tests that are worth automating).