Live data from Hacker News

Why we built Vade Studio in Clojure

bytes.vadelabs.com

41–50 of 151 posts

Re: Why we built Vade Studio in Clojure

#41
post #5

Ultimately, it all comes down to build what you're comfortable with. Additionally, when you're managing large organizations and teams. Build with what you can hire quickly for and easily scale with.

Quick (and cheap?) hires are not necessarily good hires. In my experience (and my theory) developer productivity can range from 0.5x to 5x and more, and those developers in the upper range tend to look for certain programming language which they enjoy, like Rust, Go, Elixir, Scala and Clojure. They are hard to get if you are on a "boring" stack like Java, NodeJS, PHP. So if you might need to invest some time and mone…

100% agree. You have hit the nail on the head. I went from Common Lisp to Go to now Rust and find that Rust devs are the best so far on average.

There are fewer of them, they ask for more money, but they really are exceptional. Especially Rust devs right now because there are not a lot of jobs you only find the most passionate and the most brilliant in that space. A short window though which will close as Rust gets more popular to startups, take advantage of it now.

Re: Why we built Vade Studio in Clojure

#42

Look these folks can do whatever the heck they want, use whatever language they want. However my criteria for selecting a language for use in a professional context : 0: fit to task - obviously the language has to be able to do the job - to take this seriously you must define the job and what its requirements are and map those against the candidate languages 1: hiring and recruiting - there must be a mainstream sized…

> talent shortages are not acceptable - and I don't buy the argument that "smart people are attracted to non mainstream languages which is how we find smart people", it is simply not true that "most smart people program with Scala/Haskell/Elixir/whatever" - there's smart and smarter working on the mainstream languages.

Smart people can be trained in any language and become effective in a reasonably short period of time. I remember one company I worked at, we hired a couple of fresh grads who'd only worked with Java at school based on how promising they seemed; they were contributing meaningfully to our C++ code base within months. If you work in Lisp or Haskell or Smalltalk or maybe even Ruby, chances are pretty good you've an interesting enough code base to attract and retain this kind of programmer. Smart people paired with the right language can be effective in far smaller numbers as well.

The major drawback, however, is that programmers who are this intelligent and this interested in the work itself (rather than the money or career advancement opportunities) are likely to be prickly individualists who have cultivated within themselves Larry Wall's three programmer virtues: Laziness, Impatience, and Hubris. So either you know how to support the needs of such a programmer, or you want to hire from a slightly less intelligent and insightful, though still capable, segment of the talent pool which means no, you're not going to be targeting those powerful languages off the beaten track. (But you are going to have to do a bit more chucklehead filtering.)

> if you are using a language that the AI knows little about then there's little productivity related benefits coming to your development team.

This is vacuously true because the consequent is always true. The wheels are kind of falling off "Dissociated Press on steroids" as a massive productivity booster over the long haul. I think that by the time you have an AI capable of making decisions and crystallizing intent the way a human programmer can, then you really have to consider whether to give that AI the kind of rights we currently only afford humans.

Re: Why we built Vade Studio in Clojure

#43

Look these folks can do whatever the heck they want, use whatever language they want. However my criteria for selecting a language for use in a professional context : 0: fit to task - obviously the language has to be able to do the job - to take this seriously you must define the job and what its requirements are and map those against the candidate languages 1: hiring and recruiting - there must be a mainstream sized…

The signal to noise ratio is way better if you take some eccentric language. The amount of knuckleheads that Ive had to interview just to get a single coherent developer is mind boggling (remote first).

I think in order of average dev quality (highest to lowest) I recently found:

Rust Common Lisp Go Ruby/Elixir C++ Python C# Typescript Java Javascript

Re: Why we built Vade Studio in Clojure

#44
> Today, we're building Vade Studio with just three developers – myself and two developers who joined as interns when in college. (...) Here's what we've accomplished: (...)

In how many man-hours/days? It's hard to know if the list is long or short only knowing that calendar time should be multiplied by three for calculating people time spent...

Re: Why we built Vade Studio in Clojure

#45
post #35
post #34

Earlier quoted context omitted.

The bank switched memory architectures were basically unused in mid 80s micros (C128, CoCo3, etc.). Lots of utility software like spell checkers and the like still existed. These would be trivial to implement in Lisp but are really annoying in assembler. Lisp would have been really good relative to BASIC interpreters at the time--especially since you could have tokenized the atoms. It also would have freed people fro…

> Lisp would have been really good relative to BASIC interpreters at the time I see no evidence for that. Lisp was a pain on tiny machines with bad user interface. > 64K is solid for a Lisp if you own the whole machine. I had a Lisp on an Apple II. It was a useless toy. I was using UCSD Pascal and Modula 2 on it. Much better. I had Cambridge Lisp on an Atari with 68k CPU. It was next to unusable due to frequent crash…

> There were articles for example in the Byte magazine.

And they were stupid. Even "good" Lisp references didn't cover the important things like hashes and arrays. Everybody covered the recursive crap over and over and over ad nauseam while people who actually used Lisp almost always sidestepped those parts of the language.

> I had a Lisp on an Apple II. It was a useless toy. I was using UCSD Pascal and Modula 2 on it. Much better.

And yet UCSD Pascal was using a P-machine. So, the problem was the implementation and not the concept. Which was exactly my point.

> At least there were people willing to pay for it.

Temporarily. But then it died when the big money went away and left Lisp all but dead. All the while all the people using languages on those "toys" kept right on going.

Re: Why we built Vade Studio in Clojure

#46

Clojure is a lot of fun to tinker with, but man… I love my static types. I think I’d hate to work on a large codebase in Clojure and constantly be wondering what exactly “m” is.

One of the myriad reasons why Common Lisp is far superior to Clojure is the ability to

  (declare (type Integer m))

Re: Why we built Vade Studio in Clojure

#47
> Each new layer of complexity fed my developer ego.

I'm unable to understand this mindset. All the time I read things like "Developers love complexity because it feeds their egos" but I've never encountered a situation in which added complexity made me more proud of the work. Just the opposite: being able to do more made me more proud of the work I put in, and complexity was the price I paid for that ability. The greatest hacks, the ones that etch people's names into history, are the ones -- like Unix and the Doom engine -- that achieve phenomenal feats with very little code and/or extreme parsimony of design. This is no more true than in that famous ego-stroking/dick-measuring contest of programming, the demoscene. My favorite example being the 4k demo Omniscent: https://www.youtube.com/watch?v=G1Q9LtnnE4w

Being able to stand up a 100-node K8s cluster to provide a basic web service, connected to a React SPA front end to provide all the functionality of a Delphi program from the 90s doesn't stroke the ego of any programmer I know of; but it might stroke their manager's ego because it gives them an opportunity to empire-build and requisition a larger budget next year.

Re: Why we built Vade Studio in Clojure

#48

I'm curious if Elixir could provide a similar development environment? Seems like many similar capabilities, like a focus on immutable data structures, pure functions, being able to patch and update running systems without a restart, etc.

For the most part, yes. CIDER and nREPL is better tech than IEX though. I live in both and Clojure is much more enjoyable.

I came to the opposite conclusion for the following reasons:

1. IEx provides a robust and interactive debugging environment that allows me to dig into whatever I want, even when running in production. I've never lost state in IEx, but that happens fairly often in CIDER and nREPL.

2. IEx uses Elixir's compilation model, which is a lot faster than CIDER and nREPL, leading to faster debugging cycles.

3. IEx is tightly integrated with Elixir whereas Clojure's tools are more fragmented.

4. IEx doesn't carry the overhead of additional middleware that CIDER and nREPL do.

I'm also not a fan of JVM deployments, so I've migrated all my code away from Clojure to Elixir during the past 10 years.

Re: Why we built Vade Studio in Clojure

#49

Clojure is a lot of fun to tinker with, but man… I love my static types. I think I’d hate to work on a large codebase in Clojure and constantly be wondering what exactly “m” is.

You wouldn't because of the repl. You would jack in and no exactly what m is.

With static types, I don't have the use the repl at all, I can simply hover over it in my editor.

Re: Why we built Vade Studio in Clojure

#50

Earlier quoted context omitted.

You wouldn't because of the repl. You would jack in and no exactly what m is.

With static types, I don't have the use the repl at all, I can simply hover over it in my editor.

With a REPL-connected editor (and most have a way to do this), you can simply hover over it in your editor as well. Even though most languages can have a REPL today, few integrate it in the development experience the way lisps do.
Post reply on HN