This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-08-22
Channels
- # admin-announcements (4)
- # bangalore-clj (1)
- # beginners (28)
- # boot (16)
- # clara (4)
- # cljs-dev (28)
- # cljsrn (63)
- # clojure (136)
- # clojure-berlin (7)
- # clojure-gamedev (1)
- # clojure-nl (4)
- # clojure-russia (47)
- # clojure-sg (8)
- # clojure-spec (39)
- # clojure-uk (132)
- # clojurescript (66)
- # clojurex (5)
- # clojutre (2)
- # code-reviews (14)
- # core-logic (1)
- # cursive (13)
- # datavis (1)
- # datomic (35)
- # dirac (1)
- # editors (1)
- # hoplon (46)
- # jobs (1)
- # lambdaisland (5)
- # lein-figwheel (1)
- # mount (10)
- # off-topic (3)
- # om (67)
- # onyx (54)
- # planck (7)
- # proton (15)
- # protorepl (1)
- # re-frame (174)
- # ring (4)
- # ring-swagger (3)
- # specter (14)
- # untangled (15)
morning… otfrom quite interesting discussion on twitter around spec/types… I think I have some sort of mental block when I think about going type-first designing an app. It remembers me of around 2000 when to develop Java apps I fired up ToghetherJ, modeled my domain and start changing the generated code.
Then it happened again with a Haskell project one year ago, with the impression of having to constantly chase type changes after the initial design to accommodate features. It is possibly this additional required effort that keeps in me in dynamic land
reborg: it is my punishment for not understanding that spec can do coercions the way plumatic/schema can ;-)
and I'm still trying to find the right trade offs for spec/typing in my practice (which I think is quite different from some others given my role)
otfrom same… attracted by the generative testing aspect of it but at the same time distracted by spec-ing all way down. Spec-Schema at the boundaries seems the healthier approach at the moment, especially because it overlaps with the effort to keep different teams in synch about design of interfaces, something that I need to do anyway (on paper at least).
reborg: from what I can tell you don't have to spec everything just the things you want/need to
and I like that the specs can be used for coercion and for generative testing. (the tip from seancorfield yesterday was great for that)
I’ve seen some discussion from the elm camp that one of the biggest benefits of the strong type systems is you don’t have to get the types right at the start
with dynamic, you’re often stuck with your bad decisions because the refactoring cost is high
I just think type systems are a drug that keeps luring people back to them… Wake up sheeples! Break free of your type chains!
@korny: that reminds me of http://lambda-diode.com/programming/monads-are-a-class-of-hard-drugs 😄
maybe also some form of https://en.wikipedia.org/wiki/Illusion_of_control. Not always of course, but I’ve thought that of some type obsessive behaviour
glenjamin: I think UIs are one of those places where types are designed up front more than others
there might be some discovery when using some apis, but designing the type is probably part of designing the form
glenjamin: most of my coding is going from String|JSON|Excel -> String|JSON|Excel and I end up discovering a lot about what is coerceable by experience rather than up front thought (as I usually don't control the input)
whearas when I'm designing a page, I have a good idea of what the inputs will be and what types they should be
Morning
I've found my perceptions of what a type is evolve over time and the only reason I might know that in UI would be because I don't do UI first. Even when I control the input and/or output my initial thoughts about the details usually evolve into something else. However, I frequently know what high level types I may have early in design. I've found the danger with thinking about types too early is more to do with the same danger as designing using noun analysis too early. The focus on structure before behaviour leads to misconceptions that sometime sour designs for years.
Just talked to an ex-colleague when being shown around after interview for a prospective client. He's a .NET dev cross trained to Scala but working with a Clojurian and they been doing Clojure Driven Development this afternoon. Implement in Clojure then translate to Scala!
@agile_geek that sounds like a rather painful process...
@agile_geek: an innovative process!
and also as quite a waste as well.. why build something that works, and then re-implement it. (regardless of language)
plan to write everything twice - you are going to anyway!
good point @mccraigmccraig
@thomas: they wouldn't be doing it if there wasn't value. I.e. they find it easier/faster to reason/explore problem in Clojure
your snippets are something of a mystery @otfrom
@mccraigmccraig I agree it's innovative.
also agree everything from @otfrom is a mystery 😉
@agile_geek: what's the reason for re-implementing in scala tho ?
@mccraigmccraig oh how naive to think that working in a large bureaucracy as a developer that you can just pick what language to implement in....oh bless
It's not on the list it's not getting in
@agile_geek: microservices! language is irrelevant!
Ah but they do
@mccraigmccraig aww you are thinking logically...bless
@thomas Java's not allowed either
I love that you think these dev's have a choice
but do they have a more interesting reason than "clojure's not on the list", or is that it ?
@mccraigmccraig I suspect it's no more than 'thou shalt write everything in Scala'. That's what I normally see.
The commandment comes from London as do a number of things the Newcastle centre have to conform to that they think are nonsense.
They were complaining about these constraints in my interview to me!
And I'm the one they're supposed to be interviewing!
@otfrom I seem to remember a .plist file being involved but can't remember what it's called
@otfrom: ~/.profile
or ~/.zshrc
etc
if you want it to work from an emacs inferior shell though you might have to jump through some more hoops... can't remember
@otfrom might have been something else
@agile_geek sounds like a great employer to me...
Been scanning the talk submissions so far for #clojurex they are all awesome. Need a few more, especially art/music ones but I think conf is shaping up to be really interesting.
@thomas same as every single employer I've ever worked for. Never had a choice of languages.
I didn't even get to choose as CTO!
Thou shalt do what the client asks....and be grateful!
What I find endearing about this conversation is that you think language choice is ever anything but political.
When I joined my current company (part-time contract in 2009, full-time contract in 2010, then FTE later that year), I got to introduce Scala and when that really wasn’t working out I switched us to Clojure… So some places let engineers make those choices!
@seancorfield why wasn’t scala working for you?
I don’t know how it is for bigger companies, but for startup my whole experience revolves around the “let’s use language that allows us to get lots of junior devs easily”...
@quentin: interesting to target jnr devs...cost?
in bigger companies the thought is more like : can any team across the world take over this project tomorrow.
@thomas Or can I get 100 X devs for $30 per day per head
@otfrom :thumbsup:
@seancorfield I'm not saying you can't influence smaller companies but it's not common in larger orgs
@thomas: we went through the 2.7 to 2.8 migration and it was unbelievably painful so we abandoned it rather than go through the 2.9 migration — but there were other reasons
We had a team used to dynamic languages and being able to edit-reload-debug — so Scala’s edit-compile-deploy-debug cycle was a pain, esp. with such a slow compiler.
And the compiler error messages were beyond incomprehensible for some of the team.
We also, as one of the first things we built, had an actor-heavy app… and the built-in actor library was very leaky… so we had to restart processes regularly.
not a good story… but I assume that things have improved in Scala land as people are using it in production.
@seancorfield: interesting about compiler error messages. I've been reading Java stack traces for 19 years and Clojure ones are hard for me to debug.
Thomas: I suspect ppl are now locked into a point version for the foreseeable future!
Being in a larger consultancy as a head of development for 2 years taught me that those companies think of developers like toasters or washing machines. I need 100 units of X developers by next month. Put in an order to head of dev to get them.
how many units are there in a whole X developer @agile_geek ?
do they blend ?
ah well @otfrom at least you got to practice your evil laugh
"I assume that things have improved in Scala land as people are using it in production” - ha!
I also went through scala pain back in 2011 or so - every version was “things will improve in the next release”. A very familiar refrain all over my career.
“J2EE is better now, it’s light-weight” particularly got repeated every 2 years for about 10 years.
ok, thank you for the update regarding Scala… I would have hoped the scala folks had improved on that, but maybe not
For me, the killer in scala was sbt - the worlds most horrible build tool, I remember reading the source and thinking “surely this will die under the weight of it’s own technical debt one day, and will be replaced with something better”.
"J2EE is light-weight .. compared to the black hole at the center of the galaxy"
"J2EE is light-weight ... in zero gravity environments"
I’d still use Scala over Java, if (and only if) I had a mature dev team who could define a good “Scala - the good parts” definition and stick to it. There’s some really nice language features in there - amidst the dross.
I did build kafka from source a few weeks ago… took over an hour and lots of fan spinning 😉
and J2EE is very special shall we say (can’t be to negative as my employer is one of the main vendors 😉 )
(sorry, got distracted by work) Yes, @thomas the actor issues got resolved as of Scala 2.10 I think? And the painful binary incompatibility issues around versions have improved (but still not gone away).
@agile_geek: The Clojure stack traces are just very very long, but they are at least linear. The Scala compiler error messages are sort of like clojure.spec
failure messages but on steroids 🙂 I think with practice you just get used to reading them… However, it was a big culture shock for some of my team...
I tried to do one of the online MOOCs based on Scala last year and it was just too painful after years of Clojure… Scala seems spiky and irritating compared to Clojure’s smoothness and flow...
@seancorfield: I've done two coursera MOOCs and had same experience
@mccraigmccraig: depends on the X!