morn

@maleghast http://yapster.info - we are a company directory, whatsapp style chat, and structured messaging flows (e.g. for shift-swap) on top of the chat foundation

@mccraigmccraig I shall take a look 🙂

morning

very little, if any, tech info on there @maleghast

Sure @mccraigmccraig Just really great to see another business / product built on top of Clojure

Very encouraging 🙂

morning

i was thinking i'm a fake clojurian because i'm not totally sold on the idea of clojure - it's been a very pragmatic choice, but it has definite weaknesses which could be addressed (by another language - too later for clojure now). in particular the lack of static-typing

I just said one day over coffee, “I’d like to learn Clojure”, but it happened to be with @otfrom so there was no escape from knowledge and hugs from that point on 🙂

knowledge should always come with hugs!

lol

@mccraigmccraig I feel queezy now when I look at java 🙂

but it seemed like such a good idea in the 90s @jasonbell

1995, I was there man!

I was jazzercising because Kim Polese told us to.

nothing is perfect… and there is always room for improvement.

if that wasn’t the case we wouldn’t be learning anymore and that would be really scary.

Always be learning.

So clojure won’t be the end-all. let’s see how clj(s).spec works out

and it will be a few years I suspect before we really have enough experience with it.

It’s funny - I somewhat agree with @mccraigmccraig - but it’s not static typing that I see as the weakness 🙂 My biggest issue, which isn’t really clojure’s fault at all, is the high barrier to entry for so many programmers, which mostly comes down to syntax I think.

dyu mean high barrier to entry for users who are used to macro-incompatible syntaxes @korny (as opposed to new users where i would think that clojure's relatively small syntax is probably an advantage)

yep, precisely. The millions of programmers who have learned a macro-incompatible syntax as their first, second, third and so-on language, are often just plain unwilling to move to a lisp-like syntax

If they are already enthusiastic, smart programmers will get over the hump and learn it. But if they see it as being inflicted on them from without, it’s a huge battle.

Some people are won over once you show them how powerful macros are - but by no means all

that might be a disadvantage if you are trying to improve the practises of a large enterprise @korny , but looking on the bright side it's a great recruitment filter 🙂

true 🙂

I’m by no means close to giving up on clojure - I think it will always be a primary tool for me and for any high-power teams of enthusiasts (until something even better and still lisp-like comes along!) - but I used to think I could convince people to do everything in clojure, now I’m back to “you could build 90% of your services in (X imperative language) but you should build these services in clojure, because they benefit from the power"

Also I note that JavaScript at least seems to be moving towards more macro-esque behaviour - every build pipeline has stages that play with the code at AST-level to do things like ES6 transpiling, linting, and the like...

I have heard that lisp like syntax makes it simpler/easier for none programmers to learn it…

my wife for instance found x = x + 10 most confusing… how can the value of x change… and what is it.

having imutable values makes things simpler

(as we all know now)

I don’t know for you or others but that’s probably linked to the way I’ve learned to resolve equation in math. From this angle x - x = 10 -> 0 = 10 and we don’t have a solution for this one.

and maybe (+ x 10) doesn’t look as close to an equation

My wife has made positive comments about clojure code - she has a pure maths background, and the expressions make sense to her. But I’m not sure how it goes for non-maths non-coders 🙂

Immutability thankfully is another thing that is taking over other languages - Java and JavaScript have growing numbers of immutable data structure libraries

@jasebell with me it was over wine with @otfrom rather than coffee, I blame the alcohol...and @otfrom of course! 😉

Just found out consultancy proposal I put forward to a client is probably not going to happen until next year so I'm looking for a contract to pay the bills starting in October. Give me a heads up if you see anything folks.

I find people's objections to the syntax very interesting since Clojure has such minimal syntax and mostly it's just swapping obj.func(a,b,c) to (func obj a b c) -- but many seem to find this a big obstacle.

yeah - I found the syntax easy, and once I got my head around let and the various -> macros, quite straightforward. I’ve abused both of those a fair bit too, but having these building blocks made everything else straightforward. I don’t think it’s a logical barrier - it’s more emotional.

you can lead a semicolon user to parentheses, but you can't make them think

i find in JS-land, immutability and re-use of names is often conflated

eg. x = x + 10 is more about names than immutability imo (although it requires a mutable environment)

let x = x + 10 in … 😈

shadowing should be banned 😄

I tried to explain shadowing today. Wasn't easy.

treating names and variables as distinct ideas might help?

My point got across, but code like:

(loop [foo [1 2 3]]
  (let [foo (or (do-thing foo) foo)]
    (if (something? foo)
      (recur foo)
      foo)))

Hahaha… that code should be taken out and shot! ‼️

I think there are occasionally good arguments for very, very limited shadowing but in general it should be avoided.

About the only case where I can think of justifying it is if you have a function argument that you need to preprocess at the top of a function:

(defn do-stuff [thing]
  (let [thing (preprocess thing)]
    … thing …))

Perhaps:

(defn do-stuff [raw-thing]
  (let [thing (preprocess raw-thing)]
    … thing …)))

just watched @malcolmsparks talk from ClojuTRE. great talk

got a good way of integrating clojure.test and spec (sure others have it)

(defn passes? [sym]
  (-> sym
      stest/check
      first
      :clojure.spec.test.check/ret
      :result))

(t/deftest conformer-testing
  (t/testing "Checking the conformer"
    (t/is (true? (passes? `sut/my-specced-func)))))

Do you need the call to true? in there — doesn’t passes? return true / false already?

the problem is that :result returns truthy things

though things went a bit weird on me later today so I really should verify that

Hmm, I thought is? worked with truthy / falsey…?

I'd also suggest looking at clojure.spec.test/abbrev-result — I think you can run the result of stest/check through that and get something more manageable?

I hadn't seen abbrev-result

abbrev-result looks good. still returns truthy things

night all