This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-03-24
Channels
- # admin-announcements (1)
- # aws (3)
- # beginners (52)
- # boot (150)
- # braid-chat (1)
- # braveandtrue (5)
- # bristol-clojurians (2)
- # cider (21)
- # cljs-dev (1)
- # cljsfiddle (1)
- # cljsjs (5)
- # cljsrn (4)
- # clojars (3)
- # clojure (236)
- # clojure-berlin (2)
- # clojure-czech (1)
- # clojure-madison (1)
- # clojure-russia (164)
- # clojure-sdn (1)
- # clojure-sg (2)
- # clojure-uk (64)
- # clojurescript (149)
- # core-async (31)
- # cursive (33)
- # datomic (2)
- # devcards (5)
- # funcool (3)
- # hoplon (142)
- # immutant (27)
- # juxt (7)
- # lein-figwheel (6)
- # liberator (6)
- # off-topic (4)
- # om (46)
- # onyx (26)
- # parinfer (5)
- # perun (56)
- # proton (6)
- # re-frame (19)
- # reagent (1)
- # remote-jobs (12)
- # ring-swagger (17)
- # slack-help (2)
- # spacemacs (11)
- # specter (1)
- # untangled (11)
- # yada (3)
måning
yeah, tends to end up in a debate what ‘refactoring' means. That is not my point however.
if I understand your point, we are having these kind of discussions these days. As the codebase evolves is not the size of it that is difficult to control (although it is definitely an effort) it’s the turn-over of people with different design ideas that creates the problem
assumptions on data structures and types (when they are implicit like in Clojure) is difficult to express in code
mind you, even if I’m the sole developer. I still manages to completely hose myself on a regular basis when enough time elapses (in this case CLJS 6 months, 10k lines)
I rely on my tests, my (worsening memory) and pure luck for code confidence.
… don’t get me started on components. Its a major sore point for me.
thank god
where a component is a well defined interface for a portion of code, and ideally the component abstraction is strong enough to survive the lifetime of the project
Having experienced both F# and Clj in a professional setting for non trivial projects. I have to say, the day-to-day working with the code, its a step change in productivity.
(and I think you can guess by implication who comes on top)
Just having the compiler sanity check my assumptions and telling me; ‘here, here, here and here’ is fantastic.
and, in my experience it scales much better for code/team size
keeping modules small and separated by clear interfaces (call them small-services is compensating for that uncertainty. Bigger monoliths definitely suffers this more
My current thinking is that if you don’t do schema.core/defn on EVERYTHING on clojure you are setting you up for massive pain in the future.
performance be damned
that was me 1 year ago (what I’m doing)
not good enough
so following your reasoning: is clojure with schemas all way through still better than just starting haskell?
the static guarantees you get with haskell are still way better than clojure with schemas, and you get them before you run anything
my current bad experiences is in the front end setting. And I’d say you’d be much better off with Elm than CLJS (with or without scehma everywhere)
Elm is better on pretty much every thing from tooling, docs, error messages to the quality of the code you produce.
Interestingly I’ve mostly worked on JavaScript React projects recently, and haven’t really had these problem
The backend (Clj vs haskell) is not as clear-cut (atleast to me)
although the common software architecture patterns in JS react-land involve contracts for both data and component boundaries
I can’t tell you how refreshing it is to stop all the advanced compilation / react nonsense in elm.
Morning
labelling the former nonsense because you prefer the latter seems a bit of an overreach
agreed
weirdly my biggest concern is it’s lack of polymorphism, and the weak type system compared to Purescript
a bit sore about it, wasted way to many hours waiting for advanced compilation
I figure if I’m going to use types, I might as well get the most powerful - but the error message stuff from Elm is definitely appealing
Elm is the complete package, tooling, docs ready to be used. Purescript is in construction (very much like CLJS)
that why I’d recommend it wholeheartedly over CLJS.
So, it's a bit of a trade-off (as always) and dependent on the project/environment. It's good to know that you can start fast, get to the MVP and stay away from a formal up-front definition of schemas/types when you can. Create your service as small as possible. Later on, convert/rewrite the most business related ones to stronger types. How about that?
is this the gradual types argument?
(Typescript and friends)
The JS version of React has this declarative Props validation stuff, which I find really effective in practice: http://facebook.github.io/react/docs/reusable-components.html#prop-validation
there’s practically no static checking, but defining contracts to state your assumptions at component boundaries is a good step imo
martintrojer: not against, but not related I think. Gradual typing would be an option if you already decided to start “strictly” typed on some part but don’t want necessarily the rest to be infected.
@reborg: I think you can do both (at the same time)… You’ll enjoy this talk; https://www.youtube.com/watch?v=oYk8CKH7OhE
Elm is great. I think parametric polymorphism with no ad hoc polymorphisms is better trade off than the other way round. And you can still manually plumb functions or dictionaries of functions, use sum types if you need too – a bit verbose, but type checked so you won’t get it wrong.
thomas: not really what you asked, but i’d strongly recommend writing to stdout and having something outside your process worry about log files / rotation (if you can)
although I think https://github.com/ptaoussanis/timbre#file-appender is how you do files
@glenjamin: I have added that, but there is something missing. And I don’t really want to write to stdout as that is also my user interface., but thank you for the link