TRWTF is the entire JS ecosystem
-
I just have to ask it: have you heard of any real-world, practical problems, that have been solved by using TypeScript, on any project ever? Note that "taxonomy asswankery" and "but statically typing everything is god!!!" are not practical problems.
On the other hand, "a fuckton of toolchain added" and "the compiler shits itself sometimes" are quite practical, real-world problems encountered by everyone who had to use TypeScript.
-
@wft said in TRWTF is the entire JS ecosystem:
I just have to ask it: have you heard of any real-world, practical problems, that have been solved by using TypeScript, on any project ever? Note that "taxonomy asswankery" and "but statically typing everything is god!!!" are not practical problems.
Is
Cannot read property '0' of undefineda practical enough problem?
-
@Gąska and how exactly did TypeScript help you mitigate that?
-
@wft with static typing.
-
@Gąska And strict null checks, probably.
-
@Gąska It's an answer of the class "the sun is shining".
You declare your variable as being an array. You AJAX something from the server:
let hotBabes: Array<HotBabe> = await axios.get('/hotbabes/latest'); // which returns Any, or Object, or what have you for (let i: number = 0; i < hotBabes.length; i++) { // The server hates you today and you've got nullNow don't tell me that I should spend a fuckton of time and wrap every possible API endpoint to return strict interfaces, specially crafted. This is not in the budget.
In plain Javascript, I tell "fuck taxonomies", and do this in a couple seconds:
let hotBabes = await axios.get('/hotbabes/latest') || [];
-
>be @wft
>don't bother with making type definitions
>complain that static typing doesn't help
-
@Gąska, the world is full of statically-typed software which still has byzantine numbers of bugs. Guess static typing doesn't help them very much. True, this single kind of error can be weeded out (and you would still need to handle that shit, only elsewhere, say in your API handlers), but the number of semantic bugs, which happen because the valid code is doing stupid things, won't be reduced by much — with all the added type-wankery on top.
-
@wft said in TRWTF is the entire JS ecosystem:
I just have to ask it: have you heard of any real-world, practical problems, that have been solved by using TypeScript, on any project ever? Note that "taxonomy asswankery" and "but statically typing everything is god!!!" are not practical problems.
On the other hand, "a fuckton of toolchain added" and "the compiler shits itself sometimes" are quite practical, real-world problems encountered by everyone who had to use TypeScript.
It solved the problem of "the IDE can't figure this shit out, so everything I type autocompletes to everything I've ever typed" in JS. Changing to TypeScript allowed the autocomplete to offer sane suggestions most of the time.
-
@wft said in TRWTF is the entire JS ecosystem:
@Gąska, the world is full of statically-typed software which still has byzantine numbers of bugs. Guess static typing doesn't help them very much.
It did. You just don't see it in statistics - because all those would-be-bugs have been detected instantly during compilation and never even hit the repo. Leaving only the bugs that cannot be detected by type system. And the better type system, the less bugs get through.
Seatbelt doesn't make you immortal, but it still helps a lot. Same with static types.
True, this single kind of error can be weeded out (and you would still need to handle that shit, only elsewhere, say in your API handlers), but the number of semantic bugs, which happen because the valid code is doing stupid things, won't be reduced by much — with all the added type-wankery on top.
You're right. But semantic bugs are at least an order of magnitude less common than typos, misreads, and other situations where the thing you're passing to a function ends up not being the thing the function expected.
-
@Gąska I'm wondering if all those things come from the impedance mismatch you get when you program for X years using one toolbox, and then you get another toolbox with its own set of perks and tradeoffs.
I've programmed exclusively in dynamic languages for 16 years now. Of course, I was taught programming on Pascal and C (C, with its typing being static but weak, is a nice example of fuckness you can get). But in general, I internalized the tradeoffs and I usually know where to look for trouble (also in someone else's code). That's why I don't understand why some folks get exalted with TypeScript, it looks too much like an overhead to me.
Now, I don't hate languages which were statically typed right from the start. In, say, Java, you define your taxonomy right from the start, it comes with the territory, and it's accepted because that's how things are done. It's putting static typing onto a dynamic language that I cannot stand. I feel like I'm in a European house, but all appliances inside are made for the US, and suddenly I need a voltage transformer in every friggin' outlet. And I just feel that the ratio of wins to the added work is not very good there.
-
@Gąska said in TRWTF is the entire JS ecosystem:
You're right. But semantic bugs are at least an order of magnitude less common than typos, misreads, and other situations where the thing you're passing to a function ends up not being the thing the function expected.
The über-dynamic language I kind of tolerate because it pays my bills, Perl, has a nice error about variables you didn't declare at all but are using (so does Python), and a warning for variables you only used once. Does magic at catching typos, I wish more dynamic languages had that. (However, plain variables is where the magic stops; it cannot do jack for, say, hash keys which is what you deal with a lot nowadays. Also, doesn't help if your typo matches a variable from an outer scope.)
-
@wft said in TRWTF is the entire JS ecosystem:
Now, I don't hate languages which were statically typed right from the start. In, say, Java, you define your taxonomy right from the start, it comes with the territory, and it's accepted because that's how things are done. It's putting static typing onto a dynamic language that I cannot stand. I feel like I'm in a European house, but all appliances inside are made for the US, and suddenly I need a voltage transformer in every friggin' outlet. And I just feel that the ratio of wins to the added work is not very good there.
This is a reasonable statement where your initial, "doesn't solve any problems" wasn't. Engineering is always about trade offs and we'll never agree on all of them. Sometimes I like having the...freedom of javascript but sometimes it drives me crazy and I'm happy to get back into java.
I've never used typescript so I can't really say anything useful on that specific topic.
-
@wft said in TRWTF is the entire JS ecosystem:
Now, I don't hate languages which were statically typed right from the start. In, say, Java, you define your taxonomy right from the start, it comes with the territory, and it's accepted because that's how things are done. It's putting static typing onto a dynamic language that I cannot stand. I feel like I'm in a European house, but all appliances inside are made for the US, and suddenly I need a voltage transformer in every friggin' outlet. And I just feel that the ratio of wins to the added work is not very good there.
You're looking from a wrong angle. Well, not really wrong - but there's a different angle that's more useful here. Don't look at languages. Look at projects. It's the project that you start, it's the project that you define taxonomy in. A brand new project in TypeScript is no different from a brand new project in Java, when it comes to typing. A good type hierarchy will be very helpful on every step of the way. And it takes almost no effort to write all the definitions (especially when you maintain proper documentation, in which case you have to list types of every parameter of every function anyway, static types or not).
I agree it isn't always worth it to retrofit static types on already existing, already mature, already working JS project. And I agree that when your project consists mostly of calling the upstream libraries and has little logic of its own, coming up with static interfaces for all your dependencies is also not worth it. But in general, types help. A lot. Especially when you don't have 16 years of experience.
-
@wft said in TRWTF is the entire JS ecosystem:
the world is full of statically-typed software which still has byzantine numbers of bugs
Most places where you have type problems, it's because you have real bugs. But not always (and sometimes the contortions to make the types work are themselves the source of bugs, alas). And many bugs do not relate to type problems at all; there are whole huge bunch of other ways that things can fail.
-
@levicki all the programming best practices books already banned copy-paste. It's commonly known as the DRY principle.
-
@Gąska said in TRWTF is the entire JS ecosystem:
@levicki all the programming best practices books already banned copy-paste. It's commonly known as the DRY principle.
I hope it's more a guideline than an outright ban because there's also the YAGNI principle.
The best way of putting it which I've heard so far: "If you need it once it's just coincidence. If you need it twice it could be chance. If you need it thrice you better reuse or pay the price" (the lack of correct rhyme is left as an exercise for the reader to fix - suggestions welcome).
The general idea is that it's no use to create an utility method if you need some function once, and while two different places in the code might at one point be served by identical code it might as well turn out that one of the copies needs to be radically altered once there are new requirements. When you encounter several copies of the same code though you should have a far better idea about what can be reused and what can't.
Also, I'd take a copy/paste + refactor job of some piece of code over anyone failing to follow reasonably safe refactorings / rewriting a piece of code from scratch. I used to work with one dev who was adamant that he could restructure code better when he would start from scratch, thus reintroducing bugs which were actually fixed in the original code. Having a the original and gradually phasing it out at least keeps things under control....
-
@levicki said in TRWTF is the entire JS ecosystem:
@Gąska said in TRWTF is the entire JS ecosystem:
It was already a marginal difference ten years ago. And with each year it's only getting smaller. Better focus on big picture algorithms.
I happened to help optimize Efficient genotype compression and analysis of large genetic variation datasets 3 years ago. I wrote the innermost loop in 15 minutes by hand on A4 paper while sitting on the toilet using AVX2 instructions and they got 8x speedup as expected because compiler couldn't vectorize the code. So, depending on the algorithm, compilers can still fail to produce fast code.
You're special. Congratulations. Now, could you get off your high horse for a moment and look at the other 99.99% of software industry? Where most time is spent waiting on user input and network sockets (sometimes disk I/O)?
Yes, I realize there are still some areas where nothing can beat hand-written assembly.
Indeed, and it happens more often than you think
A mind reader! Cool!
because compilers cannot understand the flow of data the way a highly skilled human can on a very small scale.
FTFY.
If used right,
mallocis no worse than GC or smart pointers.Isn't GC always worse for realtime systems because it is unpredictable?
No. For someone so well versed in modern computer architectures, you should know better than that.
Teaching entire generations of programmers to never use goto has saved the IT industry tens if not hundreds of billions of dollars in dealing with fallout from fatal bugs caused by its improper use.
I think you are exaggerating here. I think that the reduced usage of goto coincides with increased usage of (structured and otherwise) exception handling which was not available at the beginning as a built-in language construct.
It also coincided with all programming forums getting flooded with references to that "GOTO considered harmful" article.
Yes, you can write horrible buggy code with any language and any programming constructs, but goto makes it much easier.
The problem as I see it are the tools and languages which not only allow any idiot to "write code" but make it trivial to build anything using Lego programming concept. There is an abundance of "write only developers" who can't read code at all, and who have no idea how to implement the most basic algorithms, heck some of them don't even know booleans, bits, bytes, and difference between && and & in logical expressions. Firing up WinDbg and analyzing a crash dump or attaching to a process using remote debugger seems like arcane magic nowadays.
You're like some kind of anti-Blakeyrat. While he always went on lengthy rants about how programming should be no harder than writing Word documents so everyone and their dog could write userscripts for everything they need, you seem to have gone over the edge on the other side.
@Gąska said in TRWTF is the entire JS ecosystem:
all the programming best practices books already banned copy-paste. It's commonly known as the DRY principle.
What I meant is disable Ctrl+C/Ctrl+V in editor.
So you're not anti-copy-paste, you're anti-useful-features-and-making-life-easier-for-everyone-yourself-included.
-
@Gąska said in TRWTF is the entire JS ecosystem:
You're special. Congratulations. Now, could you get off your high horse for a moment and look at the other 99.99% of software industry? Where most time is spent waiting on user input and network sockets (sometimes disk I/O)?
I don't think anybody claimed that those kind of apps needed low-level hand-tuning. The claim is that your "hand tuning is a thing of the past" argument is false. There are still domains where a competent developer can outperform a compiler significantly.
@Gąska said in TRWTF is the entire JS ecosystem:
No. For someone so well versed in modern computer architectures, you should know better than that.
Yeah, try using non-deterministic GC in hard-realtime system. Good luck.
-
@Zerosquare said in TRWTF is the entire JS ecosystem:
@Gąska said in TRWTF is the entire JS ecosystem:
No. For someone so well versed in modern computer architectures, you should know better than that.
Yeah, try using non-deterministic GC in hard-realtime system. Good luck.
Yeah, try finding the words "non-deterministic" in anything I said. Good luck.
-
Okay. Show me a language that allows you to control when the GC runs and has hard limits on memory usage and execution time when GCing.
-
@Zerosquare I don't work in embedded, so I never really researched it, but I've seen some papers and articles on hard real time GCs. Upper resource limits aren't hard to achieve - just stop GC dead in its tracks when reaching the limit (a huge simplification but that's the general idea). Predictability can be achieved by manually invoking GC periodically by the main processing loop. I've also heard of some kind of null garbage collector that analyzes the code at compilation time and assigns all possible objects static storage space - can't remember details though. I think it was some JVM-ish thing, but don't take my word for it.
-
@levicki said in TRWTF is the entire JS ecosystem:
Isn't GC always worse for realtime systems because it is unpredictable?
Soft realtime or hard realtime? You can have GC in soft realtime provided you can prove that the amount of work it does is limited enough, or that it only does it when the timing guarantees aren't a problem.
-
@JBert said in TRWTF is the entire JS ecosystem:
The general idea is that it's no use to create an utility method if you need some function once,
Sometimes it is a good idea to make one anyway, just because it splits the code up into more comprehensible pieces.
-
@dkf I believe it's more a matter of abstraction. You can split it off into a separate function for organisation, but that function doesn't need 20 parameters to make it as general as possible.
-
@Zerosquare Any language where it's a library instead of a language feature. For example, a garbage collection library in Rust would be able to do all that.
-
@dkf said in TRWTF is the entire JS ecosystem:
@JBert said in TRWTF is the entire JS ecosystem:
The general idea is that it's no use to create an utility method if you need some function once,
Sometimes it is a good idea to make one anyway, just because it splits the code up into more comprehensible pieces.
Maybe I must clarify "utility method" as "a function shared with the world in some library somewhere".
Since I work in .NET all day it's a no-brainer to make private methods inside a class if that helps clarify the code flow of the actual methods implementing public methods. The difference then lies in that making a public utility method means you have to go and edit another project (or another set of classes if you use a single project), think of a good name, document the interface, etc.
For a single bit of code you don't want to do that overhead just yet. Even if you predict that some bit of code might be reused further along the line, it's better to wait until you fully understand that other usage as well.
-
@pie_flavor said in TRWTF is the entire JS ecosystem:
@Zerosquare Any language where it's a library instead of a language feature. For example, a garbage collection library in Rust would be able to do all that.
No, whether it's a language (actually, you should've said runtime) feature or library feature is irrelevant. Both can be terrible. Both can be great. Runtime GC actually has greater potential to be great than library GC. But I appreciate your tireless, mostly unwarranted Rust evangelism.
-
@JBert said in TRWTF is the entire JS ecosystem:
Maybe I must clarify "utility method" as "a function shared with the world in some library somewhere".
That's just a matter of visibility. If the same private method is called from multiple places inside one class, it's arguably still a utility method. If it's called from one place, but factors out a chunk of code that has a good meaning by itself (e.g., by doing a complex filter and sort) and which ends up simplifying things, it's still great to have and provides utility functionality which the rest of the code can just rely on being there.
Alas, some of my colleagues are terrible at this. They don't split things out, split the wrong things out, and pick bad names (
HelpfulFunctions.doTheStuff()being a classic real example; I lost my temper over that one).
-
@dkf said in TRWTF is the entire JS ecosystem:
(HelpfulFunctions.doTheStuff() being a classic real example; I lost my temper over that one).
This calls for an office pillory.
-
@Carnage defenestration even.
-
@Gąska We threatened to clean the guy's tea mug with coal tar soap.
-
This tweet made me wonder: if we actually printed the dependencies of a "hello world" create-react-app app, how tall would the stack of paper be? Let's calculate.
We'll use Pages' default margins and font size (11 pt). I arbitrarily choose Consolas as the font. That gives 49 lines of code per sheet.
tokei node_modules† reports 2,669,088 lines in the node_modules of a newly-generated create-react-app 2.1.8 app. Dividing by 49, that's 54,471 sheets of paper.A sheet of copy paper is about 0.1 mm thick. https://hypertextbook.com/facts/2001/JuliaSherlis.shtml
Multiplying sheet count by thickness, we get 5,447.1 mm = 5.4471 meters ~= 17.871 feet.
Returning to the original photo of Margaret Hamilton standing next to a printout of her node_modules directory... the paper is about as tall as her. Therefore, Margaret Hamilton is almost 18 feet tall.
Source: @garybernhardt
†
Tokei is a program that displays statistics about your code. Tokei will show number of files, total lines within those files and code, comments, and blanks grouped by language.
Bonus from the replies:
GitHub - technomancy/bludgeon: Bludgeon is a tool which will tell you if a given library is so large that you could bludgeon someone to death with a printout of it.
Bludgeon is a tool which will tell you if a given library is so large that you could bludgeon someone to death with a printout of it. - technomancy/bludgeon
-
@DCoder said in TRWTF is the entire JS ecosystem:
† Tokei is a program that displays statistics about your code. Tokei will show number of files, total lines within those files and code, comments, and blanks grouped by language.
That's kinda cool... Now I'm curious just how our code stacks up... (C++).
-
@DCoder Why is Harry Potter wearing a skirt?
-
@DCoder it just so happened that I've used create-react-app today to create React app. After it was done, its node_modules weighed almost exactly 200MB, and contained a little over 34,000 files.
-
Fortunately, some countries are finally taking measures against the evil of JS:
JavaScript infinite alert prank lands 13-year-old Japanese girl in hot water
Girl charged with spreading an unauthorized malicious program.
-
@Zerosquare for fuck's sake. That's even worse than UK police's crusade against Muslim memes.
-
Yeah. That's insane.
-
@Gąska said in TRWTF is the entire JS ecosystem:
That's even worse than UK police's crusade against Muslim memes.
It just goes to show: there's nothing that can't be made worse by adding Javascript!
-
Tangentially related: https://www.reddit.com/r/programming/comments/azho2c/css_to_get_support_for_trigonometry_functions/
TL;DR: CSS Working Group approves support for trigonometric functions in calculations.
You could previously sayheight: calc( 100% - 10px ), and now you can sayheight: calc( 100% - tan( 45deg ) ). Rather nice if you have a use for it.
(Yes, CSS has variables to make calculations even more useful, but that's been around for a while and outside the scope of this change.)/r/programming loses its mind about how there are no real use cases for trig and people should just calculate and animate all the things manually in JS and leave CSS alone. The stupidity hurts.
Why the hell is CSS being used in this way?! Why does it even have those capabilities?! I thought CSS was for applying styling to HTML documents. Calculations etc should be done in JS. This is Electron all over again.
-
@DCoder said in TRWTF is the entire JS ecosystem:
/r/programming loses its mind about how there are no real use cases for trig and people should just calculate and animate all the things manually in JS and leave CSS alone. The stupidity hurts.
Why the hell is CSS being used in this way?! Why does it even have those capabilities?! I thought CSS was for applying styling to HTML documents. Calculations etc should be done in JS. This is Electron all over again.
Is there an API to submit house-burning requests for @Polygeekery's consideration?
-
@dkf said in TRWTF is the entire JS ecosystem:
@Gąska said in TRWTF is the entire JS ecosystem:
That's even worse than UK police's crusade against Muslim memes.
It just goes to show: there's nothing that can't be made worse by adding Javascript!
alert("Mohammed is a p#censored_outside_garage#ile");
-
@DCoder said in TRWTF is the entire JS ecosystem:
Tangentially related: https://www.reddit.com/r/programming/comments/azho2c/css_to_get_support_for_trigonometry_functions/
TL;DR: CSS Working Group approves support for trigonometric functions in calculations.
You could previously sayheight: calc( 100% - 10px ), and now you can sayheight: calc( 100% - tan( 45deg ) ). Rather nice if you have a use for it.
(Yes, CSS has variables to make calculations even more useful, but that's been around for a while and outside the scope of this change.)/r/programming loses its mind about how there are no real use cases for trig and people should just calculate and animate all the things manually in JS and leave CSS alone. The stupidity hurts.
Why the hell is CSS being used in this way?! Why does it even have those capabilities?! I thought CSS was for applying styling to HTML documents. Calculations etc should be done in JS. This is Electron all over again.
This just makes me wonder: is CSS fucked up enough that it is Turing complete already?
And if so, do browser have protections against it like they do with long-running scripts?
-
@Gąska said in TRWTF is the entire JS ecosystem:
@levicki I'm all for banning all human-written
JMPinstructions.Unless the human is writing assembly?
-
@djls45 no.
-
@topspin said in TRWTF is the entire JS ecosystem:
This just makes me wonder: is CSS fucked up enough that it is Turing complete already?
I'm fairly sure it has been for a while.
And if so, do browser have protections against it like they do with long-running scripts?
I like the direction of your thoughts.
-
@dkf as far as I can tell, it used to be Turing-complete, but further changes in HTML and CSS has made all the websites using that trick to stop working.
-
@DCoder said in TRWTF is the entire JS ecosystem:
Tangentially related: https://www.reddit.com/r/programming/comments/azho2c/css_to_get_support_for_trigonometry_functions/
TL;DR: CSS Working Group approves support for trigonometric functions in calculations.
You could previously sayheight: calc( 100% - 10px ), and now you can sayheight: calc( 100% - tan( 45deg ) ). Rather nice if you have a use for it.
(Yes, CSS has variables to make calculations even more useful, but that's been around for a while and outside the scope of this change.)/r/programming loses its mind about how there are no real use cases for trig and people should just calculate and animate all the things manually in JS and leave CSS alone. The stupidity hurts.
Why the hell is CSS being used in this way?! Why does it even have those capabilities?! I thought CSS was for applying styling to HTML documents. Calculations etc should be done in JS. This is Electron all over again.
I wish they'd work on making basic things, like just centering stuff vertically, work without using crazy hacks first. The last time I had to use CSS it was just infuriating, for what seemed like no good reason.
-
@Cursorkeys not a web developer but a few years ago I found flexbox was widely supported and would do all the layouts I wanted, including simple centering. The CSS hacks are a thing of the past by now (unless legacy devices?)
