

Ask HN: Too risky to bet company on a fringe language? (Clojure, Haskell, Etc) - anonymous610

Say you're building a company around an industry that doesn't really need a lot of innovation: dry-cleaning store management, barber-shop appointments, auto-parts store, etc.<p>Is it risky to write all of your software in a niche language like Clojure or Haskell (assuming you know them)?<p>I have doubts about hiring developers in these languages if the work itself isn't challenging.
======
nunb
I'm going to assume a couple of things while answering. Feel free to point out
which of them is unwarranted.

1\. You won't write the code (ref. hiring developers)

2\. Webapp software, not desktop

3\. You have time or developer constraints (basic economic choices to make)

If the industry does not need "innovation" that does not mean that the
software itself will not be fairly complex. For example, a simple undo feature
can be a complex thing to implement, regardless of how fossilized the industry
the software is being written for is. Building software that scales, and
especially software that contains lots of social linkages is a complex
problem.

Risks are ever-present and must be balanced. You should consider:

A) Time to write the software

B) Hiring new developers

C) Buyout risk

D) Platform risk

E) Social risk.

IMHO, and speaking as a Clojure developer in a startup that uses it almost
exclusively:

A) Platform risk is negligible. As someone who has done plenty of Common Lisp
programming, I can confidently assert that the Clojure platform is way more
accessible, and moving faster. It's the JVM after all.

B) Hiring: plenty of new blood. Apparently at ITA, it was quite easy to
onboard newbies to Common Lisp. IMHO Clojure is easier. It even has fewer
parens than idiomatic, equivalent Java.

C) Time: I believe time is highly correlated with LOC. Clojure clocks in with
the lowest LOC, most elegant solutions I have yet seen. Haskell is no doubt
similar, though it's sweet spot / domain is likely different.

D) Buyout risk: I believe perceptions will change. Several large companies are
now Scala shops. They're like the early adopters who bought into 8088 PCs. The
Mac-like era of Clojure is yet to come. We've already seen one or two buyouts
of Clojure shops.

E) Social risk: lots and lots of new libraries, access to all the old java
libraries. Almost no risk here, imho.

Now, a lot of your risks may actually fall into the class of "good problems to
have". While I cannot speak to Haskell or other languages as much, my feeling
is that Clojure is a better bet in comparison.

Of course, if the use of niche languages is not your choice, you should ask
your developers why they want to use it. They should be able to explain their
reasoning.

Also, at least in the webapp domain, a lot of complexity arises from the
interplay between webservers, javascript, backend code, hosting providers etc.
Clojure has a lot of nice features here which help, but it's rather more the
interplay which contains the complexity. IOW, this aspect of complexity is
outside the domain of the backend language. Clojure has a secret weapon here
too, clojurescript, but its implications are not yet well understood. It has a
lot of potential though.

hth, and btw, if this is my boss trolling me, well, /me _starts scheme-ing_

------
fmw
I'm betting my startup on Clojure, but it doesn't feel like much of a "bet".
It is probably one of the least risky choices I've had to make and as a bonus
to the technical benefits it is also a nice way to differentiate yourself. It
is integrated with the familiar, mature JVM-platform and not that hard to
learn as an experienced developer. Integrating with existing Java or future
JVM code (e.g. Scala, JRuby, Groovy) is a huge plus, because you can start
thinking about the right tool for the job instead of troublesome integration
with legacy code.

As to hiring: I think you will have a harder time finding good programmers to
work on boring problems in a boring language (e.g. Java). Picking a niche
language would make your project more interesting, but you can also do other
things to make the working attractive to good people, e.g. actively developing
and maintaining open source libraries related to your project or allow them to
rethink the way problems are solved in your industry. Seemingly boring
problems can have very interesting solutions. It also helps when you offer
good working conditions (e.g. possibility to work remotely and all the "Aeron
chair" kind of perks you keep reading about on HN). Not everyone is right for
the typical startup or Googler lifestyle. Some very good hackers actually
prefer e.g. working from home so they can take care of baby to pulling all-
nighters at Facebook.

This is all assuming you're a technical founder. If you are: go with something
that you're not only passionate about, but that is also _the right tool for
the job_. In my case Clojure fits best, because I need the integration with
Java libraries like Apache Lucene, but in your case it might be Haskell or
something else entirely. If you aren't a programmer yourself you should find a
technical co-founder or early employee to make this kind of decision.

------
freddealmeida
I don't agree that Haskell is fringe. Haskell is more than 20 years old. It is
commonly used in finance, science and in complex projects (like pugs). The
ability to program in a strict typed functional language is often a good
indicator of programming skill.

Clojure in comparison is much younger. It does however leverage the JVM so I
suppose it stands on the shoulders of giants. Again, the ability to develop
with Lisp is a good indicator of programming skill as well.

That the industry has not innovated does not mean that your code base will
lack innovations. a data-centric approach will more than likely find hidden
data points that will allow your systems to leverage some aspects of the
market (innovation for free?).

In hiring, you may want to hire for a broader skill-set, but look for Haskell
or Clojure skills. That developers get bored should lead you to consider more
autonomous management structures.

Incidentally, I think the market you picked is excellent. Innovating in that
space will be easier. Marketing to them, much harder. I'd hire developers that
understand platform development or systematic design.

------
drallison
What do you expect to gain by using language XXX that you would not get from
languages YYY, ZZZ, and so forth. To a very large extent, programming language
is not important. Sometimes the choice of language can make a difference in
the complexity of the programming task; but knowing that a priori usually
means that you have a deep understanding of the task to be performed and that
it requires something special.

There are secondary considerations which are related to language such as the
availability of trained programmers, the availability of good documentation,
whether the language is stable or under rapid development, whether the
language you choose is proprietary or open source, and so forth, but they are
secondary considerations.

------
fefzero
What do you mean when you say "is it risky"?

* You risk that you won't be able to find developers at a salary that will help your company earn money * There is a risk that you may have to do lots of the work yourself and may not be able to pass it on if you write programs for these industries

In my opinion, you need to decide _why_ you want to use a "fringe" languages
over something with more available talent. Are you using it because it's what
you know? Because it will be fun? Or is there a benefit of that language that
you wouldn't have otherwise?

It won't be impossible, but it's hard to replace commodity software with
something that would end up being more expensive without adding any innovation
or new benefits.

