Waaah, I don't get paid to use new shiny languages
-
@error said in Waaah, I don't get paid to use new shiny languages:
@PotatoEngineer said in Waaah, I don't get paid to use new shiny languages:
If you'd used thing.a.b.c == null instead of _.isEmpty, then the above code works as you'd like – the compiler is bright enough to see that we're inside of an if block where thing, a, b, and c were all verified to be non-nil. But TypeScript can't figure out what's going on inside functions, so it throws errors at you: Lodash, which you've scattered everywhere because of how useful it is, has suddenly become an impediment. But fortunately, TypeScript gives you an out! Much like ?. is short for "access that property, or give me undefined if the object I was using was nil", TypeScript has !., the "shut up you damn compiler, I know it's not null, stop bothering me!" operator.
The problem is that the lodash type files (
.d.ts
files) don't indicate that they're performing a type assertion. This is more a problem with the library than the language, but the end result is it's too unwieldy to actually use either way.Yeah, I've worked with type files. I think the right type for _.isEmpty is
isEmpty(value: string | any[] | [] | null | undefined) value is "" | [] | null | undefined
, with a possible <T> instead of any. Writing the inverse is almost-easy, except that there's no good type for "string that has 1 or more characters in it". But you can, at least, dohasValues(value: string | [any, ...any[]] | any[] | null | undefined): value is string | [any, ...any[]]
to get the "non-empty array" bit.
-
@Rhywden said in Waaah, I don't get paid to use new shiny languages:
@error That's what I "love" about Typescript - not only do you have to deal with the quirks, no you have to learn a separate definition language as well. The stuff in those
.d.ts
files sometimes is downright funky.I've created some amazingly beautiful things with TypeScript definitions. I've created some unspeakable horrors with TypeScript definitions.
Filed under: I've created some amazingly beautiful unspeakable horrors with TypeScript definitions.
-
@PotatoEngineer said in Waaah, I don't get paid to use new shiny languages:
except that there's no good type for "string that has 1 or more characters in it".
Now that is a language problem. Truthy and falsy (and nullish) values are pretty core JS concepts. The type system should have some conception of them.
Based on how far the language has come, I'd say it's a matter of time.
-
@cvi said in Waaah, I don't get paid to use new shiny languages:
They finally got their shit together in C++20:
Except that they haven't got a strong enough type system to be able to leverage that usefully and instead require you to go through contortions to define what ought to be in a simple type constraint. So much of the weirdness in C++ stems from rejecting expressing what ought to be type constraints through the type system, and that in turn stems (I believe) from insisting that
struct
s have to be objects. One wonky but expedient decision in the language's early history has spawned decades of problems for practitioners…
-
@dkf Not sure I entirely get what you mean (which might be related to having about two decades of C++ brain damage and actually thinging it's pretty great at what it does). Coming from earlier C++, the current weird contortions seem like an improvement over the earlier weirder contortions, both in use and in implementation (i.e., more concise diagnostics).
Not sure why
struct
s being objects matters. The type system and, in turn, the templates have to work with all types regardless of whether they are primitive, POD, ..., or "proper" classes.I agree with your earlier assertion that not having a stronger distinction between structs and classes is unfortunate (but I would probably go in a different direction there, such as mainly just relaxing the layout of classes(*)). I don't think having a Java-like (single-)rooted object hierarchy is particularly useful, but YMMV.
(*) There's a more general discussion to be had about structs/classes tying memory layout and programming interface into a single thing in C/C++, but that's for a different time. Compilers being able to move around members wouldn't fix that underlying issue.
-
@dkf said in Waaah, I don't get paid to use new shiny languages:
@cvi said in Waaah, I don't get paid to use new shiny languages:
They finally got their shit together in C++20:
Except that they haven't got a strong enough type system to be able to leverage that usefully and instead require you to go through contortions to define what ought to be in a simple type constraint. So much of the weirdness in C++ stems from rejecting expressing what ought to be type constraints through the type system, and that in turn stems (I believe) from insisting that
struct
s have to be objects. One wonky but expedient decision in the language's early history has spawned decades of problems for practitioners…Joel Spolsky has a similar notion, but he claims that C++'s "original sin" was keeping C's support for C strings unchanged:
Amusingly, the history of the evolution of C++ over time can be described as a history of trying to plug the leaks in the string abstraction. Why they couldn’t just add a native string class to the language itself eludes me at the moment.
-- The Law of Leaky Abstractions
-
@cvi said in Waaah, I don't get paid to use new shiny languages:
I don't think having a Java-like (single-)rooted object hierarchy is particularly useful, but YMMV.
Without a rooted type system, how do you define a (non-generic) method or variable that will accept any value of any type?
-
@Mason_Wheeler said in Waaah, I don't get paid to use new shiny languages:
@cvi said in Waaah, I don't get paid to use new shiny languages:
I don't think having a Java-like (single-)rooted object hierarchy is particularly useful, but YMMV.
Without a rooted type system, how do you define a (non-generic) method or variable that will accept any value of any type?
TypeScript has
any
(aka I give up trying to describe this, just trust me). And its opposite,unknown
, which makes a value unusable without a cast. Andnever
for things that never actually resolve, or for denoting that the absence of a property is significant.
-
@Mason_Wheeler said in Waaah, I don't get paid to use new shiny languages:
@cvi said in Waaah, I don't get paid to use new shiny languages:
I don't think having a Java-like (single-)rooted object hierarchy is particularly useful, but YMMV.
Without a rooted type system, how do you define a (non-generic) method or variable that will accept any value of any type?
std::any
exists, I guess. It's not a problem I frequently have had. FWIW - you can create your own narrowerany
-like types that put additional constraints on the held types if you want/need.<C++ strings>
I don't typically work with text/string heavy applications, so I don't really see the need to bake it into the language, library is fine (plus you can replace it with your own if the standard one doesn't do what you need). I'd rather have language support for the "mathematical vector" types.
-
@NeighborhoodButcher said in Waaah, I don't get paid to use new shiny languages:
WTF is this garbage article? This guy mixes concepts all around and spreads misinformation time and time again.
That's Medium for you. And they want you to pay for the privilege of reading them!
-
@Mason_Wheeler said in Waaah, I don't get paid to use new shiny languages:
@cvi said in Waaah, I don't get paid to use new shiny languages:
I don't think having a Java-like (single-)rooted object hierarchy is particularly useful, but YMMV.
Without a rooted type system, how do you define a (non-generic) method or variable that will accept any value of any type?
LOL Rust doesn't have class inheritance at all and still has Any type.
-
@Gąska the article looks like the guy simply went through wikipedia descriptions of each language and thought: "it looks like C, so it must have C problems; it has null, so it's basically Java; it has GC, so concurrency is simple".
-
@dkf Well, you don’t have to jump into the rabbit holes that C++ offers. Starting from C++11 or so, the language and standard library offer enough to write most things in a concise way that doesn’t blow up in your face. Without manual memory management, without needing to check for null pointers everywhere, etc.
Sometimes I have to do some programming in C with the Motif library. Now that’s a horror. Endless boilerplate. Function parameters that aren’t marked ‘const’ when they should. Pointers everywhere and a documentation that fails to indicate anything about ownership or required storage duration of the allocated memory... *Shudder
-
@Grunnen said in Waaah, I don't get paid to use new shiny languages:
Function parameters that aren’t marked ‘const’ when they should.
I kind of wish
const
was opt-out instead of opt-in.Who am I kidding? I'm not touching that language.
-
@error In my java work, I've been
final
ing wherever I can, and similarly wish everything wasfinal
by default.
-
@error said in Waaah, I don't get paid to use new shiny languages:
@Grunnen said in Waaah, I don't get paid to use new shiny languages:
Function parameters that aren’t marked ‘const’ when they should.
I kind of wish
const
was opt-out instead of opt-in.Who am I kidding? I'm not touching that language.
Definitely, but too late to change that. More modern languages do it that way.
-
@hungrier said in Waaah, I don't get paid to use new shiny languages:
@error In my java work, I've been
final
ing wherever I can, and similarly wish everything wasfinal
by default.I use Lombok
val
(which is final) unless I needvar
. Ergonomics matter.
-
@error TIL. But I think that might be a bridge too far for collaborative work
-
@error said in Waaah, I don't get paid to use new shiny languages:
Lombok
-
@topspin That image is... a lot to unpack.
-
@cvi said in Waaah, I don't get paid to use new shiny languages:
I agree with your earlier assertion that not having a stronger distinction between structs and classes is unfortunate (but I would probably go in a different direction there, such as mainly just relaxing the layout of classes(*)). I don't think having a Java-like (single-)rooted object hierarchy is particularly useful, but YMMV.
I'd both relax the layout requirements for classes (that's the sort of thing I'd leave to compilers and platforms) and make them single-rooted (in an abstract class with no fields) so that there's at least some type sanity. I'd also remove inheritance entirely from structs (possibly methods too; in two minds about that) and keep the memory layout very tightly defined as there are applications that need that (e.g., because they're a view onto memory mapped hardware; you really don't want to second-guess things there!). I'd also make it so that operators can only be overridden by defining a whole group of mathematically-related ops (possibly by defaults) so that, for example, the usual sanity rules of
<
being the inverse of>=
are maintained. This would restrict the amount of stupidity that people can do a lot… and that'd be glorious.After all, the problem with C++ isn't a lack of power. It's that it's got so much power and so many ways to do things that actually both figuring out what's going on with a piece of code, and how to achieve a particular objective for some code, both are far more difficult than they should be. Programming languages shouldn't seek to make commonplace tasks difficult.
-
@Grunnen said in Waaah, I don't get paid to use new shiny languages:
the Motif library. Now that’s a horror. Endless boilerplate.
I try to forget the time when I was trying to use Motif/Xt. All of the drawbacks of OO with virtually none of the benefits, and exactly no language support at all. And documentation of a standard familiar to anyone used to working with the wilder parts of X11 (or Wayland).
-
@dkf said in Waaah, I don't get paid to use new shiny languages:
I'd both relax the layout requirements for classes
How does that work when the same class definition is included (via header inclusion) in multiple object files?
-
@PleegWat I assume it wouldn't matter so long as the same version of the same compiler with the same flags produces the same layout for the same code.
If you're linking together object files from different compilers/versions/flags/classes then you are .
Filed under: Or maybe some people are into that. C++ users are deviants.
-
@error Shared libraries?
It was bad enough when gcc 3.0 broke C++ binary compatibility with gcc 2.95, and you e.g. had to upgrade Qt and all software made with Qt at the same time to versions compiled with the new compiler.
You don’t want to do run into such issues whenever you choose a different compiler flag for your little project.
-
@Grunnen said in Waaah, I don't get paid to use new shiny languages:
@error Shared libraries?
Yeah, I figured after I wrote it that people probably are doing shit like that. Yet another reason I don't want to go near that infrastructure. Give me JavaScript, where I can just write code and run it. After I simply pass it through webpack, angular, typescript, babel, regenerator and minify.
-
@dkf said in Waaah, I don't get paid to use new shiny languages:
they're a view onto memory mapped hardware; you really don't want to second-guess things there!
-
@error said in Waaah, I don't get paid to use new shiny languages:
@Grunnen said in Waaah, I don't get paid to use new shiny languages:
@error Shared libraries?
Yeah, I figured after I wrote it that people probably are doing shit like that. Yet another reason I don't want to go near that infrastructure. Give me JavaScript, where I can just write code and run it. After I simply pass it through webpack, angular, typescript, babel, regenerator and minify.
Yeah but then you have to deal with Javascript.
-
@mikehurley said in Waaah, I don't get paid to use new shiny languages:
Yeah but then you have to deal with Javascript.
I was hearing so much about how WebAssembly was going to topple the JS browser monopoly, but so far I haven't seen it.
-
@error said in Waaah, I don't get paid to use new shiny languages:
@mikehurley said in Waaah, I don't get paid to use new shiny languages:
Yeah but then you have to deal with Javascript.
I was hearing so much about how WebAssembly was going to topple the JS browser monopoly, but so far I haven't seen it.
That's because we're still on the first part of the S curve.
-
@dkf said in Waaah, I don't get paid to use new shiny languages:
@Grunnen said in Waaah, I don't get paid to use new shiny languages:
the Motif library. Now that’s a horror. Endless boilerplate.
I try to forget the time when I was trying to use Motif/Xt. All of the drawbacks of OO with virtually none of the benefits, and exactly no language support at all. And documentation of a standard familiar to anyone used to working with the wilder parts of X11 (or Wayland).
I still have this book on my shelf. I haven't opened it in decades; that is good.
-
@error said in Waaah, I don't get paid to use new shiny languages:
@Grunnen said in Waaah, I don't get paid to use new shiny languages:
@error Shared libraries?
Yeah, I figured after I wrote it that people probably are doing shit like that. Yet another reason I don't want to go near that infrastructure. Give me JavaScript, where I can just write code and run it. After I simply pass it through webpack, angular, typescript, babel, regenerator and minify.
A while ago, my father wrote a webpage that scraped data and presented it usefully on a map, with a couple of filtering options. In pure JS. It's not huge, and it's easy for him to edit. He asked me for a critique at one point. I looked at it, and realized that if he jumped into my development stack, it would be quite a bit more work to set up, and realized... he's really better off just sticking with pure JS for the moment. Maybe if he significantly grows the site, it'll be worth it to convert into a modern web-dev toolkit, but for now, it's just not worth the pain.
-
@hungrier said in Waaah, I don't get paid to use new shiny languages:
@error In my java work, I've been
final
ing wherever I can, and similarly wish everything wasfinal
by default.I hope you mean fields and not methods. I just had to copy-paste 500 lines of code the other day because someone was too trigger-happy with finalizing methods when they shouldn't, and what would be a 4 line override now requires reimplementing the entire class from scratch.
-
@error said in Waaah, I don't get paid to use new shiny languages:
@mikehurley said in Waaah, I don't get paid to use new shiny languages:
Yeah but then you have to deal with Javascript.
I was hearing so much about how WebAssembly was going to topple the JS browser monopoly, but so far I haven't seen it.
Mostly because WebAssembly was developed by the same bunch of retards that developed JS. Last time I checked was when they just published the first official standard, where they codified all the trivial and obvious stuff and left actually being usable in practice in any capacity for future revisions.
-
@Gąska said in Waaah, I don't get paid to use new shiny languages:
I hope you mean fields and not methods. I just had to copy-paste 500 lines of code the other day because someone was too trigger-happy with finalizing methods when they shouldn't, and what would be a 4 line override now requires reimplementing the entire class from scratch.
The problem is that you have a 500 line class and you want to inherit from it. That should be like a dozen smaller classes, and you compose those into another class.
-
@error this class does one thing and one thing only. There's nothing that could be divided. The problem is that this one thing involves an AST with over 60 different node types. These 500 lines is just 60 times 8-line basic boilerplate that cannot be extracted in any way that wouldn't make it even worse.
-
@Gąska said in Waaah, I don't get paid to use new shiny languages:
You could argue none of this matter because you know these things will never be null, but do you really? The point of option types is to guarantee that yes, really, these things will never ever ever ever ever be null, it's just completely impossible. I can't imagine why you would ever NOT want that - for what's promised to be impossible to be actually impossible.
No, I would argue that (most) of those things don't matter because they're waaay out of scope of that function.
db
is null? Well, the world is already fucked, so any attempt at handling that is gonna be useless. Same withplugins
,plugins.hooks
,plugins.hooks.fire
, etc, etc. Pointing out that it won't handle that properly is like pointing out that if you delete the System32 directory, Windows starts crashing. Yes, but of course it does, because it's waaaay out of scope for it to handle something like that.Sure,
uid
being null is bad, but that's kinda a special Javascript kind of stupid. And yes, that's something they should probably test for, unless it's guaranteed that nobody's gonna passnull
to it.
-
@Mason_Wheeler said in Waaah, I don't get paid to use new shiny languages:
That's because we're still on the first part of the S curve.
So we've got past the J now and are going to double back on ourselves soon?
-
@error said in Waaah, I don't get paid to use new shiny languages:
I assume it wouldn't matter so long as the same version of the same compiler with the same flags produces the same layout for the same code.
I was actually assuming (when I wrote that) that either you'd have the platform specify exactly what should be done, or (better) that there'd be some sort of metadata attached to describe what is going on in the produced code. The real point is that things could be rearranged with classes; the need to model the layout guarantees of C is a hindrance. They're still needed for structs; those would be kept for low-level stuff and restricted so that you wouldn't be abusing them like general classes; you'd instead have a clear separation of roles.
And you know what? That sort of separation of roles tends to come up in other programming languages too, even ones that don't really have the basic concepts where that'd make vital sense. (See POJOs, POCOs…)
-
@Gąska said in Waaah, I don't get paid to use new shiny languages:
@hungrier said in Waaah, I don't get paid to use new shiny languages:
@error In my java work, I've been
final
ing wherever I can, and similarly wish everything wasfinal
by default.I hope you mean fields and not methods. I just had to copy-paste 500 lines of code the other day because someone was too trigger-happy with finalizing methods when they shouldn't, and what would be a 4 line override now requires reimplementing the entire class from scratch.
I do mean fields (and variables), not preventing inheritance.
-
@Mason_Wheeler said in Waaah, I don't get paid to use new shiny languages:
Any even remotely competent message pump will have a system that keeps track of messages that have been processed, and if a given message fails to process more than X number of times, it shunts it off into an "errored messages" jail for developers to take a look at and then proceeds with the next message.
note-taking intensifies
Filed under: Well, I guess the log file is an errored messages jail.
-
@sloosecannon said in Waaah, I don't get paid to use new shiny languages:
db
is null? Well, the world is already fucked, so any attempt at handling that is gonna be useless.You still don't get it. It's not about whether
db
is null right now or not. It's aboutdb
being guaranteed to never be null under any circumstances.
-
@Mason_Wheeler said in Waaah, I don't get paid to use new shiny languages:
@error said in Waaah, I don't get paid to use new shiny languages:
@mikehurley said in Waaah, I don't get paid to use new shiny languages:
Yeah but then you have to deal with Javascript.
I was hearing so much about how WebAssembly was going to topple the JS browser monopoly, but so far I haven't seen it.
That's because we're still on the first part of the S curve.
And we'll stay there until Wasm becomes actually usable. Did they figure out DOM API yet?
-
@Gąska said in Waaah, I don't get paid to use new shiny languages:
Did they figure out DOM API yet?
They only have SUB API so far.
-
@Gąska said in Waaah, I don't get paid to use new shiny languages:
@Mason_Wheeler said in Waaah, I don't get paid to use new shiny languages:
@error said in Waaah, I don't get paid to use new shiny languages:
@mikehurley said in Waaah, I don't get paid to use new shiny languages:
Yeah but then you have to deal with Javascript.
I was hearing so much about how WebAssembly was going to topple the JS browser monopoly, but so far I haven't seen it.
That's because we're still on the first part of the S curve.
And we'll stay there until Wasm becomes actually usable. Did they figure out DOM API yet?
Not exactly:
By itself, WebAssembly cannot currently directly access the DOM; it can only call JavaScript, passing in integer and floating point primitive data types. Thus, to access any Web API, WebAssembly needs to call out to JavaScript, which then makes the Web API call. Emscripten therefore creates the HTML and JavaScript glue code needed to achieve this.
-
@error said in Waaah, I don't get paid to use new shiny languages:
@Gąska said in Waaah, I don't get paid to use new shiny languages:
Did they figure out DOM API yet?
They only have SUB API so far.
Do you need a coprocessor for DIV?
Filed under: triggered
-
@Gąska said in Waaah, I don't get paid to use new shiny languages:
@sloosecannon said in Waaah, I don't get paid to use new shiny languages:
db
is null? Well, the world is already fucked, so any attempt at handling that is gonna be useless.You still don't get it. It's not about whether
db
is null right now or not. It's aboutdb
being guaranteed to never be null under any circumstances.I mean, it's JS, so it's not even guaranteed to be an object. It could be literally fucking anything.
-
@topspin said in Waaah, I don't get paid to use new shiny languages:
DIV
I know "IV", but as for D...
-
I've been reading it bit by bit over the past few days and just got to this part:
Elm is a functional compile-to-js language used primarily for frontend web development.
What makes Elm unique is its promise of no runtime exceptions, ever. Applications written in Elm are very robust.
That's a bold claim, when compiling to a language comprised entirely of runtime errors
-
@hungrier Not all JS errors are run-time errors. Many of them are design-time errors.