Clojurians Log v2

well, always hard to compare ofc.

The first post in my blog series sums up how I feel.

I tend to work in more and more complex clojure apps, 30k+

not easily "breaking-uppable” into ‘microservices'

as the code grows, team grows, time elapses, Clojure stops being your friend.

Thats exactly the reason I always wanted to code clojure in a professional setting in a larger team, to figure out how it behaves there and where the pitfalls are.

the mitigations are the same as for any dynlang. lots and lots of tests

50% is an absolute minimum, higher better

one problem with static typing in a team I'm currently seeing is that they give a sense of 'set in stone' while in practice most code is temporary and the types are not given as much thought as the reader expected

maybe this is a problem with all code. as a I reader I'm set on the wrong foot because I'm trapped in the initial design

@borkdude: what language is that?

@martintrojer: does it matter?

in my experience, absolutely

@martintrojer: This is Scala, but I have had the same experience in Java

Classes give me the same feeling, that I should not change them

I’m not even considering C-style typed languages

Java, C# falls squarely into that bucket

Scala also, if you use it like Java++

Hindley Milner type inference is a minimal requirement

Professional experience is F# and I (and the team) found more liberating than Boo (the dynlang we had some code in)

I’ve never refactored with such confidence and speed.

Clojure is the only language where I really felt productive and fast, even in a team. I don't have this feeling with Scala now, yet.

However, all larger projects become slower, despite the language of choice.

IMHO, dynlangs scales terribly

@martintrojer: I wonder how they deal with this in Boeing and Walmart, where they do have big teams working on 30k lines of Clojure

Metric ton of tests I'd imagine

I see the benefit of being able to refactor more easily when you change some case class, record, or what have you. But I'm not sure if the sacrifice of flexibility and REPL are worth the static typing. I'm just going to look at results in practice, not theory.

All in all I think one can conclude that neither dynlang nor HM-typing provides benefits that are so obvious that everybody agrees on it, like the benefits that garbage collection for instance, gave us.

@sveri: I think that is correct

@sveri: I think what you can also say is that no language can be evaluated without humans. It's the human-language combination that makes it work. It's probably also why it's so hard to study in practice.

@borkdude: Agreed, OTOH if I would have to implement a language that could be used by a computer, it would probably be a typed one, but this is just more of a feeling that I have here.

@sveri: it would probably easier for AI to discover patterns in typed languages, for example, just try all functions from String -> Int and Int -> Boolean and see if you can come up with a function from String -> Boolean that does the right thing

@sveri: On the other hand, good enough AI could infer the types in a dynamically typed language. On the bare metal, nothing is typed.

Types are mostly a compile time illusion.

@borkdude: Then the question boils down to, can the "AI" infer behavior / rules / types from machine code?

I don't know

probably not, so it needs a language it can use

and the more strict the language is, the easier it is to implement the "AI", I think

we are on a side path, AI is not the point

I think good AI could infer types from dyn. code. But it's not the point.

http://www.cs.umd.edu/~jfoster/papers/popl11.pdf

Maybe the machines force us humans to use more types, against our own will (ok, entering sci-fi mode)

I saw a documentary once where one philosopher thought that the internet is it's own intelligence that is using us humans, not the other way around

This reminds me of capitalism itself where the goal is to expand and corporations / humans fullfill the capitalisms will...

Gerhard Gundermann once wrote a song about capitalism where he talks about consumption and finally concludes that it would be better if it was not human beings drinking beer at the bar, but instead why not have machines drinking the beer and consume them themselves. Also he asked about the proportions of car driving, if you think in terms of weight is it us, that drive the cars or is it the cars, driving us...

And to draw the circle...if google can predict what you will do in the next days and then shows ads to you, helping you achieve your goal (in whatever way). Was it still you that decided your next move? Or was it googles prediction?

I saw a documentary about the Amish recently. They seem to be quite happy without all this technology.

The documentary was also about Google and/or Facebook rolling out global internet

in for example India

"types are mostly a compile time illusion" what?

@arrdem: at least on the JVM right?

No absolutely not. Unless you're referring to erasure...

I was thinking about type erasure, correct

That's hardly true tho. Erasure is an implementation detail of parameterized types. All the type information is preserved at compile and runtime, but the compiler emits checkcasts to make that happen.

Nowhere near the same as Clojure or python "well it's a map and I have no idea because everything else is a map too"

Thanks for correcting me. I should think more about it 🙂

Not that Java's type system isn't crippled and bad, but yeah.

IMO @martintrojer is absolutely correct here. Types are absolutely essential for 1) optimizing programs and 2) reasoning statically about unknown code. HM and dependently typed languages are the future.

My experience with Clojure has been that picking up someone else's code is on average miserable because invariably the "schema" (type) is either undocumented or incompletely documented.

I agree that typed is better for compiler optimisations and for static reasoning.

And in those rare cases where someone has taken the time to use assertions or schema or otherwise check their datastructures in an understandable way, you've just approximated HM badly with no guarantees.

Half my setup time on a new project is figuring out what the existing libraries expect to consume and what record structures I want to use myself.

Read: types

The problem of Scala I'm currently dealing with has probably got to do with: hey, the language + JVM offers all these cool features, let's use them all. If there was something simple like Clojure with all the benefits of static typing, with a community like Clojure, I'd be very interested.

Yeah. That's super shitty and what turned me off about scala the two times I've had to use it so far.

It's not like I understand other people's Scala code better than Clojure. It's the other way around here.

I mean, just to hammer the point home... Go read Wadler's "propositions as types", and realize that for type broadly considered you can (try to) statically prove any condition you'd dynamically assert about your data. You just sometimes can't prove and have to emit dynamic checks ala checkcast above, but even then the possible failure modes are explicit and manageable.

I personally would love to see someone put together a precondition predicate based type system for Clojure. That would be super interesting.

Alright I'm done :P

We haven proven all these nice properties about our code. But does it work? 😉

The daily code I'm dealing with is not so interesting in terms of "properties", like sorting algorithms, etc.

Property here for me means amazing mundane stuff like "is it a positive integer"

Does this validation regex match

Etc ad nauseum

Not trying to talk about proofs of program correctness

@arrdem: how can you test it before the run time

without moving your entire runtime in the compile time 😉

You can't. You get better warnings up front that what you've codified doesn't make any sense and then you have a repl that's no worse than ours. (thinking of Haskell explicitly here)

Testing still matters, you just have sanity properties for free rather than having to guard them everywhere by hand.

I mean... Clojure's error messages and dynlang error debugging are what you get for gigo applied to data.

true, but the feedback you get is extremely fast in a runtime REPL

Far better IMO to try as hard as possible to be strict about data up front and minimize the set of failure modes a programmer can experience or has to code.

Being strict about data up front vs. exploring and finding out what this data should be shaped like

The promise of HM is that you still can do that thanks to inference tho.

If you want to try another representation you can, it's just infers to a different type which is absolutely correct.

Haskell probably gives a much better experience than other typed FP languages out there now, maybe F# being an exception

Besides my experience has been that most "types" or "shapes" people ultimately wind up with map directly onto a simple record type so...

Something in between Clojure and Haskell that doesn't suck?

Working on that :P

Love ambrose but core typed sucks. Schema doesn't try for real interprocedural types. Jaunt will eventually support at a minimum Java's types in full.

interprocedural types - what's that?

yes, core.typed has never reached production quality

he's still working on it I think

My bullshit term. Just means inference and lifting nested contracts to the interface level.

(my god, Slack is slow even on my Macbook Pro)

borkdude: run moar webkit!

Ehehe

borkdude: i use weechat and the irc gateways

Alright. I should get out of bed and do things rather than rant all day.

i have 3 'teams' and...45 channels

memory impact is effectively zilch