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

121–130 of 306 posts

Re: Clojure: A Lisp that wants to spread

#121

Post by terminaljunkid »

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.

> Types solve 2% .......

Vastly understated in my experience. Even trivial python programs contain errors that could be prevented with a trivial type system like Go's

And performance. Not being fast enough is a bug. Consuming much more energy is a bug, in my book.

Sufficiently expressive type systems are better than dynamic typing. They prevent so many errors, especially in FP-inspired high level data transformation functions. I am saying this as a person who doesn't even like most of FP. (You can infer from my comment history).

Re: Clojure: A Lisp that wants to spread

#122

Post by iLemming »

yarrel wrote: post #64

The dealbreakers with Clojure for me are: 1. Weirdly irregular syntax. 2. Java import statements and Java error backtraces anywhere you want to do real work. 3. Inexcusable renaming and name collisions on basic Lisp functions. It's much, much less of a Lisp than Scheme and neither "but it's properly functional" nor "we fixed the tooling now" make that any less true or the language any more interesting for the use cas…

Well, if you are building your own thing for your own amusement you can find that perfect, more expressive language and use it.

For those of us who work for someone else - Clojure is a godsend. What's the alternative? No Lisp at all, and truly weirdly irregular syntax. Show me a single pragmatic and more or less popular language that's being used in the industry for building business apps that has nicer syntax than Clojure.

Re: Clojure: A Lisp that wants to spread

#123

Post by iLemming »

zerr wrote: post #4

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

By writing smaller functions and avoiding positional arguments. Refactoring/restructuring in Clojure - most of the time is about breaking bigger functions into smaller ones. But if you try to write smaller functions to begin with - that significantly simplifies the task of maintaining that code.

Re: Clojure: A Lisp that wants to spread

#124

Post by j88439h84 »

terminaljunkid wrote: post #121
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.

> Types solve 2% ....... Vastly understated in my experience. Even trivial python programs contain errors that could be prevented with a trivial type system like Go's And performance. Not being fast enough is a bug. Consuming much more energy is a bug, in my book. Sufficiently expressive type systems are better than dynamic typing. They prevent so many errors, especially in FP-inspired high level data transformation…

> like Go's

or Python's. It even has generics.

Re: Clojure: A Lisp that wants to spread

#126

Post by didibus »

For me, this article is spot on. I had been looking for a long time for my one language I can use for everything, and Clojure finally (just recently) got there. I can use it for scripting, writing command line apps, making backend services, writing web front-ends, making desktop applications with GUI, toying with generative art, doing data-science, making games, and more.

It really has great reach, and its only getting better. Similarly, in terms of programming language, you can use it to explore many paradigms and innovative ideas, like CSP, logic, probabilistic, functional, meta, concurrent, dynamic, typed, contracts, data-flow, OOP, condition systems, monads, etc. All this keeps me interested and constantly learning. Never having to wait for features you miss or wish you had.

I can see myself sticking with Clojure for a long time.

Re: Clojure: A Lisp that wants to spread

#127

Post by MBlume »

7thaccount wrote: post #54
pron wrote: post #18

Can we please stop using the verb transpile? Compile is fine, thank you. When it was used only for certain kinds of "shallow" compilation it was bad enough (and it was really horrible even then), but this article uses it when describing compilation with whole-program analysis and optimization and machine code as the target.

There's absolutely nothing wrong with transpile. Yes compiler covers all sorts of things (code -> assembly or code -> different language code...etc). However when I hear "transpile" I immediately think of a language going to another language like when Nim gets converted to C or JavaScript or when Clojure gets converted to Java first. It is a specific form of compilation right?

Minor nit: Clojure at no point gets converted to Java, Clojure gets converted to JVM bytecode. IIRC Clojure occasionally emits bytecode you couldn't produce with Java.

(Clojurescript does [transpile/compile, pick your favorite] to Javascript)

Re: Clojure: A Lisp that wants to spread

#128

Post by _xt8z »

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?

Totally agree, functional programming, and certainly the kind of programming you do with clojure, can get just as messy and far away from your goals as object oriented code.

Clear, organized, well-architected code, in any language, is the skill that takes a long time to develop. I do not personally find clojure makes this any easier than in any language.

Re: Clojure: A Lisp that wants to spread

#129

Post by _xt8z »

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.

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.

Re: Clojure: A Lisp that wants to spread

#130

Post by iLemming »

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,…

> Prefer functions which take their input as separate parameters.

In practice, it's better to avoid positional arguments and extensively use maps and destructuring. Of course, there's a risk of not properly passing a key in the map, but in practice that doesn't happen too often. Besides - Spec, Orchestra, tests and linters help to mitigate that risk.

Post reply on HN