There's a lot wrong with Javascript's Date, but the fact that it's an object is is not really in the top 10.
Would it have been nice if the Date object had been immutable? Sure, but the fact that changing the mutable object does indeed change the object shouldn't be a shock
It's definitely a shock when something else changes the date object you've been holding on to. The problem with mutable values has never been when you (that is, the local context) change them. It's always that you can't trust that nothing else (some very non-local code) does.
Why would you give up just because something is NP hard if there are good algorithms to approximate a solution, and an approximate but good solution is useful?
Yeah, there are many problems which are np-hard in theory, but then realistic cases give you way more constraints that make them solvable. So many hard graph problems become way simpler when applied to real maps, because you know that if you start getting away from something, your minimum remaining distance grows. But on an abstract graph there's no real mapping to our dimensions.
There's no "information you wanted" in the plain np-hard version of traveling salesman for example. There's only cost. My point was that things get easier if you have the extra information and aren't solving the plain version anymore.
The best advice is probably "don't", as it usually is to most people setting out to design a programming language, and even more so for people setting out to do a mostly backwards compatible extension to a language that isn't suited for what you want it to do.
The second best advice is probably, do just c with classes. Allow defining your own allocator to make objects of those classes. It's fine if objects built with one allocator can only refer to objects built by the same one.
Don't do templates, just do the minimum needed for a container type to know what type it contains, for compile time type checking. If you want to build a function that works on all numbers regardless if they are floats or complex or whatever, don't, or make it work on those classes and interfaces you just invented. A Float is a Number, as is an Integer. Put all that cleverness you'd waste on templates into making the compiler somewhat OK at turning that into machine types.
Very specifically don't make the most prominent use of operator overloading a hack to repurpose the binary left shift operator to mean `write to stream`. People will see that and do the worst things imaginable, and feel good about themselves for being so clever.
I don't write modern C for daily use, so I can't really say. But I've been re-learning and writing C99 more these days, not professionally but personal use - and I appreciate the smallness of the language. Might even say C peaked at C99. I mean, I'd be crazy to say that C-like languages after C99, like Java, PHP, etc., are all misguided for how unnecessarily big and complex they are. It might be that I'm becoming more like a caveman programmer as I get older, I prefer dumb primitive tools.
C11 adds a couple of nice things like static asserts which I use sometimes to document assumptions I make.
They did add some optional sections like bounds checking that seem to have flopped, partly for being optional, partly for being half-baked. Having optional sections in general seems like a bad idea.
IDK about C11; but C99 doesn't change a lot compared to ANSI C. You can read The C Programming Language 2nd edition and pick up C99 in a week. It adds boleans, some float/complex math ops, an optional floating point definition and a few more goodies:
C++ by comparison it's a behemoth. If C++ died and, for instance, the FLTK guys rebased their libraries into C (and Boost for instance) it would be a big loss at first but Chromium and the like rewritten in C would slim down a bit, the complexity would plummet down and similar projects would use far less CPU and RAM.
It's not just about the binary size; C++ today makes even the Common Lisp standard (even with UIOP and some de facto standard libraries from QuickLisp) pretty much human-manageable, and CL always has been a one-thousand pages thick standard with tons of bloat compared to Scheme or it's sibling Emacs Lisp. Go figure.
C++ is a katamari ball of programming trends and half baked ideas. I get why google built golang, as they were already pretty strict about what parts of the c++ sediments you were allowed to use.
Not Google actually, but the same people from C, AWK and Unix (and 9front, which is "Unix 2.0" and it has a simpler C (no POSIX bloat there) and the compilers are basically the philosophy of Golang (cross compile from any to any arch, CSP concurrency...)
Originally Go used the Ken C compilers for Plan9. It still uses CSP. The syntax it's from Limbo/Inferno, and probably the GC came from Limbo too.
If any, Golang was created for Google by reusing a big chunk of plan9 and Inferno's design, in some cases even straightly, as it shows with the concurrency model. Or the cross-compiling suite.
A bit like MacOS X under Apple. We all know it wasn't born in a vacuum. It borrowed Mach, the NeXTStep API and the FreeBSD userland and they put the Carbon API on top for compatibility.
Before that, the classic MacOS had nothing to do with Unix, C, Objective C, NeXT or the Mach kernel.
Mac OS X is to NeXT what Go is for Alef/Inferno/Plan9 C.
As every MacOS user it's using something like NeXTStep with the Macintosh UI design for the 21th century, Go users are like using a similar, futuristic version of the Limbo/Alef programming languages with a bit of the Plan9 concurrency and automatic crosscompilation.
That's wonderful how you tied those threads together to describe Go's philosophical origins. I'm having a great time exploring the links. And the parallel with NeXTSTEP is fascinating too, I've been interested in that part of software history since learning that Tim Berners-Lee created WorldWideWeb.app on the NeXTcube.
Not just philosphical; I've read somewhere that the first Go releases in order to bootstrap themselves they bundled the plan9 forked/simplified C compilers inside. Later releases are written in Go themselves.
There is no philosophical or technical continuity. Go is really not the continuation of anything from Bell labs, not the philosophy, not the technologies, and especially not its purposes.
Go was created at Google, for Google, by Google employees. They looked at how Google was using C++ at that time, sat down, and created a new language that would suit that task more. Here's an article of what and how by Rob Pike https://commandcenter.blogspot.com/2012/06/less-is-exponenti...
It's as much of a Google project as anything can be. "C++ is a katamari ball of programming trends and half baked ideas. I get why google built golang, as they were already pretty strict about what parts of the c++ sediments you were allowed to use." is entirely correct regarding history.
Fwiw, zero logs in that context is usually in the relation to requests through the VPN, whereas this discussion is about requests on their homepage? Or did I misunderstand something here?
Would it have been nice if the Date object had been immutable? Sure, but the fact that changing the mutable object does indeed change the object shouldn't be a shock
reply