I haven't really had a need for it: inputs are of deterministic type and conversions are required at obvious sites. @jaen

@johanatan: you mean typing? I dunno, I like compiler telling me "you dun goofed up" when compiling instead of getting "Can't cast ISeq to IFn" during runtime, possibly in a place far removed from where the problem originated. I'm not the smartest or most organised person around, so I like the computer keeping tabs on such menial things like these instead of me. Bonus points for being able to construct the types as to disallow invalid states.

Yes, I mitigate that by changing small parts/one thing at a time and using constant feedback loop of of execution/live coding. Also trying things out in REPL first. I've had good experience with core.typed although if I wanted to go down that road today I'd just use Prismatic Schemas

@jaen: ^

Well, separating things into small pieces and exploratory programming in REPL certainly can help, but it can so happen that you chew a bit too much at a time or you didn't realise some interaction will happen and the non-local blow up can still happen even then. I like increased locality of error static typing gives me. I think as cool as core.typed seems, bolting a static typing system onto a dynamic language will always be limiting to both the language and type system - you just won't be able to either type or keep using some common idioms effectively, since languages tend to grow differently depending on presence or absence of a strong static type system. Pristmatic Schema is a nice and helpful library, but still pushes failures to runtime, where I preferably would have no problems.

I really like Clojure, but the times when errors happen that static typing could have avoided still annoy me.

And probably it's a bit related to how much you trust your own programming abilities - I don't trust mine for example and would prefer the type system to stand guard so I don't screw up too much.

It's all a set of trade offs though.

Of course, static typing has advantages. It's a trade off.

I tried the Scala console, but what is annoying is that you have to exit it, then recompile and re-enter the console.

I think in Scala it makes more sense to write tests instead of trying everything from the console. Which might actually be a good thing: it forces you to write tests 😉.

Writing tests is hard, I still can't learn it D :

The Scala console makes sense when you want to try a library, but not for developing

Well, I didn't write anything big enough in Scala or Haskell to say whether that is true, so I'll take your word for it. Being able to develop without reloading the whole REPL is certainly a nice feature of Clojure.

I think with JRebel you could get that behavior maybe in Scala, but that's another tool

And paid one at that, I think?

JRebel used to be free for Scala developers but they changed that maybe 1.5 years ago

With Sbt+Scalatra+Jrebel it was possible to get a workflow where file change resulted in recompile and new jetty being started, each recompilation took something like 5 to 60 seconds.

Luckily I haven't had to work with Scala in some time, but I remember seeing some mentions of incremental recompilation being added to core and other frameworks (lift or play?) using that

@juhoteperi: isn't the idea of JRebel that you shouldn't have to restart your web server

@borkdude: Yes, I guess it's more of container reload instead of jetty restart.

Does anyone know of a Clojure library that wraps HBase that will support HBase 1.1.1? I’ve looked at https://github.com/tolitius/cbass and https://github.com/davidsantiago/clojure-hbase and neither seem to work w/ 1.1.1. I was thinking of forking clojure-hbase and looking at upgrading it but I really don’t have the time as I’ve a problem to solve in the next day or so.

@agile_geek: Nope, but the code isn’t too ugly when using it via interop. We only needed it for a couple queries at work so just made a few wrapper functions to clean up the API. Your mileage might vary.

@rok3 yeah, I've ended up using interoperability.

@borkdude: there are ways to reload what you need to from within Scala's REPL so that isn't a substantial difference

@jaen: runtime/compile time doesn't matter to me because I use tight iterations/live coding

@johanatan: well, that is quite orthogonal, when live coding the code still needs to be compiled and less checking during that still can mean uncaught bugs. But I imagine it's certainly less of a problem if you program in small bites

@jaen: huh? Orthogonal? No, they're integrated. Run happens directly after compile and they both happen on edit

@jaen: this the phases are indistinguishable

If you want to think of them as compile, you are free to do that. It's a state of mind

In Clojure they are, it's a compiled language

And it's a difference if you get an error on compile time

(for example wrong arity)

or durign runtime

(mismatched types)

Ok, you are not understanding what I am saying. Sorry about that

But out of curiosity why do you care where an error comes from?

I care about how early I can get it, which I think in case of mismatched types for example runtime is too late

Since seqs are lazy the mismatched type can propagate far enough it can be nontrivial to udnerstand the error

At least in my experience

Debugger helps a lot

But having this caught by the type system would have been even better

In my experience the time span between compile time and runtime is imperceptible

I've also not seen any vast distance between the source of an error and the actual underlying issue

if you want to have a good laugh, try this lecture https://www.youtube.com/watch?v=3wyd6J3yjcs

@johanatan: how do I reload code from the Scala console?

I'm not talking about the timespan which, yes is hardly noticeable, but about the conceptual difference. To me it's a big difference to know the code is wrong/right before you run it, or have it crash on runtime at a different place than where the error as introduced.

I've been programming in Ruby mostly (and recently in Clojure) and in my experience there's considerably more action-at-a-distance type of errors I have to back track to figure out why they happened than I encountered in static languages.

(it's kind of funny I've had more problems with it in Clojure than in Ruby, probably mostly due to regular syntax making it easier to inadvertently put things in function call position)

But that all might just be me being an awful programmer : V

@jaen: it's probably not you

@agile_geek, are there any specific features you need in HBase 1.1.1? I can bump: https://github.com/tolitius/cbass/blob/master/project.clj#L10 and retest. Just wanted to see what were you looking to get in 1.1.1 that is not in 1.0.0

@tolitius no nothing specific

@jaen: that is surprising to me-- seems like monkey patch etc is further off the beaten path in Clojure and is even less accepted than macros which are advised to be last resort

I suppose there is a time and place for everything but in my experience, those places are very few and far between

I think it all comes down to how you are using the language-- and with immutability baked in, it's definitely harder to shoot yourself in Clojure than other dyn langs

Dunno, considering Ruby is mutable to the max and Clojure is immutable I expected to have less problems in Clojure and was surprised how much problems I've had. I basically put off learning Clojure in the large until Cursive got proper debugger support because it was too annoying for me otherwise.

@agile_geek, upped to 1.1.1: https://github.com/tolitius/cbass/blob/master/project.clj#L10 it's in 0.1.4-SNAPSHOT :https://clojars.org/cbass/versions/0.1.4-SNAPSHOT let me know if it works for you