finalfantasia

“Swift has turned into a gigantic, super complicated bag of special cases, special syntax, special stuff…”

— Chris Lattner, 2024

https://blog.jacobstechtavern.com/p/apple-is-killing-swift

For those who are interested, here is the official statement from the ClojureScript team regarding Google Closure Library going into “maintenance mode” and its impact on ClojureScript:

https://clojurescript.org/news/2024-01-24-release

This is also well known in the Clojure community as Hammock-Driven Development [1].

[1] https://youtu.be/f84n5oFoZBc

They changed the default garbage collector to G1 last year.[1]

[1] https://github.com/JetBrains/intellij-community/commit/edf1c...

> The bigger issue though is wasting time wrapping Java libraries and most comments I see about Clojure interop talk as if there is no cost to it.

You are not forced to "waste time" wrapping Java libraries. As a matter of fact, thanks to the interop features that are well thought out, using Java libraries directly via the interop is encouraged and preferred to wrappers (Java Time API is a good example.) You may _choose_ to write wrappers for Java libraries if they make consuming these libraries in your code a bit nicer.

> Clojure has good foundations but the ecosystem never really developed.

There's no separate ecosystem for Clojure(Script). The established ecosystems such as JVM, .NET, and JavaScript _are_ the Clojure ecosystem. The creator of Clojure(Script) realized that it would be practically impossible to build an ecosystem from scratch without significant investment (Sun spent billions of marketing dollars alone in Java) and thus deliberately chose to make Clojure(Script) a language hosted on well-developed platforms such as JVM, .NET, and JavaScript. Also because of this focus on being a hosted language, he went to great lengths to ensure the interop with its hosting platforms is as seamless as possible. If you need an example for awkward interop with Java, try Scala.

Clojure developers tend to choose the official Clojure CLI tools [1] for new projects these days.

[1] https://clojure.org/guides/deps_and_cli

To be fair, this is not unique to Clojure. You need to deal with stack traces no matter what as long as you're using any programming language that targets the JVM (even statically type-checked languages like Scala). There are some great articles [1][2] that discuss various simple techniques helpful for debugging and dealing with stack traces.

[1] https://eli.thegreenplace.net/2017/notes-on-debugging-clojur...

[2] https://cognitect.com/blog/2017/6/5/repl-debugging-no-stackt...

Thanks to the dynamic nature of Clojure programs, experienced Clojure developers use the REPL-driven development workflow as demonstrated in this video [1].

[1] https://youtu.be/gIoadGfm5T8

I cannot answer your question. Since you love Python, I guess you don't have any problem with dynamic type-checking. You also mentioned Scheme, I take that as you don't mind parentheses either. :)

If you would like to try something that's closest to Scheme and has access to the rich libraries in both the Python and Java ecosystems, give Clojure a try. You have access to the Java libraries out of the box and, with libpython-clj [1], you get access to your familiar Python libraries.

[1] https://github.com/clj-python/libpython-clj

According to the latest status update from a member of the Clojure core team [1], we may see improvements in startup time with the next version of Clojure (1.11).

[1] https://insideclojure.org/2020/02/28/journal/

I think what @iLemming meant is that she/he doesn’t understand the appeal of having a fancy REPL _UI_ (mostly virtual terminal emulator-based readline implementations) and working with it _directly_ as opposed to sending forms from your editor of choice to a REPL server.

I kind of hold the same opinion. Being more powerful, feature-rich, flexible than readline implementations, editors are, by design, more suited to editing forms. And, I believe, “sending forms from your editor to the REPL” is what the “REPL-driven development” encourages.

Firefox just gained the ability to use Mac’s hardware media keys to control media playback in the latest beta/developer edition (71 right now): https://bugzilla.mozilla.org/show_bug.cgi?id=1575995

As a regular user and promoter of REPL.it, I like it very much and therefore submitted two PR’s [1][2] after seeing a blog post about how to contribute to it [3].

Unfortunately, those PR’s have been lingering up there for the past 4 months without any meaningful feedback. I fully understand that you are a business and therefore there are priorities but it would be great to get any kind of feedback on them in order for me proceed with further actions one way or another.

Anyway, thank you for providing such a nice tool for free and open-sourcing it!

[1] https://github.com/replit/polygott/pull/28

[2] https://github.com/replit/prybar/pull/30

[3] https://repl.it/site/blog/elisp

To anyone who's interested in this topic, I strongly recommend this talk from Rich Hickey about "giving something to somebody that they can use and making a commitment": Spec-ulation (https://www.youtube.com/watch?v=oyLBGkS5ICk)

If you're using Firefox, this extension might be a search engine-agnostic solution for you: https://addons.mozilla.org/en-US/firefox/addon/languageswitc...

Based on your description, the Lisp that you're looking for should:

  - be the most modern one
  - have a robust ecosystem
    - package management
    - tooling
  - can be used for building production-ready software
  - be an easy sell to businesses

Clojure checks every single bullet point on that list; it

  - is *the most modern* Lisp that's designed from ground up (no historical baggage/cruft)
  - is hosted on *the Java platform* (i.e., "the Java world"), which is so far the most robust enterprise software ecosystem. This means that you have access to the most robust package management system (Leiningen/Maven), the most battle-tested and production-quality libraries, and the most powerful development tools (e.g., IntelliJ IDEA), and etc.
  - is created by a pragmatic/practical guy who wants to build production-ready software. It's not the result of an academic research/experiment/thesis.
  - is the result of a trade-off that makes it an easier sell to businesses. Businesses tend to be more conservative when it comes to choosing a platform to invest on and usually prefer the ones that are battle-tested, well-established, and well-supported. As of right now, it's the Java platform. No other enterprise software ecosystem can hold a candle to it.

Of course, you don't have to take my word for it, see what others have to say about Clojure.[1]

[1] https://en.wikipedia.org/wiki/Clojure#Popularity

It seems to me what you’re struggling with is functional programming (the paradigm) instead of Clojure (the language or grammar) itself. This is pretty common for people who are used to the C-like languages. I strongly recommend reading “Clojure for the Brave and True” [1] (especially, Part 2) to anyone who is getting started on either functional programming and/or Clojure.

[1] https://www.braveclojure.com/clojure-for-the-brave-and-true/

I was passively introduced to Clojure when I joined my current team at my current company a few years ago. After spending 5 years in a humongous, horribly-maintained Java code base, and a short period of time with a new-ish Scala code base that was littered with code written in almost all kinds of programming paradigms (procedural, object-oriented, and functional) and then being intimidated by the incidental complexity of the language itself prior to this transition, I was frustrated to realize the cruel fact that I had to learn another JVM language that feels even “weirder” and more “complicated” than Scala. At first, I had similar questions as you have now: “What makes this ‘ugly’ language so special that one of our smartest team leads preferred it to, say, Scala, Go, or Rust?” It was not until I watched one [1] of “Rich Hickey’s Greatest Hits” [2] did Clojure finally “click” with me. It’s all of those principles that were applied and the values that were upheld when Rich Hickey designed this elegant language. I cannot reiterate all of them here. Go watch those talks and give this language a serious try. You might end up falling in deep love with it just as I did. :-)

[1] https://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hi...

[2] https://changelog.com/posts/rich-hickeys-greatest-hits

Yes, copy/paste between Firefox (on Wayland) and other apps was broken but was fixed in firefox-63.0.1-5.fc29.[1][2]

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1585393

[2] https://bodhi.fedoraproject.org/updates/FEDORA-2018-2d42997a...

Fedora 29 has a “firefox-wayland” package that runs the latest stable release of Firefox (63 as of now) on Wayland (instead of XWayland). I’ve been using it for a long while and it’s been great!

They post newsletters[1] about WebRender on a regular basis.

[1] https://mozillagfx.wordpress.com/2018/11/15/webrender-newsle...

As the leader in online affiliate marketing, we’ve just launched our analytics and insights platform that is written in Clojure [0]. If you like Clojure, come work with us [1].

[0] http://junction.cj.com/article/introducing-insights-cj-affil...

[1] https://engineering.cj.com

If it helps, the core team uses Atlassian JIRA [0] for issue tracking and Atlassian Confluence [1] for design and planning discussions.

[0] https://dev.clojure.org/jira/browse/CLJ

[1] https://dev.clojure.org/display/design/Home

Wow, that was a lightning-fast response!

Thank you very much!

My favorite online REPL for Clojure.

It would be great if Parinfer [0] were integrated into the Clojure (and Scheme?) REPL.

[0] https://shaunlebron.github.io/parinfer/

Until they provide a decent UI/UX to do that, you can use about:performance for now.

This feature has already ridden the release train (currently in 57 beta) [1] and should be released with Firefox 57 next month.

[1] https://www.mozilla.org/en-US/firefox/57.0beta/releasenotes/