- instaparse: takes EBNF (and other formats) as a string and gives you a parser instantly (!!!) https://github.com/Engelberg/instaparse

- re-frame: React-Redux alternative that IMO is much easier to work with https://github.com/day8/re-frame

- reagent: React wrapper https://reagent-project.github.io/

- ring https://github.com/ring-clojure/ring

- fulcro https://github.com/fulcrologic/fulcro

More than any library, though, what keeps bringing me back to Clojure is its incredibly blissful set of persistent data structures. It's a pernicious accident of history that we are taught to accept references to mutable objects as normal, inevitable, and desirable in most CS curricula. It is much easier to develop, debug, and maintain immutable data structures instead, and I consider my good fortune every time I get to debug something in Clojure rather than in some reference-laden OOP soup.

In case anyone is interested in its ideas but is stuck with JavaScript, you may be interested in a vanilla JavaScript port I've been (very sporadically) working on: https://github.com/davezuko/re-frame. It's incomplete, and definitely lacking in many areas (documentation being the obvious one), but perhaps somebody will find it useful or want to contribute back. I've personally been using it in some internal apps for a while now.

> It's a pernicious accident of history that we are taught to accept references to mutable objects as normal, inevitable, and desirable in most CS curricula. It is much easier to develop, debug, and maintain immutable data structures instead

Except for trees and graphs and the like. immutability makes working with these much more complicated.

most of the alogrithms and datastructures that you learn in CS were developed using mutability.

I am not sure that we can even develop immutable equivalents for most of them with similar time/space complexities.

Very much a side project and I'm a bear of very little brain, so it's taking me a long long time.

Seeing Clojure and other Lisp stuff in the wild gives me hope that I can lean on enough people's documentation and source that I can eventually learn what I need.

I know some folks sneer a little at Lisp, but I really enjoy trying to learn it. I haven't felt as motivated to learn a coding language since about ten years ago when I used Perl to transfer/munge data from different LDAP systems into Zimbra.

So, thank you for sharing, this is fascinating stuff.

I wonder why.

Some developers I know and hold in high regard have almost venerated Lisp, so I've always thought there must be something to it. I just thought it wasn't something you could actually use IRL, but I was wrong. I found this out when I was recently motivated to learn Clojure, and now I am starting to grok their admiration.

The usual easy excuse is about parens, but that complaint has been put to rest so many times that it's not worth replying to anymore. (And people said the same thing about Python whitespace, but now Python is at or near the top of the pile.)

Ultimately, these complaints are superficial and serve only to justify one’s laziness.

(print "foo") vs print("foo"). same same.

There's so much more to it than this. I can say without reservation that people who do not take a couple/few weeks to learn a Lisp just do not know what they are missing, and their arguments against it are viewed as children who lack enough experience to know what they are rejecting.

If you look at things other than function calls, it starts to look different:

    let x = 5,
        y = 10
    foo(x,y)

    (let [x 5 
          y 10]
      (foo x y))

It's easy to prove anything with a sufficiently small micro-benchmark. But "one line of Java" is not equivalent to "one line of Lisp", and even if it were, nobody writes Lisp code in a style that looks like a one-to-one mapping of some Java code.

This is like complaining that Japanese is inefficient because it has thousands of characters, or that English is inefficient because it takes dozens of characters to say what only takes a couple in Japanese. The concepts aren't exactly the same, and you can't just pick a trivial example and conclude that "this has fewer than that".

In your lower example, Clojure has only one more non alphanumeric character than the other example.

Furthermore, in Lisp, you always know that you have (function-name param param etc). Reading it becomes not just easier - it removes an entire layer of abstraction (syntax rules). Also, with smart editors, you gain the ability to move these around rapidly in ways that you simply cannot do with other languages.

Funny thing is, the biggest annoyance I have when not using Clojure is having to type commas between items in data structure. [1 2 3 4 5] just looks so much cleaner than [1, 2, 3, 4, 5]. I forget who wrote it, but they complained of seeing all the mouse turds "," in normal programming languages.

    (let [x 5 
          y 10]
      (foo x y))
    (foo x y) ;; now different x and y!

  {
    foo *ptr = ...; // scope this just to this block.

  }

The braces will be there if you program sanely and care about scope.

Sure, but so is the Clojure one. So I guess it's more like:

    fun bar () {
      let x = 5,
          y = 10
      foo(x,y)
    }

    (defn bar []
      (let [x 5 
            y 10]
        (foo x y)))

The parens in lisps are significantly detrimental to its first impression, and 3rd, 4th ...

I have literally never met a developer I can show a lisp code sample to whose reaction isn't "what the hell is that?"

It looks totally alien compared to C-style langs, which is what most people learn.

With Python, that is not the case at all, basic Python can be interchanged with pseudo-code for the majority of developers from C-style backgrounds.

Pretending this problem doesn't exist, only exacerbates it, and really holds back lisp adoption in my opinion.

Young children tend to look with disgust upon many meals that adults find especially delicious. Is it a problem with the food, or is it a matter of experience and perspective?

I'm very tempted to give examples, but it's not worth it here. Suffice to say, this falls squarely in the category of "you don't know what you're missing".

In this long essay by Paul Graham - http://www.paulgraham.com/avg.html - if you're willing to search for and begin reading at "The Blub Paradox", you'll get a sense of what I mean.

And then if you want to really be enlightened, at least to concepts that really what matter regarding programming languages, go watch videos from Rich Hickey (Clojure).

I think I do. I've had the argument many times here, code-as-data, metaprogramming, structured-programming. Things I don't want, aren't worth the trade-off, and things I don't want to see colleagues inflicting on others.

I've already watched (almost) every Rich Hickey video (well his main "talks"). I love them, agree with the vast majority of what he says and it has shaped me as a programmer, but I don't agree with the final conclusion being to code using lisps ;)

Curly braces are the chicken nuggets and fries of computer science, lol.

Within about 18 months at university (80s), I learned BASIC, FORTRAN, Pascal and Lisp. Syntax, yeah, whatever.

(We transitioned to C later, to my horror, with an eye towards a future using “C with classes”)

The vast majority of the programming world simply doesn't seem to agree.

Don’t expect me to be happy about that, though.

I’ll even upvote your comment, as it does matter a little. Too bad C is what “we” settled for.

Most developers only learn a new language because they're forced to: at work, or joining an existing project as part of their hobby, or because the library they need requires it, or because its the only option available to them. At the point, the fact that it looks like C, or doesn't, won't matter. And they'll get over it. No one claims Nginx/Apache DSL is great, or terribly C-like. Or even really claim that its un-C-like. But I'll reluctantly learn it (to a minimum need) because I want my damned site up. Most languages are learned like that.

Developers who learn a new language for the sake of learning a new language will likely not be drawn in by it being C-like syntax, or not. At least, most who've gone around that rodeo a few times will quickly realize that the superficial syntax isn't that interesting -- It takes 20 minutes to learn the syntax (maybe not APL). You're in it for the different semantics.

What you need for mass lisp adoption is to get a hype cycle going, and pathetic justifications for parenthesis isn't going to get you there. Babbling about how hyper-parameterized cooperatively consistent parenthesized datastructures will change the world is likely more effective.

I think it's funny that most people who complain about this are likely coming from Java, JS, or Python, not C. And they probably would suffer a lot in C...

I've made the jump to Clojure, and to be honest, it's painful going back to other languages, but not just because of the syntax, but rather the lack of expressive power, and the excess of boilerplate. I had to do some Python work last year, and it felt like coding with a straightjacket on.

For decades, I got excited every time a new idea around lisp or functional programming and I'd play with them for weeks. Eventually, I'd get to the big question, how do I bring this idea into development environment that solves the hundreds of other ugly real-world problems I have to deal with to make a usable application? Clojure solves that by being hosted.

Immutable data structures are great, but when it's the default, it's a huge win in cognitive-overhead. Maybe that feature isn't unique to Clojure but it's certainly not a prerequisite to being called a lips or a functional language.

Singly-linked lists are cool, but almost every other type of list is cooler, being able to read, eval and print those as well is really cool.

Yes, indeed.

TBH, I developed in Erlang for 10 years and, as a result, developed a strong preference for "immutable data structures everywhere".

Unlike LISPs that I've seen (admittedly not that many), with Erlang there simply is no global data so no vars to change - it's all done via function parameters and tail recursion (Erlang has TCO baked in, btw).

For those that aren’t as familiar with Clojure - there isn’t a rails or Django for web apps, so Coast is trying to fill that void.

Getting started with Luminus was fine, but it was often very confusing and I didn't understand a lot, whereas when I added things as I needed them and checked out a couple libraries, I had a lot easier time debugging what was wrong.

What's going to make Coast different?

There are a vast many things in which I am not an expert. The pick and choose / compose your libraries / lego approach sounds great until your trying to weigh different options (of which none seem to have a wide enough install base to be truly battle tested).

Is buddy/buddy-auth the way to go for security? Or is it Friend? The former seems to receive more recommendations as of late, whereas the latter has more activity on github. These are not the problems I want to be solving when building something.

I love the language, but the quality of Clojure's web ecosystem is... questionable.

If I were to build another webapp in Clojure, I think I'd just use something widely installed like Jersey for actually interfacing with the outside world. It'll be crufty Java, but it has nice things like StackOverflow activity, massive docs, giant userbase, etc.. etc..

I will learn whichever language allows me to get my site/app done as quickly as possible at first. Later after I have refined and refactored enough to know what's up... then I may decide to change.

Nextjs (despite the javascript), Rails (Ruby is great!... not Clojure, but pretty good), Django (Python is low-pain, low-effort), etc. are all easy quick ways to actually get something done BEFORE you really know what you're doing. This is critically important for those of us who don't spend all our time doing public-facing web apps.

But given the incredible power and expressiveness of Clojure, I find no reason to believe that the best rapid web development framework could be developed in Clojure if the right motivated people attempted to do so.

I don't know how many people (Plataformatec?) were behind Phoenix, but even in its early versions it was comparable to Rails. In some ways, it was even better.

There seem to be two obstacles to doing this in Clojure. The first is that people who actually know enough about Clojure to do this are actually very busy (happily) doing Clojure for work. They don't have the personal need to build a Rails for Clojure. The second is that those who would be capable already know how to pick and choose the libraries and build their own (even better, more suited for the purpose) ad-hoc frameworks for their projects.

I suppose it could be a curse of the power of Clojure that the lack of language pain points lessened the need/motivation for experts to build their own RAD framework.

It's nice to get started on a project quickly, but often that quick start is purchased at the cost of a system that is tied together in such a way that it's very difficult to change. Human beings naturally prioritize short term benefits over long term benefits. But developers have a responsibility to their employers / clients not to pick something that makes the dev's life easier in the short term by significantly raising the cost of adapting to changing requirements in the long run.

My life has been a lot simpler since I've moved away from Django to Clojure. It's less evident in weekend projects or in the first few months of a project. But I never find myself saying to a client request "unfortunately, the way Django works, it's hard to [retroactively produce reports/get the state of the application at previous point in time/fix application logic then correct a corrupted table/upgrade just by bumping version numbers/use multiple databases/not systematically overwrite data/etc]."

OTOH, there a huge companies with successful rails(github,airbnb)/django(instagram) apps, but maybe they get away with it because the have big teams to re-architect anything.

What is your preference to interact with databases in Clojure? hugsql, honeysql, clojure.java.jdbc ?

Clojure strength is its weakness. But yes, there is a long way to make it more beginner friendly

Here's why I think "just use composable libraries" is a bad idea:

First it isn't very friendly to new developers. You tell them to go out there and find their libraries and they have zero clue where to start.

The second problem is its not very friendly to developers with a couple years experience either. Frameworks take care of so much stuff that most people don't know they need to take care of. Not just obvious things like connecting to an RDBMS but also very basic stuff that every website will need like CSRF protection, session management, etc.

And finally, when you rely on a wide variety of micro libraries you're actually relying a wide variety of other developers. What is going to have more support and development in the future: 10 libraries split across 10 developers with varying levels of commitment, or 1 framework with a group of developers working together on it?

You don't need to build your framework like Rails or Django. You could make it easier to plug in other libraries. But it should have a sane default for everything it needs for the benefit of both new and intermediate developers. Spring kinda works like this. It's easy to use Spring libraries for different parts but you can also just use your own.

Even when they could have worked without it, and they over Shadow competitors in the space, why use that shiny new router library when my framework already has an one that's "easy" to reach

And then of course the worst thing to happen to a code base, the framework it's built on falls out of favour and you can't hire devs or get security patches for it anymore

"don't put your eggs in one basket", and "developers know the benefit of everything and the cost of nothing" applies here

I think if a framework is to be successful in Clojure it needs to not be intertwined with itself in the "simple made easy" sense

Additionally if the "interface" is data like you might get lucky enough that you get multiple implementations, like many cljs libraries support the react interface

With declarative programming we could certainly keep the intention of code the same whilst changing out the implementation but it would require careful coordination between library creators and a open data interface so that new requirements can be satisfied later down the line and even then multiple variants to serve completely different approaches

That's the reason I've tried to stay away from the current Javascript madness. All of modern Javascript is built on hundreds of NPM packages that will disappear in two or three years.

I certainly will never use any language or framework in production if the main feature is "nothing is included, bring your own core features" like Flask or Express unless I'm committed to building those not-included core features myself (which I probably won't). Because if I'm bringing in someone else's package, even something that's well supported by a great and developer-friendly company like Thoughtbot, that package will likely EOL before my app does. Yes I'm still absolutely bitter about Paperclip being deprecated.

This is soooo true! I actually really like Javascript but NPM is in such a bad place and it's having effects outside of just it's ecosystem. We just built an app using Nativescript which by itself is actually pretty decent but we chose to use a plugin for a specific feature we needed. But then we kept running into problems with it and, after serious back-and-forth with the plugin maintainer, it turns out his plugin depends on another plugin that has had a known, very serious bug. And that project's maintainer has known about it for at least nine months but he has said he doesn't have time to fix it. I take that to mean he's lost interest and the project is effectively dead unless someone else comes along to take the reins in maintaining it. Which we assume means the original plugin that we chose to use is also effectively dead because it so heavily relies on the other plugin.

In the end, we just removed all of the plugins as we determined they were hostile to our productivity and routed around them by rolling our own solutions.

This might have been true back in the day before security issues were a thing, but it no longer holds true.

Particularly the case in public web apps.

If someone isn’t maintaining it, don’t use it.

(Obviously it depends; for a test framework, clearly not true, but for example for the “LEGO block” you pick for auth, or say, XML parsing... yes, it matters; the point here is specifically that the “take what you want” approach to a web framework results in scattered maintenance models for different components, and that is categorically bad for long term maintenance of a web app)

If there is no activity on the repo it doesn't mean that someone is not maintaining it.

Oh, like framework developers always know which LEGO block to include in their framework. Like Rails had no vulnerabilities in the past.

> If someone isn’t maintaining it, don’t use it.

Well, good luck with not using 3/4 (or even more) of software in existence. I bet the kernel that is running on your laptop depends on the software that hasn't been updated for 30 years.

What language can't compose libs?

The main problem is whether developers can.

To me this often is "mental dark mode". You think you're more efficient, but usually aren't.

all that to say, if there is in the Clojure ecosystem analogous, I'd like to hear about it.

om.next was before that, but it seems to be almost abandoned, also fulcro author have solved a lot of depressing pain points of om.next.

Those three work like a perfect Lego.

Experience was like.. two weeks of hair pulling, gallons of coffee and no weekends, followed by intense relief and gratitude to fulcro author Tony Kay (also pathom author Wilker Lúcio) for all that not always obvious things which make great sense in the long run. This happened to me with several great Clojure things, so I immediately knew good experience was just around the corner.

Oh and his online book http://book.fulcrologic.com/ has great general SPA insights.

Three pretty serious apps with fulcro so far.

Pedestal, on the other hand, is offering compact single data structure with linear complexity increase, plus very neat async functionality out of the box.

As for fulcro3, I have chosen it first because it was kind of successor of om.next, and in om.next I was in love with its transactional data model and all that pull syntax, - fulcro3 turned out to be even better with that.

I was and am still using reagent for simpler setups, but query language and transactions is what helps to keep sanity with larger projects.

https://www.youtube.com/watch?v=PMbGhgVf9Do

Future consideration...

http://pedestal.io/

Clojurescript on Node could be a good contender, but last time I tried it, the development experience was very poor and the power of Clojure doesn’t really shine in serverless functions, so I just use Python for that which is a perfectly adequate scripting language.

It's fairly painful compared to a normal backend, and it seems like the serverless advocates are on the super high and super low end: big product teams that can justify microservices and the associated high friction, and on the other hand users/use-cases who recoil at keeping a monolithic server turned on all the time even on a wimpy cloud service.

But if you've jumped on the bandwagon, look into Datomic - Ions are the Cloure-native Lambdas there.

But in general - Do people manually deploy MySQL, Postgres, or MariaDB on EC2 servers? No, (most) people use RDS. The servers are still there, but the management is less.

Do people manually deploy RabbitMQ? No, (most) people use SQS.

Cloud providers have been working out of the same playbook for years - provide low-level compute, watch what people build, and create managed services which solve common use cases. Developers love these services, because it's less infrastructure to be on call for, and they can build products faster.

Lambda and Serverless represents the inevitable conclusion of the natural evolution of the cloud. Parts of it are still painful, but undoubtably it's getting easier and more capable.

RDS and Fargate are not serverless, bc you still have to think about scaling strategies, appropriate network topologies and you might still have to wake up at night to tweak JVM or kernel settings in your containers.

GraalVM could totally change this.

You can reuse an awful lot of code between Clojure and ClojureScript using cljc files. In my experience it is rare to have code that you want to reuse between the browser and server that you can't make portable.

Even asynchronous code with core.async is portable! In browser, it will be single threaded while on JVM it will be multithreaded, without any extra work from you.

Specifically the 'Component' library. I really didn't enjoy working with it and it one of the most complex to understand parts of our web application.

So while this seems like a fun set of slides (I have not watched the presentation yet), it's not what I would call a great introduction to Web development in Clojure overall.

I would totally start a project with pedestal today though.

This new library, `clip`, might sit better with you:

https://github.com/juxt/clip

[1] https://github.com/weavejester/integrant

[1] https://github.com/duct-framework

It makes me wish José (creator of elixir) would have chosen Clojure syntax instead of Ruby.

http://lfe.io

    (defn inc! [id]
      (kc/exec-raw (format "UPDATE articles SET count = count + 1 WHERE id = %s" id)))