Live data from Hacker News

Six Years of Professional Clojure

engineering.nanit.com

61–70 of 254 posts

Re: Six Years of Professional Clojure

#61
Walmart Labs was a step in this direction.. but we need some big companies to standardize around Clojure to jumpstart the ecosystem of knowledge, libraries, talent, etc. I’ve spoken to engineering hiring managers at fairly big companies and they’re not willing to shift to a niche language based only on technical merits but without a strong ecosystem.

If we don’t get some big companies to take on this roll the language is going nowhere.

I’m saying this because I’m a huge fan of Clojure (as a syntax and language, not crazy about the runtime characteristics) and I hope I get the opportunity to use it.

Re: Six Years of Professional Clojure

#62
post #19

> ... and the question regarding choosing Clojure as our main programming language rose over and over again If I find myself having to repeat myself justifying a certain decision time and time again, it's an indicator that the decision needs to be revised to be something which is a more intuitive fit for the organization.

Alternatively, you could document the thought process that lead up to the decision and you can point the unenlightened to the documentation instead of having to repeat yourself.

Re: Six Years of Professional Clojure

#63
post #47
post #33

Earlier quoted context omitted.

I think, the big issue with dynamic typing in popular languages like PHP and JavaScript are the automatic conversions.

You mean implicit type conversions? That's a thing you can get somewhat used to. But it throws off beginners and can introduce super weird bugs, because they hide bugs in weird ways, even if you are more experienced. Yes, I find strong typing strictly better than weak typing. An even better example of this would be Excel, the horror stories are almost incredible. So even if your environment is dynamic, you want clari…

It's always worth reminding folks that weak typing and implicit conversions can plague statically typed languages. C's implicit pointer array-to-pointer and pointer-type conversions are a major source of bugs for beginner and experienced programmers alike.

Re: Six Years of Professional Clojure

#64
post #29

Earlier quoted context omitted.

Spec will give you stronger feedback than a docstring or function signature. It can tell you (in code terms, with a testable predicate) if a call to an interface wouldn't make sense. Eg, spec can warn you when an argument doesn't make sense relative to the value of a second argument. Eg, with something like (modify-inventory {:shoes 2} :shoes -3) spec could pick up that you are about to subtract 3 from 2 and have neg…

Does the spec logic typically live inside the modify-inventory function, or elsewhere? If elsewhere, what triggers it before the function is called?

There is very little spec logic. It looks a lot like type declarations in typed languages.

It's usually outside the scope of functions, since you are likely going to want to reuse those declarations. For example, you can use spec to generate test cases for something like quick-check.

You can add pre and post conditions to clojure function's metadata that test wether the spec complies with the function's input/output.

Re: Six Years of Professional Clojure

#65

I tried to use Clojure but what put me of was that simple mistakes like missing argument or wrongly closed bracket didn't alert me until I tried running the program and then gave me just some java stack spat out by jvm running Clojure compiler on my program. It didn't feel like a first class experience.

> didn't alert me until I tried running the program

That's because that's not how Clojure developers normally work. You don't do changes and then "run the program". You start your REPL and send expressions from your editor to the REPL after you've made a change you're not sure about. So you'd discover the missing argument when you call the function, directly after writing it.

Re: Six Years of Professional Clojure

#66
post #10
post #6

One thing I don't like about all articles on clojure is that basically all of them say: ah, it's just like lisp with lists `(an (example of) (a list))` with vectors `[1 2 3]` thrown in. So easy! But then you get to Clojure proper, and you run into additional syntax that either convention or functions/macros that look like additional syntax. Ok, granted, -> and ->> are easy to reason about (though they look like addit…

Single engineers will pick clojure at companies , build a project in it, later that engineer will move on, now nobody can maintain this code so it’s rewritten in some normal language. I’ve seen that happen a few times. That code is hard to read and understand. This is why clojure will remain niche.

is it really hard to read (could be) or is it just that the average coder never saw lisp or sml and doesn't want to bother bearing the responsibility to learn something alien on duty ?

Re: Six Years of Professional Clojure

#67
post #3

I found one of the perceived weaknesses of Clojure (in this article), it being dynamically typed, is a tradeoff rather than a pure negative. But it applies that tradeoff differently than dynamic languages I know otherwise and that difference is qualitative: It enables a truly interactive way of development that keeps your mind in the code, while it is running. This is why people get addicted to Lisp, Smalltalk and si…

> What you get here goes way beyond what a strict, static type systems gets you, such as arbitrary predicate validation,

Is this refinement types, which most static languages provide? https://en.wikipedia.org/wiki/Refinement_type

> freely composable schemas,

My understanding is that you can compose types (and objects) https://en.wikipedia.org/wiki/Object_composition

I'm assuming that types are isomorphic with schemas for the purposes of this discussion.

> automated instrumentation

I know that C# and F# support automated instrumentation/middleware.

> and property testing. You simply do not have that in a static world.

QuickCheck has entered the chat: https://en.wikipedia.org/wiki/QuickCheck

Re: Six Years of Professional Clojure

#68
post #53
post #46

Earlier quoted context omitted.

How about values restricted to identifiers currently in the database table? There's always something the type system can't do.

F# has a feature called type providers that make this sort of bookkeeping between the database and the code less tedious, but even if you mess it up, static typing still gives you more safety than dynamic. If your code blew up because it should have accepted an identifier it didn’t, you know that the code has not been written to handle that case and can fix it. Alternatively, you can just choose to ignore this, and d…

A demo of a SQL type provider in action: https://youtu.be/RK3IGYNZDPA?t=2539

It requires a bit of elbow grease to make it work with a CICD system... but it works :D

Re: Six Years of Professional Clojure

#69

I tried to use Clojure but what put me of was that simple mistakes like missing argument or wrongly closed bracket didn't alert me until I tried running the program and then gave me just some java stack spat out by jvm running Clojure compiler on my program. It didn't feel like a first class experience.

> didn't alert me until I tried running the program That's because that's not how Clojure developers normally work. You don't do changes and then "run the program". You start your REPL and send expressions from your editor to the REPL after you've made a change you're not sure about. So you'd discover the missing argument when you call the function, directly after writing it.

Interesting. How exactly that looks? Do you have files opened in your editor, change them then go into previously opened repl, and just call the functions and the new version of those function runs?

Re: Six Years of Professional Clojure

#70
post #3

I found one of the perceived weaknesses of Clojure (in this article), it being dynamically typed, is a tradeoff rather than a pure negative. But it applies that tradeoff differently than dynamic languages I know otherwise and that difference is qualitative: It enables a truly interactive way of development that keeps your mind in the code, while it is running. This is why people get addicted to Lisp, Smalltalk and si…

> What you get here goes way beyond what a strict, static type systems gets you, such as arbitrary predicate validation, Is this refinement types, which most static languages provide? https://en.wikipedia.org/wiki/Refinement_type > freely composable schemas, My understanding is that you can compose types (and objects) https://en.wikipedia.org/wiki/Object_composition I'm assuming that types are isomorphic with schemas…

Right! I made the dumb, typical error to write: "You simply do not have that in a static world." When I should have written: "This type of expressiveness is not available in mainstream statically typed languages".

With "freely composable" I mean that you can program with these schemas as they are just data structures and you only specify the things you want to specify. Both advantage and the disadvantage is that this is dynamic.

Post reply on HN