Hacker News new | past | comments | ask | show | jobs | submit login
A Secret Weapon for Startups – Functional Programming? (ramanan.com)
47 points by allenleein 39 days ago | hide | past | web | favorite | 84 comments



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


> 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.


A good microservice architecture won't have an external call result in multiple serde bounces between other microservices before a response is returned. At worst it should wrap access to something slow like a database or another complicated backend service.

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

Isolation benefits, sure. Performance benefits, no, because you still run into https://en.wikipedia.org/wiki/Amdahl%27s_law


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.


> 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".


> 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.


>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.

Honest question, have you ever actually worked with decently written micro-services?

You don't send complicated objects, you send relatively simple objects. And you don't do it by hand, grpc and thrift have existed for a long time. I'd argue that part of good decoupling, in functional or micro-services programming, is making sure you only communicate simple objects around.


> Honest question, have you ever actually worked with decently written micro-services?

As decently as is possible, yes.

> You don't send complicated objects, you send relatively simple objects.

Right, which limits how powerful the overall system you can build is. That was my whole point.

> And you don't do it by hand, grpc and thrift have existed for a long time.

Sure, but they have pretty anaemic type systems and a lot of stuff is just inherently high-effort to serialize (see the recent post about defunctionalising the continuation).

> I'd argue that part of good decoupling, in functional or micro-services programming, is making sure you only communicate simple objects around.

Functional programming gives you more tools to interleave complicated constructions while still enforcing that all your concerns are treated orthogonally. For example you can form a free monad structure that contains commands that will be interpreted by one particular service, but interleaved with other computations that will be implemented by other services or directly. The types ensure that everything's properly decoupled, but you can still represent all the complexity that's there in the actual problem. You can't do that with microservices.


As an addendum, I'd say "sorely needed tooling/ecosystem stuff once you reach sufficient size" is flexible. You can probably get by with Clojure, Scala, or F# for a lot longer than you can with Haskell.


I would immediately believe Clojure and F#. Scala I'm a bit more skeptical about. Unless it's in a restricted domain with established patterns, I've seen and can imagine seeing many more codebases which sprawl into accidentally complex messes with very poor compile time ergonomics.


> You can probably get by with Clojure, Scala, or F# for a lot longer than you can with Haskell.

What experience are you basing this on? It sounds like pure assumption, and doesn't at all match my experience of working at either a Scala or Clojure company, or running my businesses on Haskell.


I actually don't have much experience with Haskell, however I do have experience with Scala and the Java and .NET ecosystems (and know personally some people very into F#). My assumption was that the libraries, build and test systems that work in JVM/.NET land probably don't work as well as in Haskell land. There are many JVM/.NET applications with very large development teams that have put a lot of work into tooling; I don't know of any large (in terms of active fulltime devs) Haskell projects so my assumptions is that these tools would be less mature there.

But perhaps I'm incorrect, hence my original use of the qualifier "probably"


I would argue that starting with the actor paradigm is better than starting with microservices (ideally with some form of dependency injection). In a way they are the same thing, but you aren't forced by the Actor paradigm to start with individual processes. You can start with a single service, and break actors out into microservices as needed. Starting with microservices seems like premature optimization to me. I feel that the actor paradigm fills this gap nicely.


I don't think most companies would take much notice of functional programming experience. So it cannot be resume driven. If you resume driven, you go with react, or containers or something.


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.


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.


Why would you write four cases? You only care about two of the cases.


I run a few startups on Haskell. Most of the work is boring imperative stuff. While it sounds like the company interviewing you were probing to see if you understand traversals and bifunctors, your proposed solution would have been given a thumbs up in code review on my team.

FWIW, I would have written your function as

    f = bitraverse id id
No "double nested flatMap lambda contraption" necessary.

Ah, it looks like you can even just use `bisequence`, which is equivalent to `bitraverse id id`. So you didn't actually need to implement anything!


This is one of the solutions, using do notation:

    solve (theInt, theString) =
      do
        a <- theInt
        b <- theString
        return (a,b)


wrnr - This is literally the 'flatmap' solution you referred to above, but in sugared form - what they were probably trying to see was whether or not you understood how to collapse a pair of Maybes into a single Nothing if either component is missing without needing to do an if test - i.e., whether or not you understand the essence of the bind operatorion in the context of the Maybe Monad.


Once you become familiar with monads and their operations, it becomes second nature. Going back from monadic operations to imperative code after tasting the forbidden fruit is awful.

In someways functional programming has kind of ruined me as a developer: I would probably never take a job where I had to write in an imperative language full-time.


Did you end up working there ? I'd suggest not to judge the idiom of their solution quickly. I understand it feels like a 20T hammer for a small nail. But it may be that they use a very high degree of function based programming composing abstraction rather than writing logic on atoms.


Haskell solution:

    uncurry $ liftA2 (,)
edit: just noticed the other comment mentioning the better solution:

    bisequence


Unless I'm not undersranding this correctly. This is basically 'zip' in most functional programming languages.


Indeed. However in Scala at least zip ends up giving you a List instead of an Option.

for {} yield seems to do the trick

    scala> val a = Some("A")
    a: Some[String] = Some(A)
    
    scala> val b = Some(1)
    b: Some[Int] = Some(1)
    
    scala> val b2 = None
    b2: None.type = None
    
    scala> for { x <- a; y <- b } yield (x,y)
    res1: Option[(String, Int)] = Some((A,1))
    
    scala> for { x <- a; y <- b2 } yield (x,y)
    res2: Option[(String, Nothing)] = None
    
    scala> a zip b
    res3: Iterable[(String, Int)] = List((A,1))
    
    scala> a zip b2
    res4: Iterable[(String, Nothing)] = List()


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?"


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.


I agree with you wrt hiring but I think the choice on language (especially at startups) largely comes down to founder knowledge.

As a full-time Scala developer (and long time Java guy) I've seen first-hand the benefits and drawbacks of both worlds: The highly populated world of Java libs and developers vs. the relatively niche Scala (but growing FAST!) community (relative to Java/Node.js/etc).

The learning curve on Scala (just like haskell) is quite high for most "standard" developers. However even given that we usually don't have much trouble getting people on-boarded and productive in Scala.

Java & Scala (thanks to the JVM) offer fantastic options for resource util. You can build very lightweight stateless microservices that run on a box with 1 or 2 cores. You can also build services that utilize hundreds of cores and terrabytes of RAM


> most companies prefer standard languages where it is easy to recruit standard-level talent for standard wages.

With the added benefit of easier recovery when the main programmer leaves and take with him/her all his/her knowledge about the code. I've heard about this plenty of times when in a relatively small company, using [name your preferred somewhat exclusive language here] was preferred because someone made that decision alone, a long time ago, and the end result being almost unmaintainable code and longer than average time to get going or even find replacements.


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.


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.


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.


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.


This relationship to self worth is a big piece of it. Valuing competence in a company is a cultural value. It's not professional, it's basically a craft/academic orientation or aspirationally so. The products I have seen them release were exceptional in their novelty.

There are upsides and downsides to the mysteriousness piece. The upside is rapid decisions based on group deference to demonstrable expertise and competence. The downside is a bottleneck where you can't delegate competence, so everything needs the guru blessing. Ultimately, this figure only gets a veto, and you get the global veto anti-pattern in the org. It's a basis for alignment that doesn't scale as well as dynamic collaboration.

To me, the quality of thinking part has an effect on the culture is expressed as the cost/benefit and scaling aspects of fast hierarchies vs. the optionality of dynamic collaboration. (viewed negatively as command/control vs. political solutions.)


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.


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.


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.


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.)


I think "power" is kind of a vague term. There is no objective scale of power, beyond a language being Turing-complete. But languages are not equally appropriate for any task, so it is certainly a competitive advantage to choose the language which best matches the task at hand.

Obviously if you want to iterate quickly, "move fast and break thinks", something like Python is more appropriate than C++. Not because Python can be said to be "more powerful" in any absolute sense, but because the trade-offs in the language design (speed of development above low-level control) makes it more appropriate.


What I took away from Graham is that there is a verbose way to do something and a concise way. I suppose writing a book to describe general relativity is a verbose way to express what the equations say.

Perhaps power = ability to be more concise which translates into "more things done per unit of time compared to a less powerful language."


But terseness is just one desirable property. Sure, all else being equal we would like to express the same with fewer tokens. But there are other factors in play, e.g. a statically typed language like Haskell will typically be more verbose due to type annotations, but you catch bugs earlier, thereby saving time. So different kinds of power is at play, and you will have to make a trade-off decision.


It’s less verbose than many statically typed languages due to inference. As long as you stay away from high level type extensions like RankNTypes, you can write whole programs without a single type annotation and still get full type checking.


Yes indeed.


Size problem is a factor too. I'll take C++ over python for fast iteration if the problem requires thousands of programmers and millions of lines of code. (Java or C# could be better yet. Or you can make a convincing argument that good architecture interfaces would break the python problem down to interfaces that you cannot iterate)


> 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?


I think you crush opposition because you're good at selling. Then you need something to sell but it's the least important thing. I'm writing this as a 95% developer and 5% salesman.

However using reasonable tools is important. The wrong ones can slow down companies and make business fail beyond the skills of the marketing departments. In my experience I didn't see much difference between Elixir, Java, Perl, PHP, Python, Ruby. Properly handled any of them could be ok even if I've got preferences. JavaScript... too much cognitive overhead because of constant ecosystem changes and fragmentation but maybe it's slowing down now.


Besides selling, I'd include having a good business plan and management skills.

Focusing on programming languages is the mother of all local optimizations. Although what we do is obsessing, not merely focusing.


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.


I bet that was really good fun, though!


It was a major strain on my marriage, among other shitty things.


Lisp/Functional programming might indeed be a silver bullet, but you still need to know how to operate a gun to use it, is the lesson.


That's why I mentioned Ruby on Rails. I think RoR-startups count as examples.


Your username seems apt here, RoR was (is?) notorious for being a particularly "weak" language in terms of performance, but being a "powerful" one in terms of being a good template with good tooling/ecosystems.

While perhaps functional languages are "powerful" in terms of performance[1], but "weak" because they have poor tooling/ecosystems, not even starting on the difficulty of recruiting, etc.

[1] Though I personally think the author is exaggerating the benefits, while conveniently skipping over the massive ((neg))((ati)(ves))))) and incomprehensible code large functional code bases often produce


> all else being equal. Hence it makes sense to use one.

It would make sense if you managed to sort out the precondition first, i.e. find sufficiently capable and affordable programmers able to use the language, make sure the language ecosystem is as capable of supporting your field as more popular languages. In other words, it rarely makes sense because "all else" is usually not equal.


> Ruby on Rails comes to mind even though it is a language and a framework.

The same could be said of Elixir + Phoenix in 2019. In a lot of ways, Elixir macros and protocols give at least as much power in building DSLs as Ruby-style metaprogramming, but there's no magic and every single module reveals which macros it uses at the top.

It's not quite the stark trade-off Rails offered vs old school Java / PHP development in the mid to late 2000s, though. In that case there was a tremendous productivity advantage for using Rails to make a web app. Now, Elixir offers moderate advantages, that grow with project size but it's competing against already well-developed Rails and Laravel ecosystems which offer excellent productivity in their own right, plus an existing gem/library for "everything".

I love what Elixir's immutability does to make testing and handling larger projects easier and I'm glad to have learned it, but in all honesty I never would have if not for having been focused on a free to use chat app in 2016-2017.


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.


This may be a specific case of a more general rule: use proven, boring tools that get the job done and focus your efforts on sales, marketing, people management and the business itself.


Do you know of any startup which have done that successfully? I would suspect it is only for very specific application where you would realize a 20x speedup in reality and where it would be a competitive advantage.


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


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.


The final code in the "Squeezing performance 2" section looks scary. I'll admit I'm not an expert in CL and have only written Clojure, but that does not look like idiomatic CL. A good comparison would be idiomatic C++ vs. idiomatic CL. If this is idiomatic CL, then i'm really surprised at the performance.


If anyone wanna try:

A native compiler backend for PureScript (via C++) https://github.com/pure-c/purec

https://www.youtube.com/watch?v=zwcwXea0in4


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?"


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.


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.


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.


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.


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.


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.


Honestly it depends on what your developer is most comfortable with.

If developer is more comfortable with haskell they will likely be faster in that than python. The added advantage it will also likely to be more correct.


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.


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


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.


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


Right. I’m not an FP advocate by any means, but the worst tangled messes always involve inheritance and hanging methods arbitrarily off of data classes. Yes, you can write clean OOP code, but you end up avoiding everything that is characteristic to OOP and your code ends up more closely resembling idiomatic Go, Rust, or C.

trilila 39 days ago [flagged]

Yup. And tests and documentation are just overhead.


> Yup. And tests and documentation are just overhead.

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


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.


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).


OK I was agreeing with the "More functional programming, less OOP, or if OOP then less design patterns" part but then "if possible no documentation or tests".

What the hell is that? You want people to not write tests or make documentation? (Totally ignoring the fact function code is easier to test and document anyway).

I'd hate to work with your code. There's probably no point me even trying to find out what you mean because I suspect its some totally ridicilous argument that only seeks to annoy whoever reads it. Nice bait.


He’s trolling. He’s lumping in FP with bad programming practices like not writing tests or docs because he allegedly gets paid to “clean up code”.


Functional programming does not nessesary mean not OOP code, for example look at Ocaml or F#


I suspect that for trilila's purposes, that's even better! Now, if only there was some way to incorporate logic programming into OCaml as well ...


> 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.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: