Hacker News Reader

Comment by lifeisstillgood | Hacker News Reader

We have had these discussions for many years (even pg wrote about Blub IIRC), but the real reason (IMO) is that language choice matters far less than we like to think.

What business we choose to build with the language will outweighs the impact of language choice a hundredfold.

Our decisions on CI/CD, our discipline on building clean architecture with whatever language we like matters more.

In short, the things that make development a productive and enjoyable experience are linked less to the language than to the skill and professionalism of the development team - and "weird" languages tend to have more skilled and professional developers working in them, so the causality / correlation tends to get mixed up.

The upshot is, worry less about learning Lisp at work, and more about fighting your corner on why we should rewrite that 3,000 line monster engine module that we all call each day but making changes to it is a nightmare.

View on HN

> "What business we choose to build with the language will outweighs the impact of language choice a hundredfold."

This is on one hand a truism that actually adds nothing to the discussion. In achieving success, of course the business matters. Even more so the best simplifications come from understanding the business domain, not from the tools used.

---

On the other hand it's also patently false. Build a web browser in Ruby. Build an operating system in JavaScript. Build your average web app in C/C++.

The tools used have inherent limits, being optimized for certain domains and not others, can make us more productive, can lower the defect rate and can keep us happy enough to see the project released.

In my experience _some_ static FP languages can lower the defect rate, can make certain problems easier to tackle, can make the code easier to maintain and refactor and due to performance being reasonable, they tend to be more general purpose than other languages — this trait being a consequence of static typing, making performance good enough, coupled with the languages themselves still being high level enough.

---

> "learning Lisp at work"

Ah, I see the problem ... many of you thought Lisp is some sort of secret sauce. It isn't, it never was, Lisp is a freaking mess.

The real problem in our industry is not applying the scientific method for advancing it. We thus rely on fashion and salesmen to sell us magic pills.

> On the other hand it's also patently false.

The sentence "language choice matters far less than we like to think", which means something like "switching between most pairs of languages in most situations doesn't make a big difference", and your examples which mean "there exist pairs of languages as well as situations where switching between them makes a big difference" are completely compatible.

In fact, I would say that the latter is not interesting because of course we know there are situations where high-performance languages are more or less appropriate, but the interesting question is whether languages that have similar aims and performance, and differ mostly in their linguistic features make a big difference.

> In my experience

Unfortunately, people will also support the effectiveness of homeopathic medicine based on their experience, and much more enthusiastically. I'm not doubting your sincerity, nor even the facts of your situation, but this doesn't count as evidence. On the other hand, the fact that different languages are tried in different places, in an industry with strong selective pressures, the fact that no single language or paradigm completely overtakes all others is evidence in favor of there not being a very big bottom-line impact.

> the fact that no single language or paradigm completely overtakes all others is evidence in favor of there not being a very big bottom-line impact.

Or perhaps because no paradigm is universally applicable to all cases. There will be a bottom line impact if the wrong tool is picked for the job.

Sure, but what I'm saying applies when comparing different languages that are reasonable choices for a given domain.

Anyway, this isn't a poll, and while opinions -- one way or another -- shape the popular opinion, they don't settle the empirical question.

>>> this trait being a consequence of static typing,

This is kind of my point. The goal is to build the right thing, right. Languages aren't the point, the advantage is techniques/ capabilities that come with it. 20 years ago memory management was a huge advantage in building the right thing right. And it had to be built into the language. but 20 years ago I had what I would now call a CD system, built around pxe-boot and bash. It made building the right thing right much easier, and had nothing to do with language choice. As does all the good things we consider - from engaged business teams to unit testing and pager duty. Our language choice impacts some of that, more often our organisational maturity matters more.

Yes some languages are "better" than others - but if the goal is to have an organisation doing something, then tools to build the organisation matter more. Software will of course be at the heart of that, but the language choice won't (much).

>What business we choose to build with the language will outweighs the impact of language choice a hundredfold.

This isn't always the case. If I tried to build a HFT company using Ruby for literally everything, it's almost guaranteed to be a completely failure, not only because it's extremely difficult to write allocation free low level code in pure Ruby, but also because anyone I tried to hire with relevant experience to build the platform would be like "WTF, why are you building a HFT platform entirely in Ruby, that's such a stupid idea, no way I'm working on that".

Or for that matter if I decided to start a company to build a web browser in pure Ruby.

I kinda agree but can't help observing that quite a few HFT firms use Java, where it's also hard to write allocation free code. They use various approaches like pauseless GCs or just sizing the heap so that they don't need to collect during the day.

HFT is also a continuum. There's a latency/strategy iteration tradeoff involved. Going "quite fast" can be better than going "super fast" if your quite fast strategy is better, but keeping at the edge of good strategies requires constant code changes. Hence the benefits of high level statically typed GCd languages.

That's basically the crux of it, syntax matters a lot less in language adoption. Most mainstream languages benefit from a "killer" app, feature, software-class or platform, which is what sees Swift become hugely popular because of iOS, Java/Kotlin getting a boost from Android, Browsers popularizing JS and many games & OS Software still written in C++ for its zero overhead abstractions.

Ecosystem, native libraries, community, knowledge, tooling, familiarity, domain suitability, hireability and overall general dev productivity & UX matters a lot more in language adoption.

I'm not seeing any big draw card from a Killer App that clearly highlights its superiority over more popular alternative languages. There's many niche areas where FP shines like implementing compilers, statistics & math models, but I don't see much appeal in mainstream usage where it adds enough value over dominant languages to overcome its deficiencies in other areas. A clear example is AI which is an area that FP would excel at but is still dominated by Python & its dominant ecosystem.

The value proposition of pure FP languages also gets diminished as mainstream languages adopts FP language features.

Language choice matters. But, except for specific cases, and within an usually wide margin, it matters less than you think. http://www.paulgraham.com/avg.html

Yes, you'll shoot yourself in the foot if trying to write a website in C++ or maybe Java. But between Python/Ruby/Modern PHP, they will probably work fine.

And the main issue I think is that, while some languages like Haskell (or Elixir, though it seems much better than Haskell) or Lisp or F#, etc might excel at some places, their advantages won't compensate for their disadvantages in the 80% of cases you don't need them (this is comparing with the modern language landscape - and even Java now is much better than Java 20yrs ago).

I love this phrase from the article above: "The safest kind were the ones that wanted Oracle experience." though I think there's a deeper meaning: they're not safer because they're using Oracle. They're safer because they're picking Oracle (hence showing that their world view is narrow). Sure, they could be geniouses in disguise and picking Oracle for that 1% where it really is way better than the competition, but most likely they aren't.

Amen. Or as Jobs said, "You've got to start with the customer experience first and work backwards to the technology. You can't start with the technology and try to figure out how you're gonna sell it"

https://youtu.be/FF-tKLISfPE

And yet, iPad.

What about it? Are you claiming the iPad started from the user experience or technology?

What do you mean by that? I’ve been using iPads as my main computing devices for the past five years (and almost exclusively for the past three). It depends on your workflows.

I'm responding to "You can't start with the technology and try to figure out how you're gonna sell it", not saying iPad is bad.

I was referring to the remarkable history of iPad, which was designed to have certain features, not designed for a particular use. Jobs started on it before iPhone, attempting to combine his and Ive's favorite features: simple, multitouch, thinner!, no keyboard, no mouse, no stylus, no buttons, lightweight, handheld (not used plugged it), great screen, etc.

It was not designed as a "solution" but as a great...thing...that would turn out to be great for...something. It was his baby, and he insisted that they keep working on it until they found a use, which they did: they turned it into an iPhone.

That was smaller (screen size) than Jobs had planned, so he made them keep going on bigger versions. They would be so wonderful, they would be great at...something. When they released the first one in 2010, they were intentionally vague about its target market. They presented it as maybe a substitute for laptops for productivity apps, they presented it as sort of a better Kindle for reading, as an artist's tool (for artists who fingerpaint), etc., with the hope that with such a great collection of features, it would be like the original LaserWriter and turn out to be perfect for some market.

Regardless of what that market would end up being, it did in fact start with the technology that two passionate designers wanted to exist for its own sake without knowing in advance what it would end up being used for.

My feeling right now is i disagree with this. I think there is a certain amount of clarity in functional languages that more imperative languages are striving for as they develop maybe. You seem to be able to express more for less in most functional languages. Out of curiosity, do you yourself work well and quickly in functional languages?

CI/CD is also separable from this issue, i think. But the thing that you can do well with it which is write and regularly run tests is not.

My thinking is the main problem is people just aren't exposed to functional languages enough and get stuck working to line theirs and other peoples' pockets before they have had enough exposure.

I also have some gripes with the actual document which i will post in a top-level reply.

While true for the more trivial cases there are examples that show the opposite e.g. Whatsapp's choice of Erlang allowed it to scale up easier with less engineers - https://www.wired.com/2015/09/whatsapp-serves-900-million-us...

Yes, most languages you can use functional style

Reply on news.ycombinator.com