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

Clojure: A Lisp that wants to spread

simongray.github.io

Post reply on HN
Print view View original

211–220 of 306 posts

Re: Clojure: A Lisp that wants to spread

#211

Post by Borkdude »

slifin wrote: post #205
snorremd wrote: post #167

Earlier quoted context omitted.

Clojure's extensive support for lazy evaluation and sequences actually makes it decent for command line tools that process streams of data. At least in terms of program architecture and elegance. The biggest mismatch used to be startup time, but with GraalVM you can get very good startup times. I made a couple of simple command line programs at my previous workplace and the functional style of Clojure combined with l…

yep, borkdude has been playing with calling Rust from Clojure too via Java JNA, so if most of your application doesn't need rust like performance but one specific part of it does then you're not dead for options

Small correction: it's JNI. JNA doesn't work with Graal as far as I know right now.

Re: Clojure: A Lisp that wants to spread

#212

Post by doglooksgood »

tensor wrote: post #26

Startup time isn't what is holding the language back. In my opinion it's: 1. Tooling. You end up spending way more time getting your tooling setup than it should be. 2. Difficulty in learning. 3. Clear best practices and frameworks. The philosophy of composing libraries is extremely powerful, but to gain broader adoption you still need straight forward frameworks and opinionated best practices. The last point has man…

If you tried Clojure a few years ago, the Tooling could be a problem. But now, the tools-deps(official Clojure cli) is awesome.

Re: Clojure: A Lisp that wants to spread

#213

Post by doglooksgood »

feanaro wrote: post #148
slowmovintarget wrote: post #109

Earlier quoted context omitted.

Static types are the new religion, like OOP was in the 90s. Types solve 2% of programming errors. They lead to coupling for the sake of the compiler, and make code harder to change, harder to write, and often needlessly constrain the utility of the code where they're applied. But they do make the IDE code-completion go, so there's that.

My experience is the opposite. Types make code much easier to refactor, in fact almost effortlessly so and with a certain confidence the code won't be hopelessly broken afterwards. They also make code easier to reason about since the coupling that exists because of types is the result of an explicit and thoughtful decision on the part of the author. You don't as often get into situations where the code appears to wor…

I think what the most import for refactoring, is about runtime.

When you get a totally unfamiliar code base, only if you can run it over and over, or at least run the tests over and over, then you can talk about the refactoring. If you can't, the refactoring is almost impossible, not matter how strong the type system is.

For an argument which require type of string, the behavior could be unexpected if you just give it a string.

Re: Clojure: A Lisp that wants to spread

#214

Post by dom96 »

7thaccount wrote: post #107
pron wrote: post #62

Earlier quoted context omitted.

It is a rather ill-defined form of compilation; i.e., it's not clear what that form is. Compilation means translation from one language to another; every compiler does that. Transpile was born because people were used to the fact that the target language of many compilers is machine code, but it's entirely unnecessary to have a separate word for that, as it doesn't add any information. There could be a meaningful ter…

I think this is just the way human language generally works being that it is organic and messy. In my field, there are numerous overlapping and even contradictory terms. I like the added distinction "transpiler" provides as I immediately know what the author means. Or the author could just use the term "compiler" plus another sentence to describe which kind. Transpiler seems like the more efficient way to convey the…

Most people use the word transpiler incorrectly (if we look at Wikipedia’s definition). Nim to C is compiling because Nim is at a higher level of abstraction than C.

If you think that any program that translates code from one language to another is a transpiler then I’ve got news for you, gcc and clang are transpilers. They translate C/C++ to Assembly after all.

Re: Clojure: A Lisp that wants to spread

#215

Post by tpfour »

peatmoss wrote: post #19
gentleman11 wrote: post #8

Why don’t lisp fans use older lisp implementations like Common Lisp or scheme? Is it just a lack of libraries and frameworks?

Some of it is libraries and frameworks. Some of it is the attention Clojure has paid to ergonomics. A lot of Clojure’s libraries seem to have been built by smart people for mediocre programmers (like me!). Elsewhere in lisp land it can feel like smart people wrote libraries for themselves. For me Racket is probably the closest thing to a decent end-to-end modern lisp experience with decent libraries outside Clojure.…

Gerbil Scheme allowed me to be productive in Scheme. It really is a treat to work with. No tooling required other than compiling Gambit, Gerbil and having a text editor. Those three things let you ship fast binaries, with static or shared libraries. Couple that with a nice macro system (a la Racket) and you can get going really fast.

Re: Clojure: A Lisp that wants to spread

#216

Post by lincpa »

_xt8z wrote: post #199
engineeringwoke wrote: post #189

Earlier quoted context omitted.

I thought he was joking at first too and googled it to find out that he was in fact serious.

The quoted part reminds me of the fizzbuzz enterprise edition.

Unfortunately, you treat the quote as a joke, and you have no ability to apply the quote at all.

Re: Clojure: A Lisp that wants to spread

#218

Post by grierson »

zerr wrote: post #4

While we are at it - how do you refactor a mid-sized/large Clojure project?

The same way you refactor any other mid size project? Refactoring 2nd ed by Martin Fowler mainly uses Javascript and Refactoring (Ruby edition) by Jay Fields are both dynamic. Tests cover you when refactoring not types.

Re: Clojure: A Lisp that wants to spread

#219

Post by PaulRobinson »

I used to work at a large Clojure shop. I've moved on, and I've heard anecdotally that they are building most new stuff in Go.

Barrier for entry and continued use in that limited experience was:

- Learning curve for new developers is very high in comparison to other languages, so moving existing engineers over sucks.

- Experienced Clojure developers want a job where they can "do Clojure", not necessarily because they're interested in the problems the business was created to solve, so hiring sucks.

- Lots of conversations turn to "the Clojure way" to solve a problem rather than using industry accepted protocols, standards and tooling. I mean, OK, but this makes interacting with the rest of the World a bit sucky.

- Most libraries never get to v1.0. Most people write 0.0.1 and may do some minor updates so you see it get to 0.0.5 and then it stays there. That's probably because it all 'just works', but it scares most devs when they see that and are about to bake it into their next release.

- Deployment is a known quantity and the JVM is useful in this regard, but it doesn't have the pure simplicity that some other runtimes do. Clojure implementations in other runtimes (Joker, Clojerl, etc.), might help or hinder here.

Startup time is a problem on CLI and desktop apps, sure. At my ex-employer, one server deployed app took several minutes to start and that had challenges.

That was not - I think - the reason the team started to look elsewhere or the reason I'm more likely to pick up Ruby, Python, Go or Elixir for my next project. There are lots of rough edges like the ones I identify above - many of them cultural - that need to be smoothed out a little, I think.

I look forward to functional methods becoming mainstream (again?), and Clojure could get there, so I wish the community luck.

Re: Clojure: A Lisp that wants to spread

#220

Post by billfruit »

devin wrote: post #156
stingraycharles wrote: post #136

Earlier quoted context omitted.

> Having leiningen not bundled into the clojure distribution, is in strong contrast to the "batteries included" approach of python. The problem is that Cognitect (the company behind Clojure) don’t use Leiningen themselves, and instead have released their own tool called deps.edn. This has only fragmented the community even further, making it even more difficult for newcomers, with questionable benefits.

That’s an exaggeration. You’re not entirely wrong, though. First, it is not called deps.edn, it is called tools.deps. Second, it is without a doubt, 100% untrue that projects that Cognitect employees work on, exclusively use tools.deps. Cognitect has client projects they start from 0, and existing projects they shepherd and grow responsibly. Their first priority is to help their clients succeed in their goals, not ch…

Fundamentally though I thought the language ecosystem needs stability and consistency. Very many of clojure related tutorials, stack overflow answers are outdated.

Like I mentioned Windows tooling and distribution seems not get much focus.

Emacs, cider, nrepl workflow on Linux is too complex with many moving parts, and very brittle(may be things have improved recently).

A major pain point for me specifically is that on an exception you don't get a live repl, you only get the stack trace of a dead program.

Even some minor inconsistencies lambda positional argument numbers seem to start from 1, than 0, which is where indexes start in all other cases.

Post reply on HN