No, they got it by Gmail being a loss leader paid by Google AdSense in the search engine. Now they have AdSense in Gmail directly, so I guess it pays for itself.
AT&T was once broken up and then after that you could connect a modem to a phone line. The whole public use of the Internet is a consequence of breaking up a “superior product” that became a bloated market incumbent resting on its laurels.
No, we should be mad at Google or any other BigTech taking over a big enough chunk of a federated system to basically dictate what can be sent/received and what not. With no human in the loop if you don't agree with their decisions.
Hear me out: Altman is signing deals with the pentagon and AWS (government sector) in the last thirty days or so. And blacklisting competitors (Anthropic). I’d say the protection money paid dividends.
Clearer for the computer, but not for the human. Many errors, some severe, have been caused by a human only looking at the indentation and not realizing the braces don't match.
That's just because most languages go by braces and have optional intendation that is just ignored by the compiler.
I'd reckon that in a language where stuff is done by indentation but optional braces exist that are just ignored so many errors would also have been caused by braces being misplaced by the programmer to queue other programmers who thought some scope happened as a consequence but the compiler disagreed due to the indentation, which by the way was caused by tabs and spaces being mixed in the code and it not properly showing up for another programmer with tab with set differently.
> whitespace/indent languages make it clear there's a lot of redundancy there too.
The only purpose for whitespace indentation is to make the code easier on the eyes. A space shouldn't have an impact in terms of execution, that would be too hazardous. It's too easy to randomly insert a space rather than a character.
> I never find myself just randomly inserting characters.
Hasn't it ever occured to you trying to insert a space at your mouse but your cursor wasn't there? People sometimes forget to click (or think the cursor is already there), myself included. Characters are easier to spot because they are not invisible and random letters cause compile errors.
If it has never occurred to you, then good for you. However I do not see what the benefit of not using closing brackets would be.
> I don’t use the mouse when editing code, so this particular mistake does not happen to me.
Fair point.
> Less visual noise.
It doesn't solve this problem of your eyes guessing the correct indentation, especially when using two spaces (I hate two spaces even with braces). You could set up your IDE so it highlights the block and prints a hint at the end what block is ending, however you lose this once you open a plain text editor.
The point of using braces for this is that you can count them.
Also, if you were to print the code without braces on a paper, it would be a hard time reading, since the paper is much smaller than a 27" monitor.
> And the ability to use braces for other syntax.
There's other ways. For example, {} in Swift can be also used for ResultBuilder. And if you need the braces without knowing the type upfront, you can prefix it e.g. ${}.
> I would love to see a language try to implement a rule where only an indented line is considered part of the previous expression.
After python, it seems like every language decided that making parsing depend on indents was a bad idea. A shame, because humans pretty much only go by indents. An example I've frequently run into is where I forget a closing curly brace. The error is reported at the end of the file, and gives me no advice on where to go looking for the typo. The location should be obvious, as it's at exactly the point where the indentation stops matching the braces. But the parser doesn't look at indents at all, so it can't tell me that.
> An example I've frequently run into is where I forget a closing curly brace. The error is reported at the end of the file, and gives me no advice on where to go looking for the typo. The location should be obvious, as it's at exactly the point where the indentation stops matching the braces. But the parser doesn't look at indents at all, so it can't tell me that.
That's somewhat a quality of service issue though. Compilers should look at where the braces go out of kilter vs indentation and suggest the possible unmatched opening brace.
I was much more opposed to this early on than I am now. With modern IDEs and extensions handling tabs vs spaces, tab width, and formatting, python ends up being very easy to read and write. I use it daily, and while I hate it for other reasons, I can't remember the last time I had any issues with indentation.
I must disagree but only a tiny bit. modern IDEs try to indent and attempt to add indentation as you code which can cause problems sometimes.
tabs vs spaces is very painful still when copying code that is in a different format. it's not just tabs and spaces, but the width of the tabs and the spaces. Even with VSCode extensions and sublime text extensions I've struggled a lot recently with this.
I commented on a sibling thread just now, but it is still very easy in python to mess up one level of indentation. When I caught bugs of that sort, it was introduced either when copy pasting, when trying to make a linter happy and doing cosmetic cleanup, or when moving code around levels of indentation, like introducing a try/except. I had one recently where if I recall correctly I moved a continue statement under or out of a try/except when messing around with the try/except logic. it was perfectly valid, and didn't stand out much visually, pydnatic and other checkers didn't catch it either. It could have happened with a '}' but it's easier to mess up a level of indentation than it is to put the '}' at the wrong level. a cosmetic fix results in a logic bug because of indentations in python. with curly's, a misplacement of that sort can't happen because of indentation or cosmetic/readability fixes.
what the curly approach asserts is a separation of readability and logic syntax.
The interpreter/compiler should understand your code first and foremost, indenting code should be done, and should be enforced, but automatically by the compiler/interpreter. Python could have used curly braces and semi-colons, and force-indented your code every time it ran it to make it more readable for humans.
we don't even use indents that way in natural language. We use things like bullet points, we need specific markers.
space is for spacing, tabs are for tabulation, they are not in any human language I know of used as terminators of statements. You know what is the equivalent of an indent or a semicolon in english? a period. <-
We have paragraph breaks just like this to delimit blocks of english statements.
A semi-colon is used to indicate part of a sentence is done, yet there is still related continuation of the statement that is yet to be finished. Periods are confusing because they're used in decimal points and other language syntax, so a semi-colon seems like a good fit.
If I had my pick, I would use a colon to indicate the end of a statement, and a double colon '::' to indicate the end of a block.
func main(): int i - 0: do: i=i+1: print(i): while(i<10):: ::
another downside of indentation is it's award to do one-liners with such languages, as with python.
There is a lot of subjectivity with syntax, but python code for example with indents is not easy for humans to read, or for syntax validators to validate. it is very easy for example to intend a statement inside a for loop or an if/else block in python (nor not-intend it), and when pasting around code you accidentally indent one level off without meaning to. if you know to look for it, you'll catch it, but it's very easy to miss, since the mis-indented statement is valid and sensible on its own, nothing will flag it as unusual.
In my opinion, while the spirit behind indentation is excellent, the right execution is in the style of 'go fmt' with Go, where indenting your code for you after it has been properly parsed by the compiler/interpreter is the norm.
I would even say the first thing a compiler as well as interpreter do should be to auto-indent, and line-wrap your code. that should be part of the language standard. If the compiler can't indent your code without messing up logic or without making it unreadable, then either your code or the language design has flaw.
with apples in that list for example, you used '2.1' to indicate a new item, the space is cosmetic, the functional indicator is '2.1'
This wouldn't look right:
Introduction
Fruit
Apples
Red apples
Green apples
I'm sure you can work it out, but it doesn't feel natural, or ideal. (i can't get hn to format it without making it all one line so i used double new line).
it would look better still with a dash or a bullet point for every sub-entry. We're not arguing that it is possible to do that, we're arguing what is ideal for readability.
In that list you can naturally guess what that ordering is, but if the items were not so interrelated it can be confusing. if the top level item is 'Ham' and the indented item under it is 'sandwich' are you wrapping the same phrase 'Ham Sandwich' , because indentation (even in python) is used when wrapping lines, or is sandwich under ham as one of the things done with ham. it is thus error-prone and more confusing, clear and specific punctuation alongside indentation makes it easier to read.
No one is saying that indentation can not be used to display lists/sublists, I'm saying that markers remove ambiguity even across movement of blocks of texts.
The issue is that you find you very often want to break those roles. Python basically has `elif` because `else if` would make each branch nest one level deeper which isn't what one wants, except Python uses exceptions for flow control so you find yourself having to use `except ... try` as an analogue to `else if` but not `excetry` exists to do the same and stop the indentation.
There are many other examples. It exists to give people freedom. Also, while humans only go by intendation it's very hand for text editing and manipulation without requiring special per-language support to move the cursor say to the nearest closing brace and so forth.
The issue is that it's a special case that acknowledges where there are cases where the indentation level it logically requires isn't what programmers find pleasant, there are many more, that just don't have that special case, so it forces indentation that's unpleasant and unintuitive.
What language is this? In C I get the correct position of the error because GCC also monitors the indentation as it parses.
A linter can point out errors based on indentation, and they frequently do. There's no need for the language to do it and then band-aid additional fixes for problems caused by significant white space.
rustc does exactly that keeping the indent level of every unbalanced curly brace. It works OK, but it isn't perfect by any stretch. More heuristics are needed.
As a casual observer who has written perhaps a dozen lines of Scala in his life, I feel like Scala approaches any “pick one” decision with “why not both?”.
Kind of. It supports an end operator as well, and imo everyone should be using it. I actually really like the `end name` approach as opposed to the Lua-style plain ends.
Yeah "You can use newline or tab characters in the HREF attribute and the browser will throw a validation error, remove the offending character, try again, then succeed" would be a more accurate title.
Validation errors aren't really "exceptions" to be thrown, they are indicators for authors that something is probably wrong but they make no visible difference in the output. I'm not sure if any browser even tracks them (and if one did, the best it could do is complain in the dev tools).
Also, this is not limited to HREF, it's defined in URL[0] so you can also put newlines in new URL("...") etc.
HTML doesn’t remove whitespace from quoted attribute values. XML replaces such things with a single space, but HTML leaves it intact. (If you want actual tabs and newlines in XML or an HTML/XML polyglot—which can be reasonable, seen for example in the HTML title attribute—you have to encode them as 	 and or similar.)
So no, this does boil down to the behaviour quoted from the URL Standard.
> the title is referring to inside html attributes, where they will be removed hence not affect where the link points.
I thought so too, until I read the URL definition in RFC 1738
In some cases, extra whitespace (spaces, linebreaks, tabs, etc.) may need to be added to break long URLs across lines. The whitespace should be ignored when extracting the URL.
No whitespace should be introduced after a hyphen ("-") character. Because some typesetters and printers may (erroneously) introduce a hyphen at the end of line when breaking a line, the interpreter of a URL containing a line break immediately after a hyphen should ignore all unencoded whitespace around the line break, and should be aware that the hyphen may or may not actually be part of the URL.
The "professor of Computer Science" seems to be confusing URLs and the textual representation of a URL inside HTML.
Considering he wrote on his blog that he "ranks among the top 2% of scientists globally", I'm guessing he's more of a Trumpesque personality, another "very stable genius".
He is a bit full of himself, but if you read some of his other work, he’s done some incredible work making fast code. Lots of SIMD, some novel algorithms, etc.
Instead of making a sarcastic response, just state plainly what you mean. This prevents you having to get into dumb arguments that don't mean anything to people who don't already know what you're trying to say.
This could just as easily be someone at the top saying "find a legitimate sounding reason to refuse this because we want to refuse it anyways". They will always give such a reason, that doesn't mean it's the real reason.
It's best to take the official statement at face value rather than assuming what's not said. If you take it to mean something that was not said, that's on you.
And if two official statements from two different organization differ, what do you do? And if, of the two, the government is known to be a bad faith actor, how does that affect your answer? Organizations lie, that is a simple fact of life. You can either deal with it or bury your head in the sand.
What are the two differing statements? The primary statement to the applicant by the FDA is what matters. Everything else is irrelevant political commentary.
> This nets us another original pixel value, img(8).
This makes it all seem really too pat. In fact, this probably doesn't get us the original pixel value, because of quantizing deleting information when the blur was applied, which can never be recovered afterwards. We can at best get an approximation of the original value, which is rather obvious given that we can vaguely make out figures in a blurred image already.
> Nevertheless, even with a large averaging window, fine detail — including individual strands of hair — could be recovered and is easy to discern.
The reason for this is that he's demonstrating a box blur. A box blur is roughly equivalent to taking the frequency transform of the image, then multiplying it by a sort of decaying sin wave. This achieves a "blur" in that the lowest frequency is multiplied by 1 and hence is retained, and higher frequencies are attenuated. However, visually we can see that a box blur doesn't look very good, and importantly it doesn't necessarily attenuate the very highest frequencies by much more than far lower frequencies. Hence it isn't surprising that the highest frequencies can be recovered in good fidelity. Compare a gaussian blur, which is usually considered to look better, and whose frequency transform focuses all the attenuation at the highest frequencies. You would be far less able to recover individual strands of hair in an image that was gaussian blurred.
> Remarkably, the information “hidden” in the blurred images survives being saved in a lossy image format.
Remarkable, maybe, but unsurprising if you understand that jpeg operates on basically the same frequency logic as described above. Specifically, it will be further attenuating and quantizing the highest frequencies of the image. Since the box blur has barely attenuated them already, this doesn't affect our ability to recover the image.
As I explain, you can't perfectly reverse these filters because of quantizing. The more the signal is attenuated, the more information is lost when quantizing. So yes, it does matter what your kernel is.
reply