Similarly, other people have advocated using strict coding discipline as a way of writing better JavaScript. Sure you can do certain things in JavaScript, but you just don't ever do those things, including ignoring entire language features completely.
That's true but important libraries (like D3, for example) use that sort of idiom standard. So unless you're just going to rewrite all your own libraries (which actually isn't entirely unreasonable), you're going to run into that kind of problem.
For example prototyping often goes much more quickly with languages that feature dynamic types
I don't think that's true, but I'm open to data that proves otherwise. Prototyping goes quickly in languages that have good libraries (if I want to prototype a new kind of web server, for example, I might try Golang, because it has good libraries for that kind of thing).
Plenty of IDEs can already handle this without much of a problem, and as I said, Google closure already does static code analysis which will probably catch any "bad" refactoring you've done.
It's not clear you've understood the problem. The bug is syntactically and semantically correct, so static analysis will not detect it. It's only manifests itself as a behavioral problem. Please try to say something that indicates you understand the issue (if you choose to again reply).
Yeah, actually, requiring setters and getters would be a decent way of working around this particular problem in the language. Good solution. Of course, if you do that, most Javascript programmers will complain and say you are not writing idiomatic Javascript, but that's a problem with the community, not the language.
Flow is cool but will not catch the problem mentioned here. If you are using Typescript then you are not using Javascript, you are using Typescript. I don't even understand why that is confusing to you.
That is more of a tooling problem, not so much of a language problem
No, tools cannot be made to fix this problem. For example, say I decide to refactor the variable 'message' to be ' outMessage'. Then in one of my code files, I have this line of code, which I fail to refactor:
obj.message = "I <3 Javascript";
That is perfectly legal, and if I miss a usage of the variable later in the same function, it's impossible to detect without understanding the intent of the code, which no tooling can do. It just gets really tough to write large programs in Javascript.
Of course, you can use Typescript as another commenter pointed out, but then you're not using Javascript anymore, you're using Typescript.
When you say refactor do you mean variable scope? Javascript variables are the way they are so that you can use them on the fly without having to pre-declare each and every variable along with it's type which is a god send not a problem. You perhaps just need to get a better handle on how the scope works, that isn't really a language problem, that's a logic problem with your mind.
No, when I say refactor, I mean refactor. I can't imagine the state of mind that would even cause such a confusion. The point is, there might not be any errors, because the usage might be entirely legal
Those poor programmers using Javascript. What a lousy language.
(If anyone wants to know why, I will pick one feature out of many. Say you wrote a large program in Javascript, which is happening more often these days. Then you want to refactor by renaming a variable. In Java or C or C# you can refactor by using an IDE automatically, and if somehow you miss an instance, it will be caught at compile time. In Perl or Objective C or Smalltalk, it will caught at runtime in the worst case. But in Javascript, it might not be caught even at runtime, and instead will just cause strange behavior).
1) Consumer buys patented toner cartridge (probably bogus/obvious patent, but that's not at issue here)
2) Consumer returns toner cartridge to recycler.
3) Recycer refurbishes cartridge and re-sells it to someone else.
Lexmark wants to say that after you've used the toner cartridge, you can't give it to someone else, because they didn't license the patent to someone else. The law isn't clear at all on the topic, so the court could go either way. Even the supreme court seemed a bit confused by the situation (this is based on reading the article, not reading the actual law documents).
It's actually heading that direction. It's hard for us as Americans to feel it because we've started getting involved in more wars, but overall the world has been improving and improving.
One way of looking at it is, "rich people aren't willing to risk their lives in war" and as the world gets richer and richer, fewer people are willing to fight in battles.
Tech workers are [i]saints[/i] in the sexism department compared to salespeople and doctors. One of the few people who ever told me that "women are not biologically as good as men" was an MBA. I've never met or heard a tech guy claim that.
FOXO4 is a complex, complex protein. In some cases it prevents cancer. In other cases, it extends longevity. Apparently in this case it somehow makes you look old. I have no explanation for that, but maybe no one does?
Because alcohol carries a risk of liver disease, there are safer ways to lower risk, he says, such as quitting smoking, exercising regularly and eating a healthy diet.
Slashdot Mirror
As far as I know, most people are using Apache Spark for new projects.
Similarly, other people have advocated using strict coding discipline as a way of writing better JavaScript. Sure you can do certain things in JavaScript, but you just don't ever do those things, including ignoring entire language features completely.
That's true but important libraries (like D3, for example) use that sort of idiom standard. So unless you're just going to rewrite all your own libraries (which actually isn't entirely unreasonable), you're going to run into that kind of problem.
I'm seriously doubting you've ever written a large program.
Ha, ancient political slogans, fun.
Church in danger!
All the worshippers of Isis call for Cn. Helvius Sabinus as aedile.
Somehow, of course. Maybe you missed that; I explained.
For example prototyping often goes much more quickly with languages that feature dynamic types
I don't think that's true, but I'm open to data that proves otherwise. Prototyping goes quickly in languages that have good libraries (if I want to prototype a new kind of web server, for example, I might try Golang, because it has good libraries for that kind of thing).
"A do-nothing congress, the worst in history." -Truman
It's funny that the lines politicians use keep working for centuries.
The survey included dependent territories, so presumably American Samoa and Puerto Rico.
In this case, you can in principle get some of the benefits of both worlds,
There is an alternative principle to consider: it could actually give you the worst of both worlds.
Plenty of IDEs can already handle this without much of a problem, and as I said, Google closure already does static code analysis which will probably catch any "bad" refactoring you've done.
It's not clear you've understood the problem. The bug is syntactically and semantically correct, so static analysis will not detect it. It's only manifests itself as a behavioral problem. Please try to say something that indicates you understand the issue (if you choose to again reply).
Yeah, actually, requiring setters and getters would be a decent way of working around this particular problem in the language. Good solution. Of course, if you do that, most Javascript programmers will complain and say you are not writing idiomatic Javascript, but that's a problem with the community, not the language.
Flow is cool but will not catch the problem mentioned here. If you are using Typescript then you are not using Javascript, you are using Typescript. I don't even understand why that is confusing to you.
It doesn't solve the problem mentioned here, and Javascript programmers do that kind of thing all the time, even in major libraries like D3.
That is more of a tooling problem, not so much of a language problem
No, tools cannot be made to fix this problem. For example, say I decide to refactor the variable 'message' to be ' outMessage'. Then in one of my code files, I have this line of code, which I fail to refactor:
obj.message = "I <3 Javascript";
That is perfectly legal, and if I miss a usage of the variable later in the same function, it's impossible to detect without understanding the intent of the code, which no tooling can do. It just gets really tough to write large programs in Javascript.
Of course, you can use Typescript as another commenter pointed out, but then you're not using Javascript anymore, you're using Typescript.
When you say refactor do you mean variable scope? Javascript variables are the way they are so that you can use them on the fly without having to pre-declare each and every variable along with it's type which is a god send not a problem. You perhaps just need to get a better handle on how the scope works, that isn't really a language problem, that's a logic problem with your mind.
No, when I say refactor, I mean refactor. I can't imagine the state of mind that would even cause such a confusion. The point is, there might not be any errors, because the usage might be entirely legal
I don't know the legal arguments, but they might say that when the recycler refurbishes the cartridge, they are practicing manufacturing.
Those poor programmers using Javascript. What a lousy language.
(If anyone wants to know why, I will pick one feature out of many. Say you wrote a large program in Javascript, which is happening more often these days. Then you want to refactor by renaming a variable. In Java or C or C# you can refactor by using an IDE automatically, and if somehow you miss an instance, it will be caught at compile time. In Perl or Objective C or Smalltalk, it will caught at runtime in the worst case. But in Javascript, it might not be caught even at runtime, and instead will just cause strange behavior).
It's a three step problem:
1) Consumer buys patented toner cartridge (probably bogus/obvious patent, but that's not at issue here)
2) Consumer returns toner cartridge to recycler.
3) Recycer refurbishes cartridge and re-sells it to someone else.
Lexmark wants to say that after you've used the toner cartridge, you can't give it to someone else, because they didn't license the patent to someone else. The law isn't clear at all on the topic, so the court could go either way. Even the supreme court seemed a bit confused by the situation (this is based on reading the article, not reading the actual law documents).
It's actually heading that direction. It's hard for us as Americans to feel it because we've started getting involved in more wars, but overall the world has been improving and improving.
One way of looking at it is, "rich people aren't willing to risk their lives in war" and as the world gets richer and richer, fewer people are willing to fight in battles.
Probably not, salespeople don't stop saying that kind of stuff. And doctors say it directly to women.
Have you looked at the compiler output from GCC (or llvm)?
Tech workers are [i]saints[/i] in the sexism department compared to salespeople and doctors. One of the few people who ever told me that "women are not biologically as good as men" was an MBA. I've never met or heard a tech guy claim that.
FOXO4 is a complex, complex protein. In some cases it prevents cancer. In other cases, it extends longevity. Apparently in this case it somehow makes you look old. I have no explanation for that, but maybe no one does?
To even consider that a group.....would sacrifice their integrity for grants, or whatever, is absolutely ludicrous.
OK, that's just naive.
Because alcohol carries a risk of liver disease, there are safer ways to lower risk, he says, such as quitting smoking, exercising regularly and eating a healthy diet.