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

231–240 of 306 posts

Re: Clojure: A Lisp that wants to spread

#231

Post by fulafel »

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…

The dynamic vs static typing language tussle has been going on for pretty long. I think at this point in history the dynamic languages are doing much better than most times in PLT history. There was a time when C & Java were considered "serious" languages and dynamic languages were the underdogs.

I think dynamic languages are generally a good default, but the current world also matches them pretty well because programs talk to the outside world in a lot more varied ways than before and static typing is not that very good across distributed systems.

Static has a better case when talking about more powerful type systems than what mainstream languages have, but those don't really show accelerating signs of breaking through to mainstream. Rust is an exception in the recent history but it's not really poised to become a widely applicable app programming language.

Re: Clojure: A Lisp that wants to spread

#232

Post by fulafel »

inferiorhuman wrote: post #59
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…

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…

Is Rust better in the browser wrt "callback hell" in your view?

In ClojureScript you can use core.async to write async code in straight-line form. But I find myself using it pretty seldom, as handling events explicitly in functions feels pretty natural in Clojure especially given how naturally closures work in the language.

Re: Clojure: A Lisp that wants to spread

#233

Post by didibus »

billfruit wrote: post #131
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…

And poor tooling support on MS Windows. Leiningen does not even have a proper installer on Windows, last time I checked. Having leiningen not bundled into the clojure distribution, is in strong contrast to the "batteries included" approach of python. There were also complexities in including local jars into projects, as it required setting up a local maven repository, which is tedious job. Also when exeptions occur c…

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 depend on git repos.

Re: Clojure: A Lisp that wants to spread

#234

Post by LandR »

akashhc wrote: post #201
LandR wrote: post #197

Earlier quoted context omitted.

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

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".

Re: Clojure: A Lisp that wants to spread

#235

Post by didibus »

_xt8z wrote: post #129
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.

I don’t know what percentage of errors are caught by static typing, but I do know what percentage of my time has been saved by switching to a statically typed language. I love clojure, but I spent at least an order of magnitude more time tracking down various bugs than I do now, simply because the compiler didn’t catch them for me.

I totally respect anyone for just choosing a language that works best for them. They are tools for craftsman, and often are about which one makes you a better programmer.

For me, Clojure definitely made me way more productive. My background was in statically typed language mostly prior, though I had done some Python and JavaScript as well. With Clojure I feel I'm between 30% to 300% more productive overall. I think some of this is personal, depends on your style and your own strengths and weaknesses.

Re: Clojure: A Lisp that wants to spread

#236

Post by galaxyLogic »

mateuszf wrote: post #144
galaxyLogic wrote: post #113

Earlier quoted context omitted.

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…

> 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? The same way as it's done in React. Think of a client app as a loop reacting…

> Think of a client app as a loop reacting to user /network events and turning state into html.

Then who, which part of the code, inserts that HTML into the DOM? Is that done by user-code or some library (when using Clojure)?

Re: Clojure: A Lisp that wants to spread

#237

Post by DannyB2 »

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 took some careful explaining to make the point that I have better things to invest my time into, such as building more code in Clojure, rather than learning yet another tool, that does something for which I have other tools already.

There were some great IDEs for Clojure. But they have all fallen into disrepair and being unmaintained.

Re: Clojure: A Lisp that wants to spread

#238

Post by mark_l_watson »

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…

Great language and ecosystem. I donated at the beginning and made my living writing Clojure code for a few years. However, I find myself way more productive using Common Lisp, perhaps because since I have used it since 1982.

I think Clojure’s sweet spot is a small team working on a large enterprise project.

Re: Clojure: A Lisp that wants to spread

#239

Post by DannyB2 »

slowmovintarget wrote: post #109
hota_mazi wrote: post #98

Earlier quoted context omitted.

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…

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.

Static types turn certain runtime errors into compile time errors. When I learned Pascal in 1982 it became quite obvious what a huge benefit this was.

That said, I still like some dynamic languages for certain things.

Re: Clojure: A Lisp that wants to spread

#240

Post by iLemming »

hota_mazi wrote: post #119
iLemming wrote: post #116

Earlier quoted context omitted.

Yeah, sometimes I look at some Typescript or Scala code and feel like I don't even understand what the heck they are trying to build anymore. Very often it feels like they're "elegantly" trying to solve some made-up, bullshit problems for some questionable gain. Feels like bureaucracy for the sake of bureaucracy. Totally like OOP shit that we're still trying to make sense of, like: public abstract class Ellipse2D ext…

You're aware that it's possible to write bad code in any language, even Clojure, right?

Look, I'm not trying to bash on static typing. I like type systems. I love Haskell's, for example. I missed static type checker in every single dynamically typed language, and Clojure is not an exception.

That being said, there's no conclusive evidence that dynamically typed systems can't be robust and scalable. Sometimes, dynamically typed systems make absolute sense, especially in the context of homoiconic language like Clojure, where you have a "true" REPL.

An analogy I can think of is wired headphones vs. Bluetooth headphones. Audiophiles would vehemently argue that you cannot deliver quality sound via wireless, and all professionals use wired headphones. But sometimes, wireless headphones are what you need - they grant you some freedom, for a small price - you have to charge them, you have to be close the source all the time, there's interference, etc. But at the end of the day, I rather charge them once in a while and enjoy the music.

After using Clojure for some time, now, whenever I need to program in a statically typed language - it feels like I'm a traveler, passing through a series of checkpoints in medieval China or something. Too much ceremony. Perhaps I'm just not smart enough to solve puzzles imposed by a type system over and over again. Maybe the simplicity that Clojure offers allows me to stay dumb and focused on the task at hand, and enjoy the ride.

Post reply on HN