4 ms·

Thanks for sharing and Kudos for TypeScript! This question is not aimed at you and certainly not at your work. I used to be a game developer from an OOP backgr

Thanks for sharing and Kudos for TypeScript! This question is not aimed at you and certainly not at your work. I used to be a game developer from an OOP background. I find this really hard to read. https://github.com/thi-ng/umbrella/blob/master/examples/hdom-canvas-draw/src/index.ts https://github.com/thi-ng/umbrella/blob/master/examples/hdom... Would anyone be able to give 2 cents about where the industry is headed in this regard? Will I be looked down on that my codebase is OOP in the future? Also for those who were cut from my cloth, did you find the transition difficult?

toxmeister 8y ago
Thanks & I used to do 12+ years of Java and other OOP languages myself before I started using Clojure in 2011 and ever since got hooked on the more functional approach without trying to become a fundamentalist FP. These days I'm mainly using TS, Clojure/ClojureScript, Go, C (not C++)... Re: the above example - you didn't really explain which aspects you find alienating, but finding this hard to read, could have to do with the fact that this demo uses a few other concepts & libs not very popular in the JS world (specifically transducers)? I totally grant that without prior knowledge of those constructs this specific code is not the easiest to comprehend (though I've tried to comment every step). In general though, IMHO this approach is a lot more direct and lightweight than any OOP solution. Having your entire UI defined using native ES6 primitve data structures, provides huge potential and endless options to transform raw app state into UI components. If you ever worked with a Lisp, you'll also find the nested inline definitions not that hard to read. To me it's also more legible than having an (often) over-engineered, multi-layered OOP architecure, riddled with inheritance and so on... Though again, this all is highly subjective. There's certainly ample opportunity to refactor this example into smaller functions and I might as well do that when I get a chance...
pjmlp 8y ago
Not at all. All successful mainstream languages have embraced a mix of OOP and FP. OOP is not a synomim for Java and C++ way of programming with classes. There are other ways of doing OOP, even all those map/filter/fold patterns were already present in Smalltalk. I learned OOP with Turbo Pascal 5.5, followed by C++, Clipper, Smalltalk, Eiffel, Oberon, Component Pascal, and many others. Parallel to that, also SWI Prolog, Lisp and Caml Light as introduction to other paradigms. It helps to keep an open mind, and approach learning by thinking about paradigms in abstract and not getting too focused on language details.
groovy2shoes 8y ago
I have no idea where the industry is headed, but I feel rather confident that there will always be some group of people that will find some reason to look down on your codebase. If you rewrote the whole thing in state-of-the-art FP tonight, then by morning there will be some contingent of zealous logic programmers with their noses turnt up. Don't worry about being looked down on. Worry about improving yourself as our field figures out how we can improve our craft. There's a lot of noise, which makes it hard to tell which things offer the most improvement, but knowledge is never a setback. You will never learn something new and be worse off than you were before. And learning something new doesn't require you to rewrite your codebase to use it, either—of course, you can if you so chose, but that's not a decision you can make until you've grokked the newness ;) As for the difficulty of the transition: I didn't find it difficult, but I also had the luxury of time. I think it could potentially be difficult for someone thrown into the deep end (e.g., "go into the `hdom-canvas-draw` example and implement new features X, Y, and Z by Thursday!"). People often talk about FP being a different way of thinking about programming. That's true to some extent, but it's not entirely different from what you're used to. I think the thing that seems strangest for newcomers to FP isn't the way of thinking, it's the terminology. Names like `filter`, `map`, `mapcat`, `partition`, &c. seem odd and incomprehensible at first. But they're just operators, like `add`, `multiply`, `insert`, `append`. They're the kind of operator that make functional programming functional: they operate (at least in part) on functions. If FP is something you want to learn, my advice is to start slow and simple. Some people can probably dive into that example code, tear it apart, figure out how it works, and learn that way. Perhaps I could if I were motivated enough, I don't know. What I do know is that I can't be arsed to do something like that. It's frustrating. Annoying. I have better things to do with my time. The common advice is Abelson & Sussman's «Structure and Interpretation of Computer Programs», which is pretty good, though it has some problems. Felleisen & al. wrote «How to Design Programs» to address some problems with SICP, and wound up introducing even more problems. The choice between those two boils down to whether you want a book that addresses you like a 13-year-old with a good grasp of the infinitesimal calculus (SICP) or one that addresses you like an 11-year-old that barely understands elementary algebra (HtDP). Personally, I rather like Paulson's «ML for the Working Programmer», which assumes you're an adult who probably doesn't hold a degree in mathematics. Unfortunately, it's not freely available like the other two. If you decide to go with SICP, I recommend using either MIT Scheme or Racket with sicp mode (you can install the mode through the menus in the DrRacket IDE). For MLftWP, I'd recommend using PolyML (any Standard ML implementation compatible with the revised definition will work fine, but PolyML is actively maintained and easy to set up). From there, you should be pretty versed in the foundations of FP, and it's just a matter of practice to get comfortable. Of course, there will always be more to learn—the student may never rest :) ETA - My best advice would be this: if you have the money and the time, read both the Paulson book and SICP; if you have the money but not the time, read the Paulson book; if you don't have the money, read SICP, which you can find in many formats on the Web (it's CC BY-SA licensed). I would not recommend HtDP to a professional programmer, and only maybe to a neophyte.

toxmeister 8y ago

Thanks & I used to do 12+ years of Java and other OOP languages myself before I started using Clojure in 2011 and ever since got hooked on the more functional approach without trying to become a fundamentalist FP. These days I'm mainly using TS, Clojure/ClojureScript, Go, C (not C++)... Re: the above example - you didn't really explain which aspects you find alienating, but finding this hard to read, could have to do with the fact that this demo uses a few other concepts & libs not very popular in the JS world (specifically transducers)? I totally grant that without prior knowledge of those constructs this specific code is not the easiest to comprehend (though I've tried to comment every step). In general though, IMHO this approach is a lot more direct and lightweight than any OOP solution. Having your entire UI defined using native ES6 primitve data structures, provides huge potential and endless options to transform raw app state into UI components. If you ever worked with a Lisp, you'll also find the nested inline definitions not that hard to read. To me it's also more legible than having an (often) over-engineered, multi-layered OOP architecure, riddled with inheritance and so on... Though again, this all is highly subjective. There's certainly ample opportunity to refactor this example into smaller functions and I might as well do that when I get a chance...

pjmlp 8y ago

Not at all. All successful mainstream languages have embraced a mix of OOP and FP. OOP is not a synomim for Java and C++ way of programming with classes. There are other ways of doing OOP, even all those map/filter/fold patterns were already present in Smalltalk. I learned OOP with Turbo Pascal 5.5, followed by C++, Clipper, Smalltalk, Eiffel, Oberon, Component Pascal, and many others. Parallel to that, also SWI Prolog, Lisp and Caml Light as introduction to other paradigms. It helps to keep an open mind, and approach learning by thinking about paradigms in abstract and not getting too focused on language details.

groovy2shoes 8y ago

I have no idea where the industry is headed, but I feel rather confident that there will always be some group of people that will find some reason to look down on your codebase. If you rewrote the whole thing in state-of-the-art FP tonight, then by morning there will be some contingent of zealous logic programmers with their noses turnt up. Don't worry about being looked down on. Worry about improving yourself as our field figures out how we can improve our craft. There's a lot of noise, which makes it hard to tell which things offer the most improvement, but knowledge is never a setback. You will never learn something new and be worse off than you were before. And learning something new doesn't require you to rewrite your codebase to use it, either—of course, you can if you so chose, but that's not a decision you can make until you've grokked the newness ;) As for the difficulty of the transition: I didn't find it difficult, but I also had the luxury of time. I think it could potentially be difficult for someone thrown into the deep end (e.g., "go into the `hdom-canvas-draw` example and implement new features X, Y, and Z by Thursday!"). People often talk about FP being a different way of thinking about programming. That's true to some extent, but it's not entirely different from what you're used to. I think the thing that seems strangest for newcomers to FP isn't the way of thinking, it's the terminology. Names like `filter`, `map`, `mapcat`, `partition`, &c. seem odd and incomprehensible at first. But they're just operators, like `add`, `multiply`, `insert`, `append`. They're the kind of operator that make functional programming functional: they operate (at least in part) on functions. If FP is something you want to learn, my advice is to start slow and simple. Some people can probably dive into that example code, tear it apart, figure out how it works, and learn that way. Perhaps I could if I were motivated enough, I don't know. What I do know is that I can't be arsed to do something like that. It's frustrating. Annoying. I have better things to do with my time. The common advice is Abelson & Sussman's «Structure and Interpretation of Computer Programs», which is pretty good, though it has some problems. Felleisen & al. wrote «How to Design Programs» to address some problems with SICP, and wound up introducing even more problems. The choice between those two boils down to whether you want a book that addresses you like a 13-year-old with a good grasp of the infinitesimal calculus (SICP) or one that addresses you like an 11-year-old that barely understands elementary algebra (HtDP). Personally, I rather like Paulson's «ML for the Working Programmer», which assumes you're an adult who probably doesn't hold a degree in mathematics. Unfortunately, it's not freely available like the other two. If you decide to go with SICP, I recommend using either MIT Scheme or Racket with sicp mode (you can install the mode through the menus in the DrRacket IDE). For MLftWP, I'd recommend using PolyML (any Standard ML implementation compatible with the revised definition will work fine, but PolyML is actively maintained and easy to set up). From there, you should be pretty versed in the foundations of FP, and it's just a matter of practice to get comfortable. Of course, there will always be more to learn—the student may never rest :) ETA - My best advice would be this: if you have the money and the time, read both the Paulson book and SICP; if you have the money but not the time, read the Paulson book; if you don't have the money, read SICP, which you can find in many formats on the Web (it's CC BY-SA licensed). I would not recommend HtDP to a professional programmer, and only maybe to a neophyte.