_halgari's comments

Same halgari, yes :D.

Yeah he took it from Bagwell, and adapted it, but in general there was a whole discussion way back in the day (~2012) questioning how creating this much garbage by boxing and throw away collections could ever be fast. Datomic is another example: making an immutable DB is a dumb idea right? Well what if storage was super cheap, and almost free? Well then maybe it's not such a bad idea.

So a lot of the Clojure community is based on this idea of taking ideas from way back in the 70's and saying "Well everything has changed, what works now that didn't then"

Oh for sure, it's a bit wonky on the JVM due to the lack of tail calls, but that sort of thing can be done via full-stack bytecode transformation.

But these people are doing this in Clojure, which is quite removed from the JVM bytecode, and talking about how it solves so many distributed problems, which I just don't see happening.

That was my issue for a long time. I even talked with their founder several times on twitter back a few years ago. Each time I was greeted with buzzwords, that I knew the meaning of but I think they assumed I didn't.

They would claim grand things like having solved the issues with continuations and delimited continuations, distributed process migration and a whole host of other very hard problems that haven't been solved in the past. I would ask their founder: "right, so you know that delimited continuations have problems with accidental captured scope, they run poorly on the JVM, how did you solve this, have any papers I can read?", and all I ever got was that Clojure, immutable data, X and Y would fix these issues and you just had to wait and see what they were cooking up.

That's when I knew they had no clue what they were doing. I'm all for pushing the boundaries of tech, but if you're doing something attempted many times before, you at least need a good elevator pitch as to why it's solved now.

I think a great example of this done right is Rich talking about Clojure. People would ask "isn't immutable data expensive to reclaim and allocate". And his reply was always that the JVM's GC was just that good that the benefits to be gained from immutable data outweighed the marginal performance penalty of the amount of garbage collected. What changed since the old lisp days? Well we now have GCs that are super fast and JITs that can optimize dynamic code well.

That's the sort of laser focused vision I never saw from Red Planet labs. You gotta get that problem statement and the solution out early, refine the elevator pitch and be able to articulate to people who know what they're talking about how you're going to succeed where others have failed for decades.

Author here, a few things to keep in mind:

Firstly, I wrote this about 3.5 years ago. I was wondering why people were suddenly commenting on it and now it all makes sense.

Part of the fun of writing articles about this is watching everyone argue about what language can be forced into representing types in a given way. Yes, I assume in any situation that if I want a feature X in a type system, that somehow Haskell can be forced to give me that feature, but that doesn't necessarily mean it will fit with the ecosystem of the language or that that's the only feature I'm looking for in the language. So saying "someone hasn't done their homework if they think X can't be done" isn't relevant, what is relevant that I'm not aware of a language that provides the type system features I want combined with acceptable set of trade-offs.

So anyways, I'll stick around for awhile and see if I can answer any questions. Thanks for the discussion, all!

Why compile ahead of time when you know nothing about what the target platform is capable of? Why compile before profiling to make sure you run the correct optimizations? Startup times are sometimes important, but it's not the end-all-be-all of computer science.

Closed source I understand, they must have something in there they don't want to give away completely for free. But "no commercial use" just cuts out something like 90% of the user base. Because depending on your definition of those terms it would also apply to anyone building anything with it that they plan on selling in the future. Even paid tutorials on how to use it would be out of the question.

It's like "how to not get people to use your tool" 101

From the license:

> You may not use REBL for commercial use.

Correct, the first game to use ECS was Dungeon Siege back in 2002: https://www.gamedevs.org/uploads/data-driven-game-object-sys...

Anyone who has done serious performance testing on a DB knows that there's a massive gap between initial findings and a well tuned system designed with the help of the database maintainers. I've seen some nasty performance out of Riak, Cassandra, SQL, ElasticSearch etc. But with each of those, once I talked to the DB owners and fully understood the limitations of the system it was possible to make massive gains in performance.

Databases are complex programs, and if I ever wrote one, it would be infuriating for someone to pick it up, assume it was "just like MySQL" and then write a blog post crapping on it because it failed to meet their expectations.

"Generalization of abstraction" sounds a lot like "a maze of twisted passages, all alike"

That's exactly what I don't like about some languages, if everything is a function, then it's all a big ball of mud. The only thing you can do with a function is call it.

I'd rather have classes of capabilities. Some things are callable, others are iterable, some are printable. But if it's truely about abstraction generalization, that sounds like a mess.

Kind of saw this coming after the third reimplementation in yet another language. And why Rust? 2 years ago they decided to use Rust to implement a new language (IIRC Rust wasn’t even 1.0 at that time). That’s a huge amount of technical risk.

I wanted to be exited about eve, but it was always too light on details, had too much risk to ever allow it to succeed, and after several pivots it failed.

This story probably been a bit different if only it was a bit less ambitious, and a lot more pragmatic.

Well, for the first time since the langauge was created you can now do `brew install clojure`, and then `clj` on the commandline and get a repl. I would have loved something that painless when I was learning Clojure.

I had the great pleasure of interviewing Zach Oakes (author of nightcoders.net) the ~1hr podcast is available here: http://blog.cognitect.com/cognicast/130

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?

What's interesting is that for me Clojure was my first lisp. One of the main reasons I never learned lisp before Clojure was all the parens that made the language impossible to read. Clojure cleans up the "normal" lisp syntax quite a bit, and that made it a lot more palatable.

Beauty is in the eye, and all that, but CL code still makes me want to claw my eyes out.

Maintainable code is very important, unless you work for some company that just produces code then dumps it on a client. The key is to balance functional purity with understandability.

Let's take something like Clojure. I get immutable data, sane multithreading (I haven't had thread related problems in my code for years), etc. All without monads. Whenever I've started doing things like introducing state monads, or seen code involving applicative and "free" stuff, it basically becomes an opaque blob of functions. Zero ability to have the code self introspect or to leverage that pile of functions.

The better method is immutable data and data-first designs. Data is searchable, introspect-able, and transformable. Most CT stuff is all about composing functions via functions. Making your entire system opaque, at least from the point of view of the program itself.

"In particular, algebraic effects are combined seamlessly, whereas monad transformers are needed in the monadic style." Implies otherwise...but to be frank, I don't care. As long as I can get these features without type pollution (as monads do in Haskell) then I'm happy.

Most of his stories are more related to immutable data, and proper programming, than anything else.

It's the design patterns if you are trying to use a 100% pure language, which is a waste of time. Here's the thing...at some point being functionally pure stops paying off. At some point you end up paying more to fit your work into a pure model, then getting any benefit from that model. This is the problem I have with CT. It seems cool and may make you feel smart, but it doesn't actually provide any benefit to writing maintainable code

Every time I've studied Category Theory I've later found a better, simpler, easier to understand, cleaner approach to doing the same thing, perhaps with a little mutation.

And then there's languages like Eff that completely remove the need for stuff like monads: http://math.andrej.com/eff/

So yeah, for me it's been more-or-less a waste of time reading up on this stuff.