8 ms·

While there are some parts of this matrix I agree with, I have to say that it seems rather "old school". The matrix seems to assume that all programmers are sys

While there are some parts of this matrix I agree with, I have to say that it seems rather "old school". The matrix seems to assume that all programmers are systems-level programmers working with compiled languages. Dynamic languages are only listed in the "scripting" knowledge section. There are tons of huge projects written entirely in dynamic languages. Assuming that dynamic languages are only for writing small scripts is disingenuous. The next improvement I can suggest is to remove the implications that knowing the FP paradigm somehow makes you a better developer, or that only a good developer can use FP. FP is a useful tool just like OOP or imperative programming. Generally speaking, a good developer should be able to compose multiple paradigms together where they fit in the problem space. Maybe if this section of the matrix were reworded to say something along the lines of "Able to use multiple paradigms in their equivalent problem space including OOP, FP, and imperitive programming to create quality software." it would be better. I do like how the author included a section for communication skills. Too often we, as developers, forget that we are ultimately only as good as the team around us is. We should work our hardest to improve our team in order to increase the quality of our work. That starts with effective communication.

ivraatiems 10y ago
Yeah, this is clearly out of date. "Experimented with Git" is the highest level in the version control row? Git is the standard now and has been for years. I think a bigger issue, though, is that some of these skills are very valuable, and some of these skills are the ones companies hire on, and those two sections are not always the same. Personally, I see myself as being somewhere around the n level on the algorithms stuff, but well into the log(n) level at the engineering/communication stuff. I've harped over and over on the weirdness of prioritizing theory knowledge over practical skill in day-to-day jobs where the practical is what matters - it's nice to see all the different dimensions so clearly laid out and given (roughly) equal attention.
- pjmlp 10y ago
  > Git is the standard now and has been for years. Only in the open source world and a few SV darlings. I am yet to do a project at a Fortune 500 among our customers that isn't based in Subversion or TFS. I have been using Git only on personal projects.
  - alexbanks 10y ago
    > Only in the open source world and a few SV darlings. In the last year I've built internal-only systems for two Global Fortune 100 companies, both of them in Git. I believe you are very incorrect.
    - pjmlp 10y ago
      You forgot to read the part "among our customers".
      - closed 10y ago
        I don't think they forgot anything. You mention your observations among your customers, in order to support a more general point. They are questioning whether that generalization follows from your observations (using observations of their own).
        pjmlp 10y ago
        For these customers it doesn't follow "Git is the standard now and has been for years.".
        alexbanks 10y ago
        Right. I am asserting that your experiences are not the norm, but in fact outliers. Which means that Git is the norm, and those that do not use it are outliers. Basically the opposite of your original claim.
        pjmlp 10y ago
        To see who is actually right, we would need to take a measurement of SCM systems across all Fortune 500 companies. Writing statements about Git's adoptin on HN posts don't make them into facts, unless they are baked by actual numbers. The fact is that both of us are wrong, because neither of us have the data of those 500 companies, only anecdotes.
- dhimes 10y ago
  hg FTW!
- coldtea 10y ago
  >Yeah, this is clearly out of date. "Experimented with Git" is the highest level in the version control row? Git is the standard now and has been for years. You'd be surprised. The vast majority of enterprise programmers have neither used it nor care to.
anuragojha 10y ago
Could you recommend a few good projects(err homework problems) where "OOP, FP, and imperative programming" could nicely (and naturally) be used to build a quality solution?
- scriptkiddy 10y ago
  I can think of a couple. Write a small toy document database with an integrated ORM. Tables/documents can be modeled as objects and the query API can be built using a functional paradigm. Doesn't need to be fancy. Could be a simple key/value store really. Or how about an HTML generation library? Or how about a toy web server? How about a command line argument parser for your favorite language? How about a small library for geometric calculations? There are many languages that have multi-paradigm support. One of my favorite multi-paradigm languages in still in it's growing phase, but it's fun to learn: https://nim-lang.org/ https://nim-lang.org/
pka 10y ago
Genuinely curious, when would OOP (as opposed to FP) be better suited to a problem domain in your opinion?
- taylorphebus 10y ago
  One big thing I was working on when I was studying FP was a processor simulator, which was basically 100% state with a bunch of things operating on different parts of the state at once. It wasn't clear to me that FP would get me any benefit even if my language would handle all the issues passing state around in that case.
  - rebeccaskinner 10y ago
    I think the more mutable state you have, and the more paths there are toward mutating that state, the more you can actually gain from using a language that forces you to be disciplined with how you handle it.
    - SomeCallMeTim 10y ago
      The hoops you have to jump through in a pure FP approach can make the problem 100x harder, though. Some problems are just more inherently imperative and stateful. I use FP code when it makes sense, and I use imperative code when it makes sense. There Is No Silver Bullet.
      - cassowary 10y ago
        really? It's been a while since I've programmed in Haskell, but something like this is about right: data Data = Data { thing :: Int, that :: Boolean }} addToThing :: Int -> State Data Int addToThing n = do x <- get thing modify (data -> data {thing: x + n}) return x It corresponds to this Typescript code: class Data { constructor( private thing: number, private that: Number ) {} addToThing(n: number) { const old = this.thing this.thing = old + n return old } } Except for the fact that you only need to see mutation if you want to, and you certainly can't use the mutation unless you want it. To me it doesn't really look like jumping through hoops, but we're up front about the mutation so no-one's ever going to get a surprise. There's no silver bullet, sure. But I don't think pure FP is really all that complex. It's mostly just different.
coldtea 10y ago
>While there are some parts of this matrix I agree with, I have to say that it seems rather "old school". The matrix seems to assume that all programmers are systems-level programmers working with compiled languages. No, it just assumes that all kinds of programmers, including front-end programmers, will be much better for knowing those things, which is true.
- scriptkiddy 10y ago
  I agree that all programs can benefit from lower-level concepts. That said, that's not how I understood the article.

ivraatiems 10y ago

Yeah, this is clearly out of date. "Experimented with Git" is the highest level in the version control row? Git is the standard now and has been for years. I think a bigger issue, though, is that some of these skills are very valuable, and some of these skills are the ones companies hire on, and those two sections are not always the same. Personally, I see myself as being somewhere around the n level on the algorithms stuff, but well into the log(n) level at the engineering/communication stuff. I've harped over and over on the weirdness of prioritizing theory knowledge over practical skill in day-to-day jobs where the practical is what matters - it's nice to see all the different dimensions so clearly laid out and given (roughly) equal attention.

pjmlp 10y ago
> Git is the standard now and has been for years. Only in the open source world and a few SV darlings. I am yet to do a project at a Fortune 500 among our customers that isn't based in Subversion or TFS. I have been using Git only on personal projects.
- alexbanks 10y ago
  > Only in the open source world and a few SV darlings. In the last year I've built internal-only systems for two Global Fortune 100 companies, both of them in Git. I believe you are very incorrect.
  - pjmlp 10y ago
    You forgot to read the part "among our customers".
    - closed 10y ago
      I don't think they forgot anything. You mention your observations among your customers, in order to support a more general point. They are questioning whether that generalization follows from your observations (using observations of their own).
      - pjmlp 10y ago
        For these customers it doesn't follow "Git is the standard now and has been for years.".
        alexbanks 10y ago
        Right. I am asserting that your experiences are not the norm, but in fact outliers. Which means that Git is the norm, and those that do not use it are outliers. Basically the opposite of your original claim.
        pjmlp 10y ago
        To see who is actually right, we would need to take a measurement of SCM systems across all Fortune 500 companies. Writing statements about Git's adoptin on HN posts don't make them into facts, unless they are baked by actual numbers. The fact is that both of us are wrong, because neither of us have the data of those 500 companies, only anecdotes.
dhimes 10y ago
hg FTW!
coldtea 10y ago
>Yeah, this is clearly out of date. "Experimented with Git" is the highest level in the version control row? Git is the standard now and has been for years. You'd be surprised. The vast majority of enterprise programmers have neither used it nor care to.

anuragojha 10y ago

Could you recommend a few good projects(err homework problems) where "OOP, FP, and imperative programming" could nicely (and naturally) be used to build a quality solution?

scriptkiddy 10y ago
I can think of a couple. Write a small toy document database with an integrated ORM. Tables/documents can be modeled as objects and the query API can be built using a functional paradigm. Doesn't need to be fancy. Could be a simple key/value store really. Or how about an HTML generation library? Or how about a toy web server? How about a command line argument parser for your favorite language? How about a small library for geometric calculations? There are many languages that have multi-paradigm support. One of my favorite multi-paradigm languages in still in it's growing phase, but it's fun to learn: https://nim-lang.org/ https://nim-lang.org/

pka 10y ago

Genuinely curious, when would OOP (as opposed to FP) be better suited to a problem domain in your opinion?

taylorphebus 10y ago
One big thing I was working on when I was studying FP was a processor simulator, which was basically 100% state with a bunch of things operating on different parts of the state at once. It wasn't clear to me that FP would get me any benefit even if my language would handle all the issues passing state around in that case.
- rebeccaskinner 10y ago
  I think the more mutable state you have, and the more paths there are toward mutating that state, the more you can actually gain from using a language that forces you to be disciplined with how you handle it.
  - SomeCallMeTim 10y ago
    The hoops you have to jump through in a pure FP approach can make the problem 100x harder, though. Some problems are just more inherently imperative and stateful. I use FP code when it makes sense, and I use imperative code when it makes sense. There Is No Silver Bullet.
    - cassowary 10y ago
      really? It's been a while since I've programmed in Haskell, but something like this is about right: data Data = Data { thing :: Int, that :: Boolean }} addToThing :: Int -> State Data Int addToThing n = do x <- get thing modify (data -> data {thing: x + n}) return x It corresponds to this Typescript code: class Data { constructor( private thing: number, private that: Number ) {} addToThing(n: number) { const old = this.thing this.thing = old + n return old } } Except for the fact that you only need to see mutation if you want to, and you certainly can't use the mutation unless you want it. To me it doesn't really look like jumping through hoops, but we're up front about the mutation so no-one's ever going to get a surprise. There's no silver bullet, sure. But I don't think pure FP is really all that complex. It's mostly just different.

coldtea 10y ago

>While there are some parts of this matrix I agree with, I have to say that it seems rather "old school". The matrix seems to assume that all programmers are systems-level programmers working with compiled languages. No, it just assumes that all kinds of programmers, including front-end programmers, will be much better for knowing those things, which is true.

scriptkiddy 10y ago
I agree that all programs can benefit from lower-level concepts. That said, that's not how I understood the article.