
A Secret Weapon for Startups – Functional Programming? - allenleein
https://www.ramanan.com/personal-blog/2019/2/25/functional-programming-and-venture-capital
======
opportune
I would say the main competitive advantage of using functional programming, or
Haskell in this case, is that it's a relatively inexpensive benefit you can
offer to employees (the cost is in rolling your own version of sorely needed
tooling/ecosystem stuff once you reach sufficient size) and lets you tap into
a pond where even a small fish can feel big.

For scalability, I disagree with the author. Being functional does not
necessarily make you scale better. The one hot backend paradigm that is
easiest to scale is to write stateless, containerized microservices.
Functional programming will nudge you in the right direction of writing
stateless code but isn't strictly necessary.

It's kind of disappointing to hear functional programming cargo-culting from
someone who admittedly doesn't really program much anymore. The software
engineering industry already has enough resume driven development perpetuated
by software engineers hyping things up to other software engineers

~~~
lmm
> The one hot backend paradigm that is easiest to scale is to write stateless,
> containerized microservices. Functional programming will nudge you in the
> right direction of writing stateless code but isn't strictly necessary.

Microservices force you to reduce your service interfaces to lowest common
denominator. You simply can't build a really powerful system out of
microservices with a reasonable amount of code, because there's no way to send
complex structures across service boundaries; you end up spending more effort
serializing and deserializing than actually doing business logic.

Functional programming lets you achieve the same isolation benefits as
microservices without the overhead.

~~~
weberc2
Why should serialization and deserialization be “effort”? Your data objects
shouldn’t be more complex than is trivially represented with JSON or else you
have a different problem. Besides, while I’m not a microservices enthusiast,
isolation isn’t the main goal of microservices, it’s being able to deploy,
scale, and operate services independently from other teams.

~~~
lmm
> Your data objects shouldn’t be more complex than is trivially represented
> with JSON or else you have a different problem.

That's the whole problem I'm talking about. Like I said, it forces you to
reduce all these interfaces to lowest common denominator.

> Besides, while I’m not a microservices enthusiast, isolation isn’t the main
> goal of microservices, it’s being able to deploy, scale, and operate
> services independently from other teams.

If you're just talking about each team having its own service, that's not
what's usually meant by "microservices".

~~~
weberc2
> That's the whole problem I'm talking about. Like I said, it forces you to
> reduce all these interfaces to lowest common denominator.

I don’t know what you mean by “lowest common denominator” or how “being forced
to write good code” is inherently bad. There are lots of efficiencies to
writing good code (easy to test, reuse, refactor, etc), not just writing
microservices.

> If you're just talking about each team having its own service, that's not
> what's usually meant by "microservices".

That may not be the definition but it’s the principally cited advantage.

------
wrnr
I've recently interviewed at a startup that was into functional programming.
The coding challenge was: transform a pair of an optional string and optional
integer, into a optional pair of string and integer. My solution was to just
check if the left and right optional where present before creating the pair
out of them. The solution they suggested was this double nested flatMap lambda
contraption. Functional programming is a fun intellectual pursuit, but
sometimes I wonder if its better to get your "I am smart" fix by reading maths
or physics in the evening, and just do the boring imperative stuff at work.

~~~
pmontra
In Elixir I would enumerate the cases with four definitions of the same
function. Four lines of code, done. It looks similar to what you did.

But I would tell them this is the simple and boring code I would run in
production but probably not the smart code they want to see in the interview.
Unfortunately smart code is often full of bugs and it costs more to deploy and
maintain.

~~~
yakshaving_jgt
Why would you write four cases? You only care about _two_ of the cases.

------
neilv
The article didn't quite say it, but there seems to be an additional bonus to
using a less-popular language that attracts enthusiast programmers: you have
special access to a pool of skilled programmers, because you're offering to
pay them to use one of their favorite tools.

I'm imagining maybe ITA Software said something like, "We're going develop a
new node in the legacy IBM mainframe airline reservation system network, from
scratch." And the responses were something like, "One, that sounds impossible;
two, why would I want to get into legacy mainframe systems." Then ITA said,
"We think it can be done with Lisp." "Where do I sign?"

------
VMG
There is nothing "secret" about these languages.

Everybody knows they exist, everybody knows they are better in certain
respects, most companies prefer standard languages where it is easy to recruit
standard-level talent for standard wages.

~~~
blub
There's no proof really that above standard talent prefers or uses functional
programming languages.

Indeed, this is a reductionist view, like saying the best engineers are those
that use a specific tool, not those that have access to a broad body of
engineering knowledge and real-world experience.

~~~
UK-AL
I think it's because functional programming does take a bit more learning to
get going with it.

That's because there are higher level abstractions like monads, bind, type
classes etc

These take more time to learn but once you know they make modelling some
problems much easier.

I do think a lot problems in programming come from businesses wanting
everything to be easy to understand and to require little training and
education.

As opposed to highly trained people who know their craft.

This as a business decision is fair enough. But you can't then complain your
software is buggy or it takes to long to build something because you haven't
built higher level abstractions. You made that decision.

------
motohagiography
I sympathize with the romantic view of FP, and I'd say that the choice of
language defines culture in companies I've worked in. I've hacked around with
Haskell/snap and worked (as non developer) in a clojure shop and my impression
is that functional languages are an expression of a culture that values a
certain quality of thinking that is just not commodity today.

I suspect you can hold off imitators in an early stage company for a few extra
months by giving the impression that there is a high cost/high risk aspect to
your product, and it creates a foundation of quality reasoning about features.

However, I have also witnessed a culture clash a few times, where to build a
business with investors, you need to scale up with commodity developer talent,
and you lose the core team when you try to integrate them. Anecdotally,
functional languages also tend to attract personalities who can be difficult
to focus on products, which are to them just side effects of discovery. A
company that depends on "geniuses," to run it is probably not a very sound
business.

If I wanted to build a company positioned for linear growth over a 20 year
horizon that was services heavy, in a specific niche like utilities or
security, I would choose a functional language for the platform. If I wanted
to position a company for exponential growth or integration/acquisition into
another product family, I'd pick something with less friction around its
cultural edges.

~~~
blub
At the end of the day, what exceptional products have developers with this
certain quality of thinking released?

It's more likely that this aura of cultured mystery is a self-defense against
the hard truth that's been recognized by businesses for decades: programming
language choice doesn't matter that much towards success OR implementation
quality, with some exceptions.

When someone wraps so much of their self-worth in a programming concept, it
would be painful indeed if it turned out that said concept is remarkable only
in their bubble.

~~~
UK-AL
I've definitely been companies where a bad code base basically destroyed the
product because we couldn't move fast enough compared to the competition.

It usually happens on established products that have been around for a few
years.

~~~
blub
And did this happen because you chose a specific language?

There are really few languages that can sink a project and that too only
happens they're used in a domain that's uncharacteristic for them. E.g:
writing a web app in classic VB. Windows GUI app in VB would be fine.

~~~
UK-AL
I think languages can definitely make things worse. Dynamic languages are
harder to refactor using automated refactor tools.

In a code base with no tests, I'd rather start with something had a powerful
type system.

But you are right that you make a mess in any language.

------
apples_oranges
Paul Graham convincingly made the case that not all programming languages are
equal in terms of power. A more powerful language should be a competitive
advantage all else being equal. Hence it makes sense to use one.

(Aside from functional programming, Ruby on Rails comes to mind even though it
is a language and a framework.)

~~~
twic
> convincingly

He wrote that article in 2001, eighteen years ago, and people haven't stopped
bringing it up on HN since. So where are these startups crushing their
opposition because they're using a more powerful language?

~~~
vincent-toups
I can give at least one data point for a startup based on Common Lisp that
crashed and burned at least in part _because_ of Common Lisp.

~~~
twic
I bet that was really good fun, though!

~~~
vincent-toups
It was a major strain on my marriage, among other shitty things.

------
typon
I would say a real secret weapon for startups would be C++. If your
service/product is 10 to 20x faster than your competitors using mainly
interpreted or GC languages... That extra bit of performance is something you
can actually market and sell. Also extra performance allows you to do more
stuff for the same time frame, so you can trade it off with more features.
Write C++ in a modern, functional way and its a very productive language.

~~~
mepian
The performance gap between C++ and GC languages like Ocaml and Common Lisp is
much smaller than 10x. Here's one example where Common Lisp yielded literally
the same performance as C++: [https://m00natic.github.io/lisp/manual-
jit.html#orgd043a43](https://m00natic.github.io/lisp/manual-
jit.html#orgd043a43)

~~~
JoeAltmaier
There's more than raw execution speed. There's footprint, which affects how
soon you have to scale (hint: 100X sooner with GC/interpreted systems).
There's latency which can be highly irregular in GC systems and can result in
very confusing behavior/bugs.

Modern systems can remove lots of complexity and enable fast prototyping,
which we are all aware of. But it comes with a cost, and that cost (e.g.
having to deal with scaling much, much sooner) hits at a sensitive time in
startup growth.

------
mediascreen
I think lots of startups are prone to something similar to the "second
version" problem.

They bring in a really good senior developer as a CTO. This person finally has
the chance to set their mark and for once build the perfect setup, no legacy
systems to take into consideration, no outdated corporate directives limiting
languages or architecture. This time it's going to be perfect.

Other aspects tend to be forgotten:

\- The startup might not require a very sophisticated tech stack. Most of what
needs to be built might be lots of html forms, user handling and a few other
thing that can be done in any language.

\- They and up with a pretty advanced stack of best-for-the-job tools and
languages that forces the company to compete with lots of other trendy startup
for a very small pool of highly paid highly qualified developers.

\- Some tooling and functionality might have to be built from scratch compared
to more widespread languages.

A healthy question to ask before picking a more specialized stack is "What do
we really gain compared to building this on Ruby/Rails, Django/Phython or
Symfony/PHP?"

------
KaiserPro
Programming languages are merely brushes with which to paint logic.

I'm going to level with you, the choice of language is a combination of luck,
personality and circumstance. Nothing else. There is no hidden knowledge, font
of programming youth, etc, etc,

Its like choosing a building material, when you want to make a house. Most
people choose bricks. When used properly you can make many a wonderful,
functional and innovative house.

In short you can do all of the things you want with any Turing complete
language.

As for scaling, its mostly never down to the language, its almost always
system design. Crucially its knowing when, where and how to store state. Does
it need to be shared?, does it need to be consistent?, how can you partition?
what stuff can you push out to static storage? None of those questions are
answered by a language.

The stated scale (10million requests in a day) is roughly 120 requests a
second. Most systems _should_ be able to handle that without costing the earth
hosting wise. Hell, the API I look after can do 5000 concurrent requests,
~8000 requests a seconds using about 2.5 cores. That's in python without any
real optimisation. Its not because python (or my skill) is awesome, its
because CPUs are really really powerful now.

A skilled programmer could easily get 2-5X more performance, but it'd cost at
least 5 years of hosting to get them in and optimise it.

TL;DR:

Its not the language, its the business plan and design that matters.

------
nl
It seems strange that no one has pointed out the PG essay making this claim
(for Lisp) and then the latter discussions where he acknowledged it slowed
Reddit's development down, and Aaron Swartz made the right choice switching it
across to Python.

------
k__
After I had my fair share of trouble with JavaScript in production, I'm very
willing to try ReasonML in my next projects.

I still love JS, but I'm not so sure anymore that it's for me.

------
namelosw
No matter if it is a secret weapon, most of the companies in the industry
won't even try because current tool works - despite working well or not.

The major difference of the industry compared to 90s is everyone stop getting
hyped by new ideas. In 90s there were companies keep re-writing from C to C++
then to Java recklessly.

Now everyone is 'smarter' \- stop worrying and love Java, forever.

And they have a famous quote for justifying being lazy: there is no sliver
bullet.

------
erokar
Scalability, safety and ease of refactoring are usually the exact problems you
should NOT focus on in a startup. Development speed and easy prototyping are
much more important and is better achieved by dynamic, multi-paradigm
languages like Ruby, Python or JS. Choosing Haskell for a startup could easily
be a form of premature optimization that would slow down development.

~~~
yakshaving_jgt
That is of course totally subjective. I run three businesses on Haskell,
having previously been a mostly PHP, JavaScript, and Ruby developer, and
having shipped many projects for startups with Ruby on Rails.

Anecdotally, I have been able to ship much more quickly and reliably with
Haskell than I _ever_ could with Ruby/Rails.

------
tcbawo
It's very hard to build a real money-making business. The best language is the
tool that gets you over the finish line. It's great to invest in new
technologies. But, I have also seen many developers push technology without
the business in mind, to satisfy intellectual curiousity or some self-serving
desire to feel superior/smart.

~~~
yakshaving_jgt
Conversely, I've seen many businesses fail because their software is too
unreliable. Better technology helps mitigate this.

------
trilila
Yes please. More functional programming, less OOP, or if OOP then less design
patterns and if possible no documentation or tests.

I make a living from untangling poorly written code, and these would mean more
work for me.

Oh please use an obscure or low traction programming language as well,
preferably an archaic one.

~~~
brightball
OOP is usually what creates the tangled mess by its very nature.

~~~
trilila
Yup. And tests and documentation are just overhead.

~~~
weberc2
> Yup. And tests and documentation are just overhead.

Why post here at all if you’re just here to troll and start flame wars?

~~~
trilila
My intentions are neither to start flame wars, nor to troll, sorry if I came
across that way.

I am being sarcastic against posts contrarian to common practice only for the
sake of being contrarian, this being one.

If a current good practice is to write tests, there will be a post against
writing tests. If a current good practice is to write documentation, there
will be a post against writing documentation. If OOP then functional.

In my consulting job I do have to untangle code written using contrarian
practices, obscure languages, and other temporary fads.

Not that Haskell is not a good language, or that functional programming is a
bad approach, but rather that neither are a secret weapon against anything
else but specific problems these are good at solving.

Good luck to those companies scaling to more than a handful of devs - they
could also hire people to migrate them the right language for the task at
hand.

~~~
weberc2
I think the communication problem here is that you’re arguing against the
notion that FP is a silver bullet, but no one here has made that argument, so
it sounds like you’re arguing that OOP is superior. I buck pretty hard at this
because everything uniquely OOP (e.g., inheritance) is generally only
problematic. And OOPproponents love pointing out that _good_ OOP programmers
don’t use these bad features/idioms/etc or they only use them where they don’t
cause problems, in which case their code ends up looking the same as it would
in any non-OOP imperative language (e.g., Go).

------
twic
> This should lend itself to superior performance. I see this with Freckle -
> the company now serves 10 million questions during the school day

Assuming a school day runs from 9 am to 3 pm, that an average of about 460
requests per second.

