Functional programming should be the future of software • Hacker News Board

Re: Functional programming should be the future of software

#131

Post by thrown_22 » Wed, Nov 02, 2022, 1:39 PM UTC

deviantbit wrote: post #126

I believe functional programming is interesting, and fun. But it is not going to replace the world. My background has spanned from working on AAA games, to simulations for the DoE, to owning my own business developing embedded products, and graduate school (yes, I went back as a gray haired, and did that late). I fell in love with Lisp many years ago on a TI Explorer. Functional languages are inherently difficult to…

>Functional languages are inherently difficult to develop applications that require state to change in non-deterministic ways. In fact, I challenge you to develop a first-person shooter in Haskell (Have fun).

Don't know about Haskell but it would be very fun to do it in Lisp.

Performance sold separately.

Re: Functional programming should be the future of software

#132

Post by Communitivity » Wed, Nov 02, 2022, 1:39 PM UTC

alanwreath wrote: post #111

kstenerud wrote: post #57

I immediately distrust any article that makes sweeping claims about one-paradigm-to-rule-them-all. The reason why multiple paradigms exist is because here in the real world, the competing issues and constraints are never equal, and never the same. A big part of engineering is navigating all of the offerings, examining their trade-offs, and figuring out which ones fit best to the system being built in terms of constra…

>> navigating all of the offerings, examining their trade-offs the amount of time you're afforded for that exercise better fit neatly inside a very small window of implementation (in other words you're probably not going to do it, or at least do it justice) >> figuring out which ones fit best to the system being built in terms of constraints constraints will always get ya. It always ends up to being what is the tool/…

To any leads reading this,

>>> navigating all of the offerings, examining their trade-offs

>> the amount of time you're afforded for that exercise better fit neatly inside a very small window of implementation (in other words you're probably not going to do it, or at least do it justice)

Every project I have worked that has done a gap analysis has executed faster and smoother than those that didn't. A gap analysis being a more rigorous approach to an analysis of tradeoffs, solution capabilities vs requirements/existing software, and sometimes scoring/ranking (often with three recommended options depending on client's choices in tradeoffs).

Re: Functional programming should be the future of software

#133

Post by metaltyphoon » Wed, Nov 02, 2022, 1:39 PM UTC

brmgb wrote: post #119

photochemsyn wrote: post #82

Hybridization of object-oriented and functional approaches seems like a decent approach to theses problems. > "Nearly all modern programming languages have some form of null references, shared global state, and functions with side effects..." Which is to say, code is organized into discrete classes, instantiated as objects, but those objects only use the functional paradigm with respect to their bound functions, i.e.…

Someone should bolt object-oriented features on top a functional programming language to see what it would look like. That would be an interesting research project. They could call it O- something and do a pun with an animal name.

Don’t need to, look at F#. Its functional first and OO is bolted on.

Re: Functional programming should be the future of software

#134

Post by kstenerud » Wed, Nov 02, 2022, 1:40 PM UTC

tylerdinner wrote: post #103

kstenerud wrote: post #57

I immediately distrust any article that makes sweeping claims about one-paradigm-to-rule-them-all. The reason why multiple paradigms exist is because here in the real world, the competing issues and constraints are never equal, and never the same. A big part of engineering is navigating all of the offerings, examining their trade-offs, and figuring out which ones fit best to the system being built in terms of constra…

Totally agree. As a Javascript dev I got functional code pushed on me in 2016. It's definitely good practice for devs to learn some of the pitfalls that FP prevents and solves, but implementing it on a massive scale front-end application just seems impractical. Having worked on a large streaming service and considering the author's 3 MONTH struggle after his 40 YEARS experience, I'd estimate that a re-write of our co…

I'm actually all for the FP things that have been added to imperative languages, which increase their power tremendously and make a lot of tasks a helluva lot easier. But like any tool, it has its place. I'd be equally leery of a pure imperative solution as I would be a pure FP solution.

Re: Functional programming should be the future of software

#135

Post by shubhamjain » Wed, Nov 02, 2022, 1:40 PM UTC

pessimizer wrote: post #120

shubhamjain wrote: post #112

Functional programming proponents like the blog's author remind of Linux users who sweared by it as a user-friendly OS, thought of everyone else as idiots, and refused to admit its serious flaws as a general-purpose OS. I am not criticizing FP. It has great ideas and many of them have been actively borrowed into other languages. But it's just annoying to see bad analogies that get repeated again and again, like these…

Did you mean to comment on the analogies you quoted other than to say that they are often used? Is being useful a problem for an analogy? > But in most of today’s programming languages, x = x + 1 is not an equation. It is a statement that commands the computer to take the value of x, add one to it, and put it back into a variable called x. This is on page 1 of every basic programming book when it's explaining how "va…

They are stupid because they don't address the fact that most procedural languages themselves have features to prevent re-assignments and mutable states (like, const). Also, variables reflect the state of the program, while microwave settings are inputs. The switching of settings doesn't make a whole lot of sense.

> This is on page 1 of every basic programming book when it's explaining how "variable" differs between math class and programming class. I can't for the life of me see what upsets you about it.

I never had a problem grasping the concept. I never equated "=" in programming to "=" in Math. It's just a symbol. Replacing "=" with "<-" would mean the same thing.

Re: Functional programming should be the future of software

#136

Post by thrown_22 » Wed, Nov 02, 2022, 1:41 PM UTC

kstenerud wrote: post #57

I immediately distrust any article that makes sweeping claims about one-paradigm-to-rule-them-all. The reason why multiple paradigms exist is because here in the real world, the competing issues and constraints are never equal, and never the same. A big part of engineering is navigating all of the offerings, examining their trade-offs, and figuring out which ones fit best to the system being built in terms of constra…

Tooling. Tooling is the major reason why no one uses functional programming languages in industry. I was very into Haskell a decade ago. Today I don't even know where to start when it comes to installing a new package. If Debian doesn't have it in their repos I usually just try building it from source and hope make all works. If it doesn't. Well I probably didn't need that package anyway.

Re: Functional programming should be the future of software

#137

Post by chriswarbo » Wed, Nov 02, 2022, 1:42 PM UTC

Ciantic wrote: post #106

Lot of the time arguments for Functional Programming seem to describe some form of total programming and avoiding partial functions. Like enforcing null checking or exhaustive matching, avoiding panics etc. When I was going through Functional Programming classes in Haskell, the teacher tried to separate total programming and functional programming. For instance Rust programs rarely use function composition compared t…

Totality can be split into two separate properties:

- All programs are defined for all inputs (exhaustive)

- All programs terminate/coterminate

The former is becoming more common (like your Rust example), but the latter isn't very widespread. For example, most would consider a function like this to be exhaustive, even though it loops forever when both Ints are non-zero:

  foo : (Int, Int) -> Int
  foo (0, y) = y
  foo (x, y) = foo (y, x)

Proving termination is hard, and often undesirable; e.g. we want servers and operating systems to keep running indefinitely. However, co-termination can be quite easy, e.g. if we define a Delay (co)datatype:

  data Delay t where
    Now   : t -> Delay t
    Later : Delay t -> Delay t

Wrapping recursive calls in 'Later' allows infinite processes, at the cost of some boilerplate (Delay is a monad, if you know what that is):

  foo : (Int, Int) -> Delay Int
  foo (0, y) = Now y
  foo (x, y) = Later (foo (y, x))

Re: Functional programming should be the future of software

#138

Post by karmakaze » Wed, Nov 02, 2022, 1:43 PM UTC

stiiv wrote: post #118

munchler wrote: post #63

Earlier quoted context omitted.

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.

After learning a bunch of programming languages and their corresponding ecosystems (incl. Rust, Lisps, Scala), F# is still my favorite by a long shot. Its only serious shortcoming, imo, is the tooling. Visual Studio is great, but if you're not on Windows, your only practical choices are VS Code + Ionide (I was a sponsor for a while; ultimately lost hope), or JetBrains Rider, which is powerful, but heavy. Comparing my…

I used Visual Studio on macOS for some small F# projects and it worked fine. The only trouble I had was with some setup instructions being spotty because there was a shift in how things were done in recent versions at the time a few years back.

Re: Functional programming should be the future of software

#139

Post by dec0dedab0de » Wed, Nov 02, 2022, 1:44 PM UTC

I don't know any purely functional languages[], so my viewpoint is skewed here. Whenever I have seen a python developer drink the functional kool-aid they end up either storing state in global variables, environment variables or in a dictionary they end up passing to every function. I then have to explain to them that passing a dictionary around and expecting variables to be in it is just half-assed OOP.

My rule of thumb is anything that needs state should be in a class, and anything that can be run without state or side effects should be a function. It is even good to have functions that use your classes, as long as there is a way to write them with a reasonable set of arguments. This can let you use those functions to do specific tasks in a functional way, while still internally organizing things reasonably for the problem at hand.

The minute people start trying to force things to be all functional or all OOP, then you know they've lost the plot.

[] I have been wanting to learn lisp for over a decade, I just never get around to it.

Re: Functional programming should be the future of software

#140

Post by karmakaze » Wed, Nov 02, 2022, 1:45 PM UTC

christophilus wrote: post #83

munchler wrote: post #63

Earlier quoted context omitted.

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.

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.

PSA: Visual Studio for Mac[0]. I know you're on Linux but for others.

[0] https://visualstudio.microsoft.com/vs/mac