Fork me on GitHub
#off-topic
<
2018-08-14
>
Empperi05:08:02

@emccue well, it's a piece (or few pieces) of a larger ecosystem built on top of kubernetes. Nothing really special, fullstack clojure (including css with garden), aleph, compojure-api, spec, postgres (this was the part that was most slowing us down, should have used something like datomic but that would have been too hard to push through considering that would have been something that would have affected stuff outside our containers)

Empperi05:08:19

re-frame on ui-side

Empperi05:08:01

I did write one thing which allowed us (or should I say I) very fast and I'm considering rewriting it into a full library during the fall and releasing it as opensource

Empperi06:08:00

oh and right, "what aspects of Clojure did help you out": - REPL driven development - Data orientation - Same language both on backend and frontend -> code sharing - Spec - Sensible approach in libraries which makes them not to be in way like they tend to be in most languages

Empperi06:08:58

Also it helps that I've been writing stuff to production with Clojure for six years. Not all the time been using Clojure, some Java, Scala, JavaScript, TypeScript etc in between but I would say that about half of my working time has been writing Clojure full-time

Empperi06:08:36

So definitely no time spent on learning stuff, just making stuff happen

henrik07:08:17

@niklas.collin I’m curious, as you’ve been using all those languages in production for this long, what are the biggest differences you see in long-term usage?

Empperi07:08:28

Right. Well, I would say that Clojure is NOT the sweet-spot for big monolithic systems. That's where static typing really starts to shine

Empperi07:08:04

But in today's world one tries to avoid big monolithic systems for several reasons so that kinda makes that a moot point

Empperi07:08:49

Java is actually a very good language especially after Java 8 and beyond. I personally highly prefer Java over Scala

Empperi07:08:38

Scala is overly complex language and it's full of unnecessary stuff which makes it just even more complex. Scala's philosophy is to minimize the amount of code you have to write. However, this is quite often done via syntatic sugar and one can write the exact same thing bytcode-wise in several different ways. Add to the fact that it is both functional and object oriented language, it doesn't have immutability by default but it has support for immutability so you can have both etc and you have a mess in your hands

Empperi07:08:56

also scala compiler is super complicated and compilation times are just horrendous

Empperi07:08:57

But one of the biggest problems with Clojure are: 1) code can degenerate pretty easily, one has to be pedantic when writing it. This means that Clojure is not that great language for below-average programmers. I think Clojure will never be a mainstream language due to this specific reason 2) REPL-driven development is great but unfortunately that tends to lead into situations where tests are not written. Where in Java for example, one needs to write tests in order to call your piece of code in isolation, with REPL you can do that trivially. REPL is great but with great power comes great responsibility and you must remember to also write the tests if you do not want your application to degenerate into a steaming pile of s**t 3) There are not that many developers out there who know Clojure. Because of this choosing Clojure is always a maintenance risk. This can of course be fixed by using Clojure more and thus exposing more developers to it, but this is not always a realistic scenario business wise

jsa-aerial14:08:58

With respect to point 2. here, it is always surprising to me how many people do not realize that 'repl oriented' development is development via an accumulative series of expression level tests. And the results are often rather more robust than typical unit tests. Second, traditional unit tests no longer make any sense now that generative testing is available. So, I would say point 2 here is largely moot nowadays

Empperi14:08:28

I agree with first point but not with second. I think generative tests are great but do not completely fullfil the same thing as unit tests. The reason is that unit tests are dualistic in nature: they provide test coverage and harness but they also work as documentation. Also unit tests are fast, generative tests are by nature slower due to sheer amount of assertions done. They are similar but I think it is maybe too extreme to say that normal unit tests are useless now. Fair points though 👍

jsa-aerial15:08:44

Well, first, for documentation, things like Spec are far better than unit tests. Second, being fast is just being incomplete and so, not really doing the job. I maintain that unit tests are no longer a good use of time.

mauricio.szabo16:08:56

I can't agree enought with points 1 and 2! While I was working with Clojure in a project, most of the team I was working with didn't yet saw the value of using schemas (specs were not still standarized). Needless to say, the code went from bad to worse after five or six features (we lost track of which attributes every map was supposed to have, and lots of NPE)

Empperi07:08:25

And when we go to browsers I can only say that NPM ecosystem is insane. There's so many things wrong there that I do not know where to begin. ClojureScript however has a much more sane ecosystem. It might be due to the fact that it is minuscule compared to NPM but whatever the reason it is much more sensible. In JavaScript land when you have a problem you start looking for a library, you add that as a dependency and then call that. This is why when you add some dependency you get gazillion transitive dependencies with it. The infamous 'leftpad' library is an extreme example of this but it actually describes the problem pretty well. With ClojureScript one can relatively trivially write a lot of functionality which would require surprising amount of code in JavaScript. This is partly due to the language but it's more about better designed libraries and how to use those. Take Reagent for example and compare that to pure React. Creating a new component in Reagent is just simply writing a function. Nothing special, nothing complex, nothing new to learn with the small exception in how you should call that function (use [component]instead of (component)). This combined with re-frame which is infinitely better designed version of what redux is trying to do provides a vastly superior productivity and expressiveness over JavasScript or TypeScript which actually just adds code due to static typing declarations.

eggsyntax14:08:24

@niklas.collin Your whole string of comments here is one that IMHO deserve to be thrown together into a blog post (or medium or whatever) -- I think it'd be a really useful case study for other folks to read.

Empperi14:08:39

Gotcha! Actually was considering this myself after I had written it. Glad to hear someone else also was thinking the same :)

metal 8
4
Empperi07:08:51

hope that answers your question @henrik?

henrik07:08:08

Very thorough, thanks @niklas.collin. It sounds overall like you’re more bullish about ClojureScript than Clojure.

Empperi07:08:39

Well, both are extremely good but I think ClojureScript makes a bigger difference in general yes

Empperi07:08:27

But if you are writing a backend which is data transformation heavy then you are more likely to get much better productivity with Clojure than with Java or Scala for example

Empperi07:08:35

because that's Clojure's sweet-spot

Empperi07:08:03

I would not write an opengl engine with Clojure due to how GPUs work and how opengl has been designed (it's a mutable state machine)

Empperi07:08:52

but most of the work I do are business systems with web frontend (if any). Usually it's about receiving or retrieving data, processing it and then dumping it to somewhere (to client, to database, to another API or whatever)

Empperi07:08:13

that's where Clojure is at it's best and thus it is without doubt the best tool for me for most of the business problems I'm trying to solve

henrik07:08:27

The recruitment situation when running a business is one of those things that comes up in conversation for every language that has below Java/JS amount of uptake. I guess it comes down to whether you think Clojure will remove more overhead than the overhead you will take on in recruitment, when finding the right person for the job.

Empperi07:08:56

a competent person can learn Clojure especially if that person has someone to mentor him

Empperi07:08:07

but as a consultant I'm constantly facing this question from my clients

Empperi07:08:17

"when your contract has ended how do we maintain this thing?"

Empperi07:08:26

and it's a very valid question

Empperi07:08:21

I've chosen Java several times over Clojure due to this specific problem. I've also told the customer that if I go the Java way then it will take me 2-3 times more time to do the exact same thing

Empperi07:08:57

sometimes the need for ensuring the availability of competent developers surpasses the extra cost included due to using inferior tools

Empperi07:08:04

it's a business decision

Empperi07:08:43

it's sad that business decisions can dictate technical tool choices but that's life

Empperi07:08:44

The more critical system we are doing the higher the propability we are not going to use Clojure. Not because Clojure wouldn't create a robust system but due to the availability of developers

Empperi07:08:22

But if I was working in a product development company I would not hesitate to use Clojure

Empperi07:08:32

after all, then I would be there to mentor all the new guys coming in

henrik07:08:56

And yet it seems like there are a few companies out there with a lot of Clojure devs

Empperi07:08:22

yup, I'm in Finland and the amount of Clojure devs is very high here comparably

Empperi07:08:46

thanks to Metosin guys and especially Jarppe who started the adoption of Clojure in finnish consultancy companies

8
👍 4
4
Empperi07:08:39

but still, for every developer in Finland who knows Clojure there's are AT LEAST 50 developers who know Java but not Clojure

Empperi07:08:53

but the amount of Clojure devs in Finland is starting to be high enough that I can actually use Clojure in actual customer projects, not all the time but every now and then

Empperi07:08:16

and a fun fact is that if we manage to use Clojure in a customer project then usually customer is super happy about the results and starts to demand Clojure from other parties too 🙂

henrik08:08:10

And yet I’ve seen that there are companies that manage to find a lot of people for their Clojure dev positions. I guess they’ve got processes in place for mentoring and so on. And if you’re large enough, I suppose you can sustain such a process more easily given the same percentual employee turnover as a small firm.

henrik08:08:52

So, why does Clojure fit so well with the Finnish psyche, I wonder 🙂

henrik08:08:15

Lower tolerance for bullshit?

dominicm08:08:25

we train a lot of juniors in clojure, it's surprising how quickly they get it.

henrik08:08:40

@dominicm What do you look for in a candidate for a junior, mentored position?

dominicm08:08:07

@henrik Someone who wants to learn often stands out.

☝️ 4
Empperi08:08:23

Clojure is relatively easy to grasp once you get past the "parenthesis problem" 🙂

Empperi08:08:58

But without a mentor if you have no experience in Clojure and you get a system written in Clojure before you it's going to be a very daunting experience

Empperi08:08:34

Like it would be in most languages but since Clojure is so different from mainstream it is even harder to get without someone telling you why it's like this

Empperi08:08:09

it's a form of unintended vendor lock-in which is morally questionable

henrik08:08:09

Thanks @dominicm and @niklas.collin. I’m soon going to find myself in a position where I’m in the mentoring seat. I’m largely self-learned myself, and I’ve never worked with Clojure devs, so any help with regards to selecting good candidates would be extremely welcome.

Empperi08:08:26

Look for people who can explain why immutability is good, people who know about functional programming and who understand data processing problems. Usually these guys are those who have felt the pain which Clojure can help with and thus they will pick the language quick and be very happy with it

borkdude10:08:41

I recently saw an RDF/Fuseki/Clojure library somewhere. Can’t remember which. Any hints?

emccue14:08:06

@niklas.collin what if, hypothetically, you were the kind of below average programmer that has code degenerate easily. What kinds of pitfalls can one fall into when programming clojure for real projects? Asking for a friend.

Empperi14:08:59

Clojure due to its very dynamic nature, it's embracing of data, it's functional programming capabilities and by being a lisp can be hard to get clean. However, there is a very simple and old rule to keep your code clean: do only one thing per function. Split aggressively all the time. This is however very easy to forget due to previously mentioned reasons.

jonahbenton14:08:36

Two things for me: 1) opportunities for clever terseness at write time become a nightmare at read or troubleshoot time. As beautiful as they are, there will always be a point at runtime when one wants a value from the middle of a long thread construct. 2) error and exception case handling. It is simply a mess in clojure- exceptions, nulls, false, missing cases, garbage in/garbage out. I also write go and the situation is so much better.

eggsyntax14:08:25

Or as Brian Kernighan put #1, "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"

Daniel Hines17:08:49

@U0FF3A4V6, doesn't this really boil down to a lack debugging tools in Clojure? And haven't there been systematic efforts at fixing this problem? I believe one such effort is @U4FFD43T4's Sayid. Interested in both your takes on this issue.

bpiel17:08:25

@U8QTB156K Sayid does have the inner trace feature that attempts to address the case where "one wants a value from the middle of a long thread construct", but I don't feel great about it. Writing the code for that feature was challenging. The resulting code is complex, but still doesn't cover many cases.

Daniel Hines18:08:48

Interesting... Thanks @U4FFD43T4!

jonahbenton18:08:31

Sayid looks like a wonderful achievement, and what is also super cool about Clojure is that the author of a super cool thing is right there to chat and respond, which is amazing.

😁 4
jonahbenton18:08:05

In the context of the conversation, however, I would say the question is more- how you keep code obvious is really important. ("Simple" vs "Easy" is a discussion for another time). What does obvious mean? At a high level, you can go away and come back in 6 months and not have to reload your prior mental map to understand what something is doing and what decisions were made and why. At a low level, all possible execution paths can be explicitly considered.

jonahbenton18:08:24

The ability to debug is obviously very useful, but there is a philosophical school that makes a distinction between thinking of a system as traceable and debuggable vs thinking of a system as observable and reason-about-able.

jonahbenton18:08:54

To make a generalization, application-level code artifacts are frequently authored from the perspective of the former; system-level and distributed system code artifacts more often from the latter.

jonahbenton18:08:23

It looks to me- could be wrong- that Sayid depends on instrumenting the vars in a program?

eggsyntax18:08:01

@U0FF3A4V6 I'd be very curious to hear you draw out that distinction further.

bpiel18:08:04

@U0FF3A4V6 sounds like an accurate description ("Sayid depends on instrumenting the vars in a program")

jonahbenton18:08:11

Thank you @bpiel- I am curious- do you and your team wind up using Sayid both at dev time, and then at maint time- when you return to something you haven't touched for a while, to kind of reload mental context? Is it part of the workflow in that way? Again- you have my utmost admiration, producing and sharing something so useful is incredible. Nothing I'm saying is in any way critical.

bpiel18:08:25

Thanks! Yes -- dev & maint time.

bpiel18:08:21

For the later, having tests to run (usually individually) works especially well

bpiel18:08:47

for getting an understanding of how something is meant to work

jonahbenton19:08:09

Yup, got it, thank you. My context- I spend time both in kubernetes/go and in clojure/java. Very different worlds. One does not have the option to connect to the debug port on a kernel or a kube api server to figure why a thing is behaving in a particular way. Those instrumentalities don't exist. The "observability" world growing up around k8s is based on an approach that fundamentally has to be "hands-off".

bpiel19:08:26

What does this k8s "observability world" include?

jonahbenton19:08:40

A hypothesis I have is that there is a reason that world is built on Go, that it almost couldn't be built on another language

bpiel19:08:26

or maybe I mean: what does it look like? how does it work?

jonahbenton19:08:36

Short version- apps emit events, tooling consumes/distills

bpiel00:08:42

When I first started writing Sayid, I found myself wishing for Clojure itself to be able to "emit events" (or similar), rather than having to instrument vars.

eggsyntax14:08:24
replied to a thread:And when we go to browsers I can only say that NPM ecosystem is insane. There's so many things wrong there that I do not know where to begin. ClojureScript however has a much more sane ecosystem. It might be due to the fact that it is minuscule compared to NPM but whatever the reason it is *much* more sensible. In JavaScript land when you have a problem you start looking for a library, you add that as a dependency and then call that. This is why when you add some dependency you get gazillion transitive dependencies with it. The infamous 'leftpad' library is an extreme example of this but it actually describes the problem pretty well. With ClojureScript one can relatively trivially write a lot of functionality which would require surprising amount of code in JavaScript. This is partly due to the language but it's more about better designed libraries and how to use those. Take Reagent for example and compare that to pure React. Creating a new component in Reagent is just simply writing a function. Nothing special, nothing complex, nothing new to learn with the small exception in how you should call that function (use `[component]`instead of `(component)`). This combined with re-frame which is infinitely better designed version of what redux is trying to do provides a vastly superior productivity and expressiveness over JavasScript or TypeScript which actually just adds code due to static typing declarations.

@niklas.collin Your whole string of comments here is one that IMHO deserve to be thrown together into a blog post (or medium or whatever) -- I think it'd be a really useful case study for other folks to read.

pablore15:08:38

Richard Stallman (RMS) is coming to my uni to give a talk about free software. What should I gift him?

dpsutton15:08:17

Office 365

😂 32
dpsutton15:08:15

I imagine he would prefer some kind of gesture. Maybe say you helped 4 people install free operating systems or something like that.

pablore15:08:33

I would, but I helped install Ubuntu and I dont think he would be happy with that

dpsutton15:08:25

well maybe a gift would be switching to a more free version and tell him you did it for him?

jgh15:08:06

free beer \o/

parens 12
jonahbenton16:08:14

@pablore I believe he used to, on his personal web pages, recommend charities to donate time/money to. I would scour those first, make a donation in his + your uni's name. I would not give him any stuff or things, he will just throw it out.

Alex Miller (Clojure team)16:08:02

Doesn’t he have a lengthy page about how he wants to be treated including gift advice?

dpsutton16:08:01

> Many holidays have become commercialized: corporate PR has taught many people that buying things for their friends or relatives on these days is "the thing to do", and the truest expression of love. I dislike the feeling that I am obliged to give a gift for some meaningless event, and get no particular pleasure from receiving gifts under these circumstances either, and hiding the fact that I don't like a gift makes me feel quite uncomfortable. I opted out of these forms of ritual consumption back in my teens, and I am glad I did. doesn't like gifts due to a holiday. unclear if this is general gift or not

Alex Miller (Clojure team)16:08:33

Is what I was remembering

dpsutton16:08:32

> DON'T buy a parrot figuring that it will be a fun surprise for me. very comprehensive

😂 12
fellshard18:08:29

Something tells me that might have come from a prior experience...

dpsutton18:08:40

yeah. that should end with "... STEVE"

3Jane16:08:53

It’s a hell of an effort, trying to return an unwanted Norwegian Blue to the shop. Perhaps he’s just trying to save himself the effort.

sundarj17:08:20

or save himself the shame of having to do so a second time