3 ms·

It's all about who is writing it and why they are writing it, not the language. Well ok JavaScript has some legacy warts, but ECMAScript 2019 enables a variety

It's all about who is writing it and why they are writing it, not the language. Well ok JavaScript has some legacy warts, but ECMAScript 2019 enables a variety of very well written code in a variety of styles, and TypeScript is icing. As for me, I've only recently entered the JavaScript game, but the php I've seen has been much, much worse. I find the quality of JavaScript I typically encounter is on-par with typical Python code, and a fair bit better than the Frankenstein monsters of dev-ops code that often has a different convention for each line of bash (with attendant third-party applications) mixed in with inscrutable environment states as you shift in and out of various orchestration layers that have zero sense of application hierarchy or even running processes. I've seen scientific codebases too, but the thing you're getting there is an authorship that is often small-team (1 or 2) and very slow to shift, with highly enculturated domain context. Of course JavaScript code is going to be a mess in organizations where you have devs coming from vastly different contexts and staying a max of 2 years with a team where all you care about is getting the pretty graphic on the screen.

test6554 7y ago
Seconded on php. I have used php, I can use php, I just choose not to any more if I can help it.
- iratewizard 7y ago
  Smart choice. I opted to stop accepting php jobs several years ago and life has never been easier.
fao_ 7y ago
> It's all about who is writing it and why they are writing it, not the language. But who is writing it and why they are writing it are inextricably linked with the language. Every language has a culture and a reason for existing, those are pressures that bear as much on the person writing the language and the code produced as much as the person writing the code does on the code and the language. Whether or not say, modern Java encourages good code is neither here nor there, as not only is there resistance to learning new things there is resistance to using the new things properly. Java has a history of bloated, inefficient code for a reason, and when you use Java, the abstractions you use will alter the code that you write. It's impossible to get away from 'bad code' without rewriting things, and then you're not coding your new project you're rewriting someone else's. It's also 'good practice' to use x y z language idioms, but there are cases when such idioms make the code much harder to read and much less clean. As an example from C: I like POSIX, but dirname and basename are two ridiculously shit functions. If I choose to use them, the rot starts infesting my code, and everything that deals with them has to account for that, which itself causes a bias towards more obtuse code.
Xelbair 7y ago
>It's all about who is writing it and why they are writing it, not the language. Well ok JavaScript has some legacy warts, but ECMAScript 2019 enables a variety of very well written code in a variety of styles, and TypeScript is icing. Good languages kinda enforce some kind of basic rules, and prevent developers form making silly mistakes - because we all do them all the time. Those languages usually trade off the performance for safety though. We should pick the safest language, that prevents errors and mistakes as long as we stay within allowed performance bounds. JavaScript can be performant, but most of the times it isn't and it isn't safe at all. At least we have typed variants of JavaScript. JavaScript by design was meant to fail gracefully - in the background - so the site works fine. Sadly nowadays sites are so JavaScript heavy that it isn't helping at all. I generally prefer statically typed languages just because there is less ambiguity and function definition can help you greatly - you know what you put it, and what it returns. With dynamic typed languages unless documentation is pristine(and in JavaScript ecosystem it is pretty varied from package to package) you are out of luck unless you look at the implementation. bash and devOps code has their own special place in hell. bash has only one advantage - it works on any linux distro out of the box, and that's it. It is unreadable untyped mess.

test6554 7y ago

Seconded on php. I have used php, I can use php, I just choose not to any more if I can help it.

iratewizard 7y ago
Smart choice. I opted to stop accepting php jobs several years ago and life has never been easier.

fao_ 7y ago

> It's all about who is writing it and why they are writing it, not the language. But who is writing it and why they are writing it are inextricably linked with the language. Every language has a culture and a reason for existing, those are pressures that bear as much on the person writing the language and the code produced as much as the person writing the code does on the code and the language. Whether or not say, modern Java encourages good code is neither here nor there, as not only is there resistance to learning new things there is resistance to using the new things properly. Java has a history of bloated, inefficient code for a reason, and when you use Java, the abstractions you use will alter the code that you write. It's impossible to get away from 'bad code' without rewriting things, and then you're not coding your new project you're rewriting someone else's. It's also 'good practice' to use x y z language idioms, but there are cases when such idioms make the code much harder to read and much less clean. As an example from C: I like POSIX, but dirname and basename are two ridiculously shit functions. If I choose to use them, the rot starts infesting my code, and everything that deals with them has to account for that, which itself causes a bias towards more obtuse code.

Xelbair 7y ago

>It's all about who is writing it and why they are writing it, not the language. Well ok JavaScript has some legacy warts, but ECMAScript 2019 enables a variety of very well written code in a variety of styles, and TypeScript is icing. Good languages kinda enforce some kind of basic rules, and prevent developers form making silly mistakes - because we all do them all the time. Those languages usually trade off the performance for safety though. We should pick the safest language, that prevents errors and mistakes as long as we stay within allowed performance bounds. JavaScript can be performant, but most of the times it isn't and it isn't safe at all. At least we have typed variants of JavaScript. JavaScript by design was meant to fail gracefully - in the background - so the site works fine. Sadly nowadays sites are so JavaScript heavy that it isn't helping at all. I generally prefer statically typed languages just because there is less ambiguity and function definition can help you greatly - you know what you put it, and what it returns. With dynamic typed languages unless documentation is pristine(and in JavaScript ecosystem it is pretty varied from package to package) you are out of luck unless you look at the implementation. bash and devOps code has their own special place in hell. bash has only one advantage - it works on any linux distro out of the box, and that's it. It is unreadable untyped mess.