[HN Gopher] Zig, Skia, Clojure, Geometry and the Japanese TV Sho...
       ___________________________________________________________________
        
       Zig, Skia, Clojure, Geometry and the Japanese TV Show: ICFP Contest
       2021
        
       Author : ajxs
       Score  : 100 points
       Date   : 2021-07-14 04:10 UTC (1 days ago)
        
 (HTM) web link (tonsky.me)
 (TXT) w3m dump (tonsky.me)
        
       | timClicks wrote:
       | This is a excellent write-up. I'm really impressed how quick it
       | was to whip up a UI for manual solving.
       | 
       | I would argue however that Rust counts as a functional
       | programming language, however. Algebraic data types, higher-order
       | programming and immutability are all idiomatic features of the
       | language.
        
         | whateveracct wrote:
         | Rust is missing the function part though. For good reason -
         | closures and GC are like PB&J. But programming exclusively with
         | closures like you can in Haskell or Scheme isn't as feasible in
         | Rust. This isn't to say Rust doesn't have excellent closures,
         | lambdas, etc given its design constraints.
        
         | dgb23 wrote:
         | I was impressed by that too. It is a very valuable skill, to be
         | able to build a UI prototype that quickly. The author
         | attributes it to Clojure and there is certainly truth in that,
         | but given he also basically learned a new programming language
         | in a day and got a decent rating on his solution makes me think
         | it is not _just_ the tool. For one, this is a smart and
         | skillful programmer. But it also takes a playful mindset and
         | training to be able to do this.
        
       | adamdusty wrote:
       | I want to like Zig, but I also want operator overloading because
       | multiplying matrices together in chains of functions is among the
       | ugliest code I've ever had to look at. There have been more than
       | a couple decent suggestions for making it clean and obvious, but
       | there are a few things that Andrew isn't willing to budge on.
       | 
       | > defer is pure genious
       | 
       | Being able to defer for resource cleanup is nice. I like that Zig
       | makes it a priority to make things adaptable (not sure that's the
       | right word). For example, everything in the std lib that
       | allocates, takes an allocator object, so if you want to implement
       | a custom allocator, it's very simple to use. If you want to use a
       | custom event loop for async, it's easy to substitute. All in all,
       | I think its shaping up to be a nice language, just not for me.
        
         | dom96 wrote:
         | If you haven't already then you might be interested in checking
         | out Nim.
        
         | pron wrote:
         | > because multiplying matrices together in chains of functions
         | is among the ugliest code I've ever had to look at.
         | 
         | OK, but _how much_ code is it? I doubt even a game engine has
         | matrix operations in more than 0.1% of its lines of code
         | (obviously, in Matlab /Julia it can by 99%). The beauty of so
         | little code is a worthy sacrifice for the explicitness of a
         | low-level language.
        
           | kettlecorn wrote:
           | It also comes up with vector addition, subtraction, and
           | multiplication, all of which are used all over in gameplay
           | code.
           | 
           | I like Zig overall, but lack of operator-overloading just
           | seems like a pain to me.
           | 
           | Zig in many ways puts faith in the coder to not screw things
           | up, but in this case it diverges from that philosophy. Would
           | it be too much to trust the user not to overload operators in
           | an unacceptable way? Social convention over technical
           | constraint.
           | 
           | That said I'd be more persuaded by the argument that it's not
           | worth the extra code and complexity for a language as concise
           | as Zig.
        
             | flohofwoe wrote:
             | IMHO better than operator overloading (which opens the
             | gates to hell) would be builtin vector and matrix types
             | like in shading languages. Currently Zig has a vector type
             | builtin (search for @Vector and/or std.meta.Vector), which
             | supports the "simple" operations (addition, subtraction
             | etc...), so it's halfway there, but no swizzle, and no
             | matrix types.
        
         | majormajor wrote:
         | Defer sounds like a nice improvement over old old languages,
         | but Java's try-with-resources is one of the nicer ways of
         | handling resource cleanup I've seen in a "mainstream" language,
         | it's fairly neat and conceptually similar to some stuff I've
         | seen done with lisp macros or Ruby blocks. It seems like defer
         | is still lacking compared to this.
        
         | judofyr wrote:
         | I was actually thinking about writing a "macro" (i.e. function)
         | which takes in a math expressions as a string and an anonymous
         | struct for these use cases:                   eval("Ax + v",
         | {.A = ..., .x = ..., v = ...})
         | 
         | Wouldn't that be cool?
        
           | kristoff_it wrote:
           | That's fairly easy to implement with comptime.
        
       | jedisct1 wrote:
       | Great write up and well done!
        
       ___________________________________________________________________
       (page generated 2021-07-15 23:00 UTC)