Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Six years of professional Clojure development

falkoriemenschneider.de

Post reply on HN
Print view View original

151–160 of 209 posts

Re: Six years of professional Clojure development

#151

Post by blunte »

afry1 wrote: post #123
blunte wrote: post #112

I really enjoy the language and even the look of it, and I have tried several times to use it. For "simple" scripts or server processes that you might call from cron, it was fine. But for web development, it was always so hard to get up and running - get everything configured and then know how to do things - that I always gave up. The Clojure community really values choosing libraries and tools and seems to echew Rai…

I've had some difficulty getting a "basic" web server up and running too. Composing libraries together is a great way to build software, but when you're starting from such a low level with a new language where that kind of development style is the norm, it's a steep initial learning curve. Have you looked into Luminus? I haven't tried it yet, but it's supposed to be a Rails-like starter kit for web apps: https://lumi…

I actually did build something basic following the book Web Development With Clojure (https://github.com/jumarko/web-development-with-clojure), but honestly the way the code snippets were presented in the book were sometimes difficult to use if trying to follow along and build it yourself.

I think you could probably get code from different chapters from their git repo, but then you're not doing it yourself - you are instead trying to read diffs to understand what's new and figure out why it has been changed.

My experience has been that there is no complete guide, tutorial, or example that is kept current and provides every detail such that you can follow it and learn. I'm sure with enough concerted effort, one obviously can learn it... but there will be some trial and error and some guesswork. Normally that's fine, but it slows the process compared to other tech stacks and their guides.

The Clojure community is nice and helpful, but they're all busy doing real work (rather than teaching). Even the book I mentioned is not yet complete and has been in progress for over two years I think.

Re: Six years of professional Clojure development

#152

Post by Scarbutt »

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…

Haskell or Rust is too far the spectrum ;), TS or Kotlin are a nice sweet spot.

Re: Six years of professional Clojure development

#153

Post by mumblemumble »

draklor40 wrote: post #150
mumblemumble wrote: post #113

Earlier quoted context omitted.

To go at it from another angle: I'm working in a relatively large Java codebase that also likes to pass around generic ad-hoc data-structures such as maps. And I'm having exactly the same problem problems there. Static typing does nothing to help the situation. I realize that data-oriented programming is more likely to happen in dynamic languages. But correlation is not causation.

IMHO Static typing => structure, not necessarily Map (which is also a type). Shaping data is quite important and having an associative array doesn't necessarily means that the data is shaped.

Right. . . but, way up at the start of this, you specifically called out using associative arrays for all your data. And what I'm saying is that, while that's absolutely true, it's also technically an orthogonal question from whether you're working in a dynamic or static language.

Yes, sure, we can say that no true Scotsman would use a static language that way. But I think that's maybe missing the point. If you can dismiss this practice in static languages by just saying, "Well, maybe you shouldn't do that," why not also apply the same dismissal to dynamic languages?

That said, there's a specific subset of dynamic languages that make it more difficult to do your domain modeling any other way. Clojure and JavaScript belong in this group. I'm not sure of other examples. Basically, if the type system has been set up such that everything is either a map or a glorified map, you aren't left with a whole lot of other options. But not every dynamic language does that.

In Python, for example, I always use dataclasses for data. As long as I'm being good about this, I don't actually need to explicitly write unit tests to verify that types are being handled properly. MyPy's got my back. And, even if I'm not using it, unit tests for covering actual behavior will typically blow up with a type error in about the same amount of time that it takes a static language's compiler to detect one.

Re: Six years of professional Clojure development

#154

Post by fulafel »

_6pvr wrote: post #147
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…

> 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 spec or malli. I think most developers cannot be trusted to make these mistakes, I wouldn't call it "careless or lazy". Languages exist with tools baked into t…

> Do you really want a dynamic language, or do you just want the ability to be careless intermittently? [...] I just think, as a codebase in a dynamic language grows, codebases seem to build lots of tooling to make that dynamic language less dynamic.

I think this is getting closer to the interesting questions. It's often a good thing that when the product matures and moves more into maintenance mode, you can then incrementally add the kinds of rigidness that suits the needs of that. Clojure has excellent support for these in the schema style data validation tools of spec, malli, etc.

If you had a rigid system and slow turnaround from the start, you might not have gotten off the ground to get that far.

Re: Six years of professional Clojure development

#155

Post by nonbirithm »

dudul wrote: post #137
nonbirithm wrote: post #16

Earlier quoted context omitted.

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…

Can you define REPL-driven here? because just to name 2, Scala and Haskell have a very good REPL.

Maybe what I should have said was something along the lines of an "iterative language." Essentially I was thinking of a language where you can reload the functions/types in a single module and see the results instantly without restarting. The shortening of the feedback loop is the important part. And also important is being able to take some code and put it in a REPL to find out what it does or modify it until it's just right.

One language which is explicitly designed to have first-class hotloading support and static types is Mun. It's not production ready, but it was born out of frustration over the dynamically typed nature of Lua while appreciating the benefits it brought to extensibility and rapid prototyping.

https://mun-lang.org/

For me Lua has the iterative part, but no types. The iterative part makes LÖVE an attractive target for gamejam developers, who don't want to be constrained by compile-restart cycles when they don't yet understand what every aspect of the finished game will look like.

Re: Six years of professional Clojure development

#156

Post by blacktriangle »

synthc wrote: post #65
jeofken wrote: post #54

Earlier quoted context omitted.

> What is mutable by default in Clojure? Nothing. All data in Clojure inherits from java.lang.Object. I get what you’re saying, but in real life commercial projects, especially when you use libraries and Java classes, the code ends up with a lot of mutable things. You can never know if any function you call does mutate something without keeping all definitions in your head, and with 20+ people on the project, this is…

Inheritance from java.lang.Object does not make Clojure data mutable. Blocking for IO does not make Clojure imperative, it not a purely functional language, but its still a functional, not imperative, language. It's possible to build a service in a purely functional language using non blocking IO that also takes minutes to render. No language will save you from a bad design. I do agree that Clojure is not the most su…

The problem is not the built-in Clojure data structures. The problem is that a huge part of Clojure's heavily marketed value proposition is seamless-ish Java interop, which means working with Java objects and all their associated mutability. So while pure Clojure has very controlled mutability, pragmatic Clojure inherits all of Java's problems. And since they hype interop so much, nobody wants to rewrite functionality in Clojure when they could just leverage Java.

Re: Six years of professional Clojure development

#157

Post by oblio »

mumblemumble wrote: post #113
draklor40 wrote: post #106

Earlier quoted context omitted.

> 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. Yes, all dynamic languages have this problem. I have transitioned to statically typed languages and it has been very peaceful so far :)

To go at it from another angle: I'm working in a relatively large Java codebase that also likes to pass around generic ad-hoc data-structures such as maps. And I'm having exactly the same problem problems there. Static typing does nothing to help the situation. I realize that data-oriented programming is more likely to happen in dynamic languages. But correlation is not causation.

Humans are weak. The easier it is for them to do the wrong thing, they'll do it.

Re: Six years of professional Clojure development

#158

Post by blacktriangle »

iainctduncan wrote: post #110
clartaq wrote: post #95

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. Com…

Curious, because I'm also doing Scheme now, and Clojure was my gateway drug, which Scheme are you using and for what sort of problem? I'm using s7, but that's because my use case is very much oriented to s7's non-typical feature set (it's computer music), but Janet looks really nice too. (Many similarities to both Clojure and s7 actually).

Interesting, Clojure was my gateway drug to CL. I wonder how common it is for people who come to Clojure but get warned off by the JVM to migrate further down the lisp road?

Re: Six years of professional Clojure development

#159

Post by void_mint »

fulafel wrote: post #154
_6pvr wrote: post #147

Earlier quoted context omitted.

> 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 spec or malli. I think most developers cannot be trusted to make these mistakes, I wouldn't call it "careless or lazy". Languages exist with tools baked into t…

> Do you really want a dynamic language, or do you just want the ability to be careless intermittently? [...] I just think, as a codebase in a dynamic language grows, codebases seem to build lots of tooling to make that dynamic language less dynamic. I think this is getting closer to the interesting questions. It's often a good thing that when the product matures and moves more into maintenance mode, you can then inc…

Yeah, it seems like programming language decision is, at least in part, a proxy for "At what point do you want to be held accountable for your program's correctness at runtime?"

Haskell/Rust - Immediately

Java/C#/Go - Relatively quickly

Dynamic Languages - Whenever you decide it becomes important

Re: Six years of professional Clojure development

#160

Post by kaliszad »

Blikkentrekker wrote: post #42
jeofken wrote: post #29

Earlier quoted context omitted.

It’s just like C or JS but the first paren goes to the left of the function name.

With function calls, yes. What makes it different is that syntactic constructs are also expressed with the same syntax and there is no special syntax, so control flow constructs use a syntax similar to function calls. This is particularly exuberant in Arc where what in many languages would be: if ( ) { } else if ( ) { } else if ( ) { } else { } Would instead be: (if ) Note the complete lack of syntax beyond a keyword…

Clojure specifically doesn't have the bracket wrapper around condition-expression pairs but syntax highlighting/ formatting considers it and aligns stuff nicely. I don't think, it is a problem that it basically is a list or function call with arguments. I do think, adding `->` just like that would be a problem because it would be very inconsistent with the syntax of Clojure.
Post reply on HN