My reply: https://twitter.com/borkdude/status/1265665818714652674 Imo he's confusing concepts.

Yea, I noticed his article because of your tweet.... I was curious to see if/how other devs reacted to his ideas...

There are some reactions here: https://twitter.com/unclebobmartin/status/1265652439237173250

This one seems reasonable: https://tedgoas.github.io/Cerberus/

thanks

We use litmus to test rendering etc

Nor Erlang, nor several others that have appeared before. Makes the survey irrelevant, IMO, that they omit many languages that are in common usage.

The relevancy of surveys is a topic full of fud anyway 🙂 This thing where you fill out the answers and then you are eager to see if the majority agrees or disagrees so you can argue with your colleagues based on popularity contests... I was never too fond of the practice 🙂

The only thing interesting was to see what kind of new trends were maybe happening, but if they get rid of all the new and different choices, it becomes a pretty bad metric for finding those trends.

if they are rare and not expected, then they can actually show something new

everyone likes the first one

😄

Why’s that? A large chunk of developers like static typing (with good reason, I think).

it’s hard not to love typescript especially because it makes writing javascript bearable

gradual static typing, incredible tooling… two things i like most

but it's a bit of "fake static typing". yeah "gradual static typing" is more appropriate.

ts is not js, you write ts not js

js was bareable even before class was added

Well, surely the graduality is a benefit here, right? Since it means you can gradually adopt TypeScript in your existing JavaScript project.

cljs is more reliable than ts to write js code

you can't gradually adopt

as with cljs, you need to adopt tooling

ts definitely wins in the marketing department 🙂 personal opinion only, not that it matters

Sure, but I was referring to gradually adding type information into your codebase.

marketing is the biggest evil in our society

As in, you don’t need to type everything to get started.

so good for them winning there

you don't need ts types at all, this is a classic sophist trap

> cljs is more reliable than ts to write js code How do you mean? I’m sure most static typing advocates would vehemently disagree on that point.

i am not so sure about that, since you have static type checking with spec, in fact, cljs has runtime type checking too, which ts can't even attempt

How do you get static type checking with spec?

I believe spec is explicitly not a type system.

that's a different statement

not as limited as a type system

i am not saying ts is limited type system wise, i heard ppl are implementing all kinds of fun things in its type system

Well, they have different strengths. Having to type out specs manually is rather different from having the compiler infer types for you. Also, no Clojure editor that I know of can inform you about your function not adhering to a spec.

I have long been of the opinion that “static” typing is very artificial in practice… so I can “guarantee” something is a string … ok cool… in very practical terms, how does that help me distinguish a zip code from a city name?

Spec on the other hand, is all about “types” during runtime (aka, in practice)

I mean, I like spec. But in my experience, you’re going to have a very hard time convincing someone who likes and is used to static types that spec is superior. At least until there’s something that can automatically infer specs and an editor that can tell you the shape of the data functions expect and let you know if you’re trying to give a function the wrong kind of thing. The REPL notwithstanding.

I feel like the biggest argument “for” static types is in the editor, aka programmer convenience and keeping things “easy” - which is fair

Totally agreed.

But I’d argue that any sort of static typing is making your life “easy” in the small… but does not help you solve the larger problems you almost certainly have

Especially with regard to the confidence they give you while refactoring.

In practice, IntelliJ + Cursive lets me refactor Clojure code with very high degree of certainty… I have a hard time coming up with a scenario where I felt I needed to do something and I couldn’t

Realistically, by re-factor, I mean “change the name of something”

Right — it’s changing the shape of something where the difficulty begins.

Sure… I’m not sure how “easy” that is in a language like Java where everything is intertwined beyond belief… haven’t done TypeScript, so I can’t speak about that

Well, the way I see it is that the “easiness” comes from the fact that your editor can immediately tell you that things aren’t OK.

And again, in my 6+ years of doing Clojure, I can’t recall a situation where I painted myself in a corner with a certain data shape and was like “well NOW I wish I could turn this data structure upside down”

Right… and maybe that comes down to a style of programming… but with the REPL, I never feel limited… one practice I’ve adopted is what I call “deep destructuring” where if I’m passing a map to a function, I destructure the map right in the arguments

Sure, but I think you’d have to have something more concrete than that to convince someone who likes static types.

can't give examples right now, because i am on the phone, but it's not the case that clojure doesn't support static typing if you really want it

(defn add-user 
  [{{:keys [city zip street]} :address
                 username :username}]
  ;...
  )

In a similar vein, I’ve been doing Python recently, and I find myself coming across type errors much more often than with Clojure. I wish I had taken a systematic approach to analyzing why that is…

I mean, sure you can always say “you need something more there” 🙂

There's two type of static type enthousiasts. The mainstream ones, they don't care about correctness and safety, they care about convenience, like IDE auto-complete, and squiggly lines if they messed up something.

But I get your point

the whole point is that fully static typing is too restrictive and it's an ideological high ground, exactly something that if you don't get 100% right, your options will be limited and the worst use that being in that position makes you blinded to its nature because it's a local maxima of other bad ideas that support it

@U0K064KQV yes…

And then you have the niche ones, they care about correctness and safety and static proofs and all that

I think with spec and and amazing spec IDE integration you can please those first ones

And spec tailors to that second group

yea… but those static proofs are probably really only important if you’re writing a compiler

good luck proving your e-commerce store logic

Though arguably it does make certain things more convenient as well, like validation and generative testing.

Well, I think there are also people who prefer designing their applications on top of types (e.g. https://blog.ploeh.dk/2015/08/10/type-driven-development/).

yea… I think ultimately there’s no convincing somebody that likes a certain cake that cake tastes bad

Right, I mean that, if we talk about writing correct and bug free software, it's easy to bring up the value proposition of Spec and how Spec can clearly help to do that. If instead we start to talk about trivial IDE conveniences and catching trivial bugs like passing a string to +, it's harder to see the value of Spec

It’s a matter of personal preference and people are different; but I’ll say one thing

Types are “extra” as far as computability and physics is concerned

there’s proofs that things that are fundamentally untyped are equivalent in power to typed things; like lambda calculus is fully Turing complete, etc

it's a fundamentally different kind of programming. every day you write the same code with small differences, it's easy to miss typos. also, you can't change too much at once, so you write what you can, and write as much as possible, editor generating the same code over and over makes you feel productive. never mind what is the end result, important is that it's working.

So the cake is extra…

My biggest issue and personal dilemma is that it is really easy to estimate the positive of types, but really hard to estimate the negatives.

I think the negatives are that ultimately you’re trying to create a “type” of something that is potentially, and very likely, not well defined

The universe has no “types”, they are human constructs, and thus, more or less, fake

Its very easy to say, hey this one time I forgot to update this function after I change the name of the key on the map, and I broke the CI because of it. If I had static type checks this would have not happened.

For the people who like static typing I know, they feel that, given type inference, there are no negatives worth mentioning (compared to dynamic typing).

That's the thing though, that's really hard to measure

@U0K064KQV this almost goes into the “convenience” category; I think with a static spec analysis via an editor, in theory you can catch those

I agree. Having to think about types instead of just the shape of your data does have its cost, but that doesn’t come off as a very convincing line of argument in itself. 🙂

I mean, static spec analysis is just a type checker :p

@U0K064KQV right…

Though I think I'd like a kind of best effort type checker in Clojure, which brings about no change to the code. Clj-kondo actually does some simple static type checking now which is nice

This was one of the most convincing arguments against types that I recall https://www.youtube.com/watch?v=YR5WdGrpoug

In my experience, static typing enthusiasts find that video the exact opposite of convincing. 😛

@U0K064KQV that would be nice for sure… a good “nice to have”… I don’t think it will fundamentally change my life but it might prevent 1 in 1000 accidental error

@U4ZDX466T lol oh really?

Yes. It’s more infuriating than anything. 😛

Then… I give up

Going to bed

LOL

Even this article https://danluu.com/empirical-pl/ does little.

But that's the thing, I don't feel it's so much being against types. Like nobody can say: the computer can just tell me where the bugs are? I don't want that. Everybody wants that off course. The question is more, what sacrifice do we make today given the existing type checkers? Can we have Clojure with static typing? Because Clojure is what I want, if you say I can't have it because of static types, then I'm losing something really important

@U4ZDX466T what’s their argument against “Maybe Not”?

That it only applies to the way Haskell types work

But OCaml types can be open

Ah, I see…

Know almost nothing about OCaml but have heard good things…

But I also thought that Haskell is one of the holy grails of types (I guess not?)

@U050KSS8M There are too many points to list, and I don’t want to run the risk of representing anyone unfairly.

@U4ZDX466T fair 🙂

I've faced this issue before. Clojure has this and that, can do this and that. And other people are like X can do that one, and B can do that one as well, and C this other thing. See, Clojure has nothing special.

But suffice to see that for most of it, I can certainly see where they’re coming from.

Its like okay, where is the language called Union of all other languages.

@U0K064KQV yea… everything can do everything… Turing-complete; important is what’s idiomatic

Which magically can do everything Clojure can :p

Even though I don’t see that talk as being anti-static typing, per se. It’s certainly anti-`Maybe` and anti-`Either`.

@U4ZDX466T as far as I recall there were some subtle but very pointed critiques… but it has been years since I watched it

Its a good talk. The talk also criticizes Spec 1

yes, I recall that

I don’t know about “subtle”. Certainly not subtle if you like Maybe or Either. :P

And shows some of the reason for Rich working on Spec 2

I've personally had all the problems Rich mentions in the talk. Basically, Maybe doesn't capture lifecycle

Something is either optional throughout or mandatory

Yep, same here. I think the gist of the talk is that whether you need some bit of data or not depends on the context, and declaring it beforehand doesn’t make sense, and I totally agree there.

@U0K064KQV in terms of what’s unique about Clojure, I came across this description recently… Clojure is one of the few (if not the only) language that is really “data-oriented”; that combined with the immutability allow you to very easily reason about your code

Anyways, if someone writes a static type checker for Clojure that infers everything and requires absolutely zero additional annotations and doesn't restrict in any way how I model my data or structure my code, I'll happily use it. But I doubt that can be, so there is clearly something we "lose" by going with static types

But it's hard to say what exactly

And I feel I too can't really say what it is I lose, but my intuition says I lose something precious

@U0K064KQV I’m almost positive that this kind of “best-effort” checker can be done… and you can progressively expand your usage of it by using type hints like ^Number, ^String

Heading to bed, good night all

Me too, GN

Sorry guys, I retract what I said at the beginning and will end with "everybody loves typescript".

https://clojurians.slack.com/archives/C03RZGPG3/p1591346885136500?thread_ts=1590670242.444000&cid=C03RZGPG3 @U4ZDX466T https://blog.cognitect.com/blog/2017/6/19/improving-on-types-specing-a-java-library ☺️

There’s no question that you can do more with spec than with static types, but as long as you have to write specs manually and your editor doesn’t tell you if you try to give a function the wrong kind of thing (or prefer to use types to design their programs), I don’t think many people who are used to static typing will be very interested. ’Course, I might be wrong.

It is not the case that you have to write specs manually, you can generate a lot from existing data. Things that need to be written manually are better written manually. You can get a lot farther with small manual coding than repeatedly relying on unchanging abstractions that automate some work that might or might not be required. You cannot write the same kind of code some people write using static types, which is basically a kind of toolbox for stitching up big trees of abstractions, but this is a good thing, that style of coding, I don't care how successful it is in the enterprise and corporate world of software is not for long term, it's basically an intermediary step between manual filing and actual programming. I am sure this nuanced position will not precipitate in a quick and superficial reaction? ☺️

> It is not the case that you have to write specs manually, you can generate a lot from existing data. If you can make that as effortless as type inference, that might indeed convince some people who prefer static typing. 🙂 > I am sure this nuanced position will not precipitate in a quick and superficial reaction? Not sure what you mean by this… I’m not a static typing advocate, if that’s what you’re implying. The rest of what you’re saying I don’t really understand, at least not without some practical examples. Anyway, all I’m saying is that as long as Clojure can’t give people who prefer static typing something like Intellij IDEA for Java or Visual Studio for C# where the editor constantly almost tells you what to write, it’s going to be hard to convince those people to cross over to something like Clojure. I’m not trying to argue for the superiority of one kind of typing system over another at all.

It seemed to me that you are making the point that giving to these people what they want is a good thing.

Ah, I see. I didn’t mean to imply that — apologies if I was unclear.

Definitely not a problem from my part, I just feel so strongly about these things since I recently made the decision to work in cljs instead of typescript for these same reasons. Biggest problem was just the lack of runtime abilities whatsoever. Yeah I can get fast autocomplete, or multi file refactor, but in the end, it's not even the kind of programming I want to do, I feel doing it as a glorified librarian.

Although, Julia is there. OK, now it does seem strange for me.

yes, well, Kotlin being pushed by google as Android's primarily language. I think mostly to say FU to Oracle

Well, it’s also a lot more palatable than Clojure to most people.

I find kotlin the new Java. The type system is more sound, it has sum and product types and is overall more comfortable to use than Java for OOP.

Yes, I too feel this is a problem. All this activity on Slack is completely hidden from search engines. And the arguably most popular developer centric website (SO) is only filled with really old Clojure questions and no recent Clojure related activity. I feel this stops many from ever trying out Clojure.

Also, as a community, we seem to celebrate every survey that puts Clojure near the top and question the credibility of every that drop Clojure from the list.

One last thing I think is (although I have not verified it with data), the developer community is growing faster than the Clojure community, so Clojure may be growing, but as a percentage share of the whole developer community, still declining.

To be honest, if you post a Clojure question on SO, you'll get an answer in less then an hour. Its not that people don't answer questions, it seems there are just not one really asking.

I agree that Slack in a way is counter productive, but it's so fun 😋

And slack is way better for the person who ask the question, but not as good for others in the future that have a similar problem

The point is not efficacy though. It is about how the Clojure community is being perceived by others, time and again.

I'd assume rise in popularity of these platforms discord/slack are probably taking an enormous amount of questions that may have otherwise been asked on SO as well. Way more appealing to post a question in slack and get an answer within a few minutes and have some live discourse than wait awhile on SO.

Maybe we should develop a bot that categorize the question on slack and publish the answers.

you can lament what people do or don't do or where they do it all you like, but you don't have any control over it, so I personally don't spend much time on it. if you want to do something good for marketing Clojure, there is a 2-step magic formula in dev marketing - 1) do cool and/or useful stuff 2) tell people about it. I don't know any other answer.

❤️

btw, I was joking, if it wasn't clear

But greater developer mindshare => more cool and/or useful stuff getting build. This is a self reinforcing cycle.

Clojurians is probably one of the biggest programming language Slacks out there. Has anyone thought about that?

software is fashion

Yeh, what brought me into clojure was seeing the cool stuff being made by small/solo teams. Precursorapp and figwheel first things that come to mind that I recall. Also reagent, I had never used react.js but was productive in it day 1 with no clojure experience using figwheel. Have some super warty code from that time.

> But greater developer mindshare => more cool and/or useful stuff getting build I don't know about that. That's one of my gripe with PHP and JS. The amount of crap out there, built with those, and when you ask questions, you'll get so many answer by people who aren't that knowledgeable. In Clojure, you have quality over quantity most of the time. I don't really feel I'm missing out on anything cool. It has everything I need. And one thing about Clojure that I find unique, is actually the fact that the community is small, I get to talk directly to the core maintainers. That's prime level support right here. I mean, even paid tiers for commercial software you'll almost never get a chance to ask questions or support from one of the actual core developers.

I'd say the only downside to Clojure's small popularity is the job opportunity being small. That's the biggest negative. Otherwise, maybe we'd get a little bit better tooling, but I don't know, it's quite impressive how good and complete the tooling is and everything that is already available considering the size of the community.

What would you want more for tools?

Don't forget about trampoline.

this one is best :star-struck:

this explains why Java 9 is so "popular" 😄

Also the documentation is brilliant

Even the "no-parens" part? :)

no, except that one 🙂 That was just a quote from the blog post

If no-parens means whitespace significant, then kill me now.

But at least Ruby doesn't have that.

https://seanfelipe.github.io/automation/languages/ruby/java/javascript/simplicity/2020/05/20/automation-ruby.html that's the original blog post if anyone interested

AFAIK "no parens" means "no need to wrap function arguments in ()".

I suppose in that case, in a way, we too have 'no parens'

Reflection is a weird one. Would Clojure be reflective :thinking_face: Seems in a non OOP context I'm not sure what to think of reflection. We can't inspect inside a function, so maybe it's not reflective

do you know paredit-forward-slurp-sexp? It does it in the opposite direction (i.e you have to place | over foo) might suffice

you could macro together paredit-backward-up, paredit-backward-down, slurp, paredit-forward-down. Kind of a non-answer I guess but best I can think of

Quickest I could find in spacemacs is k to move up a line, then SPC + k + s

I think it's an X/Y problem. I can't stop hitting insert newline below ("O" in vim bindings), which is mixing text editing with structural editing. I'll knuckle down and learn the paredit way.

there should be backward slurp sexp

backward slurp goes from

(defn foo)
[|]

[(defn foo)
|]