normac

Count me in on this as well. It's very strange because it's not a voice, but in some sense there is sound--I can "hear" when there's a rhyme, for instance.

I've heard it claimed that the reason some people think they dream in black and white is that there wasn't any color content at all (not even grayscale). They think back and can't remember any colors, and assume it must have been grayscale, because their waking consciousness can't imagine what it would be like to see something without color.

Similarly, it's hard to imagine how you could hear words with no voice speaking them (at least it's hard for me) even though we're experiencing it right now!

On the off chance you haven't heard of him, you might want to check out Daniel Tammet [1]. He's a high-functioning savant who has number-related synesthesia, can do calculations by juxtaposing images as you describe, and he's cultivated these abilities to the point that he can perform incredible feats of calculation and memorization.

[1] https://en.wikipedia.org/wiki/Daniel_Tammet

I didn't mean to compare native mobile apps to web apps (though I see now how it could be read that way). I'm talking about native software in general. I chose smartphones for the comparison because they're the most notorious about being slow, even as their hardware performance approaches what PCs were like just a few years ago. Although even some desktop apps manage to be as janky and dog slow as almost anything from the Win98 era, e.g. iTunes until a couple of years ago. By contrast, the cheapest Third World market smartphone would run Win98 apps blinding fast.

In general there's an arms race between hardware getting faster and native developers getting more and more lazy about efficiency. On the desktop, the hardware is finally winning--it's just too damn fast. Hopefully that will happen with smartphones too.

This is such a great demonstration of both how fast JS engines have become in the browser, and how much less efficient native software has become overall. Running on top of an x86 emulator in JavaScript, it's still faster to pop open a file browser and click around than it is on some modern smartphones.

One of my favorite pieces of code I've written is a 150 line Python script I made to solve a really ugly text processing problem. I have tried to use it as a code sample when talking to potential employers, but it backfires because it makes the original problem look so simple that they wonder why I bothered to send it.

Python occupies a niche that isn't going away any time soon: making it easy and natural to write readable, straightforward, more-or-less imperative, slightly boring code of the type you learned in CS 101.

This is still a very practical way to solve many problems and I'd wager for most programmers it's still the easiest way to do things. Maybe it will always be. It's hard to imagine there'll be a generation of programmers some day that finds it easier to compose dozens of tiny modules, chain callbacks with a variety of async abstractions, and implement as much as possible in tiny idempotent functions.

I feel like the worst case scenario for Python is that it will fade into the wallpaper of mature and unsexy languages like Java and C++ that nonetheless run the world and will probably be around for another 100 years at least. I'm guessing Guido would be cool with that.

Totally out of left field here, but I got some auditory synesthesia from watching this, especially on high speed. If any of you did as well and are interested why, it's probably the same phenomenon talked about here: https://www.newscientist.com/article/dn14459-screensaver-rev...

That's pretty neat. Clearly some level of parsing needs to happen before run time, or else it couldn't even balance braces to know where the function body ends. So it must be that it parses the function body just enough to figure out where it starts and ends, then does a complete parse at runtime (probably building off the results from the first stage).

That's pretty much what Tcl is, even to this day. Ousterhout saw scripting languages as extremely high level tools used to issue commands to the low level code that does the heavy lifting. It's very much the same philosophy as shell scripts, except you implement new commands as extensions to Tcl instead of command line programs, and it all runs in the same process.

Of course, the language has matured and now it's also usable for building rich and complex apps top to bottom, just like any modern scripting language.

Interestingly, Tcl was parsed the same way all the way up until Tcl 8.0 introduced a bytecode system in 1997. Each line was parsed right before execution with no separate parsing stage--your code could crash in the middle of executing from a syntax error.

Tcl is now about as fast as a typical scripting language and its implementation is regarded as a model of high-quality readable code. I wonder if John Ousterhout (the creator of Tcl) knew he was building a rough first system that he would need to rewrite later, or he really thought it was the right way to do things at the time.

(To be fair, Tcl is a whole lot simpler to parse than JavaScript and Ousterhout is a good coder, so even the pre-8.0 versions were fast enough to be practical for everyday scripting tasks.)

This kind of thing makes me wonder if there are dozens or hundreds of other cases where people were lost at sea and survived for many months and thousands of miles, but never made it to land so we'll never know.

This raises an interesting problem--could we find the word even faster by using something other than a standard binary search?

The first thing that comes to mind is skipping past letters that don't appear very often at that point in a word with the current prefix--or to be more granular, you could change your counter (here g) to a float and somehow weight each letter by how rarely it occurs after the letters you've established so far. So if you've currently established that the first four letters are "pro," and "z" almost never occurs after those letters, "z" might be given a weight above 1 so the counter skips right past it.