9 ms·

Functional programming won't succeed until the tooling problem is fixed. 'Tsoding' said it best: "developers are great at making tooling, but suck at making pro

• yodsanklai 4y ago
  > I seriously couldn't figure out the idiomatic Ocaml workflow/developer inner loop after more than a day of struggling. I tend to agree but, compiling C++ isn't just about typing "make". And it did take me more than one day to figure out python/js workflow.
• initplus 4y ago
  Honestly Haskell's tooling is really surprisingly good these days. It works fine cross platform, there is a single "blessed" path without too many options to spend time agonizing over. Today the Haskell example is just `cabal install --only-dependencies && cabal build`.
• mrkeen 4y ago
  > Functional programming won't succeed until the tooling problem is fixed. I think different people have different wants and needs with tooling. I make (and use) binaries with Haskell. I wish more mainstream languages could make binaries.
• Karrot_Kream 4y ago
  I think FP suffers from what I call the "ideological gruel" problem. A lot of niche ideology-oriented communities with very strong opinions tend to ignore usability issues not necessarily because it's a theory/practice dichotomy, but that the highly ideologically excited community ignores the problems because they're so positively motivated by the ideology. So even if you're eating gruel, if the gruel is produced by an ideology you identify strongly with, the identification alone is enough to make the gruel taste better than mere gruel. A lot of folks that use FP are willing to overlook the myriad of rough edges around tooling because they're so excited to work with FP that they often get used to the tooling. Rust made tooling UX an explicit focus of the project which is why it was able to escape the "ideological gruel" curse. Additionally most prominent FP projects are old. Both Haskell and Ocaml date from a time when UX expectations around language tooling were much lower (think C++.) The inertia around the projects never cared much for UX anyway so now in 2022 when languages like Rust and Go have raised the floor of expectation for PL tooling, Haskell and Ocaml struggle to keep up.
• jiggawatts 4y ago
  Most (all?) dependency management systems are single threaded and download thousands of tiny files one… at… a… time… I have gigabit internet and I’m lucky if some package manager can get more than a couple of megabits of throughput. Most industries would never accept less than 0.5% efficiency, but apparently software developers’ time is just too expensive to ever be “wasted” on frivolous tasks like optimisation. I kid, I kid. The real problem is that the guy developing the package manager tool has the package host server right next to him. Either the same building or even a dev instance on his own laptop. Zero latency magically makes even crappy serial code run acceptably well. “I can’t reproduce this issue. Ticket closed, won’t fix.”
• sandruso 4y ago
  The npm install experience should be baseline for newer languages. Simply let me get into hacking fast. This is one of the top reason I like tinkering with JS because it just works. (Yes, I know all weaknesses of JS ecosystem, but getting is really easy)
  • toastal 4y ago
    Please, no. Node tooling is such a mess and I can almost never get anything running easily on Nix because Node developers download binaries from the internet without understanding the system. All of these executables fail because of linked libraries. If instead they told you what libraries and executables you'd need instead loosy-goosy installing garbage all over my system, more things might work.
    • sandruso 4y ago
      Sure npm is not silver bullet. But I want the npm experience. Technical implementation can be improved as you say and I agree.
      • toastal 4y ago
        Then you should be a fan of Nix
  • intrasight 4y ago
    I do agree. I think .Net has got it right. And dotnet-script [https://github.com/dotnet-script/dotnet-script https://github.com/dotnet-script/dotnet-script] has been a game-changer for me with a REPL-like experience for unit testing and writing command-line utilities.
• thejosh 4y ago
  I'm really happy with Meson, as a lot of Wayland (the new display protocol for Linux, the "successor" of X11) apps seem to be built in C, so using meson is super simple and I don't have to worry about tooling (I don't deal much with C/C++, so let me make my change and run away please). Rust is the same, you can even define a nightly version if you want, so even the correct version is ran with rustup. It's fantastic, and I can contribute much easier to projects without worrying about tooling.
  • languageserver 4y ago
    > I don't deal much with C/C++ that is because there is no such thing.
    • bee_rider 4y ago
      C/C++ is just 1 in the limit, right?
      • xdavidliu 4y ago
        two things wrong with your statement: - the ++ operator only acts on integer types, not floats or doubles, so there is no limit to speak of here - the expression "C++" has value equal to C before incrementing, hence the expression "C/C++" is just one for positive C, even when C is small
        • bee_rider 4y ago
          So, luckily my mistakes cancel out -- C/C++ = 1 always, so it must also in the limit. Once we figure out how to define limit.
        • Iwan-Zotow 4y ago
          > the ++ operator only acts on integer types no, I believe it works on pointer types and enums as well
          • 4y ago
• dist1ll 4y ago
  Not only tooling is a problem. Name one FP language that I can use for high-performance and systems programming. Is there any one except ATS? And ATS is pretty hard (unlike C, C++ and Rust). I think it will take a while until linear & dependent type languages will hit mainstream. Rust already succeeded in that regard, so it's a great stepping stone.
  • skydhash 4y ago
    Most computers follows the Von Neumann architecture. Any imperative languages with no GC would do great because of the small number of abstractions needed to make a program run. AFAIK, C only requires to set up a stack with the registers. When we build something with lambda calculus as its core, you might want to revise that opinion.
    • docandrew 4y ago
      There’s some truth to this - imperative languages with state make sense because the underlying hardware is a series of imperative instructions and a large amount of state. What does lambda calculus hardware look like?
      • AndrewKemendo 4y ago
        Apparently it's called the "reduceron" https://www.cs.york.ac.uk/fp/reduceron/ https://www.cs.york.ac.uk/fp/reduceron/ https://www.cs.york.ac.uk/fp/reduceron/jfp-reduceron.pdf https://www.cs.york.ac.uk/fp/reduceron/jfp-reduceron.pdf
• munchler 4y ago
  I think F# has a good tooling story, since it's part of .NET and a first-class citizen in Visual Studio. It doesn't get as much love from Microsoft as C#, but it's still quite nice to use.
  • christophilus 4y ago
    Last time I used F# on Linux, the REPL was a mess and mostly unusable. Compilation takes forever. You have to edit an fsproj rather than inferring modules from the file system structure like most modern languages. It’s a great language— maybe my favorite, but the tooling stinks if you’re not using VS. I’m not switching to Windows, so that leaves me in limbo.
    • runevault 4y ago
      I'd argue Rider from Jetbrains is better than VS for F#, though that is a subscription based IDE (though you can stop paying and keep the version you originally "bought" after)
    • karmakaze 4y ago
      PSA: Visual Studio for Mac[0]. I know you're on Linux but for others. [0] https://visualstudio.microsoft.com/vs/mac https://visualstudio.microsoft.com/vs/mac
      • sk0g 4y ago
        And just for clarity, it's not proper Visual Studio, but rather an updated MonoDevelop. Was missing quite a lot of functionality (for Unity/C#) compared to VS, so I used Rider instead.
        • karmakaze 4y ago
          I didn't know Rider supported F#, thanks for the tip.
    • int_19h 4y ago
• agentultra 4y ago
  I think tsoding has the wrong idea here. Most mathematicians are not working on GHC or Haskell standards or even using Haskell. Most are still doing mathematics on pen and paper. Many use packages like Sage or Wolfram alpha. Few are using interactive theorem provers like Lean. Haskell is a poor language to be doing mathematics in. I’d say the majority of people working GHC are software developers and CS researchers. They’re a friendly bunch. What’s holding back tooling is that the developers of the de-facto compiler for Haskell are spread out amongst several organizations and there isn’t tens of millions of dollars funding their efforts. It’s mostly run by volunteers. And not the volume of “volunteers” you get on GCC or the like either. That makes GHC and Haskell quite impressive in my books. There are other factors of course but the tooling is improving bit by bit. The whole “Haskell is for research” meme needs to go into the dustbin.
  • exyi 4y ago
    I think he counts academic computer scientists more as mathematicians than developers.
    • agentultra 4y ago
      C++ and Java wouldn't be where they are without CS researchers, so I think the point still stands. These people aren't doing useless work. They're the ones making sure Concepts won't break the entire ecosystem and that have made the JVM the beast it is. Grit and determination will get you far but like it or not there is a ton of work that requires knowledge of mathematics and theory that you can't avoid if you want to make good things. What's kind of neat about Haskell is how closely researchers can work with users and collaborate on solutions. Remember, the GHC team is pretty small. Their IRC channel isn't huge. Releases still get made fairly regularly and GHC is running one of the most advanced industrial strength programming languages out there with a large ecosystem.
      • zamalek 4y ago
        > C++ and Java wouldn't be where they are without CS researchers, so I think the point still stands I'm not sure how you gleamed that they aren't important/haven't made important contributions/aren't doing useful work from that comment. Tsoding specifically said that they don't make good tooling, but make great languages. It's not memeing about "Haskell for research," it's talking about things it needs to improve (potentially to break free of that meme). For what it's worth, C++ tooling also sucks. We've just layered tons of kludges on top of it that make the ecosystem somewhat bearable. It's not ideal, contributing to a project for the first time usually requires some troubleshooting to get a working build.
• pera 4y ago
  That's interesting, I often find the tooling one of the best things that FP languages offer. In OCaml for instance I found Dune to be fantastic and extremely intuitive. Another very good experience I had was with Elixir and Hex. In Haskell I personally think that there are indeed quite a few things that could be improved around build system and packaging, but overall it's not really that bad once you learn the quirks.
  • zamalek 4y ago
    It would the OCaml community a great service if you wrote up a beginner's tutorial on working with Dune.
    • belmont_sup 4y ago
      I felt the small section on dune here was enough for me. https://ocaml.org/docs/up-and-running https://ocaml.org/docs/up-and-running Teaching anything beyond dune build or opam install feels out of place for a beginner tutorial. However, there really should be more examples of “how to do X in dune”. It took me a bit to learn how to pin a git repo for local use and installation.
• capableweb 4y ago
  > it is heavily influenced by FP Is it really? I agree with the rest of your post, that Rust provides great tooling, but not sure it's "heavily influenced by FP", at least that's not obvious even though I've been mainly writing Rust for the last year or so (together with Clojure). I mean, go through the "book" again (https://doc.rust-lang.org/book/ https://doc.rust-lang.org/book/) and tell me those samples would give you the idea that Rust is a functional language. Even the first "real" example have you mutating a String. Referential transparency would be one of the main point of functional programming in my opinion, and Rust lacks that in most places.
  • brmgb 4y ago
    Considering Rust pretty much started as a way to have a ML for system programming and was written in Ocaml, yes, I think it's fair to say it was heavily influenced by FP. It became less and less ML-like as time went on but it still as a ton of features it inherited from Ocaml and Haskell: variant types, pattern matching, modules, traits come directly from type classes, etc.
    • nequo 4y ago
      I think Rust is not particularly FP because it encourages using loops instead of recursion and “let mut” is quite idiomatic in my understanding. Those two characteristics are more relevant than the type system. For example, Scheme and Clojure don’t have type classes but are clearly FP because recursion and immutability are idiomatic. In Rust, even though it is true that .map, .fold, .filter, and .zip exist, first of all they also exist in Python, and second, they need to be sandwiched between .iter and .collect unless one is working with iterators which makes the code noisier and pushes the needle toward loops. The influence of OCaml and Haskell is clear though, and it makes the language more pleasant to use.
      • dllthomas 4y ago
        The claim was that Rust is "heavily influenced by FP"; I think that's clearly the case, while "Rust is FP" is probably not (which case you make pretty well).
• kitd 4y ago
  Tooling is why Go gets its foot in the door much quicker than other languages IMHO. A single binary with no dependencies that does pretty much everything.
  • bombolo 4y ago
    I've seen go programs fail to start because they were dynamically linked to some .so file I happened to not have.
    • anotherhue 4y ago
      Yeah ‘Fully static’ requires some extra linker flags.
    • layer8 4y ago
      They mean the `go` binary, not Go programs in general.
  • jonahx 4y ago
    Indeed. Also formatting decided at the language level (gofmt) and a standard library powerful enough to accomplish most business tasks, so you can avoid 3rd party dependencies entirely if you want, while still being productive.
• zelphirkalt 4y ago
  You gave up using a programming language after a day? And Haskell after installing/building some dependencies for 20mins? Tbh, this sounds like you were not really trying. What kind of experience with a programming language do you expect to have after a mere day? Learning takes time. Anyone might spew some not idiomatic code within a day, but really becoming proficient usually takes longer. Do you have any references for the "Rust is heavily influenced by FP" thing? To me it does not feel that much FP. I have (for now) given up writing FP like code in Rust. ML-influence -- Yeah maybe, if I squint a bit.
  • DonaldPShimoda 4y ago
    > Do you have any references for the "Rust is heavily influenced by FP" thing? To me it does not feel that much FP. The original implementation of Rust was in an ML dialect (I think OCaml?), so from that we know immediately that the original authors were familiar with FP and used it for their own purposes. It seems odd, then, to assume that there would be no influence of their own language. But if we look at the actual feature set, we find a lot of things that previously belonged almost entirely to the realm of FP. The type system as a whole has a fairly FP feel, plus algebraic data types, exhaustive structural pattern matching, maps and folds, anonymous functions, the use of the unit value for side-effecting work, the functioning of the semicolon operator (which is identical to the OCaml usage)... there's quite a lot, and those were just the examples off the top of my head!
    • steveklabnik 4y ago
      (It was OCaml, yes)
    • momentoftop 4y ago
      Yep, though it's got type-classes specifically from Haskell.
  • orf 4y ago
    > What kind of experience with a programming language do you expect to have after a mere day? Learning takes time. It does, which is why you need tooling to get out of the way and let you actually learn. Working out obscure tooling commands to build a hello world app then having to grok the error messages absolutely destroys the learning loop. For rust it took me approximately 3 minutes from scratch to install, bootstrap a project and run the hello world CLI. The rest of the day was spent purely, 100% learning rust. Not Cargo. 20 minutes to install some beginner level dependencies, presumably with little feedback as to what is going in? Dead.
• karmakaze 4y ago
  The only problem I had with tooling using F# was getting my dev env set up. The only help I need from the editor was navigating between classes/functions and build/run. Even refactoring was easier because the types are sometimes left to be inferred and not named everywhere. The type inference in F# being weaker also even helps with both compile speed and readability where annotations are needed both to help the compiler and the reader. Perhaps on larger projects other things become important, but I got the sense that it's on the devs to name things well, use type annotations where helpful, and otherwise document non-obvious aspects.
• deleted 4y ago
  [deleted]
• Shorel 4y ago
  As someone who likes both mathematics and programming, I find this comment and the article too divisive for divisiveness’ sake. Programming is applied mathematics. An assignment is not 'sloppy' like the article posts, it is just another kind of operation that can be done. A proof is very much like programming, except you are also the parser, the compiler, and the (comparatively slow) computer. Learning to write proofs helps immensely with learning how to program. We should strive to make our proofs and programs easier to understand, no matter the paradigm.
• hamandcheese 4y ago
  There are plenty of non-academic languages with tooling issues as well. I think the larger issue is simply if the language has significant usage in a large corporation who can sponsor tooling development, or not. Most tooling issues are pretty minor for small apps, it’s once one employs scores of developers that the lack of tooling begins to hurt (and by hurt, I mean cost money).