Fork me on GitHub
#clojure-uk
<
2016-03-24
>
reborg09:03:08

martintrojer: refactoring bugs? I have a different definition of refactoring

martintrojer09:03:09

yeah, tends to end up in a debate what ‘refactoring' means. That is not my point however.

reborg09:03:08

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

reborg09:03:43

assumptions on data structures and types (when they are implicit like in Clojure) is difficult to express in code

martintrojer09:03:06

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)

glenjamin09:03:52

IME apps which have some strong concept of components do well in this regard

martintrojer10:03:02

I rely on my tests, my (worsening memory) and pure luck for code confidence.

martintrojer10:03:17

… don’t get me started on components. Its a major sore point for me.

glenjamin10:03:30

not Stuart Sierra components

glenjamin10:03:34

the more general concept

glenjamin10:03:46

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

glenjamin10:03:03

then I can usually change individual components with high confidence

martintrojer10:03:38

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.

martintrojer10:03:56

(and I think you can guess by implication who comes on top)

martintrojer10:03:30

Just having the compiler sanity check my assumptions and telling me; ‘here, here, here and here’ is fantastic.

martintrojer10:03:51

and, in my experience it scales much better for code/team size

reborg10:03:02

keeping modules small and separated by clear interfaces (call them small-services simple_smile is compensating for that uncertainty. Bigger monoliths definitely suffers this more

reborg10:03:33

hence the need for components/interfaces if they don’t talk REST or other transports

martintrojer10:03:20

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.

martintrojer10:03:04

performance be damned

reborg10:03:27

wouldn’t schema at the boundaries achieve 80% of the good effects?

reborg10:03:37

sounds like a reasonable trade-off

martintrojer10:03:40

that was me 1 year ago (what I’m doing)

martintrojer10:03:44

not good enough

reborg10:03:08

so following your reasoning: is clojure with schemas all way through still better than just starting haskell?

mccraigmccraig10:03:53

the static guarantees you get with haskell are still way better than clojure with schemas, and you get them before you run anything

martintrojer10:03:05

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)

martintrojer10:03:52

Elm is better on pretty much every thing from tooling, docs, error messages to the quality of the code you produce.

glenjamin10:03:08

Interestingly I’ve mostly worked on JavaScript React projects recently, and haven’t really had these problem

martintrojer10:03:08

The backend (Clj vs haskell) is not as clear-cut (atleast to me)

glenjamin10:03:34

although the common software architecture patterns in JS react-land involve contracts for both data and component boundaries

glenjamin10:03:48

eg “flux stores” and “PropTypes"

martintrojer10:03:20

I can’t tell you how refreshing it is to stop all the advanced compilation / react nonsense in elm.

glenjamin10:03:59

you’re replacing a JS-JS compiler with an (admittedly better) JS-elm compiler

glenjamin10:03:20

labelling the former nonsense because you prefer the latter seems a bit of an overreach

glenjamin10:03:50

I really must carve out some time to do some Elm

glenjamin10:03:12

weirdly my biggest concern is it’s lack of polymorphism, and the weak type system compared to Purescript

martintrojer10:03:21

a bit sore about it, wasted way to many hours waiting for advanced compilation

glenjamin10:03:46

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

glenjamin10:03:06

and the structural typing stuff rather than nominal appeals to me as well

martintrojer10:03:14

Elm is the complete package, tooling, docs ready to be used. Purescript is in construction (very much like CLJS)

martintrojer10:03:53

that why I’d recommend it wholeheartedly over CLJS.

reborg10:03:18

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?

martintrojer10:03:08

is this the gradual types argument?

martintrojer10:03:17

(Typescript and friends)

glenjamin10:03:49

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

glenjamin10:03:25

there’s practically no static checking, but defining contracts to state your assumptions at component boundaries is a good step imo

thomas10:03:37

hi, does anyone know how to get Timbre to log to a file instead of stdout?

thomas10:03:45

the docs aren’t that clear

reborg10:03:12

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.

martintrojer10:03:59

@reborg: I think you can do both (at the same time)… You’ll enjoy this talk; https://www.youtube.com/watch?v=oYk8CKH7OhE

reborg10:03:22

will watch thanks

minimal12:03:42

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.

glenjamin12:03:58

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)

thomas13:03:02

@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