Clojurians Log v2

yes, @seancorfield thanks!

multithreaded compilers are a good thing

I guess my laptop has a fan for a reason

I couldn't possibly be any more tired of NPE

FFS, hunk of junk languages (╯°□°）╯︵ ┻━┻

In the last weeks I found out that there is something thats worse than java

Its eclipse plugin development with java

how could anyone ever have thought their architecture is a good idea -.-

life it too short to go anywhere near any language with nulls.

So many CNF Exceptions, runtime errors and after you fixed one, you have to go, install, update, whatever, built a p2 repo, dance a magic dance and pray, just to see the next runtime error

I mean, it is possible to handle NULLs sensibly, even in Java, but, how many programmers do know how? And how many then even go and do it?

" it is possible to handle NULLs sensibly"

The only sane say is banish them into the type system

http://twitter.com/cognitect/status/734748037872943104

@martintrojer: I am talking of the NULL object pattern: http://www.tutorialspoint.com/design_pattern/null_object_pattern.htm

spec looks awesome

this is probably as far as you can take runtime contracts

null punning is nice until you realize that 1) it's impossible to distinguish between sources of null and generate the "right thing" and 2) you have things that aren't monoids/groups and don't have a "right thing" to start with....

well now we have spec

so this'll be interesting

I stand by my "propositions as types" rant above wrt spec and remain skeptical but it's better than the previous status quo

Yeah. We have a Hickey approved schema spec now

If it takes on in libraries the world will be better

all the hard problem with nulls and refactoring remain however

This is still runtime contracts

It's important, but need to be paired with type checking ala typed racket

Maybe we'll get there at some point

(Hickeys anti type rant in the spec blog / about doesn't fill me with hope though)

I listened to the podcast with @mtnygard on software engineering radio. He explains it's a trade off. Flexibility (and fragility for that matter), REPL etc vs. type system. I think we'll never get the full benefits of both in one language.

One could say that writing tests is better than a REPL session, because then it's at least reproducible. But practice matters. I'm writing Scala now and I'm distracted a lot of times, because the compiler gets me out of the loop. With Clojure I had focused days of development.

Or maybe there will be a better alternative. The language has to be so fast/lightweight that it comes close to the REPL experience.

Yeah yeah, eventually the JVM startup time and compiler overhead will not matter, but we're far from there.

With clojure.spec baked in, even contrib libraries can take advantage of it (the "rule" is no contrib library can depend on anything beyond core + contrib).

I’d certainly consider writing specs for java.jdbc (as a separate, requireable namespace).

It’ll be interesting to see how much "typed Clojure" we see on top of clojure.spec...

There's an interesting conversation on twitter rn about clojure.spec depending on clojure.test.check.

https://twitter.com/gfredericks_/status/734876301958512644

One concern with clojure.spec is that it doesn't support parameterized types specs as far as I can tell.

You can talk about returning a seq, but hard to say a seq of what.

The implementation of clojure.spec.gen is pretty janky in terms of trying to look up clojure.test.check vars without actually requiring the clojure.test.check namespace.

anyway back to apartment hunting...

(s/+ integer?) for a seq of integers?

(or am I misunderstanding you @arrdem ?)

@seancorfield: that would seem to work from my not having used spec yet 😛

I’ve been playing with it on and off all day. Can’t wait for the 1.9.0 Alpha 1 build so we can actually use it officially at work!