Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clojure 1.13 adds support for checked keys

clojure.org

Post reply on HN
Print view View original

31–40 of 50 posts

Re: Clojure 1.13 adds support for checked keys

#31

Post by [deleted] »

xoxolian wrote: post #18
slifin wrote: post #2

This is a case I never really thought about - if the key is missing today you'll get nil as the value and since Clojure is a nil punning language it usually does sensible behaviour in your program I know this sounds unreliable but in practise I like a language that defaults to pragmatic code paths so I don't have to stay up at night imagining a million code paths This adds a throwing codepath which is quite drastic s…

For me: documentation at the "front door" of an interface, especially in that long moment before you decide to add a spec or Malli schema.

[deleted]

Re: Clojure 1.13 adds support for checked keys

#33

Post by drob518 »

exabrial wrote: post #19

I love the idea of clojure and perfect immutability, but holy crap I cannot grok the syntax. My C-trained brain explodes.

I went through a similar phase decades ago with Common Lisp. It takes a week or two. Now, it’s quite a natural syntax and I see the parens as a huge benefit. I like Clojure syntax even more than CL and Scheme because of the map and vector literals.

Re: Clojure 1.13 adds support for checked keys

#34

Post by iLemming »

exabrial wrote: post #19

I love the idea of clojure and perfect immutability, but holy crap I cannot grok the syntax. My C-trained brain explodes.

Lisp is tricky. Pretty much every programmer for whom it's not their very first PL hates it initially, but then there's a time, a threshold after which no other language feels more readable than Lisp.

Using structural editing idioms and the REPL, usually makes the process less vexing.

Re: Clojure 1.13 adds support for checked keys

#35

Post by vaylian »

undershirt wrote: post #25
akkad33 wrote: post #16

Earlier quoted context omitted.

What is nil-punning?

allowing functions to treat nil arguments as empty versions of their expected types

For example:

(cons some-value my-list)

If my-list is nil, then the above expression will result in a list containing only the element some-value. Otherwise it will be a list starting with some-value followed by any other values that have been previously in my-list.

Re: Clojure 1.13 adds support for checked keys

#37

Post by TacticalCoder »

slifin wrote: post #2

This is a case I never really thought about - if the key is missing today you'll get nil as the value and since Clojure is a nil punning language it usually does sensible behaviour in your program I know this sounds unreliable but in practise I like a language that defaults to pragmatic code paths so I don't have to stay up at night imagining a million code paths This adds a throwing codepath which is quite drastic s…

> ... if the key is missing today you'll get nil as the value and since Clojure is a nil punning language it usually does sensible behaviour in your program

And that is still doable AIUI: they're optional checked keys. The doc describing them makes the distinction between required and non-required keys.

Arguably we already had those: I religiously use spec'ed maps in my Clojure since a great many years (and Clojure spec is still in alpha, but "alpha" in Clojure land basically means: "more stable and less likely to change than any feature in any other language" and I'm only slightly exaggerating here).

In my case I use good old defn-spec (form Orchestra but YMMV) instead of defn. And my maps are (partially) spec'ed, using spec'ed keys (as well as any other non-spec'ed key I feel like using). Sure it's only runtime checks but it's really great.

You get to both have the extensibility (you can for example add keys that don't exist yet later on without changing any of your specs) and you can specify which keys are required.

For there is such a thing as maps where you know that this and that key must always be there.

I don't think it's an issue to have optional checked keys. Especially not when you can mix both required and non-required keys in the same map.

Re: Clojure 1.13 adds support for checked keys

#38

Post by TacticalCoder »

swannodette wrote: post #15
embedding-shape wrote: post #11

Earlier quoted context omitted.

Amazing! What are the most interesting areas for ClojureScript in the future, if you don't mind me asking for some casual semi-serious prediction? Thanks for everything you've done for Clojure and ClojureScript, I'd surely have dropped programming as a whole if I didn't discover Clojure and ClojureScript at the time I did.

Honestly what's mostly at the forefront of my mind is greatly improving the documentation around ClojureScript as well as our fork of Google Closure Library (GCL). At work we've switched to DataStar (a single JS include) and coupled that with ClojureScript/GCL - we no longer rely on anything from NPM, to call this a simplification would be a gross understatement. Bundle size is 30K gzipped and we spend no time thinki…

We switched to DataStar after seeing one of your vid about SSE. Full ack that calling it a "simplification would be a gross understatement".

Namaste!

Re: Clojure 1.13 adds support for checked keys

#39

Post by whalesalad »

iLemming wrote: post #34
exabrial wrote: post #19

I love the idea of clojure and perfect immutability, but holy crap I cannot grok the syntax. My C-trained brain explodes.

Lisp is tricky. Pretty much every programmer for whom it's not their very first PL hates it initially, but then there's a time, a threshold after which no other language feels more readable than Lisp. Using structural editing idioms and the REPL, usually makes the process less vexing.

[dead]

Re: Clojure 1.13 adds support for checked keys

#40

Post by slifin »

kevincox wrote: post #17
slifin wrote: post #2

This is a case I never really thought about - if the key is missing today you'll get nil as the value and since Clojure is a nil punning language it usually does sensible behaviour in your program I know this sounds unreliable but in practise I like a language that defaults to pragmatic code paths so I don't have to stay up at night imagining a million code paths This adds a throwing codepath which is quite drastic s…

The problem in my experience is that while nil is a perfectly reasonable default 9/10 times that 1/10 happens often enough and causes major problems that it is worth taking the extra few seconds to write it explicitly in the code to acknowledge that case and that you have checked that it is fine in the 9/10 cases or handle it in the 1/10 case. I have seen multiple major production outages in Golang code because peopl…

defaults are a different thing to nil punning

So nil will have had special consideration in Clojure core functions

That doesn't mean it doesn't crash either it will absolutely be unhappy with nils in your math

nil is usually unexpected in test outputs or at the very least an unhappy path

In terms of debugging that's why I can't quit this language flowstorm let's me visually step through what happened line by line, backwards, forwards, programmatically - whatever

Languages should be competing against each other by their best time travel debugger it just completely removes the need for guesswork

Post reply on HN