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

131–139 of 139 posts

Re: Clojure Desktop UI Framework

#131

Post by iLemming »

grugagag wrote: post #120
erichocean wrote: post #97

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?

Structural editing commands are like 'slurp' - swallows an expression inside another one; 'barf' - spits out a thing out of an expression; You can also do it from the left or right side. 'wrap' - wraps a selection into an expression; 'unwrap' - does the opposite; 'transpose' - swaps two expressions at point, and there are more commands.

Once you learn the basic structural editing commands, writing code becomes like composing poetry out of haiku pieces. Instead of thinking like: "how do I grab these vars used inside this function and refactor it to be them in their own unit?...", you'd just grab some expressions and move them around, like bricks or lego pieces. It is extremely satisfying way of writing programs. The only drawback of that approach is that later it becomes harder to work with "more traditional" PLs, you just can't easily manipulate code the same way in Python, JS/TS, Kotlin, Java, C++, etc. - you need a "structured", homoiconic, lispy language for that trick to work. Treesitter makes an effort to improve the process, but it still not on the same level of simplicity.

Re: Clojure Desktop UI Framework

#132

Post by jb1991 »

iLemming wrote: post #129
jb1991 wrote: post #96

Earlier quoted context omitted.

> 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. - T…

> IDEs like Cursive provide advanced static analysis and refactoring support.

Can you give an example? Would these tools allow you to define a custom type with fields and ensure it is correct everywhere at compile time like a static language?

Re: Clojure Desktop UI Framework

#133

Post by radix7 »

iLemming wrote: post #128
radix7 wrote: post #114

Earlier quoted context omitted.

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…

I am well aware of the benefits of a REPL, and find it pretty essential for learning any language. It didn't help me grok clojure any better, though.

I'm not sure what you mean by structural editing support. I usually find things like autocomplete or automatic parenthesis to be more of a nuisance than a help.

Re: Clojure Desktop UI Framework

#134

Post by iLemming »

jb1991 wrote: post #132
iLemming wrote: post #129

Earlier quoted context omitted.

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. - T…

> IDEs like Cursive provide advanced static analysis and refactoring support. Can you give an example? Would these tools allow you to define a custom type with fields and ensure it is correct everywhere at compile time like a static language?

While Clojure is dynamically typed, tools like clj-kondo, Cursive and clojure-lsp can offer some static analysis benefit like warning about undefined vars or functions. There isn't "true" static checking, but you can use Spec and Malli for runtime checking. That doesn't provide same level of compile-time guaranties as statically type language, yet it offers some unique capabilities that many statically typed languages struggle to match, like

- Dynamic predicates - Spec allows you to define types using arbitrary predicates, which can be more expressive than traditional static type systems;

- Runtime generative testing - Spec can automatically generate test data based on your specifications, which is powerful for property-based testing;

- Flexible validation - You can validate complex nested data structures and apply specs selectively, which is often more flexible than static type checking;

- Extensibility - Specs can be added to existing types without modifying their source, and data-driven nature of it - Specs are just data and can be manipulated programmatically.

Re: Clojure Desktop UI Framework

#135

Post by iLemming »

radix7 wrote: post #133
iLemming wrote: post #128

Earlier quoted context omitted.

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

I am well aware of the benefits of a REPL, and find it pretty essential for learning any language. It didn't help me grok clojure any better, though. I'm not sure what you mean by structural editing support. I usually find things like autocomplete or automatic parenthesis to be more of a nuisance than a help.

> find it pretty essential for learning any language

No, REPLs in other languages are not equal to REPLs in Lisp dialects. I bet what you are describing is not the same workflow that an average Clojurian would use. In other languages you typically type directly into the REPL console. With Clojure, you typically connect your editor to a running REPL instance and then manipulate things directly from the source code - you basically write the program, while living inside it - your codebase becomes a living, breathing, maleable entity.

Structural editing has little to do with autocomplete, it's just a way to manipulate expressions - move them around, raise them, transpose them, wrap/unwrap, etc.

I suppose you tried to understand Clojure by looking at the code, and that could be challenging - without proper REPL and structural editing support, it may not be the same joyful experience that many Clojurians know.

Re: Clojure Desktop UI Framework

#136

Post by radix7 »

iLemming wrote: post #135
radix7 wrote: post #133

Earlier quoted context omitted.

I am well aware of the benefits of a REPL, and find it pretty essential for learning any language. It didn't help me grok clojure any better, though. I'm not sure what you mean by structural editing support. I usually find things like autocomplete or automatic parenthesis to be more of a nuisance than a help.

> find it pretty essential for learning any language No, REPLs in other languages are not equal to REPLs in Lisp dialects. I bet what you are describing is not the same workflow that an average Clojurian would use. In other languages you typically type directly into the REPL console. With Clojure, you typically connect your editor to a running REPL instance and then manipulate things directly from the source code - y…

Yes, I've heard this sales pitch before. Yes, I used an actual REPL tied to an editor, among other configurations. I found it rather underwhelming. I tried a few other lisp dialects as well, but had the same experience. Interactivity is great, but it doesn't make up for the language itself.

Re: Clojure Desktop UI Framework

#137

Post by lispm »

iLemming wrote: post #135
radix7 wrote: post #133

Earlier quoted context omitted.

I am well aware of the benefits of a REPL, and find it pretty essential for learning any language. It didn't help me grok clojure any better, though. I'm not sure what you mean by structural editing support. I usually find things like autocomplete or automatic parenthesis to be more of a nuisance than a help.

> find it pretty essential for learning any language No, REPLs in other languages are not equal to REPLs in Lisp dialects. I bet what you are describing is not the same workflow that an average Clojurian would use. In other languages you typically type directly into the REPL console. With Clojure, you typically connect your editor to a running REPL instance and then manipulate things directly from the source code - y…

Strange, I use Lisp and type to a REPL all the time. Now you tell me that is a feature of other languages, not of Lisp?

Re: Clojure Desktop UI Framework

#138

Post by fulafel »

iLemming wrote: post #134
jb1991 wrote: post #132

Earlier quoted context omitted.

> IDEs like Cursive provide advanced static analysis and refactoring support. Can you give an example? Would these tools allow you to define a custom type with fields and ensure it is correct everywhere at compile time like a static language?

While Clojure is dynamically typed, tools like clj-kondo, Cursive and clojure-lsp can offer some static analysis benefit like warning about undefined vars or functions. There isn't "true" static checking, but you can use Spec and Malli for runtime checking. That doesn't provide same level of compile-time guaranties as statically type language, yet it offers some unique capabilities that many statically typed language…

Yep, I'd add these advantages that schema systems have:

- Power - you can do arbitrary checks on the data, static type systems are quite weak in what kind of properties they can verify (far from turing complete)

- Flexibility to do checking at where you want at runtime (eg check data at API boundaries)

- Ability to treat schemas as data, generate them, output them as data and share between systems (for example in databases), throug conversions possible to interop with other platforms (eg json schema)

- loose coupling to your programming language, are just libraries

Re: Clojure Desktop UI Framework

#139

Post by iLemming »

radix7 wrote: post #136
iLemming wrote: post #135

Earlier quoted context omitted.

> find it pretty essential for learning any language No, REPLs in other languages are not equal to REPLs in Lisp dialects. I bet what you are describing is not the same workflow that an average Clojurian would use. In other languages you typically type directly into the REPL console. With Clojure, you typically connect your editor to a running REPL instance and then manipulate things directly from the source code - y…

Yes, I've heard this sales pitch before. Yes, I used an actual REPL tied to an editor, among other configurations. I found it rather underwhelming. I tried a few other lisp dialects as well, but had the same experience. Interactivity is great, but it doesn't make up for the language itself.

"Underwhelming"? Seriously? I don't think you actually tried the real thing, have you? I don't know about you, I find it extremely satisfying, when you can run a basic Puppeteer or Playwright script and then explore the DOM structure directly from your editor, without having to copy/paste, move or change your code, or even using devtools (everything controlled from your editor), and then navigate the page interactively from your editor and execute pieces of code (that run in the browser) without any preliminary ritual, even without having to save the file.

Or you'd run a curl command once and continue exploring the data - parsing slicing, dicing, grouping, sorting any way you like, or even have it visualized in the Portal tool with charts and graphs.

Look, I'm currently writing tests for a thing, while my IDE is connected to a service running on a Kubernetes pod in the cloud - I can eval any function that affects the execution of the service, I can explore the db tables, change the routes and re-run the tests - all that without having to restart the pod, without having to deploy anything, without even having to save any files (if I don't have to).

Lisp REPL-driven development gives you immediate feedback, allows you to modify and debug running programs on-the-fly, allows you to experiment, it's great for understanding language features interactively, and it's a real, tangible productivity boost - it's superb for rapid prototyping.

> Interactivity is great, but it doesn't make up for the language itself.

The language is what allows that great interactivity and exploratory programming. I mean, I get it - while it may initially appear challenging to read, much like how sigma notation for loops in mathematics can be difficult to comprehend, with practice it becomes intuitive. One wouldn't go to math.stackexchange to complain about sigmas and other mathematical symbols being unintuitive, would they?

Post reply on HN