Early on in my career, I had to do a project in Python, together with another junior. Neither of us had any clue how to handle Python and he was on Windows, so, if I remember correctly, he had to install some dependencies from Pipenv, others from Conda, and his setup would break every two weeks in novel ways.
Eventually, we became quite good at installing a working setup, but correctly removing the broken setup was a pain. Often times, I thought that just reinstalling the whole OS would be quicker. 🫠
Every now and then a new hire comes along with a windows pc, every time they decide they want to try to get everything working on windows, after a week they give up.
No clue, all i know is that i never have to do more than that, and noone has managed to get it working on windows 🤷♂️
When i started learning programming, everything was always a pain to set up, needed to install weird IDEs from shady websites and they only worked half the time. Then a friend showed me linux where stuff just worked out of the box, just slap some code in a textfile and compile it, i never looked back (was working in c/c++ but from what i’ve seen it’s not much better for python)
Since some wsl features started coming with windows out of the box python has been pretty trivial to install. It's a far cry from the conda/cygwin nightmare hell scape it used to be
I believe, it’s because various Python libraries ship with a pre-compiled C/C++/Rust library. That library needs to be compiled for a specific target, and you often only get Linux x86_64 on Pypi, because that’s what most library devs use themselves.
Conda tries to solve that by providing a separate repository, where they do have builds for more targets available, but as a result, they have fewer libraries available in that repo. That’s why we needed to install some via Conda and some via Pipenv/Pypi.
Last time I checked, it was way easier in Windows to have a VM running Linux just for Python, than to get Python to reliably work nativelly in Windows.
'Yes boss, I need 16-Bit, 32-Bit and 64-Bit Arm and x86_64 ASM as well as MySQL, SQLite, Postgres, Firebird, Mongo and all other stuff too, so I need a lot of computers … of course all with Threadripper PRO 7995WX’s.
I’m a school bus driver, and one of my weirder experiences is listening to a middle-school boy ripping on some middle-school girl for having “only” ten thousand followers.
That’s worrying. Imagine what things like that do to those poor children. I hope she can come up with the money to buy some more followers at least. /s
When I was in middle school, social media might have been omnipresent but even the really popular kids never exceeded 1,000 followers. In high school you could increase the upper limit on followers, but most people hovered around 250 to low 1,000s depending on their popularity. And I never heard anyone talk about their follower quantity, let alone insult people over it. I suppose this is my “kids these days” moment.
Then again, we all just had personal accounts for our friends to follow and weren’t trying to be some big influencer or social media star—maybe that’s what these kids are trying to do? Either way, I am really hoping what you overheard was just banter or an ironic joke between the two, and not legit bullying.
Yup. The libraries underneath will still allow nonsense at runtime, though, and it will now be harder to see, so it’s a partial solution as done in standard practice.
An all-TypeScript stack, if you could pull it off, would be the way to go.
Most libraries have TypeScript types these days, either bundled directly with the library (common with newer libraries), or as part of the DefinitelyTyped project.
DefinitelyTyped is the exact kind of thing I’m talking about. You put TypeScript definitions over things, but under the hood it’s still JavaScript and can fail in JavaScript ways.
It can’t fail in javascript ways that require specific sequences of code to be written, if those sequences of code aren’t in the range of output of the Typescript compiler.
If there was an easy way to use rust or something on webassemly and use that instead of JS. I’d be so happy, but I can’t find how to do it without npm.
Doesn’t look like it, unfortunately. But it’s planned. Kotlin can also compile to JavaScript with DOM manipulation. I’ve not tried either scenario, myself.
Rust would probably be the wrong tool here. This is scripting, so pointers like Rust is built around aren’t really meaningful. Kotlin or Python or something are more on the ticket.
Websites have grown beyond mere scripting.
Rust is about more than just nicer pointers, it has a very expressive type system that enables correctness rarely seen outside FP.
You can use WebAssembly today, but you still need some JS interop for a bunch of browser features (like DOM manipulation). Your core logic can be in WebAssembly though. C# has Blazor, and I wouldn’t be surprised if there’s some Rust WebAssembly projects. I seem to recall that there’s a reimplementation of Flash player that’s built in Rust and compiles to WebAssembly.
Yeah, ideally TypeScript would be natively supported. Or maybe just Python, which is sort-of strictly typed, and definitely won’t do “wat”. Alas, it’s not the world we live in, and browsers take JavaScript.
Python supports type hints, but you need to use a type checker like Pyre or Pyright to actually check them. Python itself doesn’t do anything with the type hints.
The libraries underneath will still allow nonsense at runtime
Only if you use a badly written library. Most libraries have types provided by DefinitelyTyped. Those who don’t are (in my experience) so tiny that you probably aren’t using them; or, if you really wanted, can check yourself.
In the end, if you encounter a bug, it’ still 99% of the time not a library’s fault, even if it’s written in plain JS.
Like I said to the other person, those are just types over top of JavaScript that can still fail if/when coercion happens under the hood.
I don’t even know how to search it now, but a specific example came up on here of a time when JavaScript libraries will cause problems, and problems you can’t even see very well if you’re expecting it to act strictly-typed.
By that logic what we really need is a modernization of Ada, where there are no compiler warnings and anything that would generate one in another language is instead a compiler error, everything is strongly typed, etc, etc.
If you aren’t familiar with Ada, just imagine Pascal went to military school.
That analogy was chosen for a reason. Ada was originally developed by DOD committee and a French programming team to be a programming language for Defense projects between 1977 and 1983 that they were still using at least into the early 2000s. It’s based on Pascal.
It was intended for applications where reliability was the highest priority (above things like performance or ease of use) and one of the consequences of that is that there are no warnings - only compiler errors, and a lot of common bad practices that will be allowed to fly or maybe at worst generate a warning in other languages will themselves generate compiler errors. Do it right or don’t bother trying. No implicit typecasting, even something like 1 + 0.5 where it’s obvious what is intended is a compiler error because you are trying to add an integer to a real without explicitly converting either - you’re in extremely strongly-typed country here.
Libraries are split across two files, one is essentially the interfaces for the library and the other is it’s implementation (not that weird, and not that different than C/C++ header files though the code looks closer to Pascal interface and implementation sections put in separate files). The intent at the time being that different teams or different subcontractors might be building each module and by establishing a fixed interface up front and spelling out in great detail in documentation what each piece of that interface is supposed to do the actual implementation could be done separately and hypothetically have a predictable result.
I know a place where they still do this. They’ve got an 8-digit user count, 7 digit monthly profits, all running on one server that costs something like $20 a month. They’ve downsized a few years ago to single-digit employee number and just sit there and collect profits. And this is why I’m now working for a company that casually dropped a few grand for a glorified CPU usage meter and a few grand on top of that for deployment tool that does the same thing that the old guy at a former place was doing with his trusty FTP client.
In node, I get the same result in both cases. “[object Object]”
It’s calling the toString() method on both of them, which in the array case is the same as calling .join(“,”) on the array. For an empty array, that results in an empty string added to “[object Object]” at either end in the respective case in the picture.
Not sure how we’d get 0 though. Anybody know an implementation that does that? Browsers do that maybe? Which way is spec compliant? Number([]) is 0, and I think maybe it’s in the spec that the algorithm for type coercion includes an initial attempt to convert to Number before falling back to toString()? I dunno, this is all off the top of my head.
The inspector REPL evaluates as a statement-with-value (like eval), so the {} at the beginning is considered an empty block, not an object. This leaves +[], which is 0. I don’t know what would make Node differ, however.
I thought IIFE’s usually looked like (function (…params) {})(…args). That’s not the latest way? To be honest I never used them much, at least not after arrow functions arrived.
I’ve read different defenses for JavaScript for cases like this, which usually runs somewhere from you shouldn’t be doing that anyway all the way up to if you just understood the language better you’d know why. While I agree with both of those points strongly as general principles, JavaScript also violates the principle of least surprise enough to make it concerning.
For what it’s worth, I do like JavaScript. I really don’t think that there is any perfect programming language.
JavaScript, like some other languages of the time, was designed with the Robustness Principle in mind. Arguably the wrong end of the Robustness Principle, but still.
That is, it was designed to accept anything that wasn't a syntax error (if not a few other things besides) and not generate run-time errors unless absolutely necessary. The thinking was that the last thing the user of something written in JavaScript wants is for their browser to crash or lock up because something divided by zero or couldn't find an object property.
Also it was originally written in about five minutes by one guy who hadn't had enough sleep. (I may have misremembered this part, but I get the feeling I'm not too far off.)
Sure. But in a sane language doing something totally nonsensical like that is an error, and in a statically typed language it’s a compiler error. It doesn’t just silently do weird shit.
Agreed! Unfortunately these maddening behaviors were kind of set in stone several decades ago, and it has been (correctly) decided “Don’t break the web”, these weird quirks are kept in modern interpreters/compilers.
It’s actually quite interesting to read through the logic to follow when implementing an interpreter:
programmer_humor
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.