Fork me on GitHub
#clojure-uk
<
2016-04-21
>
thomas08:04:46

@agile_geek: I first came into contact with Clojure 5 years ago… and still learning new things!!!

thomas08:04:59

but most importantly…. still enjoying it!!!

yogidevbear08:04:27

thinks there's hope for me yet

mccraigmccraig08:04:05

@agile_geek @thomas i think there is a catch22 - the only way to learn deeply is by doing a lot, but until you learn deeply it's hard to get someone to pay you to do a lot (or they will want to pay you less)

mccraigmccraig08:04:46

i also think that once i've drunk more coffee i'll stop saying bloody obvious things

agile_geek09:04:35

Interesting recent blog from @martintrojer who is obviously not enjoying Clojure anymore

martintrojer09:04:42

follow my journey on the ‘beyond clojure’ series on my blog

martintrojer09:04:56

(Looking at Haskell)

agile_geek09:04:39

@martintrojer: Interesting. Both Clojure and Haskell are a bit moot for me (stuck in Java 1.5 land!)

martintrojer09:04:56

I have a number more chapters in the pipe

martintrojer09:04:11

both frontend / backend

agile_geek09:04:09

I look forward to them.

agile_geek09:04:02

I found Matthias' talk about types at Clojure West interesting. He seemed to suggest no language has got it quite right yet.

martintrojer09:04:32

Totally agree, everything’s a compromise.

martintrojer09:04:04

We (as an industry) are far off ‘the perfect language to end all languages’.

agile_geek09:04:17

I don't believe such a beast will ever exist

agile_geek09:04:19

Unless it's an AI programmer

henrygarner11:04:07

Afternoon, folks

yogidevbear12:04:43

Completely not related to Clojure, but I just skimmed over a video of a guy demoing how to build a blog site with haskell and yesod. Was really interesting. https://www.youtube.com/watch?v=SadfV-qbVg8

benedek15:04:09

@martintrojer: really enjoyed reading the opening piece (have not finished the haskell one yet). I am still enjoying using a dynamic lang so not necessarily agree with everything but also looking around for an other lang nowadays. thx for writing these

martintrojer15:04:31

btw, I still use clojure in my day job (and will continue to do for some time). Its a very reasonable compromise in the backend.

martintrojer15:04:05

In the frontend space I think we have an option that is clearly better than CLJS.

martintrojer15:04:26

And types are especially needed in UI code.

martintrojer15:04:32

^^ Disclaimer; IMHO, your mileage may vary.

benedek15:04:22

fair enough. tbh I do a bit of cljs/reagent but the app is really small. that said also the backend stuff I am doing nowadays in clojure tend to be small or micro (especially nowadays experimenting with coding AWS lambdas in clojure). by definition these can’t have the bloating related problems you discuss in the first post. so yeah I guess the types/sizes etc of the clj applications you work with matter with these things

benedek15:04:13

but still very valid points you raise

martintrojer15:04:45

Currently working in a 30+k clj codebase.

martintrojer15:04:10

both imploding under their own weight

martintrojer15:04:40

CLJS particularly bad, but UI programming is shockingly hard

glenjamin15:04:51

is that an Om app martintrojer ?

martintrojer15:04:35

Reagent, very strictly following the petrol pattern. https://github.com/krisajenkins/petrol

martintrojer15:04:54

I never go under 50% for any clojure code

glenjamin15:04:46

do you have anything like React PropTypes?

glenjamin15:04:02

i’m trying to compare where you are to my own experiences with 3 large JS/React apps

martintrojer15:04:41

PropTypes don’t think so

martintrojer15:04:06

not sure if reagent uses them somehow

glenjamin15:04:34

they’re runtime type checks per-component, I don’t think it does unless you do something specifically to get that

martintrojer15:04:55

there’s lots of schema checks to

glenjamin15:04:09

mostly in the data side, or the component side?

glenjamin15:04:40

ours were mostly on the component side, worked well as component prop documentation

glenjamin15:04:12

the data side we tried to keep pretty small & flat, and rely on factory functions to keep shapes consistent

glenjamin15:04:58

I moved on in December, I know they’ve had to change large parts of the UI since then, I’ll have to see how they got on

benedek15:04:02

i haven’t worked with a big clj(s) codebase since mailonline times (so more than 1.5 years now)

martintrojer16:04:22

where are you now @benedek ?

benedek16:04:04

backends are mostly clojure but they are small/micro mostly

benedek16:04:18

frotends are not (yet?! ;) ) cljs

martintrojer16:04:44

fight that to the bitter end

benedek16:04:32

haha. well they are ruby/vanilla js. not ideal either I guess… 😉

benedek16:04:13

well vanilla js is utterly wrong. i mean js all sorts

otfrom16:04:40

gonna be hard to give up the value of having a unified tool chain from front to back end. I value that a lot.

glenjamin16:04:23

you mean not having to switch languages, or being able to run a single command that does everything?

otfrom16:04:34

glenjamin: not having to switch languages

glenjamin16:04:56

i’ve been doing Node on the server for a while now, that’s a big win

otfrom17:04:00

and having that as a lingua franca for the whole team

glenjamin17:04:27

yeah, lots of nice overlapping network effects

otfrom17:04:28

so everyone can do front end, back end, infra set up, data science, big data

benedek17:04:11

interesting point @otfrom. although there is no such thing as single lang shop anymore at least as much as i saw here in ldn

benedek17:04:51

are you doing that node via cljs @glenjamin ? 😉

glenjamin17:04:12

nope, just JS back and front 😞

benedek17:04:46

well not sure @martintrojer would approve in the context of his arguments in his blogpost 😄

otfrom17:04:00

benedek: you've not visited here then. 😉

otfrom17:04:19

(though I'm willing to be persuaded, but I have to feel the trade offs are worth it)

otfrom17:04:43

and I'm guessing that opensensors is all clj/cljs atm martintrojer ?

glenjamin17:04:46

I have either not experienced those problems, or have internalised them enough to not worry about them

benedek17:04:56

an exclusive clojure shop. impressive

glenjamin17:04:24

certainly there are types of changes I avoid making in dynamic languages because of the inherent difficulties

otfrom17:04:25

well, there is some shell, some sql and the odd bit of java or javascript for interop

martintrojer17:04:50

We have some node stuff, tiny

glenjamin17:04:58

but I think i’m fairly aware of those limitations up-front, so i’ll make architectural choices to try and mitigate

benedek17:04:05

but i guess you are more on the small/micro services side as well otform

martintrojer17:04:15

Cljs re write in the books tho

glenjamin17:04:35

interestingly, I think lots of those clojure dynamic language problems will generalise to microservices

benedek17:04:51

like glenjamin?

glenjamin17:04:59

although maybe we spend more time designing interfaces when we know it’ll go over a network

glenjamin17:04:04

refactoring across boundaries

glenjamin17:04:27

or more accurately, making changes that span across boundaries

otfrom17:04:34

benedek: we have a bit of a mix of micro and a big old monolith

otfrom17:04:58

though even the monoliths look a bit micro underneath.

benedek17:04:14

hm… that is a special case. we did a bunch of AWS lambdas working together on a certain problem lately and we just kept them in the same codebase, easy to deploy them in batch etc. i guess this is a very much used trick in the node/micro world too

glenjamin17:04:19

i’ve done a project which was node that had ~20 individual apps in one repo

otfrom17:04:46

one of the monoliths is... more monolithic than the other

otfrom17:04:57

(you can see the debris for most of it in our github if you are keen)

glenjamin17:04:59

worked fairly well, but we still had to cater for version n-1/n+1 in data changes because atomic deployments aren’t a thing without downtime

otfrom17:04:14

we're going more down a microservices for the stuff we are doing now

otfrom17:04:34

and that is probably what will enable people to do really wacky things like lisp flavoured erlang 😛

otfrom17:04:44

or indeed typed racket

benedek17:04:59

it seems otform you are moving away from that monolith based on what you are saying

otfrom17:04:05

though the only lisps I've ever gotten proper work done in are emacs lisp and clojure

otfrom17:04:20

benedek: yes we are moving away from a monolith

otfrom17:04:38

though the particular monolith will probably live on (hopefully shrunk) for quite some time

benedek17:04:15

so re types i guess i am just repeating the well known but there is deffo a stronger argument for them on the interface level than internally if you are in the small/micro world

otfrom17:04:22

what we are writing now isn't a replacement for it though, but we've learned from what we built earlier obviously and are using what we are learning now to go back and improve the old stuff

benedek17:04:54

nobody paying for rewrites 😉

otfrom17:04:18

not for rewrites, but for new features that require refactorings first

benedek17:04:42

haha yes, that makes sense

otfrom17:04:43

and for things that reduce support costs

otfrom17:04:17

you aren't advocating UDDI and WSDL are you?

benedek17:04:49

haha, fair point. I hope i don’t but it seems i do 😉

agile_geek17:04:17

I am loving having to deal with WSDL ATM....not!

agile_geek17:04:33

Personally, 2 things I miss types for, documenting the shape of data expected/returned from fns and protection during refactoring... Case in point raised an issue in yada at weekend caused by the latter

otfrom17:04:48

UDDI killed SOAP as the Interface Repo Service (can't remember the proper name) killed CORBA before it. All distributed systems seem to die on the altar of type definition and code generation based on that.

agile_geek17:04:47

Oh they're not dead my current clients still writing soap services!

otfrom17:04:58

(and I've worked with CORBA, DCE, xmlrpc, SOAP and plain old REST (in that order))

otfrom17:04:12

agile_geek: I think that means your clients are zombies

benedek17:04:13

so validating and “documenting" your data with type for your interfaces does not mean you have generate code tho, right?

otfrom17:04:32

what do you mean by "validating"

otfrom17:04:55

I've used dtd's, xsds and relax schemas too

benedek17:04:10

if you have types you can also validate and decide what to do with invalid stuff

otfrom17:04:19

and know the difference between well formed and valid. 😛

benedek17:04:43

haha xsd-s indeed!

otfrom17:04:12

(tho most of my thinking around types lately hasn't been that types are bad, but that people are really bad at using them when they try to model the real world)

benedek17:04:36

yeah that is the bit i don’t miss from my java years

otfrom17:04:43

or rather the non-mathematical parts of the real world

otfrom17:04:19

I think too many people are damaged by Plato and his Forms

agile_geek17:04:13

@otfrom I agree about modelling with types. Maybe this is going concrete prematurely?

otfrom17:04:10

agile_geek: in what way do you mean?

otfrom17:04:53

I'm partly complaining about Animal -> Dog, Animal -> Cat, Animal -> Person, Person -> Teacher, Person -> Student

otfrom17:04:11

that seems endemic, that DDD people try to fix with bounded contexts

otfrom18:04:36

btw, haskell and erlang and the two langs on my list that I want to learn next, though I may learn erlang via lfe and haskell might be replaced (or supplemented by) typed racket

otfrom18:04:49

but my experience with scheme wasn't great

bronsa18:04:36

racket is a great language, haskell has hardly anything to do with typed racket though

otfrom18:04:14

bronsa: I understand (from the talk at clojure west mostly) that they are very different. I think it is more that I want to do some thinking about static typing and am looking for ways to do it

benedek18:04:05

which talk is that?

yogidevbear18:04:48

@otfrom: if you're interested in Haskell, maybe check out http://haskellbook.com/

yogidevbear18:04:01

I've heard good things about it

minimal18:04:03

Yeah it’s good, very thorough and good at drilling it in so you understand properly

glenjamin19:04:22

I don’t actually really hate SOAP all that much

glenjamin19:04:30

rarely used well though

glenjamin19:04:50

haskell-wise I get the feeling the cruft in the stdlib is holding it back

glenjamin19:04:18

similar-ish to how jvm clojure isn’t built on protocols

glenjamin19:04:19

according my haskell documentation browser there are 18 distinct last functions in the stdlib packages