6 ms·

While the article is particularly focused on concurrency, I think that there's a larger takeaway: namely, that language features are paraded around as, essentia

• deepGem 10y ago
  Some of the practical aspects that favour functional programming lies in parallelism, not concurrent programming. Parallelism as in multi threading. It's an order of magnitude easier to write parallel programs in Scala than in Java. I don't mean a simple hello world but real world applications which will involve transactions and potential deadlocks. Agree Yes, the parallel constructs in Scala work with Java threads underneath, but you write a lot less code. I don't think Functional programming makes any task easier. In fact I'd argue the opposite, it's quite difficult to write functional code, to unlearn imperative programming. Once you gain mastery over FP, you do write less code. Reaching that level of mastery is an uphill task, it has been for me at least.
  • jackmott 10y ago
    So there are some domains where that parallelism easing can really work out well, when dealing with jobs over thousands of cpus, or gpus etc. It can however get almost comical in the case of desktop/single server applications, where you have maybe 4 or 8 cpus available. Because you can write something nice in F# or Scala, and run it on 4 to 8 threads, get a nice speed up. But the same code, written in an obvious manner in C, ends up auto-vectorized and/or auto paralellized to some degree and runs ~8x faster on just one core. Could be more, of much less, depends on many factors, but it is something to consider. This isn't an inherent problem, but most functional languages need a lot of compiler/JIT work to make the parallel features a net performance win more of the time.
    • galacticpony 10y ago
      Not to mention that there are much better libraries for data-parallel programming available for C/C++, plus there are languages designed for data-parallelism (OpenCL, ISPC) and they're not functional either. Untold amounts of energy (and dollars) must have been wasted on the "convenience" of writing some program in Python that scales over cluster of MapReduce nodes, without investigating how an in-core solution in a straightforward native implementation would have performed.
• sgeisenh 10y ago
  The obvious example is a compiler. Java, C, Python and Javascript all lack algebraic datatypes and pattern matching, which make writing a compiler much easier. There are many additional features of Haskell that make it especially good for implementing a compiler, if you know what you're doing. I guess that's cheating because a compiler is just a function from source language to target language, so it is easily expressed in a functional language. But it does answer the question nicely.
  • galacticpony 10y ago
    I believe you're mistaking "easy" with "convenient".
    • sgeisenh 10y ago
      How so? Pattern matching makes for more readable code. And more readable code makes writing projects easier. It is also more convenient to write code using pattern matching, but that isn't the primary benefit.
      • galacticpony 10y ago
        This is a superficial view of readability, focusing on terseness and perceived syntactical elegance. "True" readability is achieved through a consistent structuring of your program, which has to conform to the expectations of the reader. Programmers must first build this expectation from picking up patterns in the code, which emerge no matter if you use pattern matching or an equivalent structure using the available language constructs.
        • joesb 10y ago
          They all contribute to readability. You can always write in assembly code, with all that consistent structuring and conforming to expectation. But I'll takes writing in higher language with "abstraction you can write yourself" any day.
    • deleted 10y ago
• SatvikBeri 10y ago
  Apache Spark is one of the most popular analytics frameworks for large datasets, and would be substantially harder to implement in a non-functional language.
  • allengeorge 10y ago
    And why is that exactly? What is it about Scala that makes it easier to develop Spark?
• greydius 10y ago
  The appeal of Haskell for me isn't necessarily that it makes everything easier. It does make a lot of things easier, but also many things become more difficult. No, the appeal of a purely functional language with an expressive type system is that it helps me write correct programs. I'm not claiming that Haskell will magically make code free of bugs, but in my personal experience when I write Haskell I make far fewer mistakes. I can't really make the same claim of other functional languages that I've used, especially those with dynamic type checking. There's really not much point in arguing about programming languages, though. People like what they like. I knew a guy that thought Fortran was still the greatest programming language because it's the fastest. Then you have the embedded device guys that will be using C until they die despite a mountain of valid criticism. Then there are the Lisp folks who are smart enough to not need help from a compiler to write programs. Etc. The thing is, these people are usually really productive with the tool that they've mastered, so of course they're all going to have anecdotal evidence of their language's superiority, just like me.
• Jtsummers 10y ago
  This is my own thesis and not really researched in the sense that I can point to any other articles, but it's what I've synthesized from my time as a programmer and studying CS. There are many camps of programming thought, but I'm going to distill them here to two. Mechanical: This is, fundamentally, the Turing machine. Assembly, C, Fortran, others, sit in this camp. They're very much concerned with the mechanical act of computation. We don't have high level abstractions (ok, we do, but they're very limited). This doesn't bar us from performing incredible feats of computation or computational thinking. But it does make some things more difficult, particularly the task of viewing the code and understanding what it was intended to model. There's a strong disconnect, then, between our high level concept of the system being developed (specification, requirements) and the low level implementation. Mathematical: This is lambda calculus. Haskell, erlang, lisp, others, sit in this camp. They're more concerned with mathematical or symbolic understandings of computation. They tend to be less concerned with low level performance (though may still achieve it quite well) and low level implementation details (I don't care if my custom type BTree is implemented as an array under the hood, I care that it behaves in a way that satisfies its definition). This makes translation from specification to implementation almost trivial. With some care, you can practical document both at once with languages like Prolog or Haskell in a single document. The drawback is primarily one of performance. But that can be handled via implementations (FFI, smarter compilers, access to low-level primitives or "unsafe" code). Hybrid: I'm not sure where to place OO, so I'm going to place it here. In theory, most OO languages should be able to deal with both quite well. In practice, they have historically sat too close to the mechanical side. Or abused the mathematical side to create horribly inefficient models. They offer the, theoretical, abstraction levels of functional languages, but the procedural components (the methods defined in the classes) to have fine control over performance. You can, technically, achieve any computational task in any language. But the levels of abstractions they provide allow certain domains of problems to be solved almost trivially. I could make a functional model of a radio system. A functional language or an OO language makes this effort almost trivial. I don't care about the underlying performance, this is a model so I can demonstrate sending messages between two radios and between components within the radios. I need to know that the specification itself is consistent, and, as a bonus, this model can be turned into a simulator for situations where we want more radios than we physically have or can set up in the lab. Implementing this in C, from a performance perspective for the latter part, makes some sense. But it makes demonstrating that the high level specification and requirements are satisfied and implemented almost impossibly difficult.
• edude03 10y ago
  I'd argue that what make FP languages better than non FP languages is when it comes to hiring developers that know FP languages are more flexible. For example I can expect a scala developer to be able to implement functional principals in say, PHP but not necessarily the other way around.
  • xlayn 10y ago
    Do you have any studies to back that claim. I could argue the opposite, FP hide away the details per design as it is declarative and not imperative being imperative per wikipedia "Imperative programming focuses on describing how a program operates." Therefore are probably bad working in constrained environments or low level programming.
    • galacticpony 10y ago
      I would argue the same way from experience. Functional programming languages tend to provide an abstraction that you could have easily built yourself by focusing on the constraints that are relevant to you - not those constraints some language theoretician has decided for you.
• bunderbunder 10y ago
  It's a big ask to suggest reading through this, but reading http://blog.ploeh.dk http://blog.ploeh.dk starting from around about 2013 is illuminative. Seemann basically wrote the book on dependency injection in .NET, and has been a pretty big evangelizer for clean object-oriented design. Some time during that year, though, he discovered F#, and from 2014 on his blog has been increasingly about functional rather than object-oriented design. By following the transition you get a pretty good luck at things (ML-style) functional programming does well, since it's basically a journal of a serious expert in object-oriented design learning switching over to the functional paradigm.
• tvural 10y ago
  Yes, exactly. When I hear people brag about how functional languages don't allow side effects, I always wonder, what's to stop you from just writing your program without side effects in an imperative language? And occasionally it will be more natural for your program to have side effects than not. I have a similar gripe with type systems. Types are restrictive metadata - they never reduce a program's complexity, and sometimes they increase it.
  • Jtsummers 10y ago
    Types absolutely do make programs easier. I work in embedded systems. Our primary programs operate on messages, binary data. Type less like you suggest would mean always grabbing contents by way of offsets. Then never knowing if they are ints, doubles or what. Even the basic type infrastructure of C is useful here. We map the blobs to structs. We can then grab the contents and manipulate them as ints, doubles, or strings. Removing types would make this a horrific task.
  • nightski 10y ago
    They aren't a restrictive metadata, they are a verifiable language for communicating intent.
• knucklesandwich 10y ago
  I wrote a comment about this below, but I think its fair to say that pedagogy has been a long standing problem in the functional programming community. A lot of the criticisms leveled at haskell for producing "toy software" are better targeted at the poor pedagogy that has plagued haskell for so long. I think there's lots of examples of production grade libraries in haskell (stm, async, lens, quickcheck, attoparsec, warp, etc.), some of which are effectively best in class among all languages. Likewise, I think there's a lack of acknowledgement of how many stellar compilers are written in haskell. Rust, Perl 6, Elm, Purescript, etc. were all either initially written in haskell (before they become self-hosting) or continue to be. This shouldn't be downplayed... a compiler is one of the most complicated kinds of software you can write, and writing a compiler in a language shows a lot about that language's versatility (which is why a self-hosted compiler is something of a benchmark). Lack of good resources for learning haskell for so long have incubated haskell as an "experts" language, particularly experts interested in PLT considering haskell extensions have been used as a PLT research platform. I think this is why you see so much evangelism for the language and relatively little industry use: its generally been inaccessible for people without a background in theory for a long time (and its not per se that the language is inaccessible so much as some of the scary sounding, alien seeming design patterns that are conventionally used). Generally I believe this is getting better, though the situation isn't perfect. As for evidence that this isn't due to deficiencies in the language, I think its worth considering how many ideas from haskell have percolated to the broader programming language community. Promises in javascript, for example, are effectively monadic (technically they're probably closer to bifunctors, but they're definitely very influenced by monads in haskell). Ad hoc polymorphism is now embraced by languages like C++ and rust. These things don't strictly need pure functions to work in the host language, but they're design ideas and language features that were originally developed to benefit a purely functional style. Edit: As pointed out below, I'm wrong about rust, it was written in ocaml.
  • jdub 10y ago
    Rust was OCaml.
  • saghm 10y ago
    I'm pretty sure Rust was originally written in OCaml, not Haskell. Unfortunately, I'm unable to find any references for this, as googling mostly leads to other comments (on HN and reddit) saying the same thing, and Wikipedia's footnote for the sentence stating this seems to be a reference for other parts of the sentence. That being said, Rust itself is heavily inspired by Haskell; most notably, Rust's traits are pretty much equivalent to Haskell's typeclasses in almost every imaginable way, up to and including the way they can be derived for types.
• duaneb 10y ago
  Really? The last Haskell project I saw on the front page was a c to rust transpiler. Seriously cool stuff even ignoring the Haskell aspect of it. It has its place, just like other languages--on a pragmatic level it is easily the best language for parsing I've ever seen in my life. But it is absolutely fetishized.
  • jdmichal 10y ago
    A transpiler is a perfect use-case for a functional language. You're literally mapping from an input domain to an output domain. That's what a function is, so it all fits very well. It's when you have things that go outside of domain-to-domain mapping that functional starts to fall apart.
    • nightski 10y ago
      You provide nothing to back up your assertion that it falls apart. I have written image capture and 3D reconstruction algorithms in Haskell which interacted with webcams, OpenGL, networking, etc.. and never felt like it was "falling apart".