Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clojure Desktop UI Framework

github.com

Post reply on HN
Print view View original

61–70 of 139 posts

Re: Clojure Desktop UI Framework

#61

Post by zikzak »

freilanzer wrote: post #56
exitb wrote: post #30

Earlier quoted context omitted.

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.

I was in a "101" undergrad compsci class the first year the program used Java (1997, I think?) and so this asst prof was showing a simple example of some Java syntax.

I had been programming in C for a while, learning from K&R, to build ray tracing input files and that sort of thing so I was kind of disappointed but whatever, I was a mature student who had rediscovered computers a couple of years before (had a C64 in the 80s) and was just happy to be there.

Anyway, this guy in the back yells out "I could do that in 2 lines of Q-BASIC" or something to that effect (Q-BASIC was definitely part of his pithy one-liner). Little did I know he was representing so many of the people I would encounter over the next decades.

Re: Clojure Desktop UI Framework

#62

Post by slowmovintarget »

CraigJPerry wrote: post #22
kpw94 wrote: 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, say line 56 to 74 which define this "color” I think you make a great point, a point that once someone has gotten used to lisp, is harder to fully appreciate. I’m at the stage now in my lisp journey that i didn’t find those hard to read but it wasn’t that long ago that i felt almost nerd sniped by this weird language. I think it’s worth pointing out that in a m…

Just don't mention Electric Clojure, because that might cause some head explosions. (Fully reactive multi-tier programs where an entire web UI is 60 lines of code and implements infinite scroll with search and dynamic viewport resizing.)

If you know Clojure, the code presented in the example seems fairly straightforward. Parentheses demarcate the syntax tree; and the last expression in any tree is the result carried forward.

Re: Clojure Desktop UI Framework

#63

Post by indigo0086 »

kpw94 wrote: 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…

not going to say you're wrong or right, but learning lisps/clojure fairly deeply you can find worse examples. Also when people learn it their mind tends to find it a very consistent langauge overall visually. I've moved on after a long stint in clojure to elixir and while I like it, most other language pale in language consistency.

Re: Clojure Desktop UI Framework

#64

Post by nine_k »

rafaelmn wrote: post #47
layer8 wrote: 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.

At this point it feels like this argument is dead an buried. So many non-native apps on every platform, most platforms even have multiple official GUI toolkits/widget styles so even first party apps are inconsistent.

The most consistently-looking desktop I have runs under Linux. With a few settings and a right theme, all GTK2, GTK3, Qt, and Java apps look and feel pretty much the same, in a pleasant way.

MacOS is a close second, with a few native apps that can't decide exactly what a checkbox or a button should look like.

And Win10 on my wife's machine is a salad, reminding me of Linux desktop experience from 1998.

Re: Clojure Desktop UI Framework

#65

Post by diggan »

layer8 wrote: 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.

Professional software (think Clip Studio Art, 3DS Max, Autodesk Fusion and alike) are almost exclusively disconnected from "native" looks, behavior and theming, which is perfectly fine, better than having a different experience depending on your OS.

I feel like it's mostly consumers who ask for native look, and particular users on macOS, as almost all other professional-oriented software doesn't offer that. But yet it comes up for every GUI toolkit that lands on the HN frontpage.

Re: Clojure Desktop UI Framework

#66

Post by pxc »

miroljub wrote: post #42
user432678 wrote: post #37

Earlier quoted context omitted.

Following the author for some time and his main point is that “electron” won already, even despite the fact that the author himself doesn’t like it. And he’s not wrong. Majority of desktop users probably don’t care already if it’s native look or not (don’t cite me on that). The goal of the project to provide a way creating quite performant desktop apps with a DX of Clojure. And it’s a nice goal.

There's no native app, even on desktops. There are a bazillion of different UI frameworks with different look & feel on Windows alone, even within Microsoft products. On Linux or macOS, the situation is no better. Native is what doesn't run in an emulator, in this case everything non-Electron fits the definition.

There are native apps, but appa are native to a desktop environment rather than to an operating system.

Unfortunately desktop environments on some proprietary operating systems are themselves comprised of apps written with different toolkits and bearing different looks and feels. But that's just a problem specific to them. KDE apps are all maybe to Plasma, GNOME apps are all native to GNOME.

Re: Clojure Desktop UI Framework

#67

Post by Pet_Ant »

thaumasiotes wrote: post #50
trentonstrong wrote: post #11

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…

> It opens with a 'cond', with three branches. First branch is if the idx-th position in word is the same as letter, return green. Second branch is if the word includes the letter at all, yellow. This is a tangent, but I've been thinking about how I feel when the conditions of an if-else ladder rely on the order they're listed in. This is an example; if you swapped the order of those branches around, the coloration w…

I mean if the checks are expensive and it's on hot path, then that's wasteful.It might also require then to use more nesting of IFs which isn't necessarily nicer.

Re: Clojure Desktop UI Framework

#68

Post by alternatex »

miroljub wrote: post #42
user432678 wrote: post #37

Earlier quoted context omitted.

Following the author for some time and his main point is that “electron” won already, even despite the fact that the author himself doesn’t like it. And he’s not wrong. Majority of desktop users probably don’t care already if it’s native look or not (don’t cite me on that). The goal of the project to provide a way creating quite performant desktop apps with a DX of Clojure. And it’s a nice goal.

There's no native app, even on desktops. There are a bazillion of different UI frameworks with different look & feel on Windows alone, even within Microsoft products. On Linux or macOS, the situation is no better. Native is what doesn't run in an emulator, in this case everything non-Electron fits the definition.

WinUI 3 aims to be native, but of course Windows is a tapestry of many eras of Microsoft UI styles. If Microsoft doesn't again change their mind on how Windows should look, then WinUI 3 is indeed the look and behaviour that people will be expecting on a Windows machine.

Re: Clojure Desktop UI Framework

#69

Post by krferriter »

thaumasiotes wrote: post #50
trentonstrong wrote: post #11

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…

> It opens with a 'cond', with three branches. First branch is if the idx-th position in word is the same as letter, return green. Second branch is if the word includes the letter at all, yellow. This is a tangent, but I've been thinking about how I feel when the conditions of an if-else ladder rely on the order they're listed in. This is an example; if you swapped the order of those branches around, the coloration w…

Having the order matter and matching the first `true` branch makes for more readable and less-wordy if statements. Otherwise when you have two conditions which have any overlap, such as A and B, for the A branch you need to add `and not B` and for the B branch you need to add `and not A`. This can create very long expressions. Having them evaluate in order and only match the first true one makes this unnecessary.

Re: Clojure Desktop UI Framework

#70

Post by troupo »

dzonga wrote: 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.

When apps have native look and feel, they have consistent behaviour, affordances and accessibility:

- buttons are labeled and placed correctly, and respond to expected input (including secondary focus and secondary action on MacOS, for example)

- dropdowns/selects behave correctly, and respond to expected input (for example, you can type to select in MacOS dropdowns).

- windows have OS-defined areas for drag/resize, for titles, for toolbars etc. They also appear correctly in the OS's window management tools (app switchers etc.)

- text inputs use the OS-default shortcuts and have access to OS-provided tools (e.g. spell checker)

- controls and windows respond correctly to keyboard and mouse. E.g. for a while Apple's own Catalyst apps didn't have the standard Cmd+Q to close the app. Many custom modals do not dismiss the modal on Escape

- context menus are standard in the places where you expect standard context menus. Well, app menus, too.

And the list just goes on and on.

Post reply on HN