8 ms·

At this day and age people should be familiar with multiple paradigms. Whether procedural, functional, or Object-Oriented they are all useful. This is why you s

At this day and age people should be familiar with multiple paradigms. Whether procedural, functional, or Object-Oriented they are all useful. This is why you see languages like C++, Java, and C# adding support for them all. It is useful to express a particular problem domain in a way that is efficient and makes sense. I would be more interested in a discussion about concurrency because it becomes more relevant across the programming-language or paradigm barrier. Because at the end of the day we are confined by how the hardware operates and concurrency is very much a modern way of thinking as developers.

TheRealPomax 10y ago
realist contrarian question: why? If you didn't receive a formal education but you got good at OOP js or php, your expected salary gets pretty close to six figures. No understanding or even theoretical appreciation of other paradigms required. And I say that as someone with a formal education in programming and decent understanding of most programming paradigms.
- ebbv 10y ago
  If you are a professional developer you should always be learning and growing your skill set. You don't have to learn about functional programming, but choosing to remain ignorant does not reflect well on you. There's a difference between learning about it and using it at work. Your job may not have any good opportunities to apply FP, but you should be learning about it in your spare time given how many great use cases it has in today's world.
  - TheRealPomax 10y ago
    the real world does not particularly line up with that statement. For a fast moving contract based world, sure, but there's also the other part of the programming landscape where codebases need to be maintained forever for institutions and large companies whose idea of stable is even stricter than OpenBSD. I know plenty of people who work on both, and the second category gets paid very good money indeed to be the sole maintainers of complex codebases, with zero need or intention to learn new approaches because it won't let them do their job any better. Does that make them less likely to get a new job? sure, unless their new job still uses the language they use right now, which when you have 20 years of experience tends to not happen - other big companies and institutions will hire you on the spot. But a more important question is: will they even get to a point where they will need to look for a new job before retiring? Chances of that are roughly zero.
    - ebbv 10y ago
      I'm not sure how your response applies to my comment? I said that your particular job may not provide an opportunity for FP but you should still learn it for the sake of professional development. Even if you never need a job that uses FP, you should understand it so that you understand why you don't need it in your job. Even if you never leave your job, having those skills will help you push for a raise and move you ahead in your field. And chances are even if your job doesn't need it now, unless you're already near retirement, eventually there will be a case where maybe it is applicable.
      - TheRealPomax 10y ago
        And my response is still "why should they"? Mind you, that's in part because of the ambiguity of the term "should": are you using the "should, as in nice to do but not required" or "should, as in required, and not doing it is wrong", because I'm on board with the first, but that is not how the original comment reads. That reads more like everyone should be familiar with multiple paradigms and not following that rule is bad. Which the real world heavily disputes.
        ebbv 10y ago
        I think it's pretty clear from my comment that I'm saying should in the same sense as you should not smell like a dumpster on a hot day and you should be nice to work with. Technically it's not required, but if you don't then you're lazy and probably not a great employee.
        mannykannot 10y ago
        If this discussion is about the use of the word "should", then it has been a waste of time.
    - johncolanduoni 10y ago
      I feel that case just begs the answer. You're describing a job which is defined as "don't change anything unless absolutely necessary", so it won't directly help your work to learn how to change things. This doesn't seem like a deep result about the uselessness of learning new programming paradigms.
- jjnoakes 10y ago
  For now maybe. But I think it is short sighted to think that trend is guaranteed to continue. Down the road, as other developers pick up different paradigms and can potentially implement the same features you are writing, with a fraction of the bugs and in a fraction of the time, why would companies keep paying you six figures?
  - TheRealPomax 10y ago
    why would you believe companies would pay multiple people lower salaries, totalling more than a single six figure salary when benefits and taxes are factored in? It's easy to ignore large corporations and both government and private institutions, but they are not interested in efficient quick fire best solutions, they mostly care about things simply not breaking, and veeeery slowly moving towards what 5 years ago was the future, just incase the actualy 5 years from now prognosis doesn't pan out. Learn all you like, it's a great idea and makes you a versatile developer ("for some, X is great"), but don't ignore a very real part of the world where versatility is literally a non-issue, and being able to maintain an aging codebase without suggesting changes is what gets you set for life. Claiming that "everyone should X" ignores the real world.
    - mannykannot 10y ago
      The history of employment is littered with the misfortunes of those who expected that one narrow and not particularly deep skill would set them for life, and the trend is accelerating. Beyond that, there is the issue of whether you would prefer to work on something interesting, all else being equal. Of course, for that to be an issue, one first must be interested in something.
- wangchow 10y ago
  Because for those who don't understand or explore other paradigms their skillset is limited. There is a lot to be learned in concurrency domain from functional paradigms. Take a look at intel threading-building-blocks which is a modern way to look at concurrency and it is very much using functional concepts. For instance, parallel_for, parallel_reduce, parallel_scan. Reducing side-effects improves potential for parallelism. https://en.wikipedia.org/wiki/Threading_Building_Blocks https://en.wikipedia.org/wiki/Threading_Building_Blocks
  - TheRealPomax 10y ago
    That has never been a problem in a large part of the programming job market. If your skill set fills the job opening a big coorporation or institution has, and that job sets you up for life (instead of the frantic contract based work for startups or small companies) then exploration is a luxury, but in no way a necessity. Note that logic applies here: I'm questioning the "you should know" claim, not claiming "you should not know" because that would be ridiculous. Learn all you like if you feel that gives you a leg up, or an enriched quality of professional life, but it is absolutely not a requirement in a well-paying part of the real world's programming landscape, so claiming "one should" is a little rich.
    - wangchow 10y ago
      Well, this is true if all one is interested in is getting a job today. However, the best developers aren't primarily concerned about getting a job or not, they are genuinely interested in programming as both an art and a science. Money and jobs is secondary (and readily available because such individuals are more skilled than those that limit their pursuits).
      - deleted 10y ago
        [deleted]
      - sbov 10y ago
        Anyone who stereotypes the practices of the best developers is kidding themselves. Some of the best developers I know only know C. In reality there are roughly two types of tech: staples and new ones. Staples are around for a long time, but HN tends to focus on new ones. The thing is, even our modern staples came from a much larger set of new pieces of tech. What this means is, that if you're using a piece of tech that has been popular for at least 20 years, you're probably good for at least the next 20. If you keep switching to the new hotness, you will have to keep doing that because you are most likely learning stuff that won't stay around.
- coldtea 10y ago
  >realist contrarian question: why? If you didn't receive a formal education but you got good at OOP js or php, your expected salary gets pretty close to six figures. No understanding or even theoretical appreciation of other paradigms required. Because it's about the knowledge, and about doing what you do better, not merely about how much you earn. "Give him threepence, since he must always make gain out of what he learns" -- Euclid said to his servant when a student asked what he would get out of studying geometry.
- lojack 10y ago
  If you're a developer making six figures and aren't really interested in staying up to date with current trends or becoming a better developer, then it may be a waste of time. This attitude may come back to bite you in the ass in ten years when you're looking for a new job and find that your skills are no longer applicable to the modern workforce. I will say that it's virtually impossible to be purely an OOP programmer without using ideas that originated with imperative or functional languages. It's also pretty difficult to be a really good OOP developer without writing at least some code that looks very functional. There's a lot of ideas and techniques that help you as a developer no matter what paradigm you choose.
coldtea 10y ago
>At this day and age people should be familiar with multiple paradigms. Whether procedural, functional, or Object-Oriented they are all useful. Why assume that "all are useful"? I'd say that most of them developed ad-hoc, and whether they are useful or not is subject to actual research on their effectiveness in the field, with controlled studies etc. Usually PL researchers go the other way around, toy with some things at the language/compiler/syntax/semantics level that think are cool/powerful/expressive etc but rarely bother with actual justification based on those that actually will use the PL, that is programmers. Which makes the whole field cargo cultish and a pop culture, as Alan Kay notes.
- the_duke 10y ago
  Being familiar with different paradigms extends your capabilities, allows you to investigate problems from different angles, and pick the solution most appropriate to the domain. Even if you learn something 'useless' (either to the current problem or in general), it allows you to discard certain solutions, and know why they are not a good approach.
- wangchow 10y ago
  They are all useful. Functional: reducing side-effects improves potential for concurrency; Object-Oriented: create a new type and overload operators to make it feel like the abstract mathematical idea it represents; Procedural: subroutines are pretty much indispensable.
  - runT1ME 10y ago
    Explain why FP doesn't do 'create a new type and overload operators to make it feel like the abstract mathematical idea it represents' better with say, parametric polymorphism?
    - ryandvm 10y ago
      Just my two cents, but regardless of whether it is a more pure representation, I'd say it is empirically more difficult for the average, object-oriented human to wrap their brain around. At least on that measure, the object oriented paradigm has demonstrated some success.
ArkyBeagle 10y ago
The path to concurrency is paved with a mix of finite state machines and event-driven programs. IMO, neither FP nor OO have all that much to say about that. FSM/event driven is pretty easy even in rickety old languages like 'C'. C++ is a bit nicer because there is dispatch demuxing built in. I suppose the same is true of Java. I guess webby stuff doesn't lead to the appeal of FSM but for everything else, it's generally a better path. FPGA guys use a lot of FSM and they simply don't have the same defect rates as software guys. I've used toolsets like ObjecTime/Rose where "everything is a state machine" and It Just Works. I'm not sure why this approach is still obscure - the various works in Verification ( with a capital V ) seem to point to FSM as a means of reducing complexity.
- dgallion1 10y ago
  I've lived the ObjectTime/Rose path. Made good money converting projects out of those tools. So yes, everyone should use them. C++14 and coroutines have replaced state machines in my world. They read like normal code, are easy to customize to your needs. Had to convert a large PLC system from Beckoff structured text to C++. Coroutines allowed me to model it close enough that a little python translator made it work. Setup actors with queues that timeout on interval and pump the (taskLets) Coroutines. Create functions that provide blocking on what ever you like. Events, msgs or time. Better IMO, compared to code shattered into bubbles in a tool or callbacks everywhere.

TheRealPomax 10y ago

realist contrarian question: why? If you didn't receive a formal education but you got good at OOP js or php, your expected salary gets pretty close to six figures. No understanding or even theoretical appreciation of other paradigms required. And I say that as someone with a formal education in programming and decent understanding of most programming paradigms.

ebbv 10y ago
If you are a professional developer you should always be learning and growing your skill set. You don't have to learn about functional programming, but choosing to remain ignorant does not reflect well on you. There's a difference between learning about it and using it at work. Your job may not have any good opportunities to apply FP, but you should be learning about it in your spare time given how many great use cases it has in today's world.
- TheRealPomax 10y ago
  the real world does not particularly line up with that statement. For a fast moving contract based world, sure, but there's also the other part of the programming landscape where codebases need to be maintained forever for institutions and large companies whose idea of stable is even stricter than OpenBSD. I know plenty of people who work on both, and the second category gets paid very good money indeed to be the sole maintainers of complex codebases, with zero need or intention to learn new approaches because it won't let them do their job any better. Does that make them less likely to get a new job? sure, unless their new job still uses the language they use right now, which when you have 20 years of experience tends to not happen - other big companies and institutions will hire you on the spot. But a more important question is: will they even get to a point where they will need to look for a new job before retiring? Chances of that are roughly zero.
  - ebbv 10y ago
    I'm not sure how your response applies to my comment? I said that your particular job may not provide an opportunity for FP but you should still learn it for the sake of professional development. Even if you never need a job that uses FP, you should understand it so that you understand why you don't need it in your job. Even if you never leave your job, having those skills will help you push for a raise and move you ahead in your field. And chances are even if your job doesn't need it now, unless you're already near retirement, eventually there will be a case where maybe it is applicable.
    - TheRealPomax 10y ago
      And my response is still "why should they"? Mind you, that's in part because of the ambiguity of the term "should": are you using the "should, as in nice to do but not required" or "should, as in required, and not doing it is wrong", because I'm on board with the first, but that is not how the original comment reads. That reads more like everyone should be familiar with multiple paradigms and not following that rule is bad. Which the real world heavily disputes.
      - ebbv 10y ago
        I think it's pretty clear from my comment that I'm saying should in the same sense as you should not smell like a dumpster on a hot day and you should be nice to work with. Technically it's not required, but if you don't then you're lazy and probably not a great employee.
      - mannykannot 10y ago
        If this discussion is about the use of the word "should", then it has been a waste of time.
  - johncolanduoni 10y ago
    I feel that case just begs the answer. You're describing a job which is defined as "don't change anything unless absolutely necessary", so it won't directly help your work to learn how to change things. This doesn't seem like a deep result about the uselessness of learning new programming paradigms.
jjnoakes 10y ago
For now maybe. But I think it is short sighted to think that trend is guaranteed to continue. Down the road, as other developers pick up different paradigms and can potentially implement the same features you are writing, with a fraction of the bugs and in a fraction of the time, why would companies keep paying you six figures?
- TheRealPomax 10y ago
  why would you believe companies would pay multiple people lower salaries, totalling more than a single six figure salary when benefits and taxes are factored in? It's easy to ignore large corporations and both government and private institutions, but they are not interested in efficient quick fire best solutions, they mostly care about things simply not breaking, and veeeery slowly moving towards what 5 years ago was the future, just incase the actualy 5 years from now prognosis doesn't pan out. Learn all you like, it's a great idea and makes you a versatile developer ("for some, X is great"), but don't ignore a very real part of the world where versatility is literally a non-issue, and being able to maintain an aging codebase without suggesting changes is what gets you set for life. Claiming that "everyone should X" ignores the real world.
  - mannykannot 10y ago
    The history of employment is littered with the misfortunes of those who expected that one narrow and not particularly deep skill would set them for life, and the trend is accelerating. Beyond that, there is the issue of whether you would prefer to work on something interesting, all else being equal. Of course, for that to be an issue, one first must be interested in something.
wangchow 10y ago
Because for those who don't understand or explore other paradigms their skillset is limited. There is a lot to be learned in concurrency domain from functional paradigms. Take a look at intel threading-building-blocks which is a modern way to look at concurrency and it is very much using functional concepts. For instance, parallel_for, parallel_reduce, parallel_scan. Reducing side-effects improves potential for parallelism. https://en.wikipedia.org/wiki/Threading_Building_Blocks https://en.wikipedia.org/wiki/Threading_Building_Blocks
- TheRealPomax 10y ago
  That has never been a problem in a large part of the programming job market. If your skill set fills the job opening a big coorporation or institution has, and that job sets you up for life (instead of the frantic contract based work for startups or small companies) then exploration is a luxury, but in no way a necessity. Note that logic applies here: I'm questioning the "you should know" claim, not claiming "you should not know" because that would be ridiculous. Learn all you like if you feel that gives you a leg up, or an enriched quality of professional life, but it is absolutely not a requirement in a well-paying part of the real world's programming landscape, so claiming "one should" is a little rich.
  - wangchow 10y ago
    Well, this is true if all one is interested in is getting a job today. However, the best developers aren't primarily concerned about getting a job or not, they are genuinely interested in programming as both an art and a science. Money and jobs is secondary (and readily available because such individuals are more skilled than those that limit their pursuits).
    - deleted 10y ago
      [deleted]
    - sbov 10y ago
      Anyone who stereotypes the practices of the best developers is kidding themselves. Some of the best developers I know only know C. In reality there are roughly two types of tech: staples and new ones. Staples are around for a long time, but HN tends to focus on new ones. The thing is, even our modern staples came from a much larger set of new pieces of tech. What this means is, that if you're using a piece of tech that has been popular for at least 20 years, you're probably good for at least the next 20. If you keep switching to the new hotness, you will have to keep doing that because you are most likely learning stuff that won't stay around.
coldtea 10y ago
>realist contrarian question: why? If you didn't receive a formal education but you got good at OOP js or php, your expected salary gets pretty close to six figures. No understanding or even theoretical appreciation of other paradigms required. Because it's about the knowledge, and about doing what you do better, not merely about how much you earn. "Give him threepence, since he must always make gain out of what he learns" -- Euclid said to his servant when a student asked what he would get out of studying geometry.
lojack 10y ago
If you're a developer making six figures and aren't really interested in staying up to date with current trends or becoming a better developer, then it may be a waste of time. This attitude may come back to bite you in the ass in ten years when you're looking for a new job and find that your skills are no longer applicable to the modern workforce. I will say that it's virtually impossible to be purely an OOP programmer without using ideas that originated with imperative or functional languages. It's also pretty difficult to be a really good OOP developer without writing at least some code that looks very functional. There's a lot of ideas and techniques that help you as a developer no matter what paradigm you choose.

coldtea 10y ago

>At this day and age people should be familiar with multiple paradigms. Whether procedural, functional, or Object-Oriented they are all useful. Why assume that "all are useful"? I'd say that most of them developed ad-hoc, and whether they are useful or not is subject to actual research on their effectiveness in the field, with controlled studies etc. Usually PL researchers go the other way around, toy with some things at the language/compiler/syntax/semantics level that think are cool/powerful/expressive etc but rarely bother with actual justification based on those that actually will use the PL, that is programmers. Which makes the whole field cargo cultish and a pop culture, as Alan Kay notes.

the_duke 10y ago
Being familiar with different paradigms extends your capabilities, allows you to investigate problems from different angles, and pick the solution most appropriate to the domain. Even if you learn something 'useless' (either to the current problem or in general), it allows you to discard certain solutions, and know why they are not a good approach.
wangchow 10y ago
They are all useful. Functional: reducing side-effects improves potential for concurrency; Object-Oriented: create a new type and overload operators to make it feel like the abstract mathematical idea it represents; Procedural: subroutines are pretty much indispensable.
- runT1ME 10y ago
  Explain why FP doesn't do 'create a new type and overload operators to make it feel like the abstract mathematical idea it represents' better with say, parametric polymorphism?
  - ryandvm 10y ago
    Just my two cents, but regardless of whether it is a more pure representation, I'd say it is empirically more difficult for the average, object-oriented human to wrap their brain around. At least on that measure, the object oriented paradigm has demonstrated some success.

ArkyBeagle 10y ago

The path to concurrency is paved with a mix of finite state machines and event-driven programs. IMO, neither FP nor OO have all that much to say about that. FSM/event driven is pretty easy even in rickety old languages like 'C'. C++ is a bit nicer because there is dispatch demuxing built in. I suppose the same is true of Java. I guess webby stuff doesn't lead to the appeal of FSM but for everything else, it's generally a better path. FPGA guys use a lot of FSM and they simply don't have the same defect rates as software guys. I've used toolsets like ObjecTime/Rose where "everything is a state machine" and It Just Works. I'm not sure why this approach is still obscure - the various works in Verification ( with a capital V ) seem to point to FSM as a means of reducing complexity.

dgallion1 10y ago
I've lived the ObjectTime/Rose path. Made good money converting projects out of those tools. So yes, everyone should use them. C++14 and coroutines have replaced state machines in my world. They read like normal code, are easy to customize to your needs. Had to convert a large PLC system from Beckoff structured text to C++. Coroutines allowed me to model it close enough that a little python translator made it work. Setup actors with queues that timeout on interval and pump the (taskLets) Coroutines. Create functions that provide blocking on what ever you like. Events, msgs or time. Better IMO, compared to code shattered into bubbles in a tool or callbacks everywhere.