Earlier quoted context omitted.
And yet we've all done it.
No. We didn't. At least not we all. That's just a myth spread by a few workaholic programmers. Luckily, there are enough 9-5 programmers to clean up the mess created by those 2AM committers.
Clojure Desktop UI Framework
121–130 of 139 posts
Re: Clojure Desktop UI Framework
#122I'm sure Clojure is a great language for some tasks... But, looking at the examples (picked the Wordle one since I know that game): https://github.com/HumbleUI/HumbleUI/blob/main/dev/examples/... I find it extremely hard to read. Even small snippets, say line 56 to 74 which define this "color", "merge-colors" and "colors"... then the "field" one lines 76 to 117 is even harder. is it more natural read for people famil…
I've tried to learn Clojure a few times and just bounced right off every time. I found it impossible to read and frustrating and tedious to write. Everyone else who tries it seems to fall in love, but I really don't get it.
Re: Clojure Desktop UI Framework
#123Earlier quoted context omitted.
> I find it extremely hard to read. I avoided Clojure for nearly 15 years because I thought so too. Turned out I spoke English and couldn't read Russian. But that didn't mean Russian was unreadable— I just didn't know how. It had nothing to do with whether or not it was "readable" or not, it was easy to read (and understand) once I learned how. After about two weeks, I found reading Clojure to be just as easy as any…
Can you expand on structured code editing?
Re: Clojure Desktop UI Framework
#124Earlier quoted context omitted.
That’s not accurate, there are cross-platform toolkits that achieve at least a close-to-native look&feel. This is very different from giving up on it entirely and going web-style UI.
If they use native widgets, they usually look really bad If they just “imitate” look and feel, they usually fall very short of the real thing Either way, it’s bad experience for the end user
Re: Clojure Desktop UI Framework
#125Earlier quoted context omitted.
If they use native widgets, they usually look really bad If they just “imitate” look and feel, they usually fall very short of the real thing Either way, it’s bad experience for the end user
I don't know, I think the Racket GUI toolkit and JavaFX work fine for building cross platform standalone applications.
JavaFX uses the same approach as Humble UI: they draw all the widgets themselves and have custom cross-platform look and feel.
We aim to be better quality version of JavaFX
Re: Clojure Desktop UI Framework
#126Clojure and Flatlaf [1] tick all the boxes for me. If I want declarative-ish UI, I can always throw in Seesaw [2]. Everything else I find cumbersome, pulls tons of unnecessary dependencies and (usually) ends up abandoned in a year or two. With Swing, I know it is well-documented and will work for the next 30 years. But YMMV and I'm hoping that HumbleUI could be an exception. [1] https://www.formdev.com/flatlaf/ [2] h…
Having worked with Swing recently, I worry that it will not work well on the near-distant future, because it feels frozen in time at about 2005. There are a lot of assumptions baked in that aren't holding up today. For example, high density and multi monitor aren't well supported. There's a bunch of stuff hard-coded in the JDK that no longer makes sense and you have to hack around.
Re: Clojure Desktop UI Framework
#127Earlier quoted context omitted.
"is it more natural read for people familiar with writing functional programs? (am I permanently "broken" due to my familiarity with imperative programing?)" As just one person who has written a great deal of functional code, it reads well to me. I think because I am used to reading it "inside out"? Reading lisp-likes is probably helpful. Take 'color' for example. It opens with a 'cond', with three branches. First br…
This is the function that confused the person you respond to, ported to Python: def color(word, letter, idx): if word[idx] == letter: return GREEN elif letter in word: return YELLOW else: return GREY I know which one I'd prefer to grok at 2AM with alerts going off.
fun color(word: String, letter: Char, idx: Int) =
when (letter) {
word[idx] -> GREEN
in word -> YELLOW
else -> GRAY
}Re: Clojure Desktop UI Framework
#128I'm sure Clojure is a great language for some tasks... But, looking at the examples (picked the Wordle one since I know that game): https://github.com/HumbleUI/HumbleUI/blob/main/dev/examples/... I find it extremely hard to read. Even small snippets, say line 56 to 74 which define this "color", "merge-colors" and "colors"... then the "field" one lines 76 to 117 is even harder. is it more natural read for people famil…
I've tried to learn Clojure a few times and just bounced right off every time. I found it impossible to read and frustrating and tedious to write. Everyone else who tries it seems to fall in love, but I really don't get it.
Perhaps you've done it wrong? To read any Lisp code one needs a REPL. And you don't typically type directly in it, you connect to it and eval things from source files. Once you get connected to a REPL, you can eval any expression and sub-expression, and with practice, you'd learn to grok the code without a REPL.
And for writing Lisp, you only need structural editing support in your editor. Once you find basic commands - moving structures around is far more enjoyable process than writing things in an unstructured language.
I am far more productive using Clojure instead of Java and Clojurescript instead of Javascript, Fennel instead of Lua, etc. - it's easier to read, easier to modify, easier to maintain. But, yeah, it does require some practice, just like any other skill.
Re: Clojure Desktop UI Framework
#129I'm sure Clojure is a great language for some tasks... But, looking at the examples (picked the Wordle one since I know that game): https://github.com/HumbleUI/HumbleUI/blob/main/dev/examples/... I find it extremely hard to read. Even small snippets, say line 56 to 74 which define this "color", "merge-colors" and "colors"... then the "field" one lines 76 to 117 is even harder. is it more natural read for people famil…
> I find it extremely hard to read. Even small snippets, And unfortunately, you won't get much compiler assistance either with Clojure, beyond basic things. So it's easy to have bugs that will take a while to track down in a complex codebase.
- Clojure has strong type inference, catching many errors at compile-time.
- The REPL provides immediate feedback and testing capabilities.
- Clojure's immutability and functional paradigms reduce bug-prone code.
- Tools like core.spec offer runtime type checking and data validation.
- IDEs like Cursive provide advanced static analysis and refactoring support.
- Clojure's simplicity and consistency make bugs easier to spot and fix.
- You also completely ignoring Clojure's rich ecosystem of testing frameworks and tools.
Re: Clojure Desktop UI Framework
#130If only Clojure wasn't tied to the fucking JVM
Besides - Clojure is not JVM-only, Clojure is a hosted language, it can work a top of different platforms: JS engine - Clojurescript; Flutter - ClojureDart; Native Code scripting - Babashka; NodeJS - nbb; .Net - Clojure CLR; Fennel even though technically is not a Clojure, is a lovely little language very similar to it and it works on Lua. There's also jank-lang, currently in development that works on top of LLVM. There are a bunch of other Clojure dialects - for Rust, Go, Python, Erlang, etc.