This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (4)
- # beginners (21)
- # boot (37)
- # cider (41)
- # cljs-dev (3)
- # cljsjs (11)
- # cljsrn (4)
- # clojure (31)
- # clojure-austin (21)
- # clojure-belgium (30)
- # clojure-canada (1)
- # clojure-dusseldorf (2)
- # clojure-poland (7)
- # clojure-russia (20)
- # clojure-taiwan (1)
- # clojure-uk (45)
- # clojurescript (90)
- # core-async (8)
- # cursive (4)
- # data-science (1)
- # datomic (5)
- # dirac (6)
- # docker (1)
- # emacs (8)
- # hoplon (102)
- # ldnproclodo (2)
- # lein-figwheel (3)
- # leiningen (13)
- # off-topic (9)
- # om (54)
- # onyx (4)
- # other-languages (101)
- # pedestal (8)
- # planck (2)
- # protorepl (1)
- # re-frame (15)
- # reagent (13)
- # spacemacs (4)
- # untangled (126)
- # yada (4)
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.
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
Professional experience is F# and I (and the team) found more liberating than Boo (the dynlang we had some code in)
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.
@martintrojer: I wonder how they deal with this in Boeing and Walmart, where they do have big teams working on 30k lines of Clojure
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 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.
@borkdude: Then the question boils down to, can the "AI" infer behavior / rules / types from machine code?
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.
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"
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.
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.
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.
The daily code I'm dealing with is not so interesting in terms of "properties", like sorting algorithms, etc.
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.
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
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...
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.
My bullshit term. Just means inference and lifting nested contracts to the interface level.