• 17 Posts
  • 79 Comments
Joined 1 year ago
cake
Cake day: July 17th, 2023

help-circle







  • That’s known as a ligature and they’re pretty common in many programming-oriented fonts, which usually have stylistic sets with different ligatures for different programming languages that you can optionally enable in your editor’s configuration. For example, here’s the stylistic sets the Monaspace font offers:

    Personally I’m not too fond of ligatures so I never enable any, but many folks do like them.

    Edit: and just as a side note, ligatures are super common in many fonts, you just might not notice them. Here’s some classic examples from the DejaVu Serif font, with and without a ligature:









  • I dint know many OO languages that don’t have a useless toString on string types.

    Well, that’s just going to be one of those “it is what it is” things in an OO language if your base class has a toString()-equivalent. Sure, it’s probably useless for a string, but if everything’s an object and inherits from some top-level Object class with a toString() method, then you’re going to get a toString() method in strings too. You’re going to get a toString() in everything; in JS even functions have a toString() (the output of which depends on the implementation):

    In a dynamically typed language, if you know that everything can be turned into a string with toString() (or the like), then you can just call that method on any value you have and not have to worry about whether it’ll hurl at runtime because eg. Strings don’t have a toString because it’d technically be useless.


  • Everything that’s an Object is going to either inherit Object.prototype.toString() (mdn) or provide its own implementation. Like I said in another comment, even functions have a toString() because they’re also objects.

    A String is an Object, so it’s going to have a toString() method. It doesn’t inherit Object’s implementation, but provides one that’s sort of a no-op / identity function but not quite.

    So, the thing is that when you say const someString = "test string", you’re not actually creating a new String object instance and assigning it to someString, you’re creating a string (lowercase s!) primitive and assigning it to someString:

    Compare this with creating a new String("bla"):

    In Javascript, primitives don’t actually have any properties or methods, so when you call someString.toString() (or call any other method or access any property on someString), what happens is that someString is coerced into a String instance, and then toString() is called on that. Essentially it’s like going new String(someString).toString().

    Now, what String.prototype.toString() (mdn) does is it returns the underlying string primitive and not the String instance itself:

    Why? Fuckin beats me, I honestly can’t remember what the point of returning the primitive instead of the String instance is because I haven’t been elbow-deep in Javascript in years, but regardless this is what String’s toString() does. Probably has something to do with coercion logic.


  • This is absolutely true, but it still seems to me that we’re throwing the baby out with the bath water when we just stick to extremely terse symbols for everything regardless of context.

    Reading articles would be so much easier if they used even slightly longer names – thankfully more and more computer science articles do tend to use more human readable naming nowadays, at least.

    Sure, longer names make manipulation harder a bit more annoying if you’re doing it by hand, but if you do need to manipulate something you can then abbreviate the terms (and I’m 60% sure I’ve seen some papers that had both a longer form and a shorter form for terms, so one for explaining shit and one for the fiddly formal stuff)

    Of course using terse terms is totally fine when it’s clear from the context what eg. ∆x means.