> You can say that about every single design decision made about every product.
No, that's not true. Many aspects of my computer's UI are user-configurable.
57,863 karma · joined January 13, 2008
No, that's not true. Many aspects of my computer's UI are user-configurable.
Peek under the hood all you want, where do you find motivation in the human brain?
But how can you tell the difference between "real" despair and a sufficiently high-quality simulation?
And yes, the director's cut. Absolutely the director's cut.
Nothing other than vanity AFAIK.
It's actually a bit of a scam because karma accumulates and never expires. I've been on the leaderboard for a long time, not because I'm making particularly valuable contributions (I only post a few times a week) but just because I've been on HN since it launched.
But there are two applications: the first is breaking in to a system under some very obscure set of circumstances that you are very unlikely to encounter in the real world. The second is to bump up your karma on HN.
BTW, if you are a Castle member, Carl Hein is currently doing a routine in the Library Bar that is IMHO in the same league Dani's Fool Us routine. We took some friends of ours to the Castle a week ago and Karl absolutely melted their brains. They're still talking about it. :-)
(And if you're not a Castle member but are in the LA area, contact me privately and I can set you up with a guest pass.)
For example: one of the biggest problems with email is that SMTP is not stateful. It handles all incoming messages in the same way. In particular, SMTP does not and cannot distinguish between spam. Spam detection is invariably relegated to a downstream heuristic system that generally looks at message content to detect spam. But this cannot possibly be reliable because one man's spam is another man's newsletter subscription.
What if instead we moved spam detection into the protocol. What if (say) we replaced the single-step process of sending an email into a two-step process, where the first step involves some kind of hand-shake to establish a connection between the sender and the receiver. This simple change would make it literally impossible to send any kind of spam other than a connection request. Those would still happen, of course (think LinkedIn "I want to connect" messages) but they would be a lot less frequent. And there are ways to eliminate even those annoyances.
A new client could become to email what iMessage is to SMS. You could have "blue bubble" messages that are authenticated as having come from the same client, which insures that the user has gone through some some level of vetting (comparable to an iPhone user signing in to their iCloud account). You could even layer new protocols on top of SMTP that were unique to your client's ecosystem, like sending money.
This idea is conceptually simple but very hard to implement because it has to be done in the client and it has to be backwards-compatible with SMTP. But since you're building a new client anyway, I thought I'd pitch this idea to you. The result could potentially be an entirely new email ecosystem.
If you want to discuss this in more detail, contact me privately. My contact info is in my profile.
You're welcome :-)
Amateur magician here (but a magician member of the Magic Castle, so I know a few things). Manual dexterity is certainly a useful skill, but it's just a tiny part of the art of magic. You can be a consummate sleight-of-hand artist and still be a mediocre magician, and conversely, some of the best magicians don't use particularly difficult sleights. The best example of that I know of is Dani Da Ortiz's routine on Penn and Teller Fool Us:
https://www.youtube.com/watch?v=5_KcQt0z-eE
Now, Dani is in fact a master at sleight-of-hand, and so one would think that you are watching a masterclass in sleights, but no. There are a few sleights, but they are not particularly difficult, beginner-level. I could do them, and I'm not particularly skilled. The trick is based almost entirely on timing and misdirection and psychological subtleties.
The degree of psychological subtlety in top-level magic continually blows my mind. The best magicians make it look like magic even when you know how the trick is done. Dani's trick is a consummate example. The performance looks like chaos, but in fact every detail is meticulously crafted and serves a purpose. It's almost like watching a dance.
That is manifestly false. Machine language and Brainfuck are both programming languages, and they are not designed for communication between humans. To the contrary, Brainfuck is deliberately designed to confuse humans.
Programming languages exist to describe processes with sufficient precision that they may be carried out by a machine. You might want a programming language to also serve the secondary purpose of communicating something to a human that reads it, but the vast majority of extant languages are not designed with this goal in mind.
> The power of modern languages come from us quickly being able to understand programs.
Again, no. The power of modern languages comes from providing higher-level abstractions that are closer to human thought processes. Modern programming languages allow you to think directly in terms of things like numbers, arrays, strings, etc. rather than forcing you to think of everything in terms of raw bits. There are many languages that are notorious for making code much easier to write than to read.
> The vast majority of bugs don't come from under-specification, but rather poor/miscommunication.
No, the vast majority of bugs come from a mismatch between the code and the programmer's mental model of what the code does, i.e. the process that the code describes. You can have bugs in code written by a single human. There is no possibility of miscommunication because there is no communication. There is just the code and the programmer's brain.
Um, no.
This can be interpreted in two ways, which lead to diametrically opposite conclusions.
1. I say "start" and you say "stop" when you think 120 seconds have passed, and the result (115 or 87) is the actual elapsed time.
2. I say "start" and some time later (which happens to be 120 seconds, but you don't know that) I say "stop" and ask you how much time you think has passed. The result is your response.
On the first interpretations, everyone's internal clock runs fast (everyone gets to 120 ahead of the actual time), and an old person's run faster than a young person's. On the second interpretation, everyone's mental clock runs slow and an old person's run slower than a young person's.
Is this some kind of new math? 100 and 110 are within 10% of each other, which seems very much in the same ballpark to me.
Alas.
Oh, wait, that's me :-)
Also, structural diff is actually a very hard problem.
That's true, but there is a very big difference between S-expressions stored as text and other programming languages stored as text because there is a standard representation of S-expressions as text, and Common Lisp provides functions that implement that standard in both directions (READ and PRINT) as part of its standard library. Furthermore, the standard ensures READ-PRINT equivalency, i.e. if you READ the result of PRINTing an object the result is an equivalent object. So there is a one-to-one mapping (modulo copying) between the text form and the internal representation. And, most importantly, the semantics of the language are defined on the internal representation and not the textual form. So if you wanted to store S-expressions in, say, a relational database rather than a text file, that would be an elementary exercise. This is why many CL implementations provide alternative serializations that can be rendered and parsed more efficiently than the standard one, which is designed to be human-readable.
This is in very stark contrast to nearly every other programming language, where the semantics are defined directly on the textual form. The language standard typically doesn't even require that an AST exist, let alone define a canonical form for it. Parsers for other languages are typically embedded deep inside compilers, and not provided as part of the standard library. Every one is bespoke, and they are often byzantine. There are no standard operations for manipulating an AST. If you want to write code that generates code, the output must be text, and the only way to run that code is to parse and compile it using the bespoke parser that is an opaque part of the language compiler. (Note that Python is a notable exception.)
What an odd design choice. Why not just have the value be the base 2 logarithm of the page size, i.e. a value between 9 and 16?
Sure, just like you can't separate "pay attention". Both are idiomatic. But you can separate "aufpassen" into "Paß auf". (For the benefit of non-German lurkers, "Paß auf" is a command to pay attention.)
In Hebrew you "place [your] heart" (lasim lev).
For years I have been submitting links through a bookmarklet that goes to /submitlink rather than submit, so I don't get the text box.
I wonder why this feature isn't used more often.
No other story on the front page has this, and I've never seen it before. How did that link get there? It is not the link to the story itself. That is on cnbc.com.
[UPDATE] There is a clue in section 3.3.1 Minimal Declaration Processing Requirements:
"A safety declaration that increases the current safety level must always be recognized. An implementation that always processes code as if safety were high may safely ignore this declaration."
To me this seems to imply that the default value of SAFETY is implementation-dependent.
It's actually much more sophisticated than that. See:
https://www.lispworks.com/documentation/HyperSpec/Body/01_db...
If I were doing this work, I'd look at a rich virtual environment like Minecraft or simcity or something like that. But it could also be coq or a code development environment.