[HN Gopher] Can Your Programming Language Do This? (2006)
       ___________________________________________________________________
        
       Can Your Programming Language Do This? (2006)
        
       Author : swyx
       Score  : 14 points
       Date   : 2024-05-09 18:45 UTC (4 hours ago)
        
 (HTM) web link (www.joelonsoftware.com)
 (TXT) w3m dump (www.joelonsoftware.com)
        
       | fire_lake wrote:
       | This article proved to be right - now all mainstream languages
       | have some kind of lambda functionality.
       | 
       | What's next? My predictions are:
       | 
       | - expression orientated
       | 
       | - algebraic effects
        
         | armchairhacker wrote:
         | Further along: affine types, refinement types, formally
         | verified preconditions/postconditions, _maybe_ even dependent
         | types.
        
           | sterlind wrote:
           | Automatic theorem provers are stuck in AI winter. Pre/post-
           | conditions and dependent types currently need too much
           | handholding. Once the AI firms deign to release heuristic
           | language models for proof discovery, we can have nice things
           | like that.
        
       | wk_end wrote:
       | Closures and stuff are great, but for the sake of being ornery:
       | function Cook( i1, i2, f )        {           alert("get the " +
       | i1);           f(i1);           f(i2);        }             Cook(
       | "lobster", "water", PutInPot );        Cook( "chicken",
       | "coconut", BoomBoom );
       | 
       | (or worse)                 Cook("lobster",            "water",
       | function(x) { alert("pot " + x); }             );
       | Cook("chicken",            "coconut",              function(x) {
       | alert("boom " + x); }            );
       | 
       | This to me looks like a great example of The Wrong Abstraction.
       | You're removing a tiny bit of code duplication at the cost of
       | creating a weird, hard-to-read, inflexible, limited-use helper;
       | he's taken something straightforward and turned it into,
       | honestly, a bit of a hash.
        
       | Jtsummers wrote:
       | https://news.ycombinator.com/item?id=14882880 - July 29, 2017 - 2
       | comments
       | 
       | https://news.ycombinator.com/item?id=2476440 - April 23, 2011 -
       | 110 comments
       | 
       | https://news.ycombinator.com/item?id=2209970 - February 12, 2011
       | - 1 comment
       | 
       | Couldn't find more, but I thought it had come up more times.
        
       | sixthDot wrote:
       | As people already commented in 2011, that's pretty common.
        
       | kazinator wrote:
       | > _Many older languages simply had no way to do this kind of
       | stuff._
       | 
       | Mainly due to not cribbing from other older languages like Lisp
       | and Algol 68.
        
       | jkaptur wrote:
       | > In fact, if you have two CPUs handy, maybe you could write some
       | code to have each CPU do half of the elements, and suddenly map
       | is twice as fast.
       | 
       | I remember this came up a lot in late-aughts functional
       | programming discussions. But is there any language where this
       | actually works? Where map is just parallel because of course it
       | is?
        
         | _se wrote:
         | https://docs.rs/rayon/latest/rayon/iter/index.html
        
         | sterlind wrote:
         | F# defines a parallel map with the same type signature as
         | sequential map, but you have to ask for Array.Parallel.map
         | rather than Array.map or whatever, because of the possibility
         | of side effects. Only in a pure language like Haskell could you
         | safely parallelize automatically. I'm not sure why Haskell
         | doesn't - maybe overhead?
        
       ___________________________________________________________________
       (page generated 2024-05-09 23:03 UTC)