Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clojure: The Documentary, official trailer [video]

youtube.com

Post reply on HN
Print view View original

81–90 of 94 posts

Re: Clojure: The Documentary, official trailer [video]

#81

Post by embedding-shape »

midnight_eclair wrote: post #80
embedding-shape wrote: post #65

Earlier quoted context omitted.

Yes, maybe that's the sort of DSL you're talking about, the other person mentioned "Clojure style discourages building DSLs" which I'm fairly sure to be about the other DSL and is also true, hence the whole "you're talking/reading past each other".

that doesn't make sense, why would they be talking about departure from traditional lisps if they weren't talking about macro-based DSLs?

> Clojure style discourages building DSLs and the like and prefers to remain close to Clojure types and constructs

This to me, seems to indicate they're talking about "DSLs not built with Clojure types and constructs", I'm just trying to have the most charitable reading of what people write and help you understand why it seems you're not actually disagreeing, just talking about different things.

Re: Clojure: The Documentary, official trailer [video]

#82

Post by midnight_eclair »

embedding-shape wrote: post #81
midnight_eclair wrote: post #80

Earlier quoted context omitted.

that doesn't make sense, why would they be talking about departure from traditional lisps if they weren't talking about macro-based DSLs?

> Clojure style discourages building DSLs and the like and prefers to remain close to Clojure types and constructs This to me, seems to indicate they're talking about "DSLs not built with Clojure types and constructs", I'm just trying to have the most charitable reading of what people write and help you understand why it seems you're not actually disagreeing, just talking about different things.

> DSLs not built with Clojure types and constructs

and in context of lisps that still most likely means macro-based DSLs using traditional lisp constructs ¯\_(ツ)_/¯

Re: Clojure: The Documentary, official trailer [video]

#83

Post by pllbnk »

lukashrb wrote: post #14

Every time I write another DTO → domain → DB mapping layer in Kotlin/TypeScript, I think about Clojure. I’m pretty grateful I learned it. It really changed how I think about software. Still, it’s a trade: less ceremony, more responsibility.

I was lucky at one point to work professionally with Clojure for several years and it has made a huge impact how I think and write code in other languages as well. Also, those other languages now seem needlessly verbose and annoying compared with Clojure.

Re: Clojure: The Documentary, official trailer [video]

#84

Post by puredanger »

agency wrote: post #58
jwr wrote: post #10

I've been running my business for 10 years now, relying on Clojure and ClojureScript. It is amazing to be able to base one's livelihood on a foundation that is so stable and well designed. Clojure has been designed by a very smart and very experienced person, and it shows. It has then been maintained and extended by a team built around a culture of maturity and stability, and the result is something you can rely on.…

Simple Made Easy[ https://www.infoq.com/presentations/Simple-Made-Easy/ ] in particular had a huge impact on the way I think about writing software at a formative time in my development/career. I have not had the chance to use Clojure professionally, but thinking about software in terms of "intertwining" is the idea I return to when evaluating software designs, regardless of technology, and gave me a way to articulat…

FYI, the canonical version (recut slides / video / audio) of this talk can now be found at https://www.youtube.com/watch?v=SxdOUGdseq4

Re: Clojure: The Documentary, official trailer [video]

#86

Post by Capricorn2481 »

midnight_eclair wrote: post #78
Capricorn2481 wrote: post #73

Earlier quoted context omitted.

In my experience, Clojure was a huge pain in the ass to get into, and there's a non-zero amount of community members that talk about it in nothing about aphorisms. I really wanted practical advice, but getting people to talk normally about it was an uphill battle. This made me almost quit several times. But it is a very pragmatic language underneath (which you've already mentioned). But I'm not sure a framework is re…

> I'm not sure a framework is really going to change that onboarding process, or help with network effects that much having one commonly accepted and recommended way does improve onboarding, because it collapses the decision space beginners face. right now they are supposed to make decisions (not even directly, but just through selecting one of the many frameworks) about things like: 1. which project templating tool…

I don't disagree with what you're saying. But by "onboarding process" I mean the effort of getting more people into Clojure, not the experience for a single person.

What I'm suggesting is Elixir has everything you're talking about in Phoenix, yet it's still an extremely niche language most people haven't even heard of. Because come on, it's a totally different paradigm than what people are trained to program in. I understand the mental math of "easier means more people," but I don't think that's really going to cut it for Clojure. I had full projects spun up the minute I started learning, but that wasn't where the difficulty was.

So yes, I think having a solid framework is good for Clojure, but the original person suggested it's not popular because it doesn't have one, and I just don't think that's true.

Re: Clojure: The Documentary, official trailer [video]

#87

Post by Capricorn2481 »

r1290 wrote: post #76
Capricorn2481 wrote: post #73

Earlier quoted context omitted.

In my experience, Clojure was a huge pain in the ass to get into, and there's a non-zero amount of community members that talk about it in nothing about aphorisms. I really wanted practical advice, but getting people to talk normally about it was an uphill battle. This made me almost quit several times. But it is a very pragmatic language underneath (which you've already mentioned). But I'm not sure a framework is re…

Wouldn’t touch it with a 10 foot pole. What would you prefer over django of the listed above? Curious.

Any of them. My experience with Laravel hasn't been flawless, but I think it's better in just about every way.

Re: Clojure: The Documentary, official trailer [video]

#88

Post by geokon »

midnight_eclair wrote: post #79
geokon wrote: post #74

Earlier quoted context omitted.

DSLs typically involves constructing macros that are domain specific (to cobble together a domain specific programming language on top of the host). Most of the linked examples are not macro based and are the exact opposite. They specifying domain specific data layouts built directly using the Clojure-native immutable datatypes. They don't create Domain specific datatypes or function-generating wrappers. It's just ra…

> DSLs typically involves constructing macros that are domain specific a DSL is a constrained language for expressing domain concepts. in traditional Lisps they are often syntax-oriented, because code is lists and macros are a natural tool. in Clojure, pervasive use of keywords, vectors and maps allows you to shift DSL design towards data interpretation rather than syntax transformation. so in Clojure doesn't discour…

The original comment you took issue with "The point being made is that the Clojure style discourages building DSLs and the like and prefers to remain close to Clojure types and constructs". You seemingly read half the sentence and in the most unfavorable way possible. (in context it's clearly not talking about "data-oriented DSLs)

> DSL is a constrained language for expressing domain concepts

What you're calling "data-oriented DSLs" is not constrained.

I guess this is all semantic, but in my book just specifying a data-structure doesn't make a language. You're not extending the host language in any way

Re: Clojure: The Documentary, official trailer [video]

#89

Post by midnight_eclair »

Capricorn2481 wrote: post #86
midnight_eclair wrote: post #78

Earlier quoted context omitted.

> I'm not sure a framework is really going to change that onboarding process, or help with network effects that much having one commonly accepted and recommended way does improve onboarding, because it collapses the decision space beginners face. right now they are supposed to make decisions (not even directly, but just through selecting one of the many frameworks) about things like: 1. which project templating tool…

I don't disagree with what you're saying. But by "onboarding process" I mean the effort of getting more people into Clojure, not the experience for a single person. What I'm suggesting is Elixir has everything you're talking about in Phoenix, yet it's still an extremely niche language most people haven't even heard of. Because come on, it's a totally different paradigm than what people are trained to program in. I un…

> the original person suggested it's not popular because it doesn't have one, and I just don't think that's true

i agree that it's not a sufficient condition, but it's an important factor and it would significantly improve the onboarding process by collapsing the decision space beginners have to navigate

even going by your definition of onboarding (the effort of getting more people) - dispersing that effort across multitude of dimensions and directions is certainly less effective than coordinating and converging

not intending to have an argument about popularity, but since you keep bringing up elixir - there's a lot that can be said about elixir/phoenix as to why they aren't more popular than they are, but they are more popular than clojure in every recent ranking i've checked ¯\_(ツ)_/¯

if anything, elixir/phoenix is a good example for how strong default improves onboarding and ecosystem cohesion, even if it doesn't make the language broadly popular

i don't look at it from perspective of "what should clojure do to be more popular than php" - there are fundamental reasons why that just can't happen in this timeline

i look at it from perspective of "what does this ecosystem lack that makes it hard for beginners to get going and stick"

and lack of "single recommended way of doing it" is at the top of my list

Re: Clojure: The Documentary, official trailer [video]

#90

Post by midnight_eclair »

geokon wrote: post #88
midnight_eclair wrote: post #79

Earlier quoted context omitted.

> DSLs typically involves constructing macros that are domain specific a DSL is a constrained language for expressing domain concepts. in traditional Lisps they are often syntax-oriented, because code is lists and macros are a natural tool. in Clojure, pervasive use of keywords, vectors and maps allows you to shift DSL design towards data interpretation rather than syntax transformation. so in Clojure doesn't discour…

The original comment you took issue with "The point being made is that the Clojure style discourages building DSLs and the like and prefers to remain close to Clojure types and constructs". You seemingly read half the sentence and in the most unfavorable way possible. (in context it's clearly not talking about "data-oriented DSLs) > DSL is a constrained language for expressing domain concepts What you're calling "dat…

> What you're calling "data-oriented DSLs" is not constrained

constraints come from the interpreter, not from the syntax

> in my book just specifying a data-structure doesn't make a language

correct, it does not

what makes it a language is defining constraints on that structure and rules for how it's interpreted

that works both for clojure (where the data structure can involve lists, vectors, maps and primitives) and traditional lisps (where data structure is lists, or to be precise cons cells and primitives)

in both cases macros can be used and are used (but don't have to be used) to prevent immediate evaluation of those data structures according to host language rules and instead change how they are evaluated according to DSL author's rules

for example, datomic queries are just data structures, but they clearly form a constrained language with well defined semantics and the fact that they're not implemented via macros doesn't make them less of a DSL

Post reply on HN