It doesn't write anything extra to the browser history. How about actually checking before exaggerating. If you are bothered by a single wrong title with the right URL, well... I think something else is wrong.
You are also completely speculating on the intent. Less drama please.
That site/app doesn't have a single piece of information about who's running it, what the privacy policy is (besides some AI slop in the FAQ section) etc. etc. - and you're supposed to put business-critical information into it (according to its demo)?!
Those TFLOPS numbers are quite useless as they are "marketing peak TFLOPS". There's usually a 10-100× difference between that and actual computational capabilities in meaningful general workloads.
It only makes sense to compare specific, well-calibrated benchmarks, such as Linpack, which is what I did.
That's assuming every developer can get the same AI efficiency boost and contribute meaningfully to any feature, which is unfortunately not really the case.
Seniors can adjust, but eg. junior frontend-only devs might be doomed in both situations, as they might not be able to contribute enough to business-critical features to justify their costs and most frontend-related tasks will be taken over by the "10x" seniors.
HTML+JavaScript-based statically hostable apps (eg. presentations) can't use paths as deep links, since there's no standard for simple static hosting or URL rewriting (even 30 years later). Oh well.
You should be able to use the query part of the URL (after ?). You can get at it with Javascript, but it doesn't influence which static HTML page is served.
Was fun and kind of meditative locking in like that – I noticed that the anti-glare coating on my screen introduces a visibly larger Δ than the later stages of the game (kind of a dithered "cloud" noise), making it quite a challenge. 0.0021 oneshot.
That does require designing the language grammar in a certain way, in particular, there should not be any optional elements in any productions used by statements on the right-hand side (otherwise it's ambiguous whether to terminate the statement or continue to the next line) that can also start a statement. Most languages violate that.
"where the context indicates that a command or definition cannot terminate at that point" is trivially unsuitable for C-like languages, `if`-`else` already violates that, since an `if` can terminate before the `else` by that definition (imagine splitting `else` to a new line).
An actually workable definition would be "unless the end of line occurs at a point where the current expression can not be terminated or the next tokens are not parseable as a separate statement", which is almost the definition of semicolon insertion in JavaScript....
But JavaScript has exactly the problem of the ambiguity since both braces (via object literals) and parentheses (via expressions-as-statements) can start a statement and those are ambiguous with eg. blocks and function calls, respectively.
You are of course right about the requirements on such a syntax, but that was precisely my point, a syntax must be designed taking into account how it should be parsed and it must be designed in such a way that the programmer will not need to write superfluous information.
C is an example of how the syntax of a programming language should not be designed and unfortunately many languages whose claimed purpose was to correct various shortcomings of C have nonetheless inherited the quirks of its syntax.
C has attempted to avoid the use of braces/parentheses/brackets in certain contexts and it has attempted to minimize the number of keywords, but the end result has been the opposite, a typical C program has much more parentheses, braces and brackets than the same program written in a language with a better syntax, like ALGOL 68, or like a non-verbose version of Ada, where the Ada abstract syntax would be preserved but most Ada keywords would be substituted with symbols (such a non-verbose Ada can easily be implemented with a source preprocessor).
In my opinion, a good syntax is of the kind usually called "fully bracketed", as popularized by ALGOL 68, where there are no ambiguities about the extent of a program structure (like the one mentioned by you with C "if", such problems do not exist in ALGOL 68, Ada and similar languages) and there are no alternatives of the kind that exist in C between using a simple statement or a compound statement, i.e. in any location it does not matter if one or more statements are written (this is the feature that makes the specification of statement termination that was used in CPL work without problems), and where several kinds of different brackets are used, not a single kind, e.g. there should be different kinds of brackets for blocks, loops and conditional statements.
Most of the problems that exist in the syntaxes of many popular programming languages are caused by the use of the ASCII character set, which has too few symbols, so it forces the use of some symbols for multiple purposes, which causes ambiguities for parsing.
When Unicode is used instead of ASCII, it is possible to use every symbol for a unique purpose, including the use of different kinds of brackets, and this makes very easy to design a syntax that avoids any kinds of parsing ambiguities.
You are also completely speculating on the intent. Less drama please.
reply