Hacker News new | comments | show | ask | jobs | submit login
Rich Hickey's response to “On whose authority?” (reddit.com)
124 points by disaster01 9 months ago | hide | past | web | favorite | 77 comments



My favorite sentence from the response is this one: “The presumption that everything is or ought to be a community endeavor is severely broken.” Community is a broad word. It can mean a bunch of very smart people working in concert to produce something truly magnificent, or it can mean giving the keys to a bunch of clowns and watching them mess around and make fun of themselves.

I really wonder this whenever I see some new-fangled open source project putting out a CODE_OF_CONDUCT.md stating community is a top value. Look, you are primarily writing software not trying to foster a community. A community can be helpful to produce great software, but a community can also mean additional mental and emotional toll, and clowns introducing discussions with little merit.


That sentence also struck a chord with me.

The dictionary definition of community:

> n. A group of people having common interests: the scientific community; the international business community.

The "Clojure community" is a group of people having a common interest in Clojure.

The sentence doesn't disparage the community, or discourage engaging with the community. Rich Hickey's 1000 word response makes the case, and is evidence itself, that he and other Clojure contributors care about the community. He is explaining that he will continue to design and develop the language as a Rich Hickey thing instead of a consensus or community driven process.

> A true community respects the autonomy of its participants... the ultimate authority and stewardship of Clojure remains with me


There's a difference in the language and the ecosystem around the language.


I've read the original article and, to be quite honest, couldn't actually determine what point it was trying to make. The action items seemed to have very little to do with the rest of the rant.

I actually read the response first and the weird thing is: I couldn't really tell you what exactly the response is replying to. I feel like the whole thing is a huge amount of verbiage expressing frustration and broken motives but any actual solid facts mentioned are peripheral at best to what's being said.

I could write multiple pages on how I fell out of love with Clojure but I doubt it would benefit anyone and it'd be a huge pain to do.

Clojure is the product of a singular aesthetic, for better or worse.


>, couldn't actually determine what point it was trying to make.

In the poorly written Chris Zheng rant, there was a link to a more mature blog post by Eric Normand.[1] (It would have been better use of Rich Hickey's time to ignore CZ and respond to Eric, but alas.)

In any case, CZ is upset that Cognitec drives the evolution of Clojure and its libraries more than the community outside of Cognitec. E.g. one of his frameworks he liked (Noir) was ignored while Cognitec pushed its own.

Here's my question, what mainstream programming language community actually meets CZ's criteria that the outside community drives the language with equal or more power than the internal team? It's certainly not Golang (Rob Pike, Brad Fitzgerald, Ross Cox, etc), nor C# (A Heilsberg, et al), nor Clang (Apple devs). Yes, they have github repos but the pull requests from outsiders is not the same priority as the internal teams agenda. Which language & community actually meets CZ's ideal?

[1] http://www.lispcast.com/cognitect-clojure


Rust is extremely community driven. The main team does work and had input. But they respond to community requests with an openness and a speed that is rare.


And they rejected a couple of his pull requests and implemented similar features themselves.

I don't think it's necessarily the responsibility of a project to validate its users. But there are examples like Node where the emphasis is on retaining and involving contributors.

https://medium.com/the-node-js-collection/healthy-open-sourc...

I'm not sure it fits everywhere but based on later posts, it seems to be working for them.


Though Node is run that way mainly because the pressure of io.js — specifically forked because Node wasn’t being run in a collaborative manner. Was an interesting time, with an excellent outcome.


Ruby is an example for sure, Haskell is another.


I don't know if it has changed recently, but for many years the core team for Ruby were all Japanese, and most of their conversations were in Japanese, and so almost nobody in the wider Ruby / Rails community had any visibility or influence on the language's development.


Right, but that is just the language and VM implementation. The most important libraries in Ruby are not written by the core team who supports the VM.


Sad thing is...Noir was dead for 4 years before Arachne came along. Go to the GitHub page, the deprication notice is from 2013! And Arachne isn’t even a Cognitect project. The author of Arachne temporarily quit his job at Cognitect to peruse his dream of a ideal web framework.

The number of facts like this that at just plain wrong in the OP just add to the offensive tone. Why should I listen to someone who has no respect for they truth?


Speaking of the truth -- http://arachne-framework.org/team/:

  Tim Ewald **
  Bob Calco ***
  Jamie Kite **
  Jay Martin
  David Nolen *
  Mike Nygard *
  Russ Olsen *
  Marc Phillips
  Nola Stowe
  Stuart Sierra *
  Luke VanderHart *
  ---
  (honorable mention) _halgari == Tim Baldridge *
  
    * Currently @ Cognitect
   ** Ex-Cognitect
  *** Affiliated (https://cognitect.com/services.html)


> what mainstream programming language community actually meets CZ's criteria that the outside community drives the language with equal or more power than the internal team?

I'd suggest Perl might get close to that.


Not even close. There's a tiny cabal of regionally and racially well connected people, most of them working in the same company, who do make the (mostly wrong) decisions.


mainstream

That's a weasel-word. For all we know, you could be using it as a synonym for a programming language community that's controlled by a corporation. Then your whole argument would be a tautology.


shoot for the stars and if you miss, at least you've reached the moon.


The original article doesn't make much sense to me either. It's just a weird rant.

I love Clojure and many of its libraries, but I think there are some aspects inhibiting its growth. Here they cover a few of these aspects:

http://www.lispcast.com/cognitect-clojure

It worries me a bit, since I would really like to have a practical Lisp that is on par with other mainstream languages in terms of tools, libraries and community. Clojure is quite healthy now, but some items need to be addressed in order not to fall behind.

I'm also quite enthusiastic about Racket getting to run on top of Chez Scheme, which may give it a bit of momentum. Besides, Clasp, with its LLVM capabilities, is the most promising Common Lisp to me right now. Sadly, it's mostly one-man project and the whole Common Lisp scene is a bit stagnant.


To me the original article read as an expression of frustration - the sort of feelings that are easy to understand but hurtful and frankly stupid to put out in public.


The comparison to a relationship with a girl out of your league really makes him come off as a bit of a twat straight off the bat.


oh man... meta-trolling is amazing.


"Entitlement" really captures the post Rich is responding to. Objections to the existence of Arachne and spec? Who is Chris Zheng to tell people what to spend their time and money on? And he wants Datomic open sourced. Waaah.


It's damn good rhetoric to label a post 'entitled' and trash the author as childish.


It's not a label, it's a description. Based on his post, that Zhang guy believes that people shouldn't have donated to Arachne, for example, because he personally didn't think it was necessary. In other words, his personal opinion should have a special status => entitled.


it deserved that label IMO


you are 'entitled' to that opinion.


Hard to deny he has a good way with words!

I can't speak for the author Rich is replying to, but I have seen many in the community comment on the opaqueness of Cognitect, even comparing it to Apple. That's not necessarily bad, but it does have the unfortunate effect of letting some people's imaginations run with negativity in their assumptions about a company's motivations.

Even if Cognitect did make money on Clojure, not sure why that should be a source of frustration. It's quite an amazing language, people should have some reward for their contributions to the industry, right?


By the way, Clojurescript is one of the greatest tools I've ever experienced in the software industry. And it is maintained by a real smart guy that gets paid by Cognitect to work on it. Isn't this a case of Cognitect spending money to improve free tools for the world? Which is the opposite of the original article's accusations?


Maybe it has gotten better in the last year or so, but I’ve been extremely disappointed in a) the scope of semantics divergence between Clojure and clojurescript, and b) the performance of clojurescript for anything larger than toy examples. After reading a blog post about scalajs[0], I came away pretty convinced that battle would be uphill. It’s just too hard to replicate one dynamic language’s semantics in another dynamic language without embedding huge and slow runtimes along with it.

[0] http://www.lihaoyi.com/post/FromfirstprinciplesWhyIbetonScal...


I don't know what problems you were having, but the performance has been extraordinary for the enterprise app that I work on (now 3 years old). In fact, the product would not even exist without the tools clojurescript brought to the table.

I don't know what you mean when you say the semantics are different between the two versions of the language, they really have the same overall design and I feel like I'm working in the same language when I switch between them.


Looks like you forgot to link to the Scala.js blog post. FWIW, as a Scala.js user the combination of Bucklescript + Reason ML looks pretty compelling: static types and lightning fast build times.

Haven't used Clojurescript but I'd imagine the code-change-reload cycle is quite fast compared to Scala.js, which while absolutely excellent in many ways, suffers from the dog slow compiler that is scalac (Scala collections blowing up generated binary size is the other drawback that comes to mind).


> the code-change-reload cycle is quite fast

I work on a 20K line enterprise CLJS app. Due to incremental compilation where only recent changes need to recompile during development, each code change (meaning, saving some source files) is on average 1 second of recompilation. With the Figwheel tool, there is no manual reload required, as it automatically refreshes the browser to reflect your most recent change.


> each code change (meaning, saving some source files) is on average 1 second of recompilation.

That's actually fairly slow, I'd expect pretty much instantaneous (hot reload is nice though). The overhead of Bucklescript, for example, is at most in the 10s of ms for code changes (saw a 2017 Strange Loop talk where the presenter claimed 200ms to compile the entire project).

Scala.js is around 2 seconds for shallow changes (affecting only one source file), which over time is a productivity drain, those seconds add up when doing front end work.


Always wanted to try bucklescript. Even has built-in persistent data structures, which is a win over purescript.


Sorry abou that, just added it.


Your claims are baseless. If there are any semantic differences between clojure and clojurescript they are so minute that I'm not aware of them. I'm a full stack developer and use both daily. There are no performance issues inherent with using clojurescript either. I say this having made a non trivial UI and pushing loads of data through it and seeing what everyone else has made. Check out precursor app.


There is a significant amount of divergence in semantics. I’m not sure why you would try to convince anyone otherwise...the clojurescript developers acknowledge this completely upfront.

https://clojurescript.org/about/differences

In my experience, all of the stated benefits of clojurescript become more and more tenuous as your intensity of use increases. Hello world seems fantastic, todomvc still seems pretty cool, but by the time you’re doing full size apps of meaningful complexity, you really start to see the limitations. In order to get any meaningful performance out of it, I ended up having to rewrite and experiment like crazy...the code looked like nothing I would have written in Clojure, using completely different idioms and data structures. And while the prototyping was fast, in the end it took me far longer to write and then iteratively optimize than it would have to write an equivalently fast version in scalajs or typescript. Maybe your experience is different, but my experience is my experience, and it most definitely is not baseless.


I've never had to make a context switch between clojure and clojurescript. If differences in semantics means I have to change how I think about solving the problem at hand, then that has been pretty much non existent in my experience. Of course with one you have browser APIs and the other is java, but when it comes to building up and transforming datastructures everything I've been doing works the same on both.

This is also why most the time you can just tack on a "c" on the extension and you have something that works on both clojure and clojurescript.

Performance is not an inherent problem of clojurescript. It was just the way you coded you prototyped your app. Your experience is valid but don't blame the problem on the tool when it was the way you solved your problem before you optimized it.

I absolutely mean no disrespect to you but I don't want your comment to dissuade others from trying out what has essentially been a utopia for me. It has allowed me to build non trivial webapps without having any familiarity with functional programming or lisp. The feedback loop is so damn tight that I was productive without knowing much of anything.

But maybe that's okay. If the everyone else is constantly updating their build tools to every flavor of the month and having to learn new versions of javascript, that gives the few of us who are mastering clojure/script a bit of an advantage.


> I've never had to make a context switch between clojure and clojurescript. If differences in semantics means I have to change how I think about solving the problem at hand, then that has been pretty much non existent in my experience. Of course with one you have browser APIs and the other is java, but when it comes to building up and transforming datastructures everything I've been doing works the same on both.

In clj:

> (+ 1 "1")

java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Number

In cljs:

> (+ 1 "1")

"11"

Now I get it...not that big of a deal, right? That's what I would say given a trivial example of something like this. Sure, this problem might not come up very often. In fact, for a team that I worked with, it only ever came up once...it's just that that one time that it came up, it corrupted 3 months worth of data. Would tests have caught this? Of course...but if you are confident in your knowledge of the clojure language, and you assume clojurescript is semantically equivalent, you would expect an exception to pop up in your repl during development, so if it works fine in clojure, why write a test for it in clojurescript?

I understand why the cljs designers would do such a thing...think of the performance implications of having to generate type checks code for every possible arithmetic operation! But it absolutely was a context switch for that team (full stack clj/cljs), and the consequences of the developers not correctly context switching was horrific. Nothing quite burns bridges with entire languages like silent errors do.

I'm fine with people trying clojurescript. FWIW, my personal experience with it was never as bad as that one team's experience. Maybe they'll never come across such a dangerous situation, hopefully they don't. But on the rare occasion that some third party web service dependency decides to serialize BigDecimals as Strings instead of Doubles, they deserve to be warned.


To be fair, in your example, the compiler does warn you:

      WARNING: cljs.core/+, all arguments must be numbers, got [number string] instead. at line 1 
Also, Clojure.spec would enforce it.


I have to agree that it is much more likely the code was not written well or idiomatically if there were performance problems. Still, I'd be very surprised that the problems actually were there.

And I actually test my clojurscript lines that I write in a JVM repl! Semantics between the two languages are virtually identical, I can test out my ideas for the JS target in a Java environment. Perhaps the OP has a different definition of "semantics".


I have two questions.

1) You wrote:

> It’s just too hard to replicate one dynamic language’s semantics in another dynamic language without embedding huge and slow runtimes along with it.

I don't understand this. Clojurescript's "runtime" itself most compiles away in Closure advanced optimizations stage (in fact a compiled Hello World Clojurescript app is only 1 line of JS -- no added runtime at all). I don't understand what about the Clojurescript runtime process should be "huge" and "slow." This contrasts with other languages like Elm that do indeed embed a large runtime with the program, but Clojurescript does not do this.

2) I am genuinely curious what performance problems you had. I'm working on a very large Clojurescript app that processes dozens of real-time incoming data points every second over a websocket and performs real-time analytics and graphical display. If ever there was a test for performance, this would be it. Aside from the rare and simple bottleneck that needed some extra thought (maybe 2 or 3 such moments in 3 years of development on the project), there have been nearly no obstacles relating to runtime speed for the app. The 2 or 3 bottlenecks I mention had minor solutions and would have occurred in any language, and were very easy to resolve. And Clojurescript's fast, immutable data structures have inspired major libraries and even other languages entirely. They are battle-tested and performant. So I'd like to know what specific issues you had, as that would be educational.


> I don't understand this. Clojurescript's "runtime" itself most compiles away in Closure advanced optimizations stage (in fact a compiled Hello World Clojurescript app is only 1 line of JS -- no added runtime at all). I don't understand what about the Clojurescript runtime process should be "huge" and "slow." This contrasts with other languages like Elm that do indeed embed a large runtime with the program, but Clojurescript does not do this.

Clojurescript now does a good job with Closure's advanced optimizations, but it has upper limits to how well it can do. For a full sized app, you can expect clojurescript's runtime code to bloat to 100k to 150k...which isn't the end of the world, but it certainly isn't good either.

While clojurescript and javascript are both dynamically typed, their type systems are semantically different. In order to approximate the semantics of the clojure type system, clojurescript has to build its own dynamic type checking system into a system that is already dynamically type checked. FWIR, the reason that clojure.spec was built into the standard distribution of clojurescript (whereas it is an optional library in clojure) was so that the compiler could perform type erasure on code with type hints...something done by default in static languages like bucklescript, scalajs, and typescript.

So while clojurescript does a good job with dead code elimination specifically, thanks to the closure optimizer, it is still a language that is inherently hard for compilers to otherwise optimize.

> 2) I am genuinely curious what performance problems you had. I'm working on a very large Clojurescript app that processes dozens of real-time incoming data points every second over a websocket and performs real-time analytics and graphical display. If ever there was a test for performance, this would be it. Aside from the rare and simple bottleneck that needed some extra thought (maybe 2 or 3 such moments in 3 years of development on the project), there have been nearly no obstacles relating to runtime speed for the app. The 2 or 3 bottlenecks I mention had minor solutions and would have occurred in any language, and were very easy to resolve.

The internet is full of examples of clojure programmers asking how to optimize code up to the already pitiful levels of performance that you can get out of javascript. Every language has it to some degree, but for some reason, it was always a 10x-100x difference for me. Collections in particular were always really bad for me. And the suggestions I received from more experienced clojurists always ended up pushing me away from what I considered to be idiomatic in clojure. Use defrecord instead of hashmaps, use javascript arrays or vectors instead of seqs, use goog.stringbuffer instead of str, use type hints whenever possible, etc.. Fast clojurescript and "idiomatic" (whatever that is supposed to mean in a lisp) clojure were far enough apart that it might as well have been scheme vs clojure.

> And Clojurescript's fast, immutable data structures have inspired major libraries and even other languages entirely. They are battle-tested and performant.

Clojurescript's immutable data structures are indeed pretty fast for immutable data structures run on a javascript runtime. But they are hardly fast. In fact, here[0] is an example of what I was talking about before: cljs written in an idiomatically clj style that performed terribly when used in cljs. And the answer on how to speed it up was to make it more like javascript!

I'm well aware of the rounds of praise that Om got when they showed how using cljs' native immutable data structures sped up React code over that written in javascript. I'd be careful to extrapolate too far with that. That optimization happened to involve a niche benefit of immutable structures (equality checking can use O(1) reference equality instead of O(n) structural equality) addressing a niche bottleneck in React (equality checking in the virtual dom). Overall, immutable datastructures tend to be about the same speed on most operations, but drastically slower on some operations, and drastically more memory hungry to boot. On servers with knowable processing power and knowably large quantities of jvm memory, that's often a tradeoff worth making for the semantic benefits of immutability. On some random user's computer using whatever javascript VM that they likely chose without consideration for how I would use it, I always felt bad making that tradeoff.

[0] https://stackoverflow.com/questions/21721028/how-to-improve-...


Agreed - Clojurescript is a ton of fun on the frontend!


This kind of drama is not healthy for technology. Do yourself a favor and don't waste time reading this, nor the original article it's responding to.


I think Rich Hickey has an excellent point about the hurt that these kind of rants cause to people in the open source community. I can't imagine this guy would ever go up to Rich Hickey and yell "Fuck You" at him in person, but somehow he feels okay about doing it from behind a screen. To quote from the linked post:

> And, if you are talking about Clojure, you are talking to me. The indirection doesn't mask the attack on people, their work and their choices.

> I have to say now to those for whom such expressions are cathartic - they hurt people, a lot. I don't believe the sentiments in the post are widely held - most people who are happily using Clojure aren't as vocal. But it doesn't take many arrows to bring someone down.

> Every time I have to process such a diatribe and its aftermath, and its effects on myself, my family, and my co-workers, I have to struggle back from "Why should I bother?", and every time it gets harder to justify to myself and my family that it's worth the time, energy and emotional burden. Every time a community engages with such a diatribe without calling it out, and decrying its tone, the civility of our discourse and treatment of others heads further down the drain.

These are the people who're building the technology we're using, and if something is hurting them and making them not want to go on with their work then that IS bad for technology. You might not care either way for the debate, but no-one should tolerate the tone that the original author used.


I actually disagree massively with this point. I love Rich Hickey's work, love Clojure but it's kind of an important principle that you have to be able to separate attacks on ideas or systems from attacks on people. If you identify yourself with an idea and I attack it, it's your responsibility to not take it personally and not a reason for me not to make a statement.

If you can't do that, you can't have debate, or science. You can only have tribalism and identity politics.


I agree but only when the "attack" is within civil bounds, which the original blog post crossed(). Otherwise you create a situation where people can attack people while hiding behind the claim they are attacking idea. It doesn't help conversation to support saying Fuck Feminism, but I have no beef with Feminists.

I believe the original post that Rich Hickey is responding to was more a misguided attempt at humor and being provocative than an actual serious attack.


> I believe the original post that Rich Hickey is responding to was more a misguided attempt at humor and being provocative than an actual serious attack.

Really? It seemed very earnest--jerkish, but earnest--to me.


Passages like this made me think the author's intent wasn't totally earnest, but going for melodramatic effect.

Now that the party is over and sunrise begins to reveal the plastic fairy lights and overdone makeup, I begin to question my life as well as the values that I am looking for within it.

And the opening was just shock value, or an emotional outburst, not that he hates and wants to move on.

...Fuck Clojure. There I've said it and God it feels good.

More misguided than malicious, which is how I would interpret it if the intent was purely earnest.


> it's your responsibility

is it? solely? so-called "debate" is a two way street, right?

sometimes "attacks" are sloppy and vicious, and it's a bit entitled to expect other people to pick apart your messaging to glean the signal in the noise.

as humans, communication is a physiological process. pretending it's cold machinery rarely ends well.


Right, I agree with you re. Two-way streets, but Hickeys comment literally states that any attack on Clojure is an attack on himself, which I don’t think is fair under the same standard you’re saying should apply... does that make sense? I don’t know if I’m explaining it right.


If you read the additional comments in the original article, comments by the same author, you can see that Rich is directly addressing those when he identifies himself with the system.


I can't tell if you were suggesting we should read the original article only, but not this response?


Neither. I had a typo.


After reading the original article and Hickey's response, I'm significantly less sympathetic to Hickey.

Here's the question: would Rock Hickey be Rich Hickey without Clojure? Would Cogitech exist without Clojure?

I understand both sides. I know the frustration of living with someone's arbitrary decisions. I also know the frustration of getting nothing but attacks from something I have worked hard to give away.

But Hickey has a higher standard here. He's gotten a lot more from the community than he admits in his response. It reads like he wants sympathy for all he has missed ot given away because of his work on Clojure. That's not a good response.


I personally don't necessarily agree with the 'significantly', but I do agree that some of the concerns raised, however poorly and entitled, are valid.


So would rich be rich without the language that rich built? This is a hilarious way of looking at it. There answer is yes.


Great comment. Cognitect, and it's ownership/dominance of the language, is one of the more unfortunate things to happen to clojure in it's evolution, and should serve as a learning point for future language creators.

I wish Rich had been able to find/take a different path and developed more of a community with a "social contract" rather than keeping clojure a semi private project which users should be grateful for the ability to use. It would bring more participation from a wider community which would make the language and community far stronger in the long run.

Recent interactions I've had with the ReasonML project are night and day different than clojure.

At this point it feels like there needs to be a clojure like language (fixing some problems like startup time) that embraces more of a social contract with the community.


An unfortunate thing? That a project's own creator ensures the quality of its future?

What I've realized as I grown older is that the majority of people are not worth my time. Loads of people will actively waste your time and talk about things without knowledge. If you listen to Rich speak in any of his presentations or interviews, it's pretty obvious he knows the same thing and his inner circle are extremely intelligent. If you want to progress you must eliminate the garbage and keep the most quality people you can around you.

We now have like 5 main versions and variants of javascript that came out in the last few years that all look like complete rubbish (purely my opinion). There seems to be a new build tool coming up every 3 months. Everyone is making a library for things as basic as calling an API or padding a string. At one point not so long ago I was one of the programmers who needed said libraries to get work done.

The code for clojure is open source. If anyone absolutely must use clojure they can do a better job than Cognitect just fork it. Or keep learning the new version of javascript that inevitably comes out every year.


The original article (which has been flag-killed) was pretty poor, but included this link in the comments: http://www.lispcast.com/cognitect-clojure


A tangent, but I find it interesting that they don't make any money from Clojure conferences. There are a few hundred attendees paying 500 USD/EUR, and they organise several conferences per year. I guess paying a few people's salary is good too according to the motivations expressed in the text.


As the author of the 'diatribe', I'm concerned that a personal account of my experience with a programming language and my reasons that I'm lacking motivation to continue to program in that language has generated this type of response. Yes, it was personal. Yes, it hurts to be rejected. Yes, it's a part of life.

I felt that Rich's response was fair. There is so much frustration and pain in the search for perfection. He has given his heart and soul to the language so of course it was expected. I'm really glad he still cares so much for the language. It's rare to see such a raw, passionate reply like that and I know that the language is in great hands.


Poor response. Basically "we're not actually evil, just trust me". Why should it be a question of trust? A programming language that is controlled by one for-profit organization is an obviously bad idea. And the last paragraph, where he suddenly goes straight for a personal attack is completely uncalled for. You, a rockstar creator of a language are in no position to personally insult your users. Never punch down.

Of course Clojure zealots lapped it up.


The initial article and this rebuff are a lot to do about nothing.


good


I get that this is important to the Lisp crew, but is this at all relevant to the general audience of HN?

What's the takeaway: avoid Closure because of one drama? Rich is right about everything? Copmuters are terrible?


My takeaway is treat people well, appreciate the community you choose to participate in, spend reflecting on your role within it and whether it's a good fit for you any longer, and recognize that if it isn't, that it's okay to move on. But again, treat people well.


And acknowledge when you are getting things from the community that you couldn't get otherwise.


The first version of HN was written in a dialect of Lisp. I can think of no messageboard on the ‘net for which Lisp-related stuff is more topical.


> I can think of no messageboard on the ‘net for which Lisp-related stuff is more topical.

I acknowledge that in my OP. Do you think it is possible that there is a site more focussed on Lisp stuff than HN that you are simply unaware of?


That is irrelevant here and you are arguing out onto a tangent for no meaningful reason.


Did you mean to respond to the reply to my post? I didn’t introduce this topic, and I’m trying to understand what about my OP caused the confusion which prompted the response.


Yes, you introduced the idea that HN's readers wouldn't be interested in this. Then, you went off on a tangent about whether or not HN is the right site or best site for lisp stuff. It's just filling the site with noise when people engage in those kinds of empty remarks.


I know nothing about Clojure but I'm always interested to read how open source maintainers interact with their community.


Why wouldn't HN readers care about lisp news?

Btw Closure and Clojure are two different things.


Oh shit, they are too




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: