Live data from Hacker News

Try Clojure

tryclojure.org

331–340 of 404 posts

Re: Try Clojure

#331
post #327

Earlier quoted context omitted.

These Java features are ruined by not allowing mutable variables to be captured. Having to do the 1-element array trick when the compiler could just do it for me is insane. If you are making JavaScript look good you are failing as a language.

You mean not having the error that go just fixed by changing the language is a problem?

JS has this error too, but nothing forces Java to have this issue if they fix the no-mutable-captures problem. Dart got this right from the start.

Here's JS showing the same issue.

  for (var i = 0; i  i)
  }
  array.forEach((fn) => console.log(fn()))  // Prints 10 every time.
The correct fix is that each loop iteration gets a fresh i instead of i just being mutated. Currently you can't see the difference in Java between there-is-only-one-i and there-is-a-fresh-i-every-time, so Java is free to do this right.

Re: Try Clojure

#332
post #79

I'm glad this is back. A version of this existed in the ancient past and helped encourage me to try Clojure which ended up being by far the most impactful decision in my professional life. It went away for a while for reasons I'm unclear on. I use Clojure nearly daily at my job and at home. Sometimes it's standard Clojure, sometimes it's the excellent Babashka flavor which I use as a make-like task runner and Zsh-lik…

As a side note, I'm always amazed by people who can use a highly expressive language (Clojure, Rust, even TS) but switch to Go when they feel like it (especially pre-1.18). To me, switching to a less expressive language is painful and infuriating. I remember having to switch from Python to Java 5, and how everything started to take 3 to 5 times longer code to express. Maybe the key thing is to only write small things…

Expressiveness has many dimensions. It depends on what you are trying to express in the first place.

C++ or Rust are expressive in both directions, towards the metal and upwards in terms of abstractions. But those languages are not easy to reason about. They come with lots of stuff, hard to grok abstractions, ceremony and so on.

Small languages like Scheme or Lua are expressive in that they don't force you to write a lot of stuff to get the job done. But those languages don't typically let you express what the computer should actually do at a lower level.

C or Zigs let you do those things and are also relatively small languages. But their facilities for abstraction are limited and they force you to express more computational details.

Go frees memory and schedules goroutines for you, but lets you express a lot more about how you lay out memory than other managed languages, so you can actually think in terms of bits and bytes. It has a great std lib so you can get stuff going quickly and reliably.

Re: Try Clojure

#333

Earlier quoted context omitted.

Functional programming languages haven't gone mainstream but functional techniques are very common now. Higher order functions, immutable data structures, declarative UI frameworks, etc are things you're quite likely to encounter in a contemporary codebase these days.

That's what I said. I do use functional programming techniques, I just wonder why functional programming languages don't see a larger following.

Good question. I suspect it's because the downsides of losing the larger ecosystem of more mainstream languages outweigh the upsides of a functional language. The libraries, package managers, tooling, runtime, debuggers, documentation, and editors etc just aren't anywhere near as mature for Haskell or Ocaml as they are for Typescript or Python, for example.

Re: Try Clojure

#334

The problem I see with clojure, isn't it missing autocompletes? You work with JVM/typescript libraries, but your editor isn't smart enough to pull types from those into clojure. That slows you down tremendously.

As a Clojure editor tool smith it pains me that this is the case. Especially for ClojureScript where I spend most of my time. I really want to fix this. For JVM interop, I think Cursive (IntelliJ Clojure plugin) is smart enough to help with autocompleting Java libraries.

Yea, Cursive is the best by far for doing Java interop. It is really good.

Re: Try Clojure

#335

Maybe online "learn lisp" repls should implement paredit keybindings in their editor and have a short section on how to manipulate s-expressions. Because you're gonna have to learn it to use the language, but it also helps people understand from the start that "oh, so using the language isn't actually complete shit". Instead, this fact always seems glossed over, and because of it anyone who spends 60 seconds writing…

At the very least they should have auto-closing and matching parens. I dread to think how many people have been put off Lisp because they think we actually type all those parens (in fact Lisp users have enjoyed IDE features many programmers could only dream of for decades).

I remember trying Clojure a few years ago, and Racket, and had similar problem with both... feels like everybody doing LISPs is using Emacs and it was hard to get a decent set up in VS Code configured and working properly

Re: Try Clojure

#336
post #116

Clojure looks productive. What frameworks libraries do people use to build web apps? Like, replacement for Django view layer and ORM (not looking to debate orms thanks)?

Check out Biff, it's very thoughtfully made: https://biffweb.com

It's kind of surprising the most popular(?) web framework uses a weird/obscure db

I have no doubt that XTDB is good, it is just surprising as a first choice and is not going to be easy to get up and running compared to the conventional alternatives

(Is there even a hosted offering for XTDB? I like that it's open source but seems that you will have to grapple with all this stuff including a Kafka cluster https://docs.xtdb.com/guides/starting-with-aws.html)

Re: Try Clojure

#337
post #327

Earlier quoted context omitted.

You mean not having the error that go just fixed by changing the language is a problem?

JS has this error too, but nothing forces Java to have this issue if they fix the no-mutable-captures problem. Dart got this right from the start. Here's JS showing the same issue. for (var i = 0; i i) } array.forEach((fn) => console.log(fn())) // Prints 10 every time. The correct fix is that each loop iteration gets a fresh i instead of i just being mutated. Currently you can't see the difference in Java between the…

Here's what I'd do:

   array = [];

   function clos(val) { return () => val; }

   for (var i = 0; i  console.log(fn()));
This outputs 0-9 instead of 10, though I'm just a silly self-taught person that never got schooled at these things, maybe there is some reason not to use closures that I don't know about.

Re: Try Clojure

#338

Earlier quoted context omitted.

Functional programming languages haven't gone mainstream but functional techniques are very common now. Higher order functions, immutable data structures, declarative UI frameworks, etc are things you're quite likely to encounter in a contemporary codebase these days.

That's what I said. I do use functional programming techniques, I just wonder why functional programming languages don't see a larger following.

Inertia of languages like Java, C, C++, C#, etc. due to university and existing projects. Also managers wanting a huge recruiting pool.

Re: Try Clojure

#339

Earlier quoted context omitted.

You don’t use the ISeq interface directly, you use them through the clojure.core API. The seq abstraction is documented at https://clojure.org/reference/sequences

It’s rare for an application developer to need to use ISeq, but library authors do use of when they want to implement custom seq’s right? For them, and also just for those curious to understand how the core interfaces work, it’s still better to be explicit and write what the contract is I reckon.

Generally, custom seqs (rare) are implemented by leveraging something like `lazy-seq`, so library authors are also not using it.

Yes, it would be good if there were javadoc on more of the impl, but this is just not an issue for the vast majority of devs.

Re: Try Clojure

#340
post #268

I still remember Professor Brian Harvey rolling out his terminal on a cart in Berkeley's CS61A and typing out commands in a scheme repl. Learning what a y-combinator was with Structure and Interpretation of Computer Programs, and building my own scheme compiler with scheme.

Oh wow, I didn't know that "Y-Combinator" was not just a fancy name but was an actual computer science concept. Thanks!

https://combinatorylogic.com/table.html it's hard to read, but there's a ton.
Post reply on HN