5 ms·

Learn a functional programming language. This has had the most impact on the way I think about systems by far. The biggest impact was realizing all of the time

Learn a functional programming language. This has had the most impact on the way I think about systems by far. The biggest impact was realizing all of the time I've spent trying to master all of the OOP acronyms hasn't paid off. I've also realized that OOP might be meant for a type of programming that I don't do (video game logic? device drivers?), where as FP seems to fit great for Web applications that are just wrapping databases and spitting out HTML or JSON. As for FP languages for a starter, I'd recommend any of Erlang/Elixir, Clojure or Scala (only for its FP features and great learning resources)

prometheuspk 12y ago
Would you say that FP itself (not the thought process it generates) would benefit me in mobile application devlopment. It's mostly gaining data and then setting it.
- platz 12y ago
  FP has been hard to realize on mobile mostly due to the limited choice of languages available.
  - rubiquity 12y ago
    Yeah, I agree with this. However, I could still see a lot of merit in writing the server that the mobile application talks to in an FP language.
  - seanponeil 12y ago
    RxJava brings lot of FP idioms to Android, and it's great
- rubiquity 12y ago
  Intentionally or not, the thought process FP languages generates will creep its way into your programs, and then probably into the way you would write object-oriented programs.
- jimbokun 12y ago
  Are you developing for iOS? Swift seems to introduce a lot of FP concepts.
  - prometheuspk 12y ago
    Mostly Android. I was thinking about maybe using Scala just to make something meaningful while learning FP.
- ufo 12y ago
  I would say that the main benefits of FP programming are 1. Its easier to define your own abstractions in libraries. Even advanced stuff like async programming can often be put on a library. 2. Languages like Haskell and OCaml have really cool type systems. Its a killer feature, IMO. I wouldn't put that much emphasis on the purity aspect. In Haskell the reason for the purity to allow for lazyness and similar languages (Ocaml, F#, etc) are perfectly OK with strict evaluation and mutation. That said, for mobile apps having a language that operates well with the rest of the ecosystem is probably a bigger concern. Its easier to choose your own language when you have more control over the running environment.
ams6110 12y ago
Erlang especially, it comes out of the box with OTP, so you don't really need to invent anything or have advance knowledge of design principles. Learn OTP, do things the OTP way. I recommend Erlang and OTP in Action by Logan, Merritt, and Carlsson. I've also heard that Joe Armstrong's latest book is really good. You can also work through the "Learn you some Erlang" exercises online.
- angersock 12y ago
  Seconding Erlang, and the pirate book (OTP in action; dude on cover looks like a pirate, maybe a Janissary). The thing about Erlang/OTP isn't just that it's a functional language, but that--for a beginner--it's very small and practical. I describe it as "a functional language written by people whose jobs depended on it". OTP (effectively, production runtime library and development patterns) is built on really sound engineering principles, and you can learn a lot from the explanation of why you build things a particular way while reading the pirate book. EDIT: The main reason that the functional aspects of Erlang are so cool when contrasted with Haskell or Scala or whatever is that they are so deeply tied into how the language functions in a production setting. It's not a matter of "my, how clever", but more of "oh, that makes implementing this reilably a shit-ton simpler". As an example: actors in Erlang (processes there) are implemented as side-effect free functions which accept messages and manually pass state around. As a consequence, we get code hot-loading for free--you can simply swap out the update functions and run a helper to update the actor state before resuming it's run cycle using the new update function. That's wicked cool, and is something that just falls out from the pragmatic language decisions made earlier in its history.
sergiosgc 12y ago
I had pretty much the same experience when learning functional programming. However, I don't think it was functional programming per se that caused a jump in my ability to design software. It was the exposure to a dual perspective. The difference is subtle but important. You need to master imperative programming for the exposure to functional to produce a evolution. You can probably get the same effect in the reverse path (functional first, imperative next) but it's quite uncommon as a learning path. The same reasoning leads me to advise exposure to logic languages (prolog and the like), to compiler design (a complex state machine) and to a complete algebraic abstraction (relational algebra is probably the best candidate). Each will bring into your toolbox an important top level tool, no matter which paradigm you use at any moment in your life.

prometheuspk 12y ago

Would you say that FP itself (not the thought process it generates) would benefit me in mobile application devlopment. It's mostly gaining data and then setting it.

platz 12y ago
FP has been hard to realize on mobile mostly due to the limited choice of languages available.
- rubiquity 12y ago
  Yeah, I agree with this. However, I could still see a lot of merit in writing the server that the mobile application talks to in an FP language.
- seanponeil 12y ago
  RxJava brings lot of FP idioms to Android, and it's great
rubiquity 12y ago
Intentionally or not, the thought process FP languages generates will creep its way into your programs, and then probably into the way you would write object-oriented programs.
jimbokun 12y ago
Are you developing for iOS? Swift seems to introduce a lot of FP concepts.
- prometheuspk 12y ago
  Mostly Android. I was thinking about maybe using Scala just to make something meaningful while learning FP.
ufo 12y ago
I would say that the main benefits of FP programming are 1. Its easier to define your own abstractions in libraries. Even advanced stuff like async programming can often be put on a library. 2. Languages like Haskell and OCaml have really cool type systems. Its a killer feature, IMO. I wouldn't put that much emphasis on the purity aspect. In Haskell the reason for the purity to allow for lazyness and similar languages (Ocaml, F#, etc) are perfectly OK with strict evaluation and mutation. That said, for mobile apps having a language that operates well with the rest of the ecosystem is probably a bigger concern. Its easier to choose your own language when you have more control over the running environment.

ams6110 12y ago

Erlang especially, it comes out of the box with OTP, so you don't really need to invent anything or have advance knowledge of design principles. Learn OTP, do things the OTP way. I recommend Erlang and OTP in Action by Logan, Merritt, and Carlsson. I've also heard that Joe Armstrong's latest book is really good. You can also work through the "Learn you some Erlang" exercises online.

angersock 12y ago
Seconding Erlang, and the pirate book (OTP in action; dude on cover looks like a pirate, maybe a Janissary). The thing about Erlang/OTP isn't just that it's a functional language, but that--for a beginner--it's very small and practical. I describe it as "a functional language written by people whose jobs depended on it". OTP (effectively, production runtime library and development patterns) is built on really sound engineering principles, and you can learn a lot from the explanation of why you build things a particular way while reading the pirate book. EDIT: The main reason that the functional aspects of Erlang are so cool when contrasted with Haskell or Scala or whatever is that they are so deeply tied into how the language functions in a production setting. It's not a matter of "my, how clever", but more of "oh, that makes implementing this reilably a shit-ton simpler". As an example: actors in Erlang (processes there) are implemented as side-effect free functions which accept messages and manually pass state around. As a consequence, we get code hot-loading for free--you can simply swap out the update functions and run a helper to update the actor state before resuming it's run cycle using the new update function. That's wicked cool, and is something that just falls out from the pragmatic language decisions made earlier in its history.

sergiosgc 12y ago

I had pretty much the same experience when learning functional programming. However, I don't think it was functional programming per se that caused a jump in my ability to design software. It was the exposure to a dual perspective. The difference is subtle but important. You need to master imperative programming for the exposure to functional to produce a evolution. You can probably get the same effect in the reverse path (functional first, imperative next) but it's quite uncommon as a learning path. The same reasoning leads me to advise exposure to logic languages (prolog and the like), to compiler design (a complex state machine) and to a complete algebraic abstraction (relational algebra is probably the best candidate). Each will bring into your toolbox an important top level tool, no matter which paradigm you use at any moment in your life.