2 ms·

Your main point seems to be that these problems aren’t the language’s fault. But I don’t see the Deno team claiming that to be the case. There’s nothing wrong w

by baddox 6y ago

Your main point seems to be that these problems aren’t the language’s fault. But I don’t see the Deno team claiming that to be the case. There’s nothing wrong with choosing a language that works with how your team likes to develop software, and rejecting a language that doesn’t work well for your team. Doesn’t need to be anyone’s “fault.”

erikerikson 6y ago
It's entirely valid for them to decide they don't want to change their ways. However, it is frequent that technologies will be rejected because the requisite learning to understand why and how to best use the technology is not done. A common example of this (in my observation and ignoring the application of the technology where it's entirely unnecessary) is NoSql where teams have attempted to use those databases as they used their relational counterparts which obviously didn't work because they didn't shift how they were thinking about using storage and structuring their systems. Anyway, that was how I read the GPs post, as attempting to note that the Deno team may not have pushed through the mental shift required to really get the most out of TypeScript. [edit: not trying to take a stance in support of the GPS post or either side of this discussion, to be clear]
underdeserver 6y ago
That's true, but I think when you choose to use a programming language, you essentially commit to doing things its way, otherwise you end up dealing with lots of friction and having to reinvent a lot of wheels. Like the Deno team claim they do. Taking up Typescript then ignoring best practices when trying to use it is unfortunate. This kind of thing would be a teaching moment for a junior engineer. It's like saying you don't want to use a dishwasher because if you stack bowls on top of each other, it doesn't clean them well. Well, a dishwasher has its faults - a lot of dishes are not dishwasher-safe, etc. - but your reason kind of misses the point.

by baddox 6y ago

erikerikson 6y ago

It's entirely valid for them to decide they don't want to change their ways. However, it is frequent that technologies will be rejected because the requisite learning to understand why and how to best use the technology is not done. A common example of this (in my observation and ignoring the application of the technology where it's entirely unnecessary) is NoSql where teams have attempted to use those databases as they used their relational counterparts which obviously didn't work because they didn't shift how they were thinking about using storage and structuring their systems. Anyway, that was how I read the GPs post, as attempting to note that the Deno team may not have pushed through the mental shift required to really get the most out of TypeScript. [edit: not trying to take a stance in support of the GPS post or either side of this discussion, to be clear]

underdeserver 6y ago

That's true, but I think when you choose to use a programming language, you essentially commit to doing things its way, otherwise you end up dealing with lots of friction and having to reinvent a lot of wheels. Like the Deno team claim they do. Taking up Typescript then ignoring best practices when trying to use it is unfortunate. This kind of thing would be a teaching moment for a junior engineer. It's like saying you don't want to use a dishwasher because if you stack bowls on top of each other, it doesn't clean them well. Well, a dishwasher has its faults - a lot of dishes are not dishwasher-safe, etc. - but your reason kind of misses the point.