Hacker News Reader

Comment by capableweb | Hacker News Reader

Yeah, I currently do. I only work with companies who can ensure I get to write and maintain Clojure/ClojureScript projects, or any other lisp-like languages.

Just like I'm sure many people would reject jobs that would force you to write assembly code now when we have higher abstraction languages, I reject jobs that are requiring me to work with inferior languages and ecosystems like Rust, Go or JavaScript. It's simply not worth the frustration anymore.

In the beginning of my career I didn't have the flexibility to choose what languages to work with though, but nowadays I am that lucky.

View on HN

I haven chosen to work for companies where a significant amount of my development output will, in theory, be in Clojure. I do work on private projects where Clojure is less ideal, and avail myself of the breadth available to the python ecosystem for example, but when there the multitudinous shortcomings do not take long to manifest.

> python ecosystem for example, but when there the multitudinous shortcomings do not take long to manifest.

What type of shortcomings? Can you provide some examples?

(The question is coming from someone who wrote a Scheme interpreter in the past, but have been using Python for the last 8 years and haven't touched Lisp in long time).

How are mentioned three inferior to Clojure and Clojurescript? What if you need performance or a bit less of maximalism in the community... Or even a community at all and libraries and support?

Go and Lisp have polar opposite philosophies; it makes sense that some developers who like one will be eager to avoid the other.

Clojure has a very strong software community, and find it to be near an ideal size. Tooling is in flux at the moment in the community, and so it has begun to show some of the lack of uniformity that is easy to find in larger ecosystems like python, java, and Appleland etc.

> How are mentioned three inferior to Clojure and Clojurescript?

They are not lisps :)

> What if you need performance

Choose a lisp that gives you performance. Clojure gets you about 80% on the way there, for the rest you can use Common Lisp if you really require performance. I've found that Clojure usually does the trick if you optimize it a bit.

> Or even a community at all

Clojure does have a community, not sure what you mean? There are forums, chats, Q&A sites, blogs, people on Twitter.

> libraries and support?

Plenty of battle-tested libraries with stable APIs, and loads of companies that offer Clojure support (not to mention the great public community that can also help with most if not all questions).

Have you actually used Clojure in any capacity? These points seems to be coming from someone who haven't actually tried to get involved.

Do you ever miss static typing?

I did, in the beginning. But then I learned better ways of achieving the same guarantees, other methodologies to "prove" (not as in "formal proofs") that my program works as it should. Once Clojure.Spec appeared it was a no-brainer to start using it, and now I want Clojure.Spec in all languages, much rather than static typing.

Is lisp really that good? I'm a novice 'tutorials and duct tape' programmer and I've been eyeing SICP lately as a way to hopefully gain confidence in knowing wtf I'm doing.

It won't give you any magic wand if that's what you expect but SICP is highly recommended.

The heart of it is that you can manipulate the AST as you use it - the structure of the language is itself data which can be acted upon. It makes for good metaprogramming which some people really like.

It's way better than Python (type warnings, speed, expressivity, stability, ease of deployment…). You won't build a web app as fast though. But if you plan to build a software that lasts and is easy to maintain, I'd recommend to give it a try.

I also choose to work for companies that use Clojure/Clojurescript. I'm not debating about languages that are better or not, but I get annoyed working in most others.

It may be true that for most high level development a high level programming language will suffice but don't just write off any other languges, because you don't like their ecosystem and/ or design. Languges like C++ or Rust are in no way competing with Clojure since their aims and target market are vastly different. Nobody should write a kernel in clojure, but maybe in rust (Redox) or C++ (Linux).

Please note I said "Clojure/ClojureScript projects, or any other lisp-like languages". I'm in no way limiting myself to just Clojure, any lisp-like language will do, say Common Lisp if performance is needed, ulisp if it has to run on a microcontroller, Babashka/Fennel/Janet if fast startup time is required and so on.

As long as it's s-expressions and interactive development oriented, I'm probably fine with it.

But for the last 4-5 years, I have literally not found a single use case where I'm forced to use C++ or Rust since multiple other (lisp-like) languages has the same target market and the ergonomics are just so much better.

> I have literally not found a single use case where I'm forced to use C++ or Rust

I use C++ to write realtime audio processing applications, especially DAW plug-ins. This is hardly C++'s primary market, but AFAIK there are no lisp-like langauges that can compete with C++ here. I'd be happy to learn something new if this isn't the case!

Common Lisp performance can be about the same as C++, so performance considerations won't stop you there at least. Common. You can also call C and C++ functions from Common Lisp, so the ecosystem shouldn't stop you either.

It would help if you outlined what's missing from for example Common Lisp in order for it to compete with C++, then maybe I'll be able to give more helpful suggestions that will help you.

The reason people use C/C++ for audio is because a kind of 'soft realtime' performance is required. The thread producing audio cannot block for an unbounded amount of time, ever. If you are late to produce an audio buffer, a nasty audible glitch will be the result. This means no file access, no waiting for mutexes, and certainly no garbage-collection pauses.

This is why managed languages like Lisps are rarely (if ever) used for the DSP in audio applications. I am an audio programmer who loves all things lispy, so believe me, I wish this weren't the case.

Fast is unimportant -- latency and determinism are paramount. It's true that GC'ed languages have been used in realtime applications but it's always an uphill battle. There are also low-latency GCs that are being rolled out. I think there's patent issues there but whatever. Might as well just do resource management at compile time.

I don't understand why you gave the example of C++ (Linux)

Linux is written in C, and, perhaps someday, Rust.

Linus doesn't like C++ and has explicitly objected to, among other things, its enthusiasm for implicit allocation. Rust's implicit allocation all lives in libraries and so the Rust for Linux project ripped that out.

Reply on news.ycombinator.com