1. 9

    This reads like a long enumeration of reasons to use clojure in general (macros, code is data is code, etc.), but there’s very little argument about why it’s good for compilers in particular. What makes clojure better suited for that than, say, OCaml or Haskell?

    1. 6

      I find most arguments for X is greating for writing compilers pretty weak, even the more common ones about OCaml/Haskell/Standard ML (and I like both MLs and lisps a lot). Any high-level language is great for writing compilers. As far as I’m concerned, the only ones that aren’t “great” (where “great” means “easy”) are ones where you need to bring your own standard library and do manual memory management (e.g. C).

      1. 2

        You can still talk about why macros, code is data is code, etc are particularly useful to writing compilers. What do they let you do that you couldn’t do otherwise?

        1. 2

          Sure I’m not saying all programming languages are identical. But the awesome parts of languages are awesome no matter what the domain so that’s why I find the arguments about being good for compilers weak as if you can’t easily write compilers in any high level language.

          1. 5

            I think Lisps in particular are so good for writing compilers in particular because they make treating code as data trivial, which is exactly what you want to do in a compiler, because it needs to represent code in a data structure somehow anyway.

            Of course, if the parsing is particularly involved, a Lisp doesn’t offer that much more. It’s mostly useful if you’re using s-expressions throughout. But if you’re not using an s-expression syntax, languages with pattern matching and first class support for ADTs will be at a distinct advantage over languages without those (hence the reason SML is so popular). Optimizations and term rewriting is basically pattern detection and manipulation. A language without first class support for those will give you more friction.

            1. 2

              Part of it is that I don’t like the idea that novice programmers will be turned off by compilers because they always read that sml or clojure or C (or whatever) are great for building compilers and since they don’t know sml or clojure or C it’s not worth trying to build a compiler.

        2. 3

          This is a good talk directly comparing the trade between writing a compiler in Clojure and F#.

          1. 1

            I read this thru earlier and it made very little sense to me. I re-read it and I think what’s going on here is that they’re talking about the fact that using lisp to write a compiler for a lisp is a good fit, but I think they just straight up forgot to say what language it was that they were compiling? Anyway it’s not particularly coherent as-is.

          1. 1

            There isn’t any evidence presented in the article that composability (which is not metricized) helps any more than more formally explored forms of machine learning.

            Here’s an example of a flawed argument from the article about why neural networks can’t do NLP: “Pixels come from dumb sensors, but as we have seen, words come from people with rich models of both the world and likely listeners.”

            1. 1

              Last I checked, existing AI approaches can only produce expert systems, and aren’t able to do effective transfer learning and self directed learning. A general purpose AI needs to be able to learn independently to solve novel problems that it hasn’t previously encountered, and to do that efficiently it must be able to leverage existing learning from other contexts. As the article states:

              The set of possible situations is effectively infinite because situations are composed of combinations of an almost infinite set of possible pieces. The only way to match that complexity is to be able to dynamically compose pieces to fit the situation—we need the ability to combinatorially choose model pieces to match the combinatorial complexity of the environment.

              Meanwhile, I’m curious what specifically you’re claiming is flawed in the argument that neural networks doing NLP have limited and superficial understanding of the content. That’s demonstrably the case.

            1. 5

              Fast or elegant. Writing Java in Clojure for higher performance is meh. This is what we get when trying to use a too high level of abstraction. It is really good that we have a simple way to observe performance and fix the bottlenecks though.

              1. 7

                The reality is that idiomatic Clojure without any optimizations is fast enough for vast majority of situations. Clojure is already significantly faster than a lot of popular languages like Ruby or Python out of the box. So, the amount of times you actually need to do these kind optimizations is pretty rare in most domains Clojure is used. However, having the ability to tweak performance to this level is really handy when you do end up in a scenario where that’s needed. I’m very much a fan of writing code with maintainability in mind as the primary concern, and optimizing things on case by case basis as the need arises. Clojure is hands down one of the best languages I’ve used in this regards.

                1. 1

                  Clojure is already significantly faster than a lot of popular languages like Ruby or Python out of the box.

                  Any sources, if you don’t mind my asking?

                  1. 3

                    Totally anecdotal, but my rewrite of the Riemann monitoring system from Ruby to Clojure improved throughput by something like two orders of magnitude right off the bat, and that was the first thing I ever wrote in Clojure. With a little work, we went from ~700 events/sec (in ruby) to ~10 million events/sec per node. Not an apples-to-apples comparison there–that’s years of optimization, batching and network tricks, and different hardware, but like… coming from MRI, the JVM was a game changer.

                    1. 2

                      Here’s a post from AppsFlyer discussing a significant performance boost when we moving from Python to Clojure.

                  2. 1

                    I completely agree with you. My only problem is that is very hard to sell Clojure to people. Both clients and co-workers. Clojure and F# are the two default languages I use a lot for writing code for myself. Unfortunately team mates and clients force me to use Python, TS, C#, etc.

                    1. 3

                      My team’s been using Clojure for close to a decade now, and what I observed over that time is that developers experienced in imperative style often have a hard time getting into FP. Yet, when my team hires students who have little to no programming experience, they’re able to pick up Clojure very quickly and tend to love the language.

                      I think the big problem is with mismatched expectations. People build up a set of transferable skills that allow them to quickly move from one language to another as long as those languages are within the same family. If you learn a language like Ruby then you can quickly pick up Python, Js, or Java. You’ll have to learn a bit of syntax and libraries, but how you approach code structure and solve problems remains largely the same.

                      However, using a language like Clojure or F# requires a whole new set of skills that you wouldn’t pick up working with imperative languages. People tend to confuse this with FP being inherently more difficult as opposed to just being different.

                1. 4

                  Is anyone using natively-compiled Clojure for anything? Clojure is seeming more attractive lately, given:

                  1. there’s a natively-compiled option
                  2. ClojureScript seems like the best alternative to writing JavaScript/TypeScript
                  3. new tools like Babashka have made scripting with Clojure possible
                  4. Rich Hickey and the language are now being supported by Nubank
                  1. 2

                    Looks like natively compiled stuff is mostly getting use for developer tooling like clj-kondo. Calva makes heavy use of this to provide intelligence for VS Code. I’ve used Babashka for some internal tooling and scripting, and it’s definitely a great way to do automation.

                  1. 1

                    @yogthos I’m really intrigued by this idea that the “real” hardware design underlying the PDP-11-like abstraction is more like a functional programming model…could you elaborate on that or link to more reading? I’ve read that ACM paper but it’s pretty brief. So maybe I just don’t understand the link to FP. Thanks.

                    1. 1

                      I don’t really have another paper handy, but basically what it comes down to is shared mutable state. The reason FP is a better fit is because you structure your code as a series of data transformation pipelines, and state is carried explicitly between them. This model maps much better to how a modern CPU or a GPU actually works internally. So, if we embraced a programming model without shared mutable state then it would map much closer to how hardware works and avoid the need for what’s effectively a VM layer in between.

                      1. 2

                        That makes a lot of sense. Thanks!

                    1. 7

                      Counterpoint from Planning & estimating large-scale software projects:

                      Engineering does not work in a vacuum, and there are commercial contracts that will be signed, at a high level, without your involvement. Deals that will have been agreed before you joined the organization. “Tie-ins” with other companies that have specific launch dates. Marketing and finance departments that want to know when they’ll need to spend £xm on producing a Christmas ad campaign.

                      Entire teams of people, who aren’t software engineers, and are used to being held accountable for delivery dates in their fields, will expect you to be able to tell them when your part of a project is likely to be done.

                      1. 3

                        Thing is that if you don’t involve your technical people in the initial project planning when you decide on timelines and sign contracts then these numbers are just being pulled out of thin air. Expecting your technical team to commit to made up timelines and budgets that weren’t informed by technical expertise means that you’re setting up your project to fail.

                      1. 1

                        how can i buy this ebook from india ( my card was rejected in pragprog)

                        1. 1

                          Unfortunately, I’m not in the loop regarding how sales work with pragprog. I was under impression that it was global though.

                        1. 4

                          Just grabbed a copy to replace my 1st edition, thanks!

                          1. 2

                            Hopefully the new content is gonna prove useful. :)

                            1. 2

                              I bought it a fairly long time ago to help me get started on a personal project but ended up not having enough free time to work on it, so now I’ll be swinging back around and I’m sure it will help. Just gotta’ set aside some time to get back into personal projects.

                          1. 4

                            The fact that Copilot produces code with subtle bugs, such as using floats to represent currency, makes it a complete non-starter. This makes it strictly worse than using StackOverflow where at least actual people will review solutions. It seems like auditing the code it craps out will often require as much effort as writing the code from scratch. I’m also willing to be that it will be predominantly be used by people who are least likely to spot the problems in code that it produces.

                            The only situations where I can see it being actually useful would be artistic projects where there’s no objectively correct solution.

                            1. 4

                              This is a little tangential but, I often fantasize about an alternate timeline where a LISP-style language got popular instead of PHP or especially where something like ClojureScript took JavaScript’s place in our timeline, and how much more enthusiastic I would be about modern software development had that happened. It’s sort of like, at least for the type of software I’d be developing, all roads lead to JavaScript and although I’ve been using it for 20 years I (hate?) it and I don’t see that changing.

                              1. 5

                                We could have lived in the alternative universe where JavaScript was still Mocha/LiveScript, had Lisp syntax, and was exactly the same language love to hate otherwise. Surprisingly plausible.

                                1. 2

                                  Also if you just ignore the warts of JS-the-language I’m not sure that JS-the-ecosystem would’ve looked a lot better. I mean, we could hope, but I think it’s been a victim of its success and many solutions have been thought out by people without a lot of experience (because it’s so beginner friendly, which is good) and it’s basically the same thing as with PHP back then. Easy entry -> many beginners -> bad libraries get traction -> etc.pp

                                2. 3

                                  Imagine if some exec at Mozilla didn’t insist that JavaScript had to have C style syntax to be familiar. Lisp would’ve been the most commonly used language today.

                                  1. 5

                                    Just because it’d be a Lisp doesn’t mean it’d be a good Lisp. (See: Emacs)

                                    1. 2

                                      Sure, but the syntax would’ve certainly been cleaner and less confusing than C inspired syntax with Lisp semantics. Js would’ve also introduced a lot of programmers to s-expressions which would’ve likely led to more s-expression based languages in the wild. Finally, we could’ve had a single unified syntax for markup, styling, and logic leveraging s-expressions.

                                    2. 4

                                      Exec at Netscape, not Mozilla.

                                  1. 1

                                    For me the fundamental difference between the two is around how logic relates to data. OO approach couples data with the logic that operates on it. An object is effectively a state machine, and its methods are the API to manipulate and inspect its state. An OO program is structured as a graph of such interdependent state machines.

                                    On the other hand, FP approach keeps logic and data decoupled. Functions accept data as their input and produce data as their output. The state is expressed via chaining of these functions.

                                    I think there are numerous advantages to the latter approach. It makes code reuse much easier since the functions do not care about where the data comes from, and can be directly applied in different context. Data can be easily serialized and transformed in a general fashion while objects require custom approach for each type of object. Objects are both opaque and stateful, making large object graphs impossible to reason about. Data is transparent and inert, and each pure function can be safely reasoned about in isolation.

                                    1. 2

                                      I think the biggest advantage of Fediverse is that it’s largely non-commercial at the moment. Traditional commercial social media platforms compete in a zero sum game. Each platform wants to keep their users there in order to monetize them, and if people visit other platforms that’s seen as taking away from the profit of your platform. Therefore, commercial platforms tend to gravitate towards lock ins making it difficult to share media across them. This is why screenshotting things and reposting them to different platforms has become so prevalent.

                                      On the other hand, Fediverse being non-commercial means that it’s a positive sum game. The entire Fediverse grows as people join any of the platforms, and that means more users and more content for everybody. In this model there is incentive to share content across different platforms, and ActivityPub provides a standardized way to achieve that.

                                      1. 4

                                        Non-commercial isn’t the whole story; I think a lot of Fediverse applications copied the UX of proprietary social media without thinking of the repercussions. Twitter is designed to maximize engagement to the detriment of community; taking out the profit motive but keeping the design means you still have the design decisions that led to problems in communities.

                                        1. 1

                                          I find Mastodon has actually done quite a bit to address problems with Twitter UI. For example, Mastodon explicitly chose not to allow quote tweeting since that’s often used abusively. It has a great content warning system, and better ways to manage interactions with users such as blocking. I think it’s disingenuous to say that the UX was simply copied.

                                          1. 1

                                            I think the CW system as implemented is flawed; i.e. I think using tags in CWs would have allowed people to filter based on what they do/don’t want to see. As of now, I’m fine with most content enough I auto-expand things, but there are some things that I would prefer not to - the Mastodon implementation kinda desensitizes you to seemingly sensitive content.

                                            I think papering over the reply count is a small step; I’m curious what a rethink of the UX would be like to avoid all the predatory behaviours would be like though.

                                            1. 2

                                              Mastodon evolved based on user feedback and contributions from the community. The CWs might not be perfect, but it’s already much better than having nothing at all which is the case with Twitter. If people find the system to be deficient then it’s possible to have a discussion about it, and to submit patches to improve it. On the other hand, you have practically no control over the evolution of the UI on a commercial platform.

                                      1. 4

                                        Since 2017 the interest for Clojure dropped significantly, almost to zero, to a 2008 level (the language was created in 2007): https://trends.google.com/trends/explore?date=all&q=%2Fm%2F03yb8hb

                                        This sounds scary. No one would invest in such a curve.

                                        More, the founders / the company behind Clojure were bought up last year by a bank. We all know what this means in other areas.

                                        And so on.

                                        I’ve started learning Clojure a month ago. And these are my back-thoughts on it.

                                        1. 10

                                          The trends chart for Apache Spark shows interest in that technology near a 5-year low and trending downward. Interest in SQL, Java, JavaScript have been on downward trajectories for 15+ years, and are currently at an interest level metric very near to Clojure.

                                          Would it be fair to call it scary to invest in those technologies?

                                          1. 8

                                            Since 2017 the interest for Clojure dropped significantly, almost to zero, to a 2008 level (the language was created in 2007): https://trends.google.com/trends/explore?date=all&q=%2Fm%2F03yb8hb

                                            This sounds scary. No one would invest in such a curve.

                                            If you think that’s scary, wait ’til you see the same graph for Java!

                                            https://trends.google.com/trends/explore?date=all&q=%2Fm%2F07sbkfb

                                            Or C#!

                                            https://trends.google.com/trends/explore?date=all&q=%2Fm%2F07657k

                                            Or JavaScript!

                                            https://trends.google.com/trends/explore?date=all&q=%2Fm%2F02p97

                                            Or C!

                                            https://trends.google.com/trends/explore?date=all&q=%2Fm%2F01t6b

                                            Or C++!

                                            https://trends.google.com/trends/explore?date=all&q=%2Fm%2F0jgqg

                                            I used to think Google Trends correlated with language popularity, but these are pretty strong counterexamples.

                                            1. 6

                                              Right, G Trends shows even React is in a serious downward spiral.

                                              Point taken, thanks for everybody clarifying this.

                                            2. 5

                                              More, the founders / the company behind Clojure were bought up last year by a bank. We all know what this means in other areas.

                                              I don’t. What’s the concern about being owned by a bank?

                                              1. 3

                                                More, the founders / the company behind Clojure were bought up last year by a bank. We all know what this means in other areas.

                                                This also happened to Elixir and it seems to be doing fine?

                                                1. 3

                                                  Google trends isn’t really a useful metric. What’s more interesting is that there are more and more companies using Clojure commercially. For example, we had Clojure/north conference in Toronto where lots of people presented from companies that are entirely built on Clojure stack. There are lots of new companies popping up doing innovative stuff with Clojure every year. Roam Research being a good example.

                                                  The communities on Slack, Reddit, and Clojureverse are very active, and constantly growing.

                                                  There are now projects like Clojurists Together for funding open source ecosystem and ensuring that it’s sustainable. Incidentally, one of the first things that happened from Cognitect being bought by Nubank was that they started funding open source developers on Github.

                                                  Clojure is a mature language, with a large ecosystem around it, and a very active community. It’s not a hype driven language, but it’s very much sustainable and has been for many years now.

                                                  1. 1

                                                    Definitely, I choose Clojure/Script as an alternative to JavaScript web dev due to all the above.

                                                    However I still don’t feel safe, because of the language popularity. For example on the 2020 Stack Overflow Dev Survey (https://insights.stackoverflow.com/survey/2020#technology) Clojure didn’t hit the list. A presence there would be reassuring.

                                                    I see Clojure a one way path: take a deep breath, go down into the rabbit hole (yes, Clojure learning is not simple at all, Clojure is unlike others) and never look back.

                                                    1. 2

                                                      This seems like a pretty limited perspective… Learn more languages and you’ll see that Clojure is easier to learn (and better to use) than most if not all.

                                                      If the syntax, style, or ideas seem foreign, than all the better! You can write (C, Lisp, Cobol) in any language, and learning the pros and cons of each style is never time wasted.

                                                      1. 1

                                                        Clojure is the 9th language I’m learning.

                                                        So far I find it so strange like Assembly. And functional programming such a shift when I transitioned from procedural programming (C) to object-oriented programming (C++).

                                                        These makes one cautious.

                                                        For example, with React was no question to learn it, to invest in. It was the solution for the problem I was waiting for ages.

                                                        On Clojure I can’t see really that clear path. Functional programming, for example, is solved elsewhere more thoroughly and in a simpler way (https://github.com/MostlyAdequate/mostly-adequate-guide).

                                                        That’s why language popularity would be a good indicator whether to adopt it, or not.

                                                        However, on HN, the comments on this same article are more alarming: https://news.ycombinator.com/item?id=27054839

                                                        It seems to explain why the language popularity is dropping. Clojure starts as a nice promise, then problems rise, people flock away.

                                                        1. 13

                                                          Been writing Clojure professionally for a little over nine years, both on teams of hundreds and as a solo engineer. I can’t speak to popularity, but Clojure has been (and remains!) an exceedingly nice language choice for long-running services and desktop applications. It combines a well-designed standard library, reasonable performance, an emphasis on immutability and concurrency-safety without being dogmatic about evaluation semantics, just the right amount of syntax, excellent JVM interop, and access to a huge swath of Clojure and other JVM libraries. It’s a generally mature, stable language which solves data-oriented problems well. The major drawbacks, in my view, are a lack of static typing (though I’ve used spec, schema, and core.typed to some avail here), unnecessarily unhelpful error messages, slow (~5 to ~20s) startup times, and that working with JVM primitives efficiently is more difficult than one might like. And, of course the usual JVM drawbacks: garbage collection, for instance.

                                                          None of this is really new per se. I wouldn’t worry too much about popularity metrics or library churn rate–one of the nice things about Clojure is that it’s fairly stable, and libraries from a decade ago tend to work basically unchanged. After Scala, that was a breath of fresh air for me. What I’d ask, were I in your position, is whether the language’s ergonomics, libraries, and speed are suitable for the kind of work you’re trying to do.

                                                      2. 2

                                                        My team’s been using Clojure for around a decade now, and things have only been getting better all around in that time. I think the most important part is that there are a lot of companies using it nowadays as their core platform. There is a lot of commercial interest in keeping the language and its ecosystem alive and active. I don’t think Clojure will ever get big like Java or Python, but I really don’t see it going away either at this point.

                                                        It’s also worth noting that Clojure can be sustainable with a smaller community because it piggy backs on JVM and Js runtimes. We have access to entire ecosystems from these platforms, and can seamlessly leverage all the work from the broader community.

                                                    2. 2

                                                      I’m not so sure about Google trends as real data point… but there seems to be less buzz, but people are still using it.. and I don’t think there ever was a real hype.

                                                      I had noticed that my personal interest had diminished a bit and when most of the people from the irc channel migrated to Slack I didn’t join them. Stuff still seems to get regular updates and as just a casual user no Clojure release really excited or disturbed me - that could be because I’d neber used it to its full potential (likely) or that they were just iterating in small steps and not being revolutionary (also likely). I don’t think I’ve had to do meaningful changes over the years to the codebases I started between 2011 and 2013 and they run on the lastest Clojure version…

                                                    1. 1

                                                      The disadvantage is that it has been shown to be unsuited to a large proportion of applications. Specifically those in business, commerce and industry that model a large complex “external” [*1] problem domain. Consider that much of computing outside of academia, computing infrastructure, and the data sciences, previously attempted to model transformation flows and data independently. Over a decade and a half was spent on dataflow diagrams and the entity-relationship models they transformed, during the effectively discontinued era of “structured analysis” methodologies.

                                                      As an industry, it seems we are condemned to relearn the lessons of the past with each new generation, and this is an example of my “Best Ever (Ever) Silver Bullet Software Methodology and Technology Treadmill™️”:

                                                      (1) Promotion of some previously known (variation of a) method often renamed. (2) Excited adoption as a silver bullet solution for all. (3) Discovery of (often previously learned but now forgotten) limitations over time. (4) Disillusionment. (5) Repeat.

                                                      [*1] A problem domain outside of the expertise of the development team

                                                      1. 6

                                                        Not that I don’t believe you, but are you able to provide concrete examples? I’m not old enough to have lived through the era of entity-component diagrams etc..

                                                        1. 5

                                                          The disadvantage is that it has been shown to be unsuited to a large proportion of applications.

                                                          [citation needed]

                                                          Clojure is used in lots of domains for all kinds of applications today, and feedback from companies using is overwhelmingly positive.

                                                          “Best Ever (Ever) Silver Bullet Software Methodology and Technology Treadmill™️”:

                                                          Nobody is claiming any silver bullets here, and obviously each approach has its trade offs. What was said that there are problems associated with OO, and how these problems can be addressed using FP style.

                                                        1. 6

                                                          My team switched to Clojure from Java for around a decade now and we’re very happy with our decision. I copresented on on of the applications my team develops and some of the benefits we got from using Clojure that would be difficult to achieve with traditional languages like Java.

                                                          1. 2

                                                            I guess the lesson here is: Rewriting things anew is fun, profiling existing code … not so much.

                                                            Anyway, author can do whatever he prefers with his time, so go ahead!

                                                            1. 6

                                                              however willing the author was to profile their code, i don’t see what they could have done about clojure’s startup time

                                                              1. 2

                                                                Nowadays, you could probably just use babashka for that use case.

                                                                1. 0

                                                                  True. I forgot that Clojure is pretty much only open-source in the Google sense (“you can read the code, and that’s it”).

                                                                  1. 2

                                                                    i don’t get what point you’re trying to make - how would someone writing a music dsl in clojure be expected to fix the language’s performance issues when the core developers have been unable to? this wasn’t his app being slow, it was the fixed startup cost clojure itself imposed.

                                                                    1. 1

                                                                      I think that performance would be better if Clojure had a more open development story as it would distribute the work on more shoulders. That’s the cost of Clojure’s “no contributions” style of development.

                                                                2. 3

                                                                  Three different langauges (clojure, go, kotlin) also seems like a bit much, personally…

                                                                1. 4

                                                                  This is something that has been frustrating me in Clojure ever since I started using it (pre-1.0) and every time I go back to it I see nothing has changed:

                                                                  1. Terrible start-up time. Clojure could’ve been a choice for writing Android apps but just isn’t, because the Clojure developers haven’t cared enough in the last 10+ years to optimize it. In the beginning people said “JVM startup is slow” but these days java starts fast enough.
                                                                  2. Terrible errors/exceptions. The stack traces are awful, extremely long and understanding them is more of a “interpreting art” thing than anything else because often the reason something falls apart is a nil value 30 stack frames below.

                                                                  Yet none of these issues seem to be even remotely an issue woth looking at. Instead we get an idiosyncratic version of type checking called Clojure Spec and niche data structure optimizations called transducers.

                                                                  1. 2

                                                                    The startup time issue while quite present is a bit more muddy. Apparently startup time is linearly related to the amount of code you’re loading, including dependencies, since effectively you compile the universe on every JVM startup.

                                                                    For development there’s not much you can do but there’s some: avoid Lein and use the Clojure cli tools. Lein launches two JVMs and adds some layers that might be unnecessary. Precompile your deps as per https://clojure.org/guides/dev_startup_time

                                                                    For production you can generate an AOT Uberjar that at least removes the compiler from the picture. That’s your ceiling, you cannot go faster than that unless you start selecting your dependencies with startup size in mind, or going the route of dynamically loading namespaces when needed (amortizing the cost).

                                                                    Regarding the error messages, there was some work done but it covers only some cases. In my experience, the core team actually listens to complains but is batching work so the response is slow. If you have some specific stacktrace and some idea of what it should be, I would go to ask.clojure.org and open a question.

                                                                    1. 1

                                                                      Nowadays, there is babashka that covers a lot of use cases where startup time is an issue. Meanwhile, I find that ClojureScript works pretty well for mobile development. Obviously there are cases where Clojure isn’t a good fit, but for many situations it does work very well.

                                                                      Errors and exceptions have been getting a lot better in recent versions. Personally, I don’t actually know why people keep saying interpreting stack traces is hard. Vast majority of the time you just got to the end of the trace and look for the last reference to a namespace from your code. My experience is that errors tend to be very close to the line listed, and typically in the same function. There is also lots of REPL middleware, such as this one, that makes exceptions easier to read.

                                                                    1. 8

                                                                      Here’s a pitch I wrote for Clojure. One major advantage with Clojure in web dev space is that it runs both on the server and the client. Here’s comparison of different front-end frameworks for a real-world app, and Clojure does consistently well in terms of bundle size, speed, and conciseness.

                                                                      1. 3

                                                                        As noted at the top, feel free to add projects to one of these pages, depending on whether it’s a DSL embedded in another language (Python, etc.) or a stand-alone shell language:

                                                                        https://github.com/oilshell/oil/wiki/Alternative-Shells

                                                                        https://github.com/oilshell/oil/wiki/Internal-DSLs-for-Shell

                                                                        1. 5

                                                                          I just added janetsh and janet-sh to the first and second pages respectively

                                                                          1. 3

                                                                            there’s also closh

                                                                            1. 3

                                                                              Though slightly off-topic, I find babashka has a better philosophy of combining bash and clojure (ie. it doesn’t mix the two nor try to be a shell).