Six years of professional Clojure development • Hacker News Board

Re: Six years of professional Clojure development

#91

Post by slifin » Thu, May 06, 2021, 2:23 PM UTC

fnord123 wrote: post #61

joelbluminator wrote: post #11

Earlier quoted context omitted.

I don't think it's about it's dynamicism but more about it being functional. Plenty of super popular dynamic languages out there. I think that's also what keeps elixir from becoming something more mainstream, most people come from OOP and are used to thinking about programming that way.

You're both wrong. If it was dynamicism then why are JS, Python, and Ruby so popular? If it's about being functional then why has Scala got more users? Languages are driven by the platform. There is no Clojure platform that people want to use, so no one uses Clojure. If a language isn't bound to it's own platform, it can share a platform and displace other tools like python, go, and rust do with C and C++ (docker is…

Compile that same app with graalvm native and you'll get near instant hello world

If you don't want to have to manually compile your app then you can use https://babashka.org/

How many platforms do you think Clojure has?

Re: Six years of professional Clojure development

#92

Post by comma_at » Thu, May 06, 2021, 2:24 PM UTC

cies wrote: post #87

comma_at wrote: post #62

Earlier quoted context omitted.

> If you cannot have compile time guarantees on correctness, the discipline to not break things becomes a key feature. On the other hand, if you have strong correctness guarantees, you may more easily incur some breakage (and thus actually fix things). Yes, and the result of that is cabal hell. Types aren't there to help you break your API. Once the API is out and it has users it is rude to break them. The linux kern…

Cabal hell is fixed with tooling. Part of that tooling is running tests, but a large part of it is "it compiled together so it should work together" (which is a safety dynamic typed langs dont offer).

No it is not. People still reach out from stack when a dependency has updates and it's not in stack yet.

Nobody cares if it compiles together. The point is if a new feature or a bug fix is introduced in a breaking way you cannot bump your dependency and start using it, or progressively move to the new API.

Re: Six years of professional Clojure development

#93

Post by mark_l_watson » Thu, May 06, 2021, 2:34 PM UTC

thomastjeffery wrote: post #71

pjmlp wrote: post #10

Earlier quoted context omitted.

JVM and .NET are the top runtimes with best in game GC implementatios, JIT compilers, JIT code cache, and monitoring tools for production code. In fact plenty of them, given that there are multiple implementation to choose from. Meanwhile other languages keep playing catchup and having to rewrite extensions in C.

The runtimes themselves may be great, but the tooling is bloated and uncomfortable. Every time I use Clojure, I am reminded how much I hate using Java. The error messages alone are enough to turn me away. So is having to set up a whole Leiningen project just to get started. A Clojure without Java would be very attractive to me.

I usually use Cider + Emacs for Clojure. Cider let’s you interactively check values and makes error messages more understandable, at least to me.

I think that many Clojure programmers skip the JVM and use ClojureScript with node. Personally, given my history with Java I find that Lisp + JVM ecosystem is why I use Clojure sometimes instead of Common Lisp.

Re: Six years of professional Clojure development

#94

Post by dkersten » Thu, May 06, 2021, 2:36 PM UTC

YuukiRey wrote: post #15

Clojure is the most enjoyable language I've ever used and I love the interactive development. I haven't written code in any other language that even comes close. Unfortunately I am too lazy and careless to use Clojure in any serious capacity though. I really need a Haskell or Rust compiler to remind me of all my silly mistakes. I can't be trusted to get to the same level of confidence through unit tests or linting or…

I've been using Clojure since the summer of 2009, started a startup with it, using it exclusively on one project right now... and I agree about static types. I love many many things about Clojure, its my favourite language to use and I find it very well designed over all. But proper first class static types are the one thing I wish it had.

My dream programming language is basically a statically typed Clojure.

I've on and off poked at trying to make something like that (parsed using instaparse, type checked in Clojure, compiled to C++ using https://github.com/arximboldi/immer for the data structures), but haven't had the time to really get anywhere with it. Plus, even if I succeeded, I wouldn't have the rich Clojure (and by extension, Java and Javascript) ecosystem.

Re: Six years of professional Clojure development

#95

Post by clartaq » Thu, May 06, 2021, 2:38 PM UTC

I've used Clojure for going on 10 years now and it has been one of the most enjoyable programming languages I've ever used. But I've gone back to Scheme for a few ridiculous reasons.

1. TCO. Using `recur` in Clojure just breaks my thought process. 2. Difficulty in getting down to the metal when needed. Using JNI is painful. In Scheme, when needed, the FFI usually handles plain old C. Much easier in my opinion. 3. Community. Rich is a really smart guy and has made great contributions, but he doesn't suffer fools lightly and I am a fool. Great for a scientist, not so much for a "benevelent dictator for life" of a programming language. 4. Pragmatism over correctness. There was a long running conflict about some set operations that did not return correct results. To my mind, there is no argument against correctness. 5. Slow startup. Not always a problem except when it is. 6. ClojureScript. Could be my unfamiliarity with ClojureScript/JavaScript, but I find I have to revert to JavaScript too often to get something done. And if I can't just use ClojureScript, why use ClojureScript?

Like any Lisp, Scheme is easier to read than Python, Java, JavaScript, Haskell, PHP, Perl, Fortran, Forth, APL, etc. Pascal is pretty good in this regard though. Clojure might actually be better in my opinion.

Why not Common Lisp? It's pretty good and at least as powerful. The warts annoy me though.

So I will continue using Scheme while looking into Janet https://github.com/janet-lang/janet. Janet has most of the things I like about Scheme _and_ Clojure. More experience will tell. I just miss the way maps are handled in Clojure.

Re: Six years of professional Clojure development

#96

Post by mark_l_watson » Thu, May 06, 2021, 2:40 PM UTC

pjmlp wrote: post #89

thomastjeffery wrote: post #71

Earlier quoted context omitted.

The runtimes themselves may be great, but the tooling is bloated and uncomfortable. Every time I use Clojure, I am reminded how much I hate using Java. The error messages alone are enough to turn me away. So is having to set up a whole Leiningen project just to get started. A Clojure without Java would be very attractive to me.

There is nothing else that gets close to the world promised to us by Xerox PARC. Don't blame Java for the issues that are Clojure's fault. The only Lisps that can match such tooling are Allegro and LispWorks.

Well, I owned a Xerox Lisp Machine from 1982 to about 1987. True, a great programming environment, but the situation is so much better today. For example, I own a LispWorks Professional license, and the support and quality of the product is fantastic. My friends at Franz have similar quality products like Allegro and AllegroGraph. Even Clojure+Cider or Haskell+Intero or Haskell+VSCode (easiest to set up) is arguably better than dealing with lack of deployment options for Lisp Machines.

Re: Six years of professional Clojure development

#97

Post by mumblemumble » Thu, May 06, 2021, 2:44 PM UTC

draklor40 wrote: post #81

yogthos wrote: post #70

Earlier quoted context omitted.

My team structures projects by breaking things up into small isolated components that can be reasoned about independently. We'll often do it at the level of namespaces, where a namespace will describe a particular workflow or data transformation, and namespaces tend to be 500 lines or less. It's a similar idea to microservice architecture without the overhead of having to actually split the application up into separa…

``` breaking things up into small isolated components that can be reasoned about independently ``` - This is insufficient for the same reasons unit tests are not enough and you also need integration tests. The moment you cross namespace boundaries, you will end up not setting keys /entries in maps , missing logic etc and end up needing something like Spec/Schema....

> you will end up not setting keys /entries in maps

This is what I run into. But that's not exactly a dynamic language problem. It's more of a data-oriented programming (in the Clojure sense) problem.

I'm coming to the opinion that data-oriented programming techniques only make sense inside a fairly tightly bounded context. One that's small enough that you can see and understand the whole thing at once. As soon as you've got ad-hoc data structures crossing logical boundaries, you lose the ability to keep track of it all, and it becomes very difficult to ensure everyone's interacting with these ad-hoc types in a compatible manner.

Incidentally, this is also exactly why I dislike JSON for APIs. I'd much rather share data across boundaries using data structures with explicit, nominal, static types. Like what you get in gRPC.

Anyway, my Clojure experience is limited, but I think this is why I have an easier time letting Python code get big than I did Clojure. With Python, I've got myself into some problems with data oriented programming, too. But with Python, it was easy (and idiomatic) to walk that back and switch to using dataclasses.

Re: Six years of professional Clojure development

#98

Post by dkersten » Thu, May 06, 2021, 2:48 PM UTC

vasquez wrote: post #26

joelbluminator wrote: post #11

Earlier quoted context omitted.

I don't think it's about it's dynamicism but more about it being functional. Plenty of super popular dynamic languages out there. I think that's also what keeps elixir from becoming something more mainstream, most people come from OOP and are used to thinking about programming that way.

I really like Clojure, it's the language that finally made FP "click" for me. It was my go to for hobby/side projects for quite a while. Dynamic typing is why I eventually switched. Haskell scratches the same itches that Clojure did, but the compiler and type system are immensely helpful, and keep saving me from tripping over my own feet.

Somewhat off topic: My problem with Haskell is that every time I've tried to read the documentation, I've felt like I needed a PhD in type theory to understand all of the terminology. As a practitioner (not a researcher), I just want to know how to do things, but the documentation has always been a roadblock to me. So, after a number of attempts at learning to use Haskell, I've decided its not for me. Not because of the language itself, but because of the traditions around it.

Re: Six years of professional Clojure development

#99

Post by grncdr » Thu, May 06, 2021, 2:48 PM UTC

regularfry wrote: post #32

snotrockets wrote: post #21

Earlier quoted context omitted.

I don’t think it’s the parents, but the s-expression themselves. LISPs forces you to maintain the stack for the parse tree in your head, something humans aren’t that great at — s-expressions are the programming language equivalent of center embedding, which is quite alien for human languages (the depth is three at most: compare that to your favorite lisp program)

If you've seen 300+ line react components marching off the right of the screen, you'll know that maintaining the parse tree in your head isn't a barrier to popularity.

While this made me laugh a bit, I think there's a meaningful difference between using "tree-like" syntax for all your code (lisp & S-expressions) vs declarative UI descriptions (JSX).

A deeply nested syntax is beneficial for UI work because you can correlate the structure of the code with the interface/document being rendered. S-expressions for HTML/UI in the form of Hiccup-style templates are equally good (if not better) for the same reason.

In JSX however, there is a clear syntactic distinction between behaviour (C-like JavaScript syntax) and interface descriptions (HTML-like element constructors). In Lisps, the uniformity makes it harder to quickly distinguish "behaviour" from "data", which is kind of the point, but comes with a trade-off in readability.

Re: Six years of professional Clojure development

#100

Post by mikelevins » Thu, May 06, 2021, 2:54 PM UTC

nonbirithm wrote: post #16

lukashrb wrote: post #6

Nice article. Sadly a lot of people won't even try clojure since it is dynamic typed. I see their point but nevertheless clojure does something really well here. As the author obserserves designing around some core data structures results in high code reuse. A library like spec is also way better in encoding business requirements than all the mainstream language typesystems e.g. a number in business context has mostl…

Can we have a REPL-driven language that's statically typed? My hope is yes, in that it's just that the work hasn't been put in yet to create to create the equivalent of Typescript for Clojure or Lua that compiles down to the actual, extensible language. I always wish that it would become unnecessary to have to choose between stability and extensibility when selecting a programming language. Having a Clojure with stat…

Depends on what you mean by "repl-driven". If you mean a statically-typed language with a decent repl, then yes, you can have that--for example there are Haskell and ML implementations that give it to you.

If you mean "repl-driven" in a stronger sense, in the sense of a livecoding repl-driven environment that supports building programs by interactively modifying them as they run, then about the only place you find full-featured support for that style of programming is in old-fashioned Lisp and Smalltalk systems. Maybe also in Factor, and arguably in FORTH (though with fewer conveniences).

There's no reason in principle that you can't have a full-featured repl-driven environment for a statically-typed language; I just don't know of any. That's not a big surprise, though. There aren't all that many of them for dynamically-typed languages, either. It takes a lot of work to build one, and the builders pretty much need to know up front what it is they're trying to build, which means they probably need to have seen one before. Most programmers haven't.

Static types aren't particularly an obstacle, but strong immutability is. A full-featured repl-driven livecoding environment wants the programmer to be able to inspect and change anything and everything in the live environment as it runs. Soft immutability is fine; it's okay if you have to say "Mother, may I?" before changing something. Hard immutability is a problem, though. If it's actually _impossible_ to change something, that's incompatible with the nature of a repl-driven livecoding environment. A programmer accustomed to livecoding environments will experience that impossibility as a bug in the environment.