greggman3

I agree that having a "can't modify this object" via this reference is useful and that JavaScript doesn't have it. TypeScript has it with `ReadOnly<T>`

It could be worse. You could be in python that has no const whatsoever :P

I also agree pass by reference is useful. JavaScript only has pass by value, similar to python.

I suspect they spent several millions of dollars a year and at least 20-30 people if not more and I think you don't have any idea of how hard the problem is and how it's getting harder all the time.

It's going to get even harder as spammers use ChatGPT like tech to write individual spam messages for each person

Of course, why not?

How about reframing to "Is spam getting harder to filter?"

No one at google wants spam.

> That brings me to something I really want in JS, actual unmutable values. If you use `const x = new SomeClass()`, you cannot reassign it, but you can change fields. The first time I encountered `const`, I thought it did the opposite. It would be cool if you could declare something (object, array) to be an immutable value.

That sounds like a fundamental mis-understanding. Variables do not hold objects, they hold references to objects.

    const foo = {};
    let bar = foo;

foo and bar hold references to the same object. They do not hold the object themselves. foo's reference can not be changed. It's const. bar's reference can. But the object is independent of both variables.

If you want the object itself to be unmodifiable there's Object.freeze.

    const foo ...

makes foo const. If you wanted a shortcut for making the object constant (vs Object.freeze) it would be something like

    let foo = new const SomeObject()

This doesn't exist but it makes more sense than believing that `const foo` some how makes the object constant. It only makes foo constant (the reference).

I agree that

(1) named intermediate values are sometimes more readable ... though I have examples where it's very hard to come up with names and not sure it helped

(2) debugging is easier.

For (2) though, this IMO is a problem with the debugger. The debugger should allow stepping by statement/expression instead of only by line (or whatever it's currently doing). If the debugger stopped at each pipe and showed in values (2) would mostly be solved. I used a debugger that worked by statements instead of lines once 34 years ago. Sadly I haven't seen once since. It should be optional though as it's a tradeoff. Stepping through some code can get really tedious if there are lots of steps.

I don't consider ASCII simple because it needs to be parsed (more than a binary format).

As sample example, a binary format could be as simple as

    struct Header {
      uint32 width;
      uint32 height;
    }

    struct Image {
      Header header;
      uint8* data;
    }

    Image* readIMG(const char* filename) {
      int fd = open(filename, ...)
      Image* image = new Image();
      read(fd, &image->header, sizeof(image->header));
      size_t size = image->header.width * image->header.height * 4;
      image->data = malloc(size);
      read(fd, image->data, size);
      close(fd);
      return image;
    }

Yea I know, that's not a complete example, endian issues, error checking.

Reading a PPM file is only simple if you already have something to read buffered strings and parse numbers etc... And it's slow and large, especially for todays files.

I had my car stolen from an apartment complex garage in like 1991. Sure it sucks to have my car stolen but the only irreplaceable thing was 36 mix tapes that were in the car. Guess that's an issue that no longer exists :P

I forgot where I heard this but "It's impossible to remember what it was like not to know something". This generally means all kinds of things are obvious to someone that knows a topic. They're so obvious they're invisible, forgotten about, and therefore you don't even think to teach them.

Honestly, I don't consider PNG a simple format. The CRC and the compression are non-trivial. If you're using a new language that doesn't have those features built in and/or you don't have a reasonable amount of programming experience then you're going to likely fail (or learn a ton). zlib is 23k lines. "simple" is not word I'd use to describe PNG

Simple formats are like certain forms of .TGA and .BMP. A simple header and then the pixel data. No CRCs, no compression. Done. You can write an entire reader in 20-30 lines of code and a writer in other 20-30 lines of code as well. Both of those formats have options that can probably make them more work but if you're storing 24bit "True color" or 32 bit "true color + alpha" then they are way easier formats.

Of course they're not common formats so you're stuck with complex formats like PNG

1000 square feet is only small in the USA. 1000 sqft is the average size of a home in Japan. 50% are smaller. There's plenty of creative ways to use 1000 sqft

I believe the reason there's no if/else is because CSS is supposed to be easy enough to interpret relatively quickly (in a finite amount of time). The moment you add if/else you'd up with a full programming language and the halting problem and an arbitrary amount of calculations before the system can finally know what to render.