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

Six Years of Professional Clojure

engineering.nanit.com

Post reply on HN
Print view View original

201–210 of 254 posts

Re: Six Years of Professional Clojure

#201

Post by alaq »

ivanech wrote: post #141
alaq wrote: post #119

Earlier quoted context omitted.

How did you make the switch? Were you already working for the same company? Did you already know Clojure, from open source, or side projects?

I work at Ladder [0], and almost everything is done in Clojure/ClojureScript here. I had no previous experience in Clojure – Ladder ramps you if you haven't used it before. My interview was in Python. We're currently hiring senior engineers, no Clojure experience necessary [1]. [0] https://www.ladderlife.com/ [1] https://boards.greenhouse.io/ladder33/jobs/2436386

This is great to hear that Clojure experience is not a requirement! Thank you for sharing. I am based in NY and not willing to relocate, so I will look into NY/remote companies :)

Re: Six Years of Professional Clojure

#202

Post by alaq »

marciol wrote: post #199
ivanech wrote: post #141

Earlier quoted context omitted.

I work at Ladder [0], and almost everything is done in Clojure/ClojureScript here. I had no previous experience in Clojure – Ladder ramps you if you haven't used it before. My interview was in Python. We're currently hiring senior engineers, no Clojure experience necessary [1]. [0] https://www.ladderlife.com/ [1] https://boards.greenhouse.io/ladder33/jobs/2436386

Remote from everywhere or only in USA?

Looks like the remote situation is only temporary.

From their website [0]: "On returning to our office in Palo Alto, California At the moment, our employees are currently living and working all over the country. When it’s safe to gather again, we fully intend to return to the office."

[0] https://www.ladderlife.com/careers

Re: Six Years of Professional Clojure

#203

Post by [deleted] »

iLemming wrote: post #175
joelbluminator wrote: post #115

Earlier quoted context omitted.

I donno why you're being downvoted, it's a questionable decision and probably the company would have been better off with Python/PHP/Node. Hiring and onboarding are extremely important for a startup. You know what else? Finding answers to common questions on Google/Stackoverflow; I am now working with Ember and can tell you guys you take a 50% productivity hit by using a tool that's obscure on Google. Sure once you b…

> Hiring and onboarding are extremely important for a startup. If you're a small company, you usually cannot afford to hire "mediocre" talent. It is much more expensive to undo the crapola they'd implement. Trying to hire those who are at least interested in learning and using languages like Clojure, Rust, Haskell, Elixir, Elm, etc., is a very good quality filter. ROI from hiring a smaller number of Clojure devs, rat…

[deleted]

Re: Six Years of Professional Clojure

#204

Post by joelbluminator »

iLemming wrote: post #175
joelbluminator wrote: post #115

Earlier quoted context omitted.

I donno why you're being downvoted, it's a questionable decision and probably the company would have been better off with Python/PHP/Node. Hiring and onboarding are extremely important for a startup. You know what else? Finding answers to common questions on Google/Stackoverflow; I am now working with Ember and can tell you guys you take a 50% productivity hit by using a tool that's obscure on Google. Sure once you b…

> Hiring and onboarding are extremely important for a startup. If you're a small company, you usually cannot afford to hire "mediocre" talent. It is much more expensive to undo the crapola they'd implement. Trying to hire those who are at least interested in learning and using languages like Clojure, Rust, Haskell, Elixir, Elm, etc., is a very good quality filter. ROI from hiring a smaller number of Clojure devs, rat…

> Trying to hire those who are at least interested in learning and using languages like Clojure, Rust, Haskell, Elixir, Elm, etc., is a very good quality filter.

That's not my experience. It doesn't say a whole lot, it just says a person is bored a bit and is confident in his ability to learn new things, you can filter for learning abilities by looking at what the person achieved; doing new stacks is just one metric. Also it's sometimes the type of people who care more about learning/trying new tech on the job than actually helping the business (for exmaple by introducing GraphQL because they read about it in a blog and it looks cool, not because they really think the business needs it).

Re: Six Years of Professional Clojure

#205

Post by playing_colours »

uDontKnowMe wrote: post #148
codingkoi wrote: post #137

Earlier quoted context omitted.

Your third point about having to encode everything isn’t quite true. Your example is just brittle in that it doesn’t allow additional values to show up causing it to break when they do. That’s not a feature of static type systems but how you wrote the code. This blog post[1] has a good explanation about it, if you can forgive the occasional snarkyness that the author employs. In a dynamic system you’re still encoding…

I've seen this article and I applaud it for addressing the issue thoroughly but I still am not convinced that static typing as we know it is as flexible and generic as dynamic typing. Let's go at this from an other angle, with a thought experiment. I hope you won't find it sarcastic or patronizing, just trying to draw an analogy here. So, in statically typed languages, it is not idiomatic to pass around heterogeneous…

I believe your comments provided a good insight into your approach to programming. I may be wrong in my understanding, but let me elaborate.

You expect your programming language to be a continuation of your thoughts, it should be flexible and ductile to your improvisations. You see static typing as a cumbersome restricting bureaucracy you have to obey to.

Whereas I see type system like a tool that helps to structure my thoughts, define the rules and interfaces between construction blocks of my program. It is a scaffolding for a growing body of code. I found that in many cases, well defined data structures and declarations of functions are enough to clearly describe how some piece of code is meant to work.

It seems we developed different preferred ways of writing code, maybe, influenced by our primary languages, features of character, type of software we create. I used Scala for several years, but recently I regularly use Python. Shaping my code with dataclasses and empty functions is my preferred way to begin.

Re: Six Years of Professional Clojure

#206

Post by roenxi »

hota_mazi wrote: post #92
dgb23 wrote: 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…

In 2021, I find it hard to justify using a dynamically typed language for any project that exceeds a few hundreds of lines. It's not a trade off, it's a net loss. The current crop of statically typed languages (from the oldest ones, e.g. C#, to the more recent ones, e.g. Kotlin and Rust) is basically doing everything that dynamically typed languages used to have a monopoly on, but on top of that, they offer performan…

Although you are right, the Clojure community probably by and large agrees with you. That is why everyone is excited about spec - it looks a lot like a type system for Clojure.

Re: Six Years of Professional Clojure

#207

Post by [deleted] »

hota_mazi wrote: post #200
didibus wrote: post #196

Earlier quoted context omitted.

In Clojure you know the number of arguments to a function and the name of functions and variables, and the code is all very well structured as an AST (being a Lisp). So you can do a lot of refactorings with that such as: Rename function, rename variable, rename namespace, extract constant, extract function, extract local variable, extract global variable, convert to thread-first, convert to thread-last, auto-import,…

All these refactorings can only be done automatically and safely if you have type annotations (i.e. core). Without them, all these refactorings can break your code (as in, not even compiling, let alone run).

[deleted]

Re: Six Years of Professional Clojure

#208

Post by pjmlp »

jhgb wrote: post #181
hota_mazi wrote: post #92

Earlier quoted context omitted.

In 2021, I find it hard to justify using a dynamically typed language for any project that exceeds a few hundreds of lines. It's not a trade off, it's a net loss. The current crop of statically typed languages (from the oldest ones, e.g. C#, to the more recent ones, e.g. Kotlin and Rust) is basically doing everything that dynamically typed languages used to have a monopoly on, but on top of that, they offer performan…

> automatic refactorings (pretty much impossible to achieve on dynamically typed languages without human supervision) ...are we talking about the thing pioneered by Smalltalk's Refactoring Browser?

You are forgetting that Smalltalk with its image has the visibility of the whole world AST, so its dynamism has some helping metadata to go along the OS features.

Also it wasn't perfect, hence why Strongtalk was born, the remains of which now live on Hotspot.

Re: Six Years of Professional Clojure

#209

Post by pjmlp »

blacktriangle wrote: post #114
dgb23 wrote: 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…

I feel like there's a missing axis in the static/dynamic debate: the language's information model. In an OOP language, types are hugely important, because the types let you know the object's ad-hoc API. OOP types are incredibly complicated. In lisps, and Clojure in particular, your information model is scalars, lists, and maps. These are fully generic structures whose API is the standard Clojure lib. This means that…

Smalltalk is "OOP x dynamic".

CLOS is "OOP x dynamic".

Common Lisp has arrays, structures and stack allocation.

IDE were invented from Smalltalk and Lisp development experience.

Re: Six Years of Professional Clojure

#210

Post by didibus »

hota_mazi wrote: post #200
didibus wrote: post #196

Earlier quoted context omitted.

In Clojure you know the number of arguments to a function and the name of functions and variables, and the code is all very well structured as an AST (being a Lisp). So you can do a lot of refactorings with that such as: Rename function, rename variable, rename namespace, extract constant, extract function, extract local variable, extract global variable, convert to thread-first, convert to thread-last, auto-import,…

All these refactorings can only be done automatically and safely if you have type annotations (i.e. core). Without them, all these refactorings can break your code (as in, not even compiling, let alone run).

I believe you're mistaken, but please explain otherwise?

None of those seem to require type information from my reasoning (and are also all available in Emacs for Clojure)

For example, moving a function from one namespace to another, you know where this function is being used from the require declarations, and you know where you've been told to move it too and where it currently resides. So you can simply change the old require pointing to its old namespace to point to the new namespace and cut/paste the function from the old to the new. Nothing requires knowing the type or the arguments or the return value of the function.

See a gif of it in action: https://raw.githubusercontent.com/clojure-emacs/clj-refactor...

Post reply on HN