Clojure: A Lisp that wants to spread • Hacker News Board

Re: Clojure: A Lisp that wants to spread

#261

Post by billfruit » Tue, Mar 03, 2020, 2:44 AM UTC

dragandj wrote: post #221

stingraycharles wrote: post #200

Earlier quoted context omitted.

Are you saying that just because there is a choice of configuration build tools and utilities for Python, the argument that there is a standard way of doing things is invalid? If I want to start a Python project, I `pip install -r requirements.txt` and I can start using it. In Clojure, I need to choose which tool I want to use to perform this simple task, in Python this is standardized. Leiningen, Boot, tools.deps an…

There is such de-facto standard in Clojure too. just do `lein`. + even if you choose another build tool, it is: 1) compatible 2) if you're a newcomer, you probably only need a few dependencies, which is configured in the same way as lein's `project.clj` I mean, I agree that there definitely is a need for better guides for Clojure and defaults, but I don't think that is the reason Clojure is not more popular, and that…

But as I said, lein is not distributed with clojure, and installing lein on Windows is not straightforward.

Re: Clojure: A Lisp that wants to spread

#262

Post by lincpa » Tue, Mar 03, 2020, 3:48 AM UTC

harperlee wrote: post #249

lincpa wrote: post #229

Earlier quoted context omitted.

show you github or blog, Time is not ability.

Your github is full of text and cloned repos... and you refused my earlier suggestion of sharing practical examples of your Tao, so it seems strange that you are so quick to demand proof of competency through code just to discuss with you.

If I give an example of one aspect of a topic and students cannot understand other aspects, then I will not repeat the explanation or example.

        ---- Confucius, a famous Chinese educator

Imagination is more important than knowledge.

The true sign of intelligence is not knowledge but imagination.

Logic will get you from A to B, imagination will take you everywhere.

        ---- Albert Einstein

Confucius and Albert Einstein mean the same thing. I have enough examples. If you still do n’t understand, you are not suitable for learning my theory.

My github is mainly my blog and my project homepage, and other code bases are just collections of other excellent developer projects.

I think hellofuck is not good, but he is not convinced, so I think he can show himself with blog or github.

Re: Clojure: A Lisp that wants to spread

#263

Post by fulafel » Tue, Mar 03, 2020, 5:40 AM UTC

LandR wrote: post #234

akashhc wrote: post #201

Earlier quoted context omitted.

https://github.com/lread/clj-graal-docs

Thanks! Took a while, but I got this working on Linux. Gave up on Windows, like with everything it never seems to work on Windows. End result is 8.1MB for "hello world".

Windows can run Linux binaries now :)

Re: Clojure: A Lisp that wants to spread

#264

Post by fulafel » Tue, Mar 03, 2020, 5:42 AM UTC

DannyB2 wrote: post #237

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…

Yes, this. Tooling. If you want to get started, Clojurists will insist you learn emacs. After all it's so great you must learn it. Now I have nothing against emacs. But I don't expect to have to invest significant effort to learn a specific editor in order to use a programming language. No other programming language has this requirement. I was surprised at how many Clojure users took this as an attack upon emacs. It…

You might have a biased sample of Clojurists, in my vicinity ~50% use Cursive.

Not sure where you get the disrepair part, Cursive is alive and well and seems to be a sustainable business for the author, and Calva also seems to do be doing well.

It's true that there have been various open source IDE efforts that are dead now (Counterclockwise for Eclipse went the way of Eclipse, Lighttable and Nightcode were probably a bit too experimental / radical)

Re: Clojure: A Lisp that wants to spread

#265

Post by didibus » Tue, Mar 03, 2020, 6:55 AM UTC

billfruit wrote: post #260

didibus wrote: post #233

Earlier quoted context omitted.

This is being addressed currently. There is now a bundled into the Clojure distribution package manager called "tools.deps". It currently have alpha support for Windows. They are still ironing out the quirks: https://github.com/clojure/tools.deps.alpha/wiki/clj-on-Wind... You no longer need local Maven repo, because tools.deps supports local dependencies, you can basically just depend on local folders. It also can de…

Yes, but that again begs the question why these are being addressed such late in the evolution of the language/ecosystem.

That's just a matter of man power. Things take time, this sort of tooling wasn't the priority. The community was able to easily take over that space, and relying on Maven was a great way to start off.

If you look at Python, Pip appeared in 2011, where as Python launched in 1991. And if you look at the Python scene, it's pretty messy as well, just read this guide: https://packaging.python.org/guides/tool-recommendations/

Pip isn't even the recommended one to use anymore, slowly being superseded by Pipenv, yet you also have Poetry and conda and to package things you still need setup tools and you have to use twine to submit wheels to pypi, etc. And I still see a lot of guides telling you to use easyinstall still.

In Clojure, you had Maven first as the de facto, then Leiningen became de facto, and now you have an official one with tools.deps as the new de facto.

Re: Clojure: A Lisp that wants to spread

#266

Post by [deleted] » Tue, Mar 03, 2020, 8:59 AM UTC

didibus wrote: post #89

zerr wrote: post #4

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

So, my first answer is that you shouldn't have too, and if you do, you might not be writing proper Clojure code. The most fundamental concept in Clojure, from the famous Rich Hickey talk Simple Made Easy ( https://www.infoq.com/presentations/Simple-Made-Easy/ ) is that your code should strive to be decomplected. That means that your program should be made of parts that when modified do not break anything else. This,…

[deleted]

Re: Clojure: A Lisp that wants to spread

#267

Post by lincpa » Tue, Mar 03, 2020, 9:05 AM UTC

lincpa wrote: post #262

harperlee wrote: post #249

Earlier quoted context omitted.

Your github is full of text and cloned repos... and you refused my earlier suggestion of sharing practical examples of your Tao, so it seems strange that you are so quick to demand proof of competency through code just to discuss with you.

If I give an example of one aspect of a topic and students cannot understand other aspects, then I will not repeat the explanation or example. ---- Confucius, a famous Chinese educator Imagination is more important than knowledge. The true sign of intelligence is not knowledge but imagination. Logic will get you from A to B, imagination will take you everywhere. ---- Albert Einstein Confucius and Albert Einstein mean…

Typographical error:

1.hellofuck -> hellofunk

2.Show you github or blog -> Show your github or blog

Finally, you try to downvote my comments, and it doesn't make any sense, you should know that everyone's talent is different, just as your talent doesn't suitable for learning my theory, Or rather, you have no fate with the Tao.

Re: Clojure: A Lisp that wants to spread

#268

Post by thu2111 » Tue, Mar 03, 2020, 9:45 AM UTC

stingraycharles wrote: post #142

mistersys wrote: post #67

Earlier quoted context omitted.

Uhm.. I want to give the benefit of the doubt, but frankly this seems deceptive, or at least out of date, unless I'm totally missing something. Why is there no magical --client / --script option for the Clojure ClI to make startup faster, if this is such an easy solution? Also, you show system time, but the time to load dependencies is in user time, which is slow by the nature of Clojure. Example: $ time java -client…

As mentioned in other comments, the -client option is ignored on 64 bit JVMs, so it has no practical effect. Giving the benefit of doubt, Rich Hickey must have been using a 32 bit JVM.

That's not quite it. The client/server distinction was removed from the JVM many years ago. These days the JVM switches between modes on the fly on a per-method basis, this is called tiered compilation, so the optimisations are in effect on by default. Back in 2006 yes it may have made a big difference but it wouldn't have made startup magically instant.

IIRC Clojure apps are slow to start because they do a lot of first-time setup work that isn't actually executing user code. It's not so much a JVM problem as a Clojure-emitted-code problem. The GraalVM native-image tool fixes it because it can start an app in a pre-initialised state.

Re: Clojure: A Lisp that wants to spread

#269

Post by thu2111 » Tue, Mar 03, 2020, 9:50 AM UTC

PaulRobinson wrote: post #219

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…

Experienced Clojure developers want a job where they can "do Clojure"

This seems like a common problem with functional languages in general. I've heard the same thing about Haskell, repeatedly. Such devs search out a place where a Haskeller/Clojurist got into a tech lead position and then all pile in, before you know it the team is spending half its time writing DSL compilers instead of adding features to the product.

I look forward to functional methods becoming mainstream (again?)

Has it ever been mainstream? AFAIK it's always been this basically strange offshoot of the family tree that split off a long time in the past.

The core problems you highlight don't have any obvious solution, unfortunately. Learning materials can be improved but ultimately Lisp is very old and very unlike more modern languages. Libraries not getting to 1.0 is a symptom of a small community that derives more satisfaction from an intellectual exploration than having lots of users, combined with lack of commercially driven outcomes. Startup time I guess can be solved with technical solutions (and is being solved, as a side-effect of other projects elsewhere in the JVM ecosystem).

Re: Clojure: A Lisp that wants to spread

#270

Post by stingraycharles » Tue, Mar 03, 2020, 10:14 AM UTC

thu2111 wrote: post #268

stingraycharles wrote: post #142

Earlier quoted context omitted.

As mentioned in other comments, the -client option is ignored on 64 bit JVMs, so it has no practical effect. Giving the benefit of doubt, Rich Hickey must have been using a 32 bit JVM.

That's not quite it. The client/server distinction was removed from the JVM many years ago. These days the JVM switches between modes on the fly on a per-method basis, this is called tiered compilation, so the optimisations are in effect on by default. Back in 2006 yes it may have made a big difference but it wouldn't have made startup magically instant. IIRC Clojure apps are slow to start because they do a lot of fi…

I understand, but either way, the example Rich Hickey used to execute the sample Clojure application in less than a millisecond seems impossible?

In other words, if Rich' example is real and recent, what could possibly be the environment in which this worked?