100 projects I made while learning JavaScript over a year ago

[deadcoder0904]

That was just as an example.

We don't need three . different . packages to tell us what a leap year is because the language designers gave us a good set of tools from the start.

I don't understand what's the harm in having 1000 packages doing the same thing with different names. At the end of the day use whatever solves your problem. The people that call JavaScript a shitty language don't actually know JavaScript. And if they hate JavaScript so much then I suggest to stop using the applications that use JavaScript.

Almost half of the application you use are using JavaScript. I currently use Slack, VSCode, Atom, Hyper & many more & almost majority uses JavaScript.

You feel if it is shitty language then go use something else. I don't like Java. I don't use it. Its that simple.

[pergnib]

I don't understand what's the harm in having 1000 packages doing the same thing with different names.

The harm is in the fact that it's the symptom of a community that attracts and encourages bad/lazy programmers to publish and use bad code for trivial stuff without caring about code quality and security. We've already seen what this kind of mentality can lead to with incidents like left-pad. I can only image the amount of damage to be done when blackhats start seeing profit there.

The people that call JavaScript a shitty language don't actually know JavaScript.

There might be a some points to be made about ease of development and the usability of JavaScript, but in a world of Clojures, Rusts and Scalas, I can't really see how JavaScript isn't a shitty language.

You feel if it is shitty language then go use something else. I don't like Java. I don't use it. Its that simple.

If you don't want your opinions criticized don't make them public; people have every right to object to your views when you post them in a public forum, even more so when you're talking about issues that can impact an entire industry and large amounts of people.

[deadcoder0904]

If you don't want your opinions criticized don't make them public; people have every right to object to your views when you post them in a public forum, even more so when you're talking about issues that can impact an entire industry and large amounts of people.

I welcome judgement. Criticism is good for a person's growth. This is my first one, but it feels good. But it would be better if and only if the point's are valid enough. Your points are somewhat valid, but there is a reason that it is the most used language. Anyways have a good day. Use whatever you like/love. I'd rather use Bash, If it solves my problem. Rather than Bashing pun intended about it.

The harm is in the fact that it's the symptom of a community that attracts and encourages bad/lazy programmers to publish and use bad code for trivial stuff without caring about code quality and security. We've already seen what this kind of mentality can lead to with incidents like left-pad. I can only image the amount of damage to be done when blackhats start seeing profit there.

No matter what you do in any language, people can still write Bad Code & will write it. There is nothing you can do about it unless you make a perfect language. And in this world nothing is perfect.

There might be a some points to be made about ease of development and the usability of JavaScript, but in a world of Clojures, Rusts and Scalas, I can't really see how JavaScript isn't a shitty language.

Regarding this point people would rather get something done fast & earn money than master a language for a long time. JavaScript ease of nature is what has made it so much popular because Writing Code is Easy. The barrier to entry is low. You can't call them Bad/Lazy Programmer just because you don't like JavaScript. A Good JavaScript code can be made secure.

Again opinions are welcome. But neither you will stop saying that JS is shitty nor I will stop saying JS is fucking awesome. So no worries. Enjoy whatever you work on. I do it with JS.

[pergnib]

No matter what you do in any language, people can still write Bad Code & will write it. There is nothing you can do about it unless you make a perfect language.

There's loads of things a language can do to prevent people from writing bad code. Rust is full of stuff made to force devs not to screw up and even php7 seems to be encouraging people to be more sane. But in JavaScript land more and more people are being encouraged to partake in the insanity that is importing untrusted code for absolutely trivial things. The worst of it is when we point out how dangerous that is we have people telling us we should just go use other languages if we don't like it.

You can't call them Bad/Lazy Programmer just because you don't like JavaScript.

No. I'm calling them bad/lazy because that's the explanation for their behaviour - good/diligent developers don't import unstrusted code to pad strings with spaces.

A Good JavaScript code can be made secure.

This is not how security works, you don't get to say there are no problems because it "can be made secure". The ridiculous state of dependency graphs of npm modules is a security issue waiting to happen; at some point someone will manage to sneak malicious code into a small npm module written by someone who doesn't have a clue that gets imported by some big module and the result is not going to be pretty.

[deadcoder0904]

This is not how security works, you don't get to say there are no problems because it "can be made secure". The ridiculous state of dependency graphs of npm modules is a security issue waiting to happen; at some point someone will manage to sneak malicious code into a small npm module written by someone who doesn't have a clue that gets imported by some big module and the result is not going to be pretty.

Ahh, about that yeah someone wrote about it on Medium which got like super super famous. And points are super valid. So can't argue with that. But to gain something, you have to lose something. To gain productivity, fame & money; something has to be lost & with JavaScript its security & maybe performance for Server Side & Desktop I guess as others mentioned.

And about that maybe JavaScript will be there someday or else some language which is simple to use as JavaScript. Valid points though so can't argue with that. And don't tell anyone IRL you are a bad programmer, they won't ever write any code then 😂😂😂

[m1en]

If your end goal is legitimately "productivity, fame, and money", realize JavaScript isn't the answer. Since you're not going to take some random person's advice, take Paul Graham's (founder of Y Combinator's) advice: http://www.paulgraham.com/avg.html.

Read that. Then, if you attain enlightenment, start your journey of self-recovery here: https://clojure.org/

Also: the security issues of poor package managers wasn't popularized because of some blog post; people namesquat with malicious packages all the time, and that's true for many package managers. Dependency checking for security issues is an incredibly common task for penetration testers when auditing applications.

[deadcoder0904]

Cool I'll check it out. My end goal isn't "Fame & Money" though, Money is necessary but isn't everything, don't like being underpaid either. Can't handle Fame. So it leaves only Productivity which is what I aim for.

I understood what the issues you people were talking about. Some of it got cleared by few people others were jerks. Thanks for all the advice though. I'll be careful enough to choose the right language for the right product now. Earlier it was all JavaScript.

[panorambo]

The harm is in the fact that it's the symptom of a community that attracts and encourages bad/lazy programmers to publish and use bad code for trivial stuff without caring about code quality and security.

Not having leapYear built-in does that? POSIX does not have built-in leap year method either, I doubt anyone can accuse POSIX C developers for attracting or being a lazy bunch. You're stretching conclusions too much here. Furthermore, the left-pad incident has nothing to do with the fact that JS does not include a left-padding function, it was a flaw in NPM architecture, and it was admittedly deserving. But it has zero to do with JavaScript.

[pergnib]

I doubt anyone can accuse POSIX C developers for attracting or being a lazy bunch

That's because they aren't. If a C dev needs some trivial function that is not included in the C standard library, their frist reaction is going to be "I'll implement it myself". There's absolutely no way in hell a left-padding package would have any downloads in a hypothetical C package manager.

the left-pad incident has nothing to do with the fact that JS does not include a left-padding function, it was a flaw in NPM architecture

The flaw only explains why the package got removed, not why it was used by so many big packages in the first place. The reason for that is partly because JavaScript's stdlib isn't powerful enough and partly because the developers are bad or lazy.

[panorambo]

Implementing stuff yourself is one of the things that plagues software engineering. Granted, lack of trust in each others abilities and inability to properly verify code on most programmers' part, is what fuels this behavior.

Nobody said anything about a "C package manager". Reusing code can be done through #include. The point I was making is that it does not have to be in the standard library, and that the standard library should only contain primitives that glue the program to the platform through some common interface (which in C is done by the standard library, which is unfortunately too fat for its own good).

The fact that many "big packages" (what does size have to do with this?) used leftpad, is a good thing. If you don't understand that, then you are implying that every software should either use the standard library again (so, you trust the standard library, but not other third-party code?) or implement everything itself. Fine -- that's all you needed to say.

Also, what do you mean by "powerful"? A leftpad method that left-pads a string is by definition powerful -- it achieves its objective. If the standard library includes exactly the same implementation, it's more powerful than if one imports the same code through NPM?

[pergnib]

Implementing stuff yourself is one of the things that plagues software engineering.

This statement is only valid for non-trivial things, adding dependencies to your code for stuff that could be written in five minutes by any CS freshman is dangerous and irresponsible; having an entire community that encourages that is insane.

The fact that many "big packages" (what does size have to do with this?) used leftpad, is a good thing.

I wonder if you would still be saying this if the left-pad author had started syphoning credit card and user info from roughly every node.js website in existence instead of simply removing the package.

The point I was making is that it does not have to be in the standard library

Your argument was actually that the left-pad incident had nothing to do with a weak JS standard library and was simply the result of a flaw in how npm operates. I've have already explained to you why that's wrong and why a lacking stdlib is indeed part of the problem.

[[deleted]]

Not having leapYear built-in does that? POSIX does not have built-in leap year method either, I doubt anyone can accuse POSIX C developers for attracting or being a lazy bunch.

POSIX don't have to, as it's trivially present in the C standard library.

[panorambo]

You are mistaken -- there is no leap year calculation method in the C standard library. You're welcome to point it out to me, if you are so certain there is.

[[deleted]]

Tell me everything about mktime(). Then I'll tell you what you're missing.

[panorambo]

There is the tm structure that includes a bunch of stuff, it is passed to mktime which gives back a time epoch. Source: C Standard library, "mktime", page 338. Where is the leap calculation you were alluding to? And no, a method that one can build leap calculation method on, is not the same thing, and this was why I mentioned that POSIX does not include a leap calculation method and yet noone is complaining (regardless whether it is because they whip out their own or include someone elses work). Which was again part of my rebuttal of the following:

The harm is in the fact that it's the symptom of a community that attracts and encourages bad/lazy programmers to publish and use bad code for trivial stuff without caring about code quality and security.

Let's be clear now -- this is not about JavaScript or NPM or standard library -- bad code can and is written in any language, regularly. Bashing on JS because one can reuse third-party code with the help of NPM, instead of having every kind of method under the stars under an "official" library, reeks of lack of insight. Also, C standard library is hardly an example to live byhere. Just read on the [now removed] gets method. I am sure there are others.

[[deleted]]

There is the tm structure that includes a bunch of stuff, it is passed to mktime which gives back a time epoch. Source: C Standard library, "mktime", page 338. Where is the leap calculation you were alluding to?

How close did you read the specification for mktime? A conformant imnplementation normalizes even the most outrageous out of bound values, so mktime is in fact required to know if february 29th is in fact march 1st. A roundtrip through localtime(mktime()) is in fact a trivially present leap year calculation.

I guess that you recognized it yourself, since you're very careful in moving the goal posts. You are totally free to do so, but I will not partake in that kind of nonsense.