Live data from Hacker News

Clojure Desktop UI Framework

github.com

51–60 of 139 posts

Re: Clojure Desktop UI Framework

#51
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…

If you haven't used a Lisp-inspired language, yeah, it's going to seem different than all those imperative Algol-derived languages that have been popular for so long.

I don't use Clojure professionally, but I've spent years using the language personally. It might be hard to believe, but it really is beautiful once you learn it, and extremely powerful as well.

Re: Clojure Desktop UI Framework

#52
post #24
post #21

Earlier quoted context omitted.

Clojure is a lisp. Lisp languages represent code as trees. That's why you have so many parentheses. The trees contain language constructs (if, cond, let, defn, ...), data (numbers, strings,...) and names (function names, names of value bindings). There is also some more advanced syntax for quoting and macros. When reading lisp code, you navigate it like a tree. Indention matters and clean lisp code has the same inden…

(i'll just make it clear that indentation matters to users as a strongly recommended convention for ease of reading. to the interpreter, you can write everything on a single line)

I'll add that the related 'power' many Lisp acolytes talk about stems from the fact that everything is a list of lists. Due to this, you can write programs that take syntax (a list of lists) and modify that syntax to do something else (another list of lists).

Imagine a language that has a built in parser and code generation library.

Re: Clojure Desktop UI Framework

#53
post #32

The readme says it is aiming for a “web look”, with no intention to make it look — and, presumably, behave — native. As a user, that’s not what I expect and hope for from a desktop application.

Isn't this the case with a lot of desktop GUIs that are cross platform?

Re: Clojure Desktop UI Framework

#54
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.

[deleted]

Re: Clojure Desktop UI Framework

#55
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…

This one's pretty clean for Clojure code, due to the simplicity of the data model, in the most conventional sense, as the state of the program is just the word, the guesses, and the grid of colored characters for the guesses.

External dependencies you manage like in most other applications nowadays, you don't hit external services in the "guts" of your code unless you really need to, for performance, testability and to keep the less reliable parts of your code isolated, you keep the interactions with external services as close to the "main" of the application as you can.

When things break down is with more complex data models of the application, not even as much because of the language itself but because Clojure programmers actively reject using record types and interfaces, and just pass dictionaries around. You wind up with some code that, bafflingly, gives the impression of being very simple and neat, but you can't tell what it's actually doing.

Re: Clojure Desktop UI Framework

#56
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.

> I know which one I'd prefer to grok at 2AM with alerts going off.

I hate meaningless statements like this. This means nothing, other maybe that you know Python. 20 years ago people might have said that about Python - I even know many people today who would say that about Python.

Re: Clojure Desktop UI Framework

#57
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…

Lisp becomes easier to read if you have an IDE plugin that removes opacity from parentheses

Re: Clojure Desktop UI Framework

#58
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.

Having a bit of Lisp experience (really not a lot), I find it very easy and elegant to read.

> is it more natural read for people familiar with writing functional programs? (am I permanently "broken" due to my familiarity with imperative programing?)

No, most people who say something like this are simply unwilling to invest an evening into a language they're not already familiar with.

Re: Clojure Desktop UI Framework

#59
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…

It's possible to write some pretty unreadable code with Clojure, just like it's possible in any programming language.

I can tell you that this code is very easy to read if you are familiar with Clojure. In fact, this example is lovely! Seeing this code really makes me wanting to try this library! Clojure has this terse, yet readable aesthetic that I like a lot.

But I completely understand you because at some point Clojure code also looked alien to me. You are not broken for having familiarity with some style of code. Familiarity is something you can acquire at any time, and then this code will be easy to read.

True hard-to-read code is one that is hard to understand even if you master the language it is written in.

Re: Clojure Desktop UI Framework

#60
post #34
post #31

where did the myth that people prefer apps that look native to the platform come from? There are two types of apps: 1. the ones that professionals use and 2. the ones that consumers use. for 1. they don't care if it looks native, as long as it works and is performant e.g. DAWs, Video Editing tools, Trading, etc. 2. likewise I don't think it matters that much. my guess is the myth came from OS makers.

Native look&feel makes for a consistent UX across apps. Users learn one set of conventions and UI controls that uniformly applies to all applications. In addition, all applications benefit from enhancements made to the native UI toolkit and integration with the OS (input methods, file dialogs, keyboard navigation, automations, …). Moreover, web UIs tend to be less sophisticated and less power user friendly, due to HT…

I don't personally believe it's ever been true that users want the same UI styling across apps. When given the option to customize the colors or layout of an app, users will do that. People want their applications to follow common UI patterns, but applications should have some kind of personality to them, otherwise they just look like Microsoft or Apple products
Post reply on HN