This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (2)
- # beginners (22)
- # boot (223)
- # cider (161)
- # cljs-dev (19)
- # cljsrn (4)
- # clojure (186)
- # clojure-austin (6)
- # clojure-beijing (1)
- # clojure-boston (3)
- # clojure-china (1)
- # clojure-czech (1)
- # clojure-france (1)
- # clojure-greece (10)
- # clojure-russia (17)
- # clojure-uk (154)
- # clojurebridge (3)
- # clojurescript (82)
- # component (12)
- # cursive (12)
- # datomic (71)
- # dirac (3)
- # editors (2)
- # emacs (29)
- # flambo (31)
- # hoplon (21)
- # immutant (11)
- # instaparse (17)
- # jobs (2)
- # jobs-discuss (2)
- # jobs-rus (1)
- # lein-figwheel (12)
- # leiningen (2)
- # off-topic (44)
- # om (78)
- # onyx (38)
- # parinfer (1)
- # re-frame (34)
- # reagent (32)
- # spacemacs (56)
- # untangled (74)
- # vim (12)
- # yada (2)
@agile_geek: I first came into contact with Clojure 5 years ago… and still learning new things!!!
thinks there's hope for me yet
@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)
i also think that once i've drunk more coffee i'll stop saying bloody obvious things
Interesting recent blog from @martintrojer who is obviously not enjoying Clojure anymore
follow my journey on the ‘beyond clojure’ series on my blog
first chapter here; http://martintrojer.github.io/beyond-clojure/2016/04/21/beyond-clojure-haskell
(Looking at Haskell)
@martintrojer: Interesting. Both Clojure and Haskell are a bit moot for me (stuck in Java 1.5 land!)
I have a number more chapters in the pipe
both frontend / backend
I look forward to them.
I found Matthias' talk about types at Clojure West interesting. He seemed to suggest no language has got it quite right yet.
Totally agree, everything’s a compromise.
We (as an industry) are far off ‘the perfect language to end all languages’.
I don't believe such a beast will ever exist
Unless it's an AI programmer
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
@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
more to come
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.
In the frontend space I think we have an option that is clearly better than CLJS.
And types are especially needed in UI code.
^^ Disclaimer; IMHO, your mileage may vary.
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
Currently working in a 30+k clj codebase.
And 10+k CLJS
both imploding under their own weight
CLJS particularly bad, but UI programming is shockingly hard
Reagent, very strictly following the petrol pattern. https://github.com/krisajenkins/petrol
I never go under 50% for any clojure code
i’m trying to compare where you are to my own experiences with 3 large JS/React apps
PropTypes don’t think so
not sure if reagent uses them somehow
they’re runtime type checks per-component, I don’t think it does unless you do something specifically to get that
there’s lots of schema checks to
ours were mostly on the component side, worked well as component prop documentation
the data side we tried to keep pretty small & flat, and rely on factory functions to keep shapes consistent
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
i haven’t worked with a big clj(s) codebase since mailonline times (so more than 1.5 years now)
where are you now @benedek ?
fight that to the bitter end
gonna be hard to give up the value of having a unified tool chain from front to back end. I value that a lot.
you mean not having to switch languages, or being able to run a single command that does everything?
interesting point @otfrom. although there is no such thing as single lang shop anymore at least as much as i saw here in ldn
are you doing that node via cljs @glenjamin ? 😉
well not sure @martintrojer would approve in the context of his arguments in his blogpost 😄
I have either not experienced those problems, or have internalised them enough to not worry about them
certainly there are types of changes I avoid making in dynamic languages because of the inherent difficulties
We have some node stuff, tiny
but I think i’m fairly aware of those limitations up-front, so i’ll make architectural choices to try and mitigate
Cljs re write in the books tho
interestingly, I think lots of those clojure dynamic language problems will generalise to microservices
although maybe we spend more time designing interfaces when we know it’ll go over a network
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
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
and that is probably what will enable people to do really wacky things like lisp flavoured erlang 😛
though the particular monolith will probably live on (hopefully shrunk) for quite some time
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
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
I'm not sure I understand what you mean by https://clojurians.slack.com/archives/clojure-uk/p1461258975000198
I am loving having to deal with WSDL ATM....not!
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
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.
Oh they're not dead my current clients still writing soap services!
so validating and “documenting" your data with type for your interfaces does not mean you have generate code tho, right?
(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)
@otfrom I agree about modelling with types. Maybe this is going concrete prematurely?
I'm partly complaining about Animal -> Dog, Animal -> Cat, Animal -> Person, Person -> Teacher, Person -> Student
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
racket is a great language, haskell has hardly anything to do with typed racket though
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
@otfrom: if you're interested in Haskell, maybe check out http://haskellbook.com/
I've heard good things about it