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

191–200 of 306 posts

Re: Clojure: A Lisp that wants to spread

#191

Post by maehwasu »

As someone who uses Clojure a lot:

It would be a lot better for language adoption if people would write more blog posts showing best practices for tooling, and less vague stuff about how awesome the language is.

For example, the startup time thing is completely irrelevant if you use Emacs/VSCode with a standalone REPL that you connect to.

It's non-trivial to set this up (more because of lack of consolidated info rather than time it takes), but it can easily be standardized across machines/envs (I Dockerize all projects in a simple way to allow team members to get started up with REPLs easily).

Re: Clojure: A Lisp that wants to spread

#192

Post by dimitar »

roenxi wrote: post #182
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…

The other interesting problem is that the experts are using tools and concepts that are a long way away from a beginner and that can make it harder for beginners to learn. In Clojure when a beginner wants to accomplish a task their biggest problem is that they are solving the wrong problem or being pushed to deal with problems they don't understand. Case in point the var/agent/ref system is fantastic and probably cri…

The advice the community usually gives is just use hashmaps. You can easily refactor when you need that more difficult functionality, because the language strongly disincentives mutable state, which is what usually causes issues.

Re: Clojure: A Lisp that wants to spread

#193

Post by snorremd »

galaxyLogic wrote: post #113
scarredwaits wrote: post #44

Earlier quoted context omitted.

I can attest that full stack (server-browser) Clojure code sharing works very-very smoothly. I've been developing web applications like that for some time now, and apart from less context swithing (because it's the same language on both sides), sizeable parts of the code are cross-compiled to run both on the browser and the JVM with very little or no extra effort. Example 1: I'm using Clojure's Spec library for valid…

Much of the client-side code is about manipulating the DOM. Such code must assume the DOM-API exists. So such code can not run on the server unless there is some kind of ducky DOM environment there as well. And since client-side relies much on destructively manipulating the DOM, how can such code be tested on the immutable clojure server? > sizeable parts of the code are cross-compiled to run both on the browser But…

I did a project where we used ClojureScript both on the server and the client. The server ran on Node.js and so most libraries could be used on both the server and client. We used reagent to render our app which made it possible to use reacts render DOM to string functionality.

Essentially the app was developed as an isometric app, and we had some additional stuff in the server part of the application.

While running ClojureScript serverside might not be everyone's cup of tea, it worked well for us.

Re: Clojure: A Lisp that wants to spread

#194

Post by dragandj »

maehwasu wrote: post #191

As someone who uses Clojure a lot: It would be a lot better for language adoption if people would write more blog posts showing best practices for tooling, and less vague stuff about how awesome the language is. For example, the startup time thing is completely irrelevant if you use Emacs/VSCode with a standalone REPL that you connect to. It's non-trivial to set this up (more because of lack of consolidated info rath…

I totally agree, and that's why I am going to write a book about that:

https://twitter.com/draganrocks/status/1226811229362147331

It has to wait until I wrap up the books that are currently in progress [1], but I expect to start this summer.

[1] https://aiprobook.com

Re: Clojure: A Lisp that wants to spread

#195

Post by dragandj »

stingraycharles wrote: post #186
dragandj wrote: post #181

Earlier quoted context omitted.

Does it matter when all these tools are compatible (on the level of artifacts and distribution repository)?

For the experienced user, it doesn't matter. But for the newcomer, it's one more additional choice to make, and, as the grandparent said, is in sharp contrast to a "batteries included" approach you see in Python. Given that build tooling is one of the more frequent complaints, more fragmentation in this area is undesired.

It's funny that you mentioned Python :) https://wiki.python.org/moin/ConfigurationAndBuildTools

Re: Clojure: A Lisp that wants to spread

#196

Post by maehwasu »

dragandj wrote: post #194
maehwasu wrote: post #191

As someone who uses Clojure a lot: It would be a lot better for language adoption if people would write more blog posts showing best practices for tooling, and less vague stuff about how awesome the language is. For example, the startup time thing is completely irrelevant if you use Emacs/VSCode with a standalone REPL that you connect to. It's non-trivial to set this up (more because of lack of consolidated info rath…

I totally agree, and that's why I am going to write a book about that: https://twitter.com/draganrocks/status/1226811229362147331 It has to wait until I wrap up the books that are currently in progress [1], but I expect to start this summer. [1] https://aiprobook.com

Awesome.

To put my own money when my mouth is, here is the bash script to start up a nREPL server in Docker: https://pastebin.com/PPmfDPyA

Here is the Dockerfile: https://pastebin.com/ymcUFdYT

And here is a sample deps.edn with the cider alias: https://pastebin.com/2a7vSFD7

To run this, you'd just put them all in one directory, run cider-up.sh, and then connect to the REPL with Cider in EMACS, or in Calva for VSCode with "Jack in to or Connect to REPL Server" and then "localhost" "4444"

Re: Clojure: A Lisp that wants to spread

#197

Post by LandR »

cube2222 wrote: post #91
inferiorhuman wrote: post #59

Earlier quoted context omitted.

What got me started with Clojure was a coworker at megacorp. He's since moved on to a company that makes widespread use of Clojure in production. Startup time was a huge factor for me because I wanted to write command line tools with it. The leaky abstractions were the other painful part – Clojure itself wasn't so bad, but Clojurescript (which would sidestep the startup issue) always seemed to leave me in callback he…

Nowadays you can use GraalVM to have quick startup time for commandline tools with Clojure.

KNow of any good tutorials for how to use Graal with Clojure?

Re: Clojure: A Lisp that wants to spread

#198

Post by smnplk »

hota_mazi wrote: post #98
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…

I think you are omitting the main reason why Clojure never succeeded: it's dynamically typed at the core. It's on the wrong side of history in that respect. I know it's trying very hard to catch up to statically typed languages now by retrofitting some type system, but it's too little, too late. Static types are where the current state of the art is, and we're not going back. Clojure missed that train and will never…

I understand the issues with dynamic typing, but I don't think you can just compare Clojure to other dynamically typed languages, because Clojure is very data driven language. You have lists, vectors, maps and sets. Most of the time this is enough and these are the parameters to functions and also return values of those functions. And on top of that, you don't always have to think about these too, because of the unified sequence abstraction, which allows you to use the same core functions for processing/transforming those underlying types.

Re: Clojure: A Lisp that wants to spread

#199

Post by _xt8z »

engineeringwoke wrote: post #189
_xt8z wrote: post #185

Earlier quoted context omitted.

I definitely saw nothing but sarcasm in the comment you are replying to. But now after looking at their other comments, I see it was not sarcasm. What an understatement for how messy functional programming can actually be.

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.

Re: Clojure: A Lisp that wants to spread

#200

Post by stingraycharles »

dragandj wrote: post #195
stingraycharles wrote: post #186

Earlier quoted context omitted.

For the experienced user, it doesn't matter. But for the newcomer, it's one more additional choice to make, and, as the grandparent said, is in sharp contrast to a "batteries included" approach you see in Python. Given that build tooling is one of the more frequent complaints, more fragmentation in this area is undesired.

It's funny that you mentioned Python :) https://wiki.python.org/moin/ConfigurationAndBuildTools

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 and Maven are all candidates to do this.

Post reply on HN