This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-09-19
Channels
- # bangalore-clj (35)
- # beginners (42)
- # boot (89)
- # cider (9)
- # clara (2)
- # cljs-dev (29)
- # cljsjs (3)
- # cljsrn (14)
- # clojars (9)
- # clojure (332)
- # clojure-brasil (1)
- # clojure-dev (5)
- # clojure-italy (4)
- # clojure-russia (36)
- # clojure-spec (38)
- # clojure-uk (65)
- # clojurescript (114)
- # clr (11)
- # community-development (105)
- # core-async (10)
- # cursive (4)
- # datascript (1)
- # datomic (58)
- # defnpodcast (3)
- # emacs (4)
- # hoplon (7)
- # juxt (3)
- # keechma (8)
- # off-topic (7)
- # om (109)
- # om-next (8)
- # onyx (26)
- # pedestal (3)
- # planck (8)
- # re-frame (76)
- # reagent (28)
- # rum (25)
- # spacemacs (2)
- # specter (35)
- # untangled (31)
- # yada (27)
@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 🙂
very little, if any, tech info on there @maleghast
Sure @mccraigmccraig Just really great to see another business / product built on top of Clojure
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!
@mccraigmccraig I feel queezy now when I look at java 🙂
but it seemed like such a good idea in the 90s @jasonbell
if that wasn’t the case we wouldn’t be learning anymore and that would be really scary.
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 🙂
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.
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.
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
eg. x = x + 10
is more about names than immutability imo (although it requires a mutable environment)
let x = x + 10 in …
😈
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)))
just isn't generally comprehensibleHahaha… 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 …))
and even there I’d probably want to restrict that to a small handful of exceptions to the "don’t do it!" rule.Perhaps:
(defn do-stuff [raw-thing]
(let [thing (preprocess raw-thing)]
… thing …)))
just watched @malcolmsparks talk from ClojuTRE. great talk
(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?
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?