3 ms·

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 simu

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 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). There are many types of applications where functional languages are perfect, but there are more that it would be a disaster. To make broad sweeping claims, such as this article, just encourages unnecessary discourse, and shows the ignorance of the author, and his limited understanding of the domain of problems that functional languages will benefit from, and the larger domain of problems that will not benefit from them. As an employer, I don't hire people for their functional programming skills. If they have them, the better, but we have over 3 millions lines of code in C++, and close to a million in Java. We are not starting over, and new projects will leverage existing code.

thrown_22 4y ago
>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.
- deviantbit 4y ago
  Then try it.
- mikedelago 4y ago
  Common lisp has a "pretty OK" story for calling C code whenever some speed is needed [0,1]. In my opinion, they suffer from some of the documentation/quick start problems that common lisp has, but they're otherwise usable. Some of Naughty Dog's late 90's/early 2000's games (Jak and Daxter, Jak II) were written in a lisp called GOAL, Game Oriented Assembly Lisp [2] [0] https://github.com/rpav/cl-autowrap https://github.com/rpav/cl-autowrap [1] https://github.com/cffi/cffi#cffic2ffi https://github.com/cffi/cffi#cffic2ffi [2] https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp
ParetoOptimal 4y ago
> In fact, I challenge you to develop a first-person shooter in Haskell (Have fun). https://hackage.haskell.org/package/frag https://hackage.haskell.org/package/frag > There are many types of applications where functional languages are perfect, but there are more that it would be a disaster. Can you give an example or two of an application in a functional language would be a disaster? > To make broad sweeping claims, such as this article, just encourages unnecessary discourse, and shows the ignorance of the author, and his limited understanding No, it's an opposing viewpoint to the popular "right tool for the job" and "take the best from functional, best from imperative, and smash them together". See "The curse of the excluded middle by Erik Meijer". > As an employer, I don't hire people for their functional programming skills. I certainly choose my jobs with language and ecosystem in mind.
- deviantbit 4y ago
  frag-1.1.2 failed during the building phase. The exception was: ExitFailure 1 Go fix that for us. ``Can you give an example or two of an application in a functional language would be a disaster?`` Sure, code that tests its self. Not happening. Which means, most embedded applications where fault tolerance is a must. If you don't know what caused the error, well, lets here your ignorant response. Explain how you trap those problems in a functional language, and do it as simple as you can, say in C, or Pascal. ``opposing viewpoint to the popular "right tool for the job"`` So you advocate a hammer for screw. Got it. You're exactly the kinda of person I won't hire. You're so bent on proving you're right, you ignore the right tool for the right job.
  - tome 4y ago
    > frag-1.1.2 failed during the building phase. The exception was: ExitFailure 1 > > Go fix that for us. Isn't there an error message just above saying that you need to install the development version of the GL library? Fix it yourself; we can't! Granted, that error message could be made easier to read.

thrown_22 4y ago

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

deviantbit 4y ago
Then try it.
mikedelago 4y ago
Common lisp has a "pretty OK" story for calling C code whenever some speed is needed [0,1]. In my opinion, they suffer from some of the documentation/quick start problems that common lisp has, but they're otherwise usable. Some of Naughty Dog's late 90's/early 2000's games (Jak and Daxter, Jak II) were written in a lisp called GOAL, Game Oriented Assembly Lisp [2] [0] https://github.com/rpav/cl-autowrap https://github.com/rpav/cl-autowrap [1] https://github.com/cffi/cffi#cffic2ffi https://github.com/cffi/cffi#cffic2ffi [2] https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp

ParetoOptimal 4y ago

> In fact, I challenge you to develop a first-person shooter in Haskell (Have fun). https://hackage.haskell.org/package/frag https://hackage.haskell.org/package/frag > There are many types of applications where functional languages are perfect, but there are more that it would be a disaster. Can you give an example or two of an application in a functional language would be a disaster? > To make broad sweeping claims, such as this article, just encourages unnecessary discourse, and shows the ignorance of the author, and his limited understanding No, it's an opposing viewpoint to the popular "right tool for the job" and "take the best from functional, best from imperative, and smash them together". See "The curse of the excluded middle by Erik Meijer". > As an employer, I don't hire people for their functional programming skills. I certainly choose my jobs with language and ecosystem in mind.

deviantbit 4y ago
frag-1.1.2 failed during the building phase. The exception was: ExitFailure 1 Go fix that for us. ``Can you give an example or two of an application in a functional language would be a disaster?`` Sure, code that tests its self. Not happening. Which means, most embedded applications where fault tolerance is a must. If you don't know what caused the error, well, lets here your ignorant response. Explain how you trap those problems in a functional language, and do it as simple as you can, say in C, or Pascal. ``opposing viewpoint to the popular "right tool for the job"`` So you advocate a hammer for screw. Got it. You're exactly the kinda of person I won't hire. You're so bent on proving you're right, you ignore the right tool for the right job.
- tome 4y ago
  > frag-1.1.2 failed during the building phase. The exception was: ExitFailure 1 > > Go fix that for us. Isn't there an error message just above saying that you need to install the development version of the GL library? Fix it yourself; we can't! Granted, that error message could be made easier to read.