Live data from Hacker News

Clojure Desktop UI Framework

github.com

121–130 of 139 posts

Re: Clojure Desktop UI Framework

#121

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.

note how they said grok and not work? this is what oncall looks like, reading code at 2 AM

Re: Clojure Desktop UI Framework

#122
post #114
post #10

I'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.

It does take some patience, but once it clicks, it's just awesome.

Re: Clojure Desktop UI Framework

#123

Earlier 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?

I think they mean when you learn the shortcuts for selecting and manipulating entire blocks between matching parentheses in an editor that helps balance them and so on, making it rather easy to test things out and refactor Lisp-like code.

Re: Clojure Desktop UI Framework

#124
post #98
post #95

Earlier 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

I don't know, I think the Racket GUI toolkit and JavaFX work fine for building cross platform standalone applications.

Re: Clojure Desktop UI Framework

#125
post #124
post #98

Earlier 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.

That’s two perfect examples! Racket seems to try to use native widgets, and looks horrible as a result, at least on macOS

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

#126
post #72

Clojure 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.

I recommend using the JetBrains JRE, they have fixed lots of these sorts of issues, as well as greatly improved hot class reloading for development.

Re: Clojure Desktop UI Framework

#127
post #30

Earlier 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.

Kotlin time (since we're in the JVM context for Clojure)

    fun color(word: String, letter: Char, idx: Int) =
      when (letter) {
        word[idx] -> GREEN
        in word -> YELLOW
        else -> GRAY
      }

Re: Clojure Desktop UI Framework

#128
post #114
post #10

I'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.

> I found it impossible to read and frustrating and tedious to write.

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

#129
post #96
post #10

I'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 codebases may be easier or more difficult to maintain depending on factors such as team experience, project complexity, and code quality. The ease of tracking down bugs varies across programming languages and is influenced by development practices and tooling. Clojure codebases are not more difficult to maintain than any other PLs.

- 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

#130

If only Clojure wasn't tied to the fucking JVM

Well, first of all, JVM, even though it still gets a lot of bad rap (mainly due to Java) turns out to be really nice piece of tech, especially if the aim is to scale CPU-intensive tasks.

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.

Post reply on HN