Fork me on GitHub
#other-languages
<
2016-05-17
>
martintrojer06:05:08

well, always hard to compare ofc.

martintrojer06:05:43

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

martintrojer06:05:04

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

martintrojer06:05:28

not easily "breaking-uppable” into ‘microservices'

martintrojer06:05:58

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

sveri07:05:33

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.

martintrojer09:05:37

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

martintrojer09:05:16

50% is an absolute minimum, higher better

borkdude09:05:59

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

borkdude09:05:44

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

martintrojer09:05:59

@borkdude: what language is that?

martintrojer09:05:15

in my experience, absolutely

borkdude09:05:27

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

borkdude09:05:40

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

martintrojer09:05:56

I’m not even considering C-style typed languages

martintrojer09:05:05

Java, C# falls squarely into that bucket

martintrojer09:05:18

Scala also, if you use it like Java++

martintrojer09:05:43

Hindley Milner type inference is a minimal requirement

martintrojer09:05:22

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

martintrojer09:05:33

I’ve never refactored with such confidence and speed.

borkdude09:05:17

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.

borkdude09:05:07

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

martintrojer09:05:01

IMHO, dynlangs scales terribly

borkdude09:05:27

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

martintrojer09:05:47

Metric ton of tests I'd imagine

borkdude09:05:00

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.

sveri09:05:44

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.

borkdude09:05:51

@sveri: I think that is correct

borkdude09:05:28

@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.

sveri09:05:47

@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.

borkdude09:05:04

@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

borkdude09:05:43

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

borkdude09:05:50

Types are mostly a compile time illusion.

sveri09:05:29

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

borkdude09:05:50

I don't know

sveri09:05:29

probably not, so it needs a language it can use

sveri09:05:52

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

borkdude09:05:38

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

borkdude09:05:04

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

borkdude10:05:18

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

borkdude10:05:22

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

sveri10:05:38

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

sveri11:05:10

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...

sveri11:05:38

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?

borkdude11:05:15

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

borkdude11:05:46

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

borkdude11:05:49

in for example India

arrdem15:05:38

"types are mostly a compile time illusion" what?

borkdude15:05:24

@arrdem: at least on the JVM right?

arrdem15:05:50

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

borkdude15:05:04

I was thinking about type erasure, correct

arrdem15:05:29

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.

arrdem15:05:03

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"

borkdude15:05:25

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

arrdem15:05:37

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

arrdem15:05:36

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.

arrdem15:05:58

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.

borkdude15:05:00

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

arrdem15:05:13

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.

arrdem15:05:59

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.

arrdem15:05:08

Read: types

borkdude15:05:04

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.

arrdem15:05:56

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

borkdude15:05:01

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

arrdem15:05:50

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.

arrdem15:05:35

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

arrdem15:05:11

Alright I'm done :P

borkdude15:05:37

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

borkdude15:05:35

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

arrdem15:05:39

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

arrdem15:05:51

Does this validation regex match

arrdem15:05:00

Etc ad nauseum

arrdem15:05:23

Not trying to talk about proofs of program correctness

borkdude15:05:41

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

borkdude15:05:01

without moving your entire runtime in the compile time 😉

arrdem15:05:17

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)

arrdem15:05:59

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

arrdem15:05:53

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

borkdude15:05:49

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

arrdem15:05:04

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.

borkdude15:05:07

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

arrdem15:05:46

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

arrdem15:05:21

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

borkdude15:05:14

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

arrdem15:05:58

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

borkdude15:05:58

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

arrdem15:05:08

Working on that :P

arrdem15:05:17

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.

borkdude15:05:35

interprocedural types - what's that?

borkdude15:05:54

yes, core.typed has never reached production quality

borkdude15:05:12

he's still working on it I think

arrdem15:05:20

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

borkdude15:05:26

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

bvulpes15:05:56

borkdude: run moar webkit!

bvulpes15:05:15

borkdude: i use weechat and the irc gateways

arrdem15:05:21

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

bvulpes15:05:29

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

bvulpes15:05:37

memory impact is effectively zilch