4 ms·

>One of my devs was really sabotaging processes just because he hate JS. Did you fire him/her?

illuminati1911 8y ago
I hope they fired the people who thought using JS in 2017/2018 unless absolutely necessary is a good idea. Both Kotlin and Swift are extremely elegant and modern languages with awesome set of features while JS lacks fundamental things like type(s)afety and is filled with inconsistency errors/problems etc. And yeah yeah, JS is not complete garbage. I'm well aware of that, but there is no point bringing a broken knife into a gun fight.
- coding123 8y ago
  That might be a perspective, our team uses typescript and we feel it's like bringing the army to a gun fight.
  - tzahola 8y ago
    The “gun” being which language?
- sodafountan 8y ago
  Well, I guess going by your logic Microsoft should fire everyone busily writing Office365, Skype, Microsoft Teams, and Visual Studio Code in javascript. Also, type safety isn't a "fundamental thing" it's a design decision made by the creators of the language.
  - jayshua 8y ago
    It's certainly a language design decision, but as I've been using more powerful type systems I'm coming to the conclusion that not using a language with a good type system for any project intended to be maintainable in the long term is just bad engineering.
    - chrisco255 8y ago
      Type systems do nothing to save you from making unmaintainable code. How many awfully engineered, slow to iterate, legacy monolith systems with convoluted OOP architectures were built in Java or .NET? All that type safety was a mere crutch for deeply nesting state in 14 layers of inheritance. I've worked on enterprise systems that take 10x as long to ship a feature in than something like Node. Nevermind that it's easy to add types to JS these days if you really want them. How you architect a system and manage state (and how simple you keep it) has far bigger implications than types.
      - filleduchaos 8y ago
        Yes, this is why TypeScript and Flow never got off the ground, and why PHP, Python and Ruby are all definitely not adding static type checking.
        chrisco255 8y ago
        Adding TS won't magically make your code base maintainable. TS/Flow are both successful, great projects for adding types. They help with tooling, and you spend less time inspecting the underlying code. But now you also have to maintain those types when things change. I work on a very large JS code base and the number of type errors I see is pretty rare. That being said, I'm not opposed to types. It's just not the panacea that people claim it is. Good tests and simple architectures will do more to make a code base maintainable than types will.
      - jayshua 8y ago
        Yes, it's clearly true that architecture plays a major role. I've worked on one of those inheritance towers before. But adding/changing/removing code in a dynamically typed language always leaves me worried that I've missed something. The only notice I have in such systems that I have missed something is a production runtime exception. Sure it takes longer up front to add a feature. And it's typically harder than in a dynamic language. My point is that taking the convenience of an untyped language is usually a poor/lazy architectural decision.
  - filleduchaos 8y ago
    Those things (or at least the one of them whose source we actually have access to) are written in TypeScript. Why do you think Microsoft created the language? Also they aren't exactly being rewritten in JS - the person who tweeted that later casually clarified that "well, actually" they're using JS as a sort of build system/integration over a still huge amount of native code.
    - sodafountan 8y ago
      What's your point? Typescript is a superset of javascript, they're still using javascript. And yeah I saw the tweet and the response, it sounds to me more like they're building specific components of applications with javascript, not really build systems. It's almost like some of the best developers in the world like to use the right tool for the right job, and in many cases that tool appears to be javascript. FIRE THEM!
      - filleduchaos 8y ago
        It's rather hypocritical to argue that the lack of type safety is a feature not a bug and then turn around and claim TypeScript as a superset of JavaScript.
  - monocularvision 8y ago
    I would assume MS is largely using TypeScript.
  - kodablah 8y ago
    I thought it was pretty clear this was in the context of mobile apps.
- lazerwalker 8y ago
  If you disagree with someone over a technical decision, that's one thing. Assuming you're a professional software developer, I'd like to think at least once in your career you've managed to find common ground with someone who disagreed with you, and have realized that disagreements over e.g. programming language preference usually (even if not always :P) just mean that person's priorities differ from yours, rather than that they're incompetent. If you consciously produce poor work because you disagree with that technical decision, rather than either going along with it or finding more a more appropriate venue to express that disagreement, that belies an attitude that's seemingly at odds with being a member of a collaborative workplace.

illuminati1911 8y ago

I hope they fired the people who thought using JS in 2017/2018 unless absolutely necessary is a good idea. Both Kotlin and Swift are extremely elegant and modern languages with awesome set of features while JS lacks fundamental things like type(s)afety and is filled with inconsistency errors/problems etc. And yeah yeah, JS is not complete garbage. I'm well aware of that, but there is no point bringing a broken knife into a gun fight.

coding123 8y ago
That might be a perspective, our team uses typescript and we feel it's like bringing the army to a gun fight.
- tzahola 8y ago
  The “gun” being which language?
sodafountan 8y ago
Well, I guess going by your logic Microsoft should fire everyone busily writing Office365, Skype, Microsoft Teams, and Visual Studio Code in javascript. Also, type safety isn't a "fundamental thing" it's a design decision made by the creators of the language.
- jayshua 8y ago
  It's certainly a language design decision, but as I've been using more powerful type systems I'm coming to the conclusion that not using a language with a good type system for any project intended to be maintainable in the long term is just bad engineering.
  - chrisco255 8y ago
    Type systems do nothing to save you from making unmaintainable code. How many awfully engineered, slow to iterate, legacy monolith systems with convoluted OOP architectures were built in Java or .NET? All that type safety was a mere crutch for deeply nesting state in 14 layers of inheritance. I've worked on enterprise systems that take 10x as long to ship a feature in than something like Node. Nevermind that it's easy to add types to JS these days if you really want them. How you architect a system and manage state (and how simple you keep it) has far bigger implications than types.
    - filleduchaos 8y ago
      Yes, this is why TypeScript and Flow never got off the ground, and why PHP, Python and Ruby are all definitely not adding static type checking.
      - chrisco255 8y ago
        Adding TS won't magically make your code base maintainable. TS/Flow are both successful, great projects for adding types. They help with tooling, and you spend less time inspecting the underlying code. But now you also have to maintain those types when things change. I work on a very large JS code base and the number of type errors I see is pretty rare. That being said, I'm not opposed to types. It's just not the panacea that people claim it is. Good tests and simple architectures will do more to make a code base maintainable than types will.
    - jayshua 8y ago
      Yes, it's clearly true that architecture plays a major role. I've worked on one of those inheritance towers before. But adding/changing/removing code in a dynamically typed language always leaves me worried that I've missed something. The only notice I have in such systems that I have missed something is a production runtime exception. Sure it takes longer up front to add a feature. And it's typically harder than in a dynamic language. My point is that taking the convenience of an untyped language is usually a poor/lazy architectural decision.
- filleduchaos 8y ago
  Those things (or at least the one of them whose source we actually have access to) are written in TypeScript. Why do you think Microsoft created the language? Also they aren't exactly being rewritten in JS - the person who tweeted that later casually clarified that "well, actually" they're using JS as a sort of build system/integration over a still huge amount of native code.
  - sodafountan 8y ago
    What's your point? Typescript is a superset of javascript, they're still using javascript. And yeah I saw the tweet and the response, it sounds to me more like they're building specific components of applications with javascript, not really build systems. It's almost like some of the best developers in the world like to use the right tool for the right job, and in many cases that tool appears to be javascript. FIRE THEM!
    - filleduchaos 8y ago
      It's rather hypocritical to argue that the lack of type safety is a feature not a bug and then turn around and claim TypeScript as a superset of JavaScript.
- monocularvision 8y ago
  I would assume MS is largely using TypeScript.
- kodablah 8y ago
  I thought it was pretty clear this was in the context of mobile apps.
lazerwalker 8y ago
If you disagree with someone over a technical decision, that's one thing. Assuming you're a professional software developer, I'd like to think at least once in your career you've managed to find common ground with someone who disagreed with you, and have realized that disagreements over e.g. programming language preference usually (even if not always :P) just mean that person's priorities differ from yours, rather than that they're incompetent. If you consciously produce poor work because you disagree with that technical decision, rather than either going along with it or finding more a more appropriate venue to express that disagreement, that belies an attitude that's seemingly at odds with being a member of a collaborative workplace.