HN user

blain_the_train

79 karma
Posts0
Comments95
View on HN
No posts found.

Java has more build tools then Clojure, so thus is more “more fragmented” apparently. I replied “wat” as a slang version of “what” and a short version of “what do you mean” because that’s the only reasonable reply to “spec seems kind of weird and not well thought out either”. I’m asking OP to qualify there statement with something that could even start to be a conversation about various tradeoffs.

But really, i wish i hadn’t hit enter and i wish i could delete my comment because OP’s comment isn’t a good entry point to discussion anything.

So clojure has three main build tools: Lein, deps, and boot.

Meanwhile in the java world you have: Gradle, Maven, Ant, etc...

And Clojure CLI tools also seem like a total shitshow compared to go or rust’s tooling.

Wat

Spec seems kind of weird and not well thought out either.

WAT?

Even in the most naive models your "market value" is based off Demand (how many jobs) AND supply (how many people can do the job), you need to be concerned about the ratio, not one side or the other.

If Pytyon has 100 jobs and 100 people then the ratio is 1 If Clojure has 10 jobs and 5 people then the ration is 2 and Clojure has a healthier market for you then python.

I'm saying that it's hard to build a basic lego block with another lego block. You have to use plastic, heat and a mold.

That's why we have a wide range of programming languages at different levels, and why it's common for people to say "high level" or "low level" languages.

It's unclear to me what your suggesting, or what question your asking really.

CSS suffers from the lack of composability and organizational features found in modern high level programming languages. If your excited about modern css features like "is" or "has", then you agree it needs more functions to keep up with customer demand.

I wrote a bit about this problem from the perspective of a clojure and clojurescript developer on my blog. https://drewverlee.github.io/posts-output/2021-8-26-css-opti...

The reason, clojure and clojurescript is relevant is those programming languages can easily compile to css, allowing users to easily add pl features that don't exist in css and not force devs to learn the same concepts twice. It can do this becuase as a lisp, turning clojure native hashmaps into classes (or attributes if you prefer) is like pouring water into a container. We numerous libs to do this in the clojure ecosystem, here is a reddit discussion around the newest one: https://www.reddit.com/r/Clojure/comments/w56tg8/shadowcss_c...

Though i would personally opt for the slower page perf and faster dev performance of just using cljs compiled to inline-styles solution, as i suggest in my blog.

Of course there might be performance benefits to coding at the lower css level directly, but on average that's not a good tradeoff for most teams i have worked on. s

correct. the way i see it, lisp operates at the abstraction level of lists. which most people call "user applications".

if you need to build things that build the building blocks of lists it's not a good fit.

I'm asking a question about human psychology really. Maybe in a too cheeky way, because I feel some language enthusiasts, unintentionally, do the same by implying there programs are "safer" by being more constrained, without really justifying the claim.

I'm asking how haskell encourages people to use composable well understood abstractions and data structures?

Clojure does this by putting them into the syntax itself as primates E.g ([] () #{} {}) see? the list () contains a list of things, one of which itself is a list. This cuts away the translation barrier, i don't have to label the ocean as wet if your in it.

In this way all clojure developers are lead to think and talk to the machine the same way, this unifies how all Clojure programmers often choose to express intent.

It's at the heart of what Rich wanted for the language, making simple easy. Or as i see it know, making simple useful structures so easy to reach for, your discouraged, before you know better, to do something else. That's why i view clojure as more constrained then haskell, because I'm not sure haskell has that level of built in encouragement in it's design. I think the authors were interested in what could be, as where rich has taken a much narrow stance on how to deliver high level programs.

it's not clear to me, and from the studies i have seen, that Haskell leads to less unintended exceptions than Clojure.

haskell might certainly lead to less nil pointer expections, but that doesn't even mean the faulty logic is easier to resolve right?

what I'm saying is, no one pays to avoid nil pointer expections. if they did, i would simply right no code and call it a day.

the question is, does a language let you express your intent accurately. imo, this is what clojure gets right, because it helps me talk to the machine in the machines terms: datastructures.

clojure makes using well understood types easy by putting them into the snytax. it wires it into your brain.

my worry is, and hear this on every level, haskell is too open ended, people will choose to reinvent lists and sets and hashmaps making it harder and harder to understand how anything can compose together.

yes, everyone in these communities does this to some degree:

typescript, coffeescript, scala, kotlin, etc...

you're going to end up creating classes using the raw CSS

A program can read what looks like inline css and produce class names for youand put those in class files.

When developing your see "height 20px" In your app its compiled to "h-20" with a css file "h-20: height 20"

This is better because you don't have to learn another way to express the same logic.

Because you don't just drop into the reply in tests. You can drop into the repl on a production system. Or during a live dev env. No more guessing what the input was that blew things up, your gonna do that investigation on the real patient.

What's happening here is more subtle. The interviewers question didn't carry enough information to get the answer they wanted.

They created a puzzle where you needed to ask for more information. Intentionally or not, they were discovering if they could communicate with you. That the communication failed doesn't mean your somehow less then them. It means you just have a different background.

Now to the problem, the problem people don't set good goals. It probably doesn't make sense to hire a carbon copy of yourself.

The repl is another tool. I can and do run my tests in the repl. I can set my tests to run everything I change a fill, now the repl has enhanced my tests.

The reason the repl is widely used in clojure is because it's the fastest way to get feedback on ridge code.

I draw a sightly superficial line between ridge and dynamic code. Ridge code would be like an API call to get very specific specific results, here the repl is better then a unit test, for it would be too much for code and time to capture your specific API call results, namely because you haven't really tested anything much larger than a couple data points.

So, it's the opposite, unit tests are often used because languages lack a repl.