4 ms·

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 dynam

by 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.
  - watwut 8y ago
    Then why pick the "developers have to learn something new" as tradeoff to discuss? That is odd choice as I don't recall unwillingness to learn language to be issue, ever. Nor was bigger issue to find programmer for language that is not obscure. I did not meant project by big company. I mean large project of the kind people call enterprise, regardless of whether it is done by big company or small contracting company with freedom to choose tech (pretty common here). Yes mobile and quick responsive frontend in js are necessary, but they are also more expensive and time consuming to produce larger project. It is harder to maintain in them and harder to do more complicated business processes in them. Refactoring messy javascript is much harder then refactoring messy static code. Hence, popularity and all that hope towards typescript and flow and what not.

by Jach 8y ago

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.
- watwut 8y ago
  Then why pick the "developers have to learn something new" as tradeoff to discuss? That is odd choice as I don't recall unwillingness to learn language to be issue, ever. Nor was bigger issue to find programmer for language that is not obscure. I did not meant project by big company. I mean large project of the kind people call enterprise, regardless of whether it is done by big company or small contracting company with freedom to choose tech (pretty common here). Yes mobile and quick responsive frontend in js are necessary, but they are also more expensive and time consuming to produce larger project. It is harder to maintain in them and harder to do more complicated business processes in them. Refactoring messy javascript is much harder then refactoring messy static code. Hence, popularity and all that hope towards typescript and flow and what not.