I used to write websites with Notepad. The upside is that you really had to learn HTML to do it; the downside is that it proves to the world that you’re a fucking lunatic.
People seems to be riled up by this, but turbo is mostly used with ruby on rails, right? I’m not familiar with ruby on rails, does it actually support some form of static typing it type hints? From the blog post, the dev (which is also the ruby on rails creator) doesn’t seem to be a fan of bolting static typing into dynamic typing language.
In Ruby, the convention is usually that things are duck-typed (the actual types of your inputs don't matter as long as they implement whatever you're expecting of them, if not, we throw an exception). Type hinting could be possible, but it basically runs contrary to the idea.
Now, Ruby on Rails developers are expecting some kind of magic conversion happening at the interfaces. For example, ActiveRecord maps the database datatypes to Ruby classes and will perform automated conversions on, say, date/time values. But from the developer perspective it doesn't generally matter how this conversion actually happens, as long as there's something between the layers to do the thing.
RoR is very… specific. Some love it because it comes with magic. Many hate it for the same reason.
You either knows the magic and love it, or you hate it with a passion. You never really know when (not if) your change will break the system because it’s supposed to name in a very specific way that work by, again, magic.
I think there’s a positive coming from this competition, though. Apparently this infighting has re-lit the want for type annotations to be embedded in vanilla JS (ECMAScript proposal). I feel like this would be the ideal scenario: things working right out of the box without needing a compile step or additional tooling.
You can get as close as it gets to this experience by using alternative runtimes such as Deno or Bun, which have native TS support (meaning you can just execute a .ts file without having to transpile it), but of course as soon as you have to write code for a browser you are back in the middle ages.
Depending on how it pans out, it’s either not useful enough. Who the hell doesn’t use namespaces or enums. Or - as
These constructs are not in the scope of this proposal, but could be added by separate TC39 proposals.
implies - a door opener to outsource TypeScripts problem unto other peoples and not to investing into improving WebAssembly. That’s just MS being lazy and making their problems other peoples problems.
I feel like this would be the ideal scenario: things working right out of the box without needing a compile step or additional tooling.
It’s just annotations. No proposed semantics of a type system which your browser could check on its own.
Uhhh, typescript devs? Enums were useful once, but typescript evolved everything else around it and these days using direct values is actually far better.
And I don’t think anyone uses Namespaces other than for defining external modules.
My bad, I’m not deep enough into our frontend stack to realize Hjeilsberg already did what he does best - ruining enums. (I guess he is not to blame for global imports in c#, so i can not add ‘questionable import module/namespace ideas’.)
And it seems like this proposal contains type declarations (in order to compensate for their enums), among other typescript specific things. So, guess it is option B, then.
Yeah it’s interesting because JS is interpreted, not compiled. The proposal allows for type annotations in the syntax but no actual interpreter consequences. On the one hand that makes sense because otherwise you’re in the territory of runtime type-checking which would be a huge performance hit and would sort of defeat the purpose of static types anyway. But that means you still have to rely on your IDE or a linter for this to be useful.
I don’t see any practical use case for it as is as anyone wanting to use them would want the full TS feature set anyways, but I could see it being a good step forward for more meaningful features to be added in the future.
To be perfectly frank, I’ve only seen the drama on social media platforms. Outside of this one library Ive hardly seen anyone trying to fight typescript in the professional community.
Mypy is just okay. Haven’t used TS to know the dark corners there, but any type system that’s bolted on to the language is going to have dark corners in the best case.
It’s better than no type system, however. I remember when typed languages were “bad” because it “slowed you down” and “wasn’t necessary if you know what you’re doing”… how naive I was when I repeated those words so many years ago :)
I view it more like a powered exoskeleton around a blob fish. IMO static typing is way more valuable than strong typing and I’d take static typing only over strong typing any day if I can only choose one.
Yeah I love this feature. I love it so much that I’ll also tell everyone who cares to listen how you can use it. Edit your ~/.config/kitty/kitty.conf file to include map ctrl+c copy_and_clear_or_interrupt and you are good to go. Only issue I have that it doesn’t seem to work in the vscode terminal.
Oh what a great way to further entrench a bad habbit! Hang on I need to remedy some refactored code with rm -rf * which Kitty made safe if I’m in a directory with my project files 🙄
Yes! You know what it is, don’t you boy? Shall I tell you? It’s the least I can do. Steel isn’t strong, boy, flesh is stronger! Look around you. There, on the rocks; a beautiful girl. Come to me, my child.
TypeScript of course. The compiler often times catches mistakes in variable names, API methods, whatever. So it saves time by not having to run the whole application all the time. Also the input help is much better, when the editor knows sth is a string or a number, for example.
programmer_humor
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.