I think that particular issue was addressed in the recent Clojure release [https://clojure.org/news/2024/09/05/clojure-1-12-0] ("Clojure developers can now invoke Java methods taking functional interfaces by passing functions with matching arity.")
Yeah, and most of my professional Clojure experience was from 2018 to 2021, and a few personal projects in 2022 and 2023, and that lack of support for the functional APIs really annoyed me; I was writing a Kafka Streams application, which uses lots of lambdas, and it annoyed me enough to rewrite it with vanilla Java.
I'm sure it's a difficult thing to implement, so I'm a little forgiving, but considering that Java interop is one of the biggest selling points for Clojure I do think it's fair to criticize a bad experience with it.
I need to play with the newer stuff though; the linked changes seem cool as hell.
This looks pretty amazing. I will take it for a spin next week. I want to make a RAG that will answer questions related to my new car. The manual is huge and it is often hard to find answers in it, so I think this will be a big help to owners of the same car. I think your library can help me chunk that huge PDF easily.
Reminds me of Planck's principle:
> A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die and a new generation grows up that is familiar with it ...
>> In practice, they are a niche endeavor used by a bunch of hackers and computer science nerds.
I don't know anything about federation, but what you said basically describes the Internet when it started, so I don't see how you can imagine it is not going anywhere based on that. Most tech starts as a "niche endeavor of a bunch of hackers and computer science nerds" (I'm also thinking of Apple starting at a computer club).
Federation and open protocols aren't new ideas, and the vast majority of people have collectively decided that there is no value for them in those ideas. This isn't pioneering stuff that everyone would jump onto if only it was known/available to them. It is available, and has been for a long time, and the people are not biting. I see no reason to assume that this is going to change.
Data structure + algorithm is a valid way of building large programs. That is basically how Clojure is designed, and it works pretty well for big applications.
My point is that there is nothing about functional programming, specifically the "Data structure + Algorithm" style, that makes it unsuitable for building complex applications like air traffic control system or bank lending system, and it has in fact been used successfully in domains like that.
I was mostly supplying an example rather than taking a side in the philosophical argument, to be clear. I’d call that idiomatic Clojure, but I’m a heathen that very much appreciates Clojure being on top of the JVM and offering Java interop.
Another big Clojure UI/graphics framework is Quil, which is based on Processing and does an even worse job of hiding it’s imperative/stateful core.
> The problem with that is that (nearly?) every GUI toolkit is object oriented
Except for things like React which are more or less functional reactive programming, but in case of react its stateful. Functional reactive programming exist, and GUI is not obliged to be OO
clojure was introduced in 2007, there have been many GUI toolkits that have been implemented entirely from scratch in other languages since then. QML+QtQuick, Dart+Flutter, Nuklear in C, Nana or neoGFX in C++, etc etc
"Advanced" (read: decades old) type systems. They provide tools like algebraic data types, generics, interfaces, row polymorphism and many others, but just those four allow expressing a gargantuan amount of invariants in the type system without sacrificing flexibility. Invariants that can be proven once and be maintained throughout years of code churn without repetitive runtime checks, heavy discipline or overly repetitive automated tests that attempt to poorly reimplement a type system.
They can be used not only as a way to let the compiler help you out in not making mistakes but also as an exploratory tool to test out many edge cases with quick feedback and as an informational aid to help quickly introduce new developers into a codebase with its own business domain explained in a language that allows conveying "this is possible" and "this isn't possible" much more quickly than reading tons of procedural code until the reader comprehends all the implicit rules laid down by the program's behavior.
Well, respectfully (while not disagreeing with you), I have to say that you seem to live in some idealistic utopia of software crafting. Between the crazy world of gazillion lines of shitty Python or Javascript, and some incredible proof assistants, I think Clojure finds itself in a quite pragmatic, practical, and cozy niche.
Notably, Clojure "speaks money". Money necessitates reliability and requires defect-free software. At the same time, modern, digitized money management desires flexibility and efficiency in fixing bugs and adding new features; Clojure very often fits perfectly for it.
That is why it is so prevalent within fintech startups. If someone pays you to play around with advanced type systems, and you love that, what can I say? You are a lucky one. I get paid to build something that works. I'm not a zealot; I use Clojure because it makes sense (for me). But some people prefer Python and Javascript. And that's fine.
I believe fintech is mostly a functional hub. There's an above average amount of Haskell, F#, and Scala in it. Most of the Clojure influence I believe comes from Nubank initially starting out as a Clojure shop IIRC.
Unfortunately I also happen to not get paid to play around with languages, although I'm open to such a position if you know of any available one. I get paid to write robust software and to work with engineers that don't always have 10+ years of experience. I get paid to deal with requirements that change every bloody week because we have quick customer feedback, customers that are very vocal about wanting things a certain way and highly intolerant of software crapping the bed when they go and try their "super normal, and expectable" extreme edge case.
I've dealt with those cases across many languages across the years, and you could easily guess that I would be very desperate for the money if you find me in another job working in a dynamic language dealing with constant changes.
By the way, it's okay if you're not familiar with the concepts I brought up by name, but if you have worked with Rust, TypeScript, Haskell, Scala, Kotlin, PureScript, Elm, F#, Swift or one of many others, you're probably familiar with them. They're everyday tools to programmers using those languages, not some strange academic tool.
It seems I have been very unlucky. Because mine was that hacks piled, and piled, and piled, and no one ever got back to them because we could just do something horrible with metadata and cond our way to no man's land, without any types serving as documentation for the mess that was being created.
>I get paid to write robust software and to work with engineers that don't always have 10+ years of experience.
...
> I've dealt with those cases across many languages across the years
I'm not trying to denigrate your experience, and I'm not pretending that we work in different industries and deal with very dissimilar problems. But if anything I learned from the years of writing software - there are no silver bullets. Every single tool has cons and pros. You can't just look at any instrument, framework, library, language through a tiny keyhole and make assumptions. And I'm not saying you have. Perhaps you have rich experience using Clojure that led you to the conclusions you made. From my perspective - I have the opposite of that. And again, it's not because I have not seen what you have. Clojure, in my opinion, compensates for the lack of static typing with a plethora of other features. Features that many other languages can't offer but are essential for me.
I've used Tabula for many years, and it works great. Use it for converting PDF invoices from specific supplier for import into our system. Changed a task that took about a day each month, to about 10 minutes each month.
Nope, it doesn't. I've honestly found tabula is pretty limited in its use. When it works it works well, but when it doesn't you're still stuck writing a lot of hodge podge code. Not sure why there's not more criticism of it.
Regarding your long lines issue - from your description it sounds instead like an unicode issue which I also ran into a while back.
What happens is that your main programming font does not have the unicode characters, so Emacs falls back to searching all your fonts for each character it can't find, which is slow if it has to search through many different fonts.
reply