4 ms·

GOF is one of the most useful books I’ve read in my software career (now spanning over 20 years), and I’d recommend it to any beginning developer. Design patte

by irq11 8y ago

GOF is one of the most useful books I’ve read in my software career (now spanning over 20 years), and I’d recommend it to any beginning developer. Design patterns did not “fail”; they’re ubiquitous in software. At worst, you can say that the terminology has changed because our industry has the attention span of a caffeinated ferret.

Jach 8y ago
GoF changed the terminology, too. To quote Peter Norvig: "Before the Gang of Four got all academic on us, ``singleton'' (without the formal name) was just a simple idea that deserved a simple line of code, not a whole religion." I recommend any new developers to familiarize themselves with dynamic languages (hopefully beyond JS) and to consider the idea that design patterns are just missing programming language features, and different languages will have (or not have) different patterns based on their feature set. (Norvig, again, for some intro material: http://norvig.com/design-patterns/ http://norvig.com/design-patterns/)
- watwut 8y ago
  But even then, I would not use dynamic language for large project expected to live long nor the kind of projects that is currently done in "enterprise". So even in cases where pattern is workaround for language not being dynamic, changing langauge just for that might not be what you want.
  - Jach 8y ago
    Of course there are always tradeoffs to make when choosing a language, especially if you expect "enterprise" scale. Others will choose (and have chosen) a dynamic language, even if you don't; many dynamic languages can scale to mega sized systems just fine. (Here's an interesting talk from a while ago from a startup thinking about building for a scale beyond what startups normally deal with, and how Clojure was a nice fit for them: https://www.youtube.com/watch?v=BThkk5zv0DE https://www.youtube.com/watch?v=BThkk5zv0DE) Changing languages also has a bunch of tradeoffs, but in mega sized software you ought to have already solved the modularity problem that lets you get that big in the first place. Being well modularized, you should be able to introduce a new language without too much impact on the rest of the systems. I used to be pretty pessimistic that more interesting languages could never be introduced to BigCo and survive, but seeing the evolution of JavaScript and Java play out, plus what's going on in mobile with Objective C + Swift and Java + Kotlin, and BigCo developers adapting to all this new syntax (both JS's and Java's latest versions are very much completely new languages compared to what the codebases started in) I'm more optimistic that developers can in fact be taught something new. The real difficulties are political, and only one minor component of that is being able to reassure that learning is fairly easy and possible.
    - watwut 8y ago
      None of what you wrote make dynamic language better for that particular task or easier to use for such task. It just makes it possible if you put in additional effort. Of course big companies use all kind of languages, what they don't do is using it for enterprise bussines project. Javascript or kotlin being used for something else in same company is irrelevant. The issue is not even syntax, that is why it is no problem to update Java. The tooling around it still works the same, ecosystem works the same. The issue is any programmers ability to figure out someone else's code - meaning importance to compilation errors being visible at compilation time, trustworthy "find all callers" etc. Of course developers can learn something new. That does not mean that the new thing is suitable for task they are working on. Also, framing everyone who disagree with you as incompetent is awfully dishonest tactic. Suitable for toxic corporations (and toxic startups) for sure, but not something that should work in any kind of rational workplace.
      - Jach 8y ago
        I'm not making the argument that dynamic languages are better for any particular task; I assume it, but that's a separate issue. Your comment says you would not use a dynamic language for a "large project expected to live long nor the kind of projects that is currently done in "enterprise"" on the basis that by switching to dynamic languages you save on some pattern cruft. My comment is agreeing, there are other tradeoffs to consider, I wouldn't necessarily expect anyone to switch languages just on syntax. The second half of my comment was considering another tradeoff, which is "do developers need to learn something new? can they? will they?" and more importantly for management "do we need to allocate more time for onboarding?" and the related "does this shrink our hiring pool and by how much?" Even if weighing those favor choosing (or moving to) a particular dynamic language, of course that might not be enough to change! Tooling is a factor as you point out, but there are even more tradeoffs to consider. Big companies do in fact use dynamic languages for big enterprise business projects. I work for one, we (among many, many other big companies -- though I'm not sure what your cutoff point for big company is, we're not one of the two Trillion Dollar Behemoths if revenue is a factor) use JavaScript extensively, if not exclusively. It's not "for something else", the business depends on JS. Take away the mobile apps, ok we can live, take away the JS, um, what's going to talk to our equally important server and database code? (Not to mention do all the important things that are only implemented in JS rather than the backend?) > Also, framing everyone who disagree with you as incompetent is awfully dishonest tactic. Suitable for toxic corporations (and toxic startups) for sure, but not something that should work in any kind of rational workplace. Ok? I don't disagree and don't think I've ever framed people that way unless it was a joking reference to Linus Torvalds' git introduction 10 years ago for a Google presentation where he defined those that disagree with him for the duration of the talk as stupid and ugly. I'm not sure if you're on a tangent or something in my comment (or the video I linked?) gave that impression.
BerislavLopac 8y ago
Caffeinated ferret is my spirit animal...

by irq11 8y ago

Jach 8y ago

GoF changed the terminology, too. To quote Peter Norvig: "Before the Gang of Four got all academic on us, ``singleton'' (without the formal name) was just a simple idea that deserved a simple line of code, not a whole religion." I recommend any new developers to familiarize themselves with dynamic languages (hopefully beyond JS) and to consider the idea that design patterns are just missing programming language features, and different languages will have (or not have) different patterns based on their feature set. (Norvig, again, for some intro material: http://norvig.com/design-patterns/ http://norvig.com/design-patterns/)

watwut 8y ago
But even then, I would not use dynamic language for large project expected to live long nor the kind of projects that is currently done in "enterprise". So even in cases where pattern is workaround for language not being dynamic, changing langauge just for that might not be what you want.
- Jach 8y ago
  Of course there are always tradeoffs to make when choosing a language, especially if you expect "enterprise" scale. Others will choose (and have chosen) a dynamic language, even if you don't; many dynamic languages can scale to mega sized systems just fine. (Here's an interesting talk from a while ago from a startup thinking about building for a scale beyond what startups normally deal with, and how Clojure was a nice fit for them: https://www.youtube.com/watch?v=BThkk5zv0DE https://www.youtube.com/watch?v=BThkk5zv0DE) Changing languages also has a bunch of tradeoffs, but in mega sized software you ought to have already solved the modularity problem that lets you get that big in the first place. Being well modularized, you should be able to introduce a new language without too much impact on the rest of the systems. I used to be pretty pessimistic that more interesting languages could never be introduced to BigCo and survive, but seeing the evolution of JavaScript and Java play out, plus what's going on in mobile with Objective C + Swift and Java + Kotlin, and BigCo developers adapting to all this new syntax (both JS's and Java's latest versions are very much completely new languages compared to what the codebases started in) I'm more optimistic that developers can in fact be taught something new. The real difficulties are political, and only one minor component of that is being able to reassure that learning is fairly easy and possible.
  - watwut 8y ago
    None of what you wrote make dynamic language better for that particular task or easier to use for such task. It just makes it possible if you put in additional effort. Of course big companies use all kind of languages, what they don't do is using it for enterprise bussines project. Javascript or kotlin being used for something else in same company is irrelevant. The issue is not even syntax, that is why it is no problem to update Java. The tooling around it still works the same, ecosystem works the same. The issue is any programmers ability to figure out someone else's code - meaning importance to compilation errors being visible at compilation time, trustworthy "find all callers" etc. Of course developers can learn something new. That does not mean that the new thing is suitable for task they are working on. Also, framing everyone who disagree with you as incompetent is awfully dishonest tactic. Suitable for toxic corporations (and toxic startups) for sure, but not something that should work in any kind of rational workplace.
    - Jach 8y ago
      I'm not making the argument that dynamic languages are better for any particular task; I assume it, but that's a separate issue. Your comment says you would not use a dynamic language for a "large project expected to live long nor the kind of projects that is currently done in "enterprise"" on the basis that by switching to dynamic languages you save on some pattern cruft. My comment is agreeing, there are other tradeoffs to consider, I wouldn't necessarily expect anyone to switch languages just on syntax. The second half of my comment was considering another tradeoff, which is "do developers need to learn something new? can they? will they?" and more importantly for management "do we need to allocate more time for onboarding?" and the related "does this shrink our hiring pool and by how much?" Even if weighing those favor choosing (or moving to) a particular dynamic language, of course that might not be enough to change! Tooling is a factor as you point out, but there are even more tradeoffs to consider. Big companies do in fact use dynamic languages for big enterprise business projects. I work for one, we (among many, many other big companies -- though I'm not sure what your cutoff point for big company is, we're not one of the two Trillion Dollar Behemoths if revenue is a factor) use JavaScript extensively, if not exclusively. It's not "for something else", the business depends on JS. Take away the mobile apps, ok we can live, take away the JS, um, what's going to talk to our equally important server and database code? (Not to mention do all the important things that are only implemented in JS rather than the backend?) > Also, framing everyone who disagree with you as incompetent is awfully dishonest tactic. Suitable for toxic corporations (and toxic startups) for sure, but not something that should work in any kind of rational workplace. Ok? I don't disagree and don't think I've ever framed people that way unless it was a joking reference to Linus Torvalds' git introduction 10 years ago for a Google presentation where he defined those that disagree with him for the duration of the talk as stupid and ugly. I'm not sure if you're on a tangent or something in my comment (or the video I linked?) gave that impression.

BerislavLopac 8y ago

Caffeinated ferret is my spirit animal...