This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # 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)
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)
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.
Just having the compiler sanity check my assumptions and telling me; ‘here, here, here and here’ is fantastic.
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.
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.
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.
labelling the former nonsense because you prefer the latter seems a bit of an overreach
weirdly my biggest concern is it’s lack of polymorphism, and the weak type system compared to Purescript
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)
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?
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.
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