Artyom Bologov
@aartaka@merveilles.town  ·  activity timestamp 2 days ago

So #TypeScript has:
- Types
- Interfaces
- Regular classes
- Anonymous classes
- Abstract classes
- Probably something else I'm not aware of yet

Why have all these, especially given that most of them are the same thing but with different restrictions? You can just do classes well enough and ditch most of it. #CommonLisp has classes that can easily dub as interfaces or abstract classes, why not just steal the idea and cut the amount of terms to learn and differentiate in, like, three times?
Artyom Bologov
@aartaka@merveilles.town  ·  activity timestamp 2 days ago

> If you need to protect values in your class from malicious actors, you should use mechanisms that offer hard runtime privacy, such as closures, WeakMaps, or private fields.

I mean yeah, but doesn't that expose the public/protected/private propaganda as shallow? I know that there are other reasons to use public/private (like building a more parseable and granular #API), but the main thing there is still the subliminal desire to protect the precious secrets of the object. Which never happens with public/private, actually. We've been lied to. Like with many other things about #TypeScript.
Artyom Bologov
@aartaka@merveilles.town  ·  activity timestamp 2 days ago

> When inferring from a type with multiple call signatures (such as the type of an overloaded function), inferences are made from the last signature (which, presumably, is the most permissive catch-all case)

I mean, it's likely quite true and reasonable in practice, but why not infer the actual signature from the existing ones? #TypeScript has a freaking Turing-complete type system and supposedly as state-of-the-art type inference engine, so why not do something as simple as function overload type merging?
Artyom Bologov
@aartaka@merveilles.town  ·  activity timestamp 3 days ago

Okay, so hear me out: literal types (typing the value as literal "foo") are cool, but... providing literally the same value to a literally typed variable might error out because the type of the provided value will be "string" and not ""foo""?! So they just introduced literal types and gave everyone the reason to never use them. I looooooooooove #TypeScript 👺
Artyom Bologov
@aartaka@merveilles.town  ·  activity timestamp 2 days ago

Oh, so "const" type assertion on #TypeScript tuples means they are "readonly" and "this" in interface definition means the object that interface methods are used on. So TS uses protected keywords for its own purposes without considering how confusing this is. As someone who's into API poetry, I'm infuriated.
Artyom Bologov
@aartaka@merveilles.town  ·  activity timestamp 3 days ago

Okay, so hear me out: literal types (typing the value as literal "foo") are cool, but... providing literally the same value to a literally typed variable might error out because the type of the provided value will be "string" and not ""foo""?! So they just introduced literal types and gave everyone the reason to never use them. I looooooooooove #TypeScript 👺
Artyom Bologov
@aartaka@merveilles.town  ·  activity timestamp 3 days ago

Okay, one more #TypeScript hater post: override functions are useless. Their selling point is that you can provide multiple (supposedly compatible) signatures for a function and then process whatever comes in being certain of its type. Except... it only allows one implementation body. So you may have five override signatures, but only one implementation function. And this implementation is doomed to re-invent type/value dispatching, even though TS was supposed to help. To illustrate, here's a simple "take string or int, convert it to int, and print it out" function in #CommonLisp, #JavaScript, and #typescript

(defmethod foo ((x string))
(foo (parse-integer x)))

(defmethod foo ((x integer))
(format t "~&X is d%" x))

-----------------------------------

function foo (x) {
if (typeof x === "string"){
foo(parseInt(x));
} else {
console.log("X is " + x)
}
}

------------------------------------

function foo(x: number): void;
function foo(x: string): void;
function foo(x: string | number): void {
if (typeof x === "string") {
console.log("X is " + parseInt(x));
} else {
console.log("X is " + x);
}
}

- CL generic function is short and strictly typed.
- JS function is short-ish and does its own type dispatching.
- TS function is LONG and DOES ITS OWN TYPE DISPATCHING. Useless, in other words.
⚯ Michel de Cryptadamus ⚯
@cryptadamist@universeodon.com  ·  activity timestamp 7 days ago

Ω🪬Ω
new release of #Fedialgo, the customizable timeline algorithm / filtering system for your Mastodon feed, counts the number of times each hashtag appears in your timeline even if people don't use a "#" character to give you a better sense of what people are talking about in the Fediverse.

there's a little bit of art vs. science here because some strings are disqualified from this kind of counting (e.g. a word like "the" should not be counted even if some maniac decided to make it a hashtag) so let me know if you see any weirdly high counts.

* Link: https://michelcrypt4d4mus.github.io/fedialgo_demo_app_foryoufeed/
* Code: https://github.com/michelcrypt4d4mus/fedialgo_demo_app_foryoufeed
* Video of FediAlgo in action: https://universeodon.com/@cryptadamist/114395249311910522

#activitypub #algorithm #algorithmicFeed #algorithmicTimeline#Fedi#FediTips#FediTools #Fediverse#Feed#FOSS#Masto #MastoAdmin #Mastodon #mastohelp#MastoJS #nodejs #node #opensource#SocialWeb #timeline#TL#webdev #hashtag #typescript