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

Is Typed Clojure worth the trouble?

blog.juxt.pro

Post reply on HN
Print view View original

21–30 of 62 posts

Re: Is Typed Clojure worth the trouble?

#21

Post by arh68 »

I like how:

- first, the ClojureScript REPL whines at smelly coercions out of the box

  cljs.user=> (+ 1 "2" nil)
  WARNING: cljs.core/+, all arguments must be numbers,
      got [number string] instead. at line 1 
  WARNING: cljs.core/+, all arguments must be numbers,
      got [number clj-nil] instead. at line 1 
  "12null"
- second, the author kind of hints you should be using schemas & coercion already (so as to desmellify)

- third, you can typecheck a codebase incrementally

Also, I really thought I'd see that quote about 100 functions operating on a 1 data structure easier to grok than 10 functions operating on 10 different data structures. Of course, it's nicer when that 1 data structure (or even the 10) has a schema instead of being void *.

Re: Is Typed Clojure worth the trouble?

#22

Post by Skinney »

bostonOU wrote: post #19
Skinney wrote: post #17

Earlier quoted context omitted.

For Clojure, I know there has been talk about this. Clojure allows you to insert Type Hints, which allows Clojure to remove reflection in certain cases, which improves both runtime and compile speed. Typed Clojure should be able to insert Type Hints automagically for you since you provide type information anyway, although it doesn't do that today. For ClojureScript there really isn't any performance optimization to b…

I believe ClojureScript only supports boolean type hints/performance optimization. Other type hints are "supported" but don't do anything.

Yeah. They are not really necessary in a Javascript VM that is optimized for these sort of languages anyway.

Re: Is Typed Clojure worth the trouble?

#23

Post by JadeNB »

nmrm2 wrote: post #13

I am impressed by the fact that Typed Closure is a lot of things in addition to language design -- library development, editor/tool development, even community engagement and evangelism. > Clojure codebases typically rely on tests to verify the correctness of the code. OT, but this is a pet peeve of mine. Tests aren't verification, and they cannot demonstrate correctness (without being exhaustive). Clojure codebases…

> Tests aren't verification, and they cannot demonstrate correctness (without being exhaustive).

Agreed, but it's important to note that there's very little that can demonstrate correctness. Most type systems by themselves don't; as Pierce describes it in TAPL, "[a] type system is a syntactic method for automatically checking the absence of certain erroneous behaviors" (emphasis mine). It's possible that, in a dependent type system, those certain behaviours will be sufficiently many that you can prove the correctness of a program specification, but even a rich system like Haskell's usually doesn't offer such guarantees (just consider `tail []`; or, for an example that's not just a Prelude wart, `take n xs`).

Re: Is Typed Clojure worth the trouble?

#24

Post by JadeNB »

Skinney wrote: post #18
cantankerous wrote: post #16

Earlier quoted context omitted.

What about the cognitive load of chasing down things like null reference errors, which in some strongly typed languages don't even exist? And no, they're not always fairly obvious to find, especially when you're fixing somebody else's code.

The keyword being "some". I've rarely had any problems with null/nil reference errors in Clojure, because nil is treated both as false and as the empty list, so most of the time you do the right thing in case of nil. You also don't call methods on objects, but send values to functions, which eliminates a large source of NPE right there. Clojure is also a compiled language. So things like calling a function with the w…

> most of the time you do the right thing in case of nil

I can't remember where, but I was just reading something yesterday to the effect that a solution that works most of the time is worse than a 'solution' that never works: at least you'll notice the latter quickly, whereas you might not notice the former until it's buried so deep in your code that you've forgotten the hidden assumptions it involves.

Re: Is Typed Clojure worth the trouble?

#25

Post by Skinney »

JadeNB wrote: post #24
Skinney wrote: post #18

Earlier quoted context omitted.

The keyword being "some". I've rarely had any problems with null/nil reference errors in Clojure, because nil is treated both as false and as the empty list, so most of the time you do the right thing in case of nil. You also don't call methods on objects, but send values to functions, which eliminates a large source of NPE right there. Clojure is also a compiled language. So things like calling a function with the w…

> most of the time you do the right thing in case of nil I can't remember where, but I was just reading something yesterday to the effect that a solution that works most of the time is worse than a 'solution' that never works: at least you'll notice the latter quickly, whereas you might not notice the former until it's buried so deep in your code that you've forgotten the hidden assumptions it involves.

By that logic, most object oriented languages like Java, C# and C++ are fundamentally flawed as calling a method only works most of the time.

Besides, code in general only work most of the time. Static typing does not protect you from bugs.

Re: Is Typed Clojure worth the trouble?

#26

Post by the_af »

Skinney wrote: post #25
JadeNB wrote: post #24

Earlier quoted context omitted.

> most of the time you do the right thing in case of nil I can't remember where, but I was just reading something yesterday to the effect that a solution that works most of the time is worse than a 'solution' that never works: at least you'll notice the latter quickly, whereas you might not notice the former until it's buried so deep in your code that you've forgotten the hidden assumptions it involves.

By that logic, most object oriented languages like Java, C# and C++ are fundamentally flawed as calling a method only works most of the time. Besides, code in general only work most of the time. Static typing does not protect you from bugs.

> Static typing does not protect you from bugs.

But it does. It doesn't protect you from all bugs, but nobody claimed it did.

Re: Is Typed Clojure worth the trouble?

#27

Post by JadeNB »

Skinney wrote: post #25
JadeNB wrote: post #24

Earlier quoted context omitted.

> most of the time you do the right thing in case of nil I can't remember where, but I was just reading something yesterday to the effect that a solution that works most of the time is worse than a 'solution' that never works: at least you'll notice the latter quickly, whereas you might not notice the former until it's buried so deep in your code that you've forgotten the hidden assumptions it involves.

By that logic, most object oriented languages like Java, C# and C++ are fundamentally flawed as calling a method only works most of the time. Besides, code in general only work most of the time. Static typing does not protect you from bugs.

I didn't call anything flawed, fundamentally or otherwise; but I take your point.

I think that there is an important distinction between 'almost-there' solutions.

Suppose that you have a piece of code that is specified to work in a certain way. Because code, and the hardware on which it runs, is made (at least indirectly) by humans, it will fail under some conditions; it only satisfies its specification. I think that we are all comfortable with this kind of "works most of the time".

By contrast, consider 'smart' products—for example, the auto-complete on your phone. This also, after a bit of training, works most of the time, and can make some brilliant inferences. However, I think that most people can agree that the "most of the time" for auto-completion is qualitatively different from the "most of the time" for specified software: it is reasonable to rely on the latter, but not, or at least not nearly as much, on the former (http://www.damnyouautocorrect.com).

Re: Is Typed Clojure worth the trouble?

#28

Post by outworlder »

Skinney wrote: post #25
JadeNB wrote: post #24

Earlier quoted context omitted.

> most of the time you do the right thing in case of nil I can't remember where, but I was just reading something yesterday to the effect that a solution that works most of the time is worse than a 'solution' that never works: at least you'll notice the latter quickly, whereas you might not notice the former until it's buried so deep in your code that you've forgotten the hidden assumptions it involves.

By that logic, most object oriented languages like Java, C# and C++ are fundamentally flawed as calling a method only works most of the time. Besides, code in general only work most of the time. Static typing does not protect you from bugs.

But they are. As in, they fail to handle the null case properly.

Re: Is Typed Clojure worth the trouble?

#29

Post by Skinney »

the_af wrote: post #26
Skinney wrote: post #25

Earlier quoted context omitted.

By that logic, most object oriented languages like Java, C# and C++ are fundamentally flawed as calling a method only works most of the time. Besides, code in general only work most of the time. Static typing does not protect you from bugs.

> Static typing does not protect you from bugs. But it does. It doesn't protect you from all bugs, but nobody claimed it did.

True, should have specified what I meant. The thing is, static typing doesn't necessarily protect you from more bugs than a dynamic language. For instance, Clojure is less prone to NPEs because you don't call methods on objects, and because a lot of your program manipulates datastructures, and nil is treated as an empty datastructure. Of course, a language like Rust, which doesn't have null, does protect against NPEs. It's all relative.

Re: Is Typed Clojure worth the trouble?

#30

Post by Skinney »

JadeNB wrote: post #27
Skinney wrote: post #25

Earlier quoted context omitted.

By that logic, most object oriented languages like Java, C# and C++ are fundamentally flawed as calling a method only works most of the time. Besides, code in general only work most of the time. Static typing does not protect you from bugs.

I didn't call anything flawed, fundamentally or otherwise; but I take your point. I think that there is an important distinction between 'almost-there' solutions. Suppose that you have a piece of code that is specified to work in a certain way. Because code, and the hardware on which it runs, is made (at least indirectly) by humans, it will fail under some conditions; it only satisfies its specification. I think that…

I know you didn't, but if you have a language have a core semantic that only works "most of time," and "most of the time" is worse than "never," then you have a language that is worse than not having a language at all, which means that it is fundamentally flawed. Yes, I probably did enjoy my logic courses at the university too much.
Post reply on HN