serhei

Dijkstra's personal language design (GCL) actually used anything-based indexing -- you specify the lower bound explicitly when you declare the array, so even if indexing starting from some runtime value k (e.g. k=7, k=b.lower-bound for some existing array b, etc.) is most natural, you provide that as the lower bound. Then a(i) would be translated to e.g. a[i-k] in compilation.

Getting Inform7 to work well probably depended on 'text adventure'/IF culture, since the text adventures themselves rely on this kind of 'restricted natural language' interface to navigate. Conversely, IF developers built up a lot of intuition on how to make pseudo-natural-language input feel natural while keeping the restrictions obvious.

In practice, using UIs that a corporate design department or product manager would never approve today is an implicit fashion-signal.

> The disclosed AI use was apparently limited to inventing the name of a fictional disease. The organizers still counted it among the year’s AI-assisted winners.

This one was interesting to see, because cases like this make the difference between luddite exclusion (anything that transitively comes from 'AI' is spiritually-tainted bits) and accurate disclosure (LLM output is distinguished from human product). Either policy is a valid choice, but lumping the two together as equally 'AI-assisted' tends to confuse rather than help.

This is similar to the 'no gray areas' problem with compiling a list such as https://codeberg.org/ethical-foss/ai-free-foss-alternatives repo and needing a complex system of tags to avoid mixing projects that have measured/conservative stances short of full exclusion, with projects that have gone full slop-cannon.

> Only developers think that in most cases, the hard part is code. Its never been.

The correct way to think about this:

The hard part is ensuring the product does not exhibit undesired behaviours. Writing code is one possible tool for ensuring this. Replacing writing code with LLMs only works to the extent that LLMs accurately predict your definition of 'undesired'. The more unique and innovative your product, the more likely the LLM prediction is to be inaccurate.

There are... multiple blog posts online now about how to use freely available data and modest amounts of compute to train a custom GPT-2-sized model from scratch. It would be quite a policing effort to prevent.

Clearly Apple's decision is based on paternalism, which most people don't appreciate when it's combined with government power. Compare:

"Clearly the ability to eliminate opposing viewpoints was a huge part of the Chinese government's decision, but was far from the only one. Stability and economic prosperity are also very important. My grandma can obey simple laws. But telling her to go to research contradictory political perspectives and decide the correct course of action is a completely different story. Not to mention how many people will just vote for the candidate that pushes their emotional buttons, and read whatever crap on Facebook and click next, next, next until they've elected Donald Trump."

It's still completely illogical to install an update just to wait for another update to fix the problems introduced by the first update.

Apple has had a planned-obsolescence approach for years and years [1], but with the way software used to be distributed and the consumer expectations on hardware design it was less of a problem before. If you want to keep using an old Mac, there are plenty of OS install disks, copies of old shareware floating around, sites like Low End Mac which document what works and what doesn't. The hardware was also usually more repairable. I'm worried that current Macs in the age of App Store OS updates and glued battery will be rendered into expensive paperweights that much more certainly when Apple withdraws support.

[1]: https://www.folklore.org/StoryView.py?story=Diagnostic_Port.... -- "[Steve] would also rather have them buy a new 512K Mac instead of them buying more RAM from a third-party."

You may laugh, but it seems scarily plausible to develop a machine algorithm that generates 12 articles, have a human go through to pick the 3 least-ridiculous ones and do some light editing, and push it out to the news.

Yes, that was a typo on my part. Lake Ontario lengthens any NY-Toronto train line. Lake Erie lengthens any NY-Detroit train line.

I'm not sure that makes sense as a single rail route. If Toronto and Detroit are intermediate stops on a line from NY to Chicago, that would mean the train either goes the long way around Lake Ontario (pointlessly adding travel time) or it goes to Toronto via Niagara and then doubles back west (pointlessly adding travel time for NY-Detroit-Chicago passengers).

Really, Lake Ontario makes any NY-Detroit train line much longer than it could be otherwise.

There could also be a desire to push partial-autonomy features in the short term, when Model 3 owners are making the decision day-by-day whether to drive the car completely manually or whether to rely on whatever level of Autopilot is available now or in 2 years. If driving the car without Autopilot is deliberately made to feel weird and akward, more people will turn on Autopilot in more situations.

Don't worry, those buildings can always be repurposed as condominiums. Unless the housing bubble implodes in which case Toronto has bigger problems.

I'm more concerned about whether the streetcar running on top of there will ever be more than just a sketch. An extension of the streetcar network in that direction has been proposed, canceled, procrastinated, debated for years but nothing actually happening so far.

The ability to buy something on Steam is sadly no longer a guarantee that it works.

Seems like Peter Thiel just has a policy to keep a finger in a lot of pies. Reminds me of the time Yarvin wrote a criticism of Sam Altman:

> Sam Altman (whom I don't know, but SF is a small town and I probably know someone who knows him) ... [1]

It's amusing that the missing link between them would be Peter Thiel.

([1]: If you really want to read the full post you can easily find it using Google.)

To paint a less rosy picture, many countries are good at keeping out US based tracking / social media monopolies because they want to support their own tracking / social media monopolies. It's kind of a "well, duh" moment that China is going to support its own Internet services rather than let that data be collected by people in the United States.

Russia has a similar government-backed Internet services ecosystem going on, although they dropped the ball on blogging and wound up having to do a complex operation to buy Livejournal (where all the Russians were) and move the servers to Russian territory.

Have a look at https://sandstorm.io/

> After a lot of lunacy including running around in the backyard and driveway looking for a spot of coverage, we finally settled on a system of handwritten IOU notes, and most people had to buy in twice and have an appointed stranger promise to send them BTC later. > > I would argue that there were few people savvier than our group when it came to Bitcoin, and we were having this experience? I realized I was maybe a little too immersed in the hype to see where Bitcoin was falling short in usability.

Ironically, this is not too different from how the financial industry solved the problem of having trouble moving large quantities of precious metals. Lots and lots of IOU notes. Eventually, the IOU notes were so ubiquitous that the underlying precious metals could be dispensed with entirely, and we got fiat.

The reasoning on this guy's website is often pretty fascinating: http://www.worlddreambank.org/P/PLANETS.HTM -- these are entire fantasy planets. For a warm-up exercise, he started out by tilting the Earth in different ways and working out how that would affect climate and biomes.

It's worth noting that conventional railways tend to sacrifice a bit of speed (relative to what you could engineer them for) in favour of being flexible in terms of how much passenger capacity can be provided, supporting a mixture of local/express services, and so forth. So the 'sweet spot' for a conventional or high-speed rail line between two locations may tend to be larger.

That's pretty similar to how languages like Scala with higher-order features translate down to the JVM bytecode (which is subject to certain restrictions).

The next boom will be in whatever _isn't_ being hyped right now.

I believe hype is actually Musk's primary product: by constantly coming up with these announcements he plays his part in maintaining the narrative of the US being the leader in tech innovation, over and above the narrative of the US being a formerly cutting-edge economy that is in the process of falling behind. (Which one is actually true is debatable, but managing perceptions is an important part of keeping the economy running.) Someone who merely organized solid electric car manufacturing or workable private space launches would probably not be as successful in attracting investment.

I certainly don't look forward to auditing a Solidity contract with the complexity of the federal tax code.

Imitating other code that is known to work [1]. Lots of testing. Fixing the bug when someone runs into it and complains (a viable last-resort for almost anything besides a Solidity contract).

[1]: For example, when working with filesystems, people write code that they saw other people using. The code may or may not work as designed depending on the specific filesystem. see e.g. https://danluu.com/file-consistency/

Thanks, I edited my comment to be more readable.

Heck, the basic methods of writing provably correct programs have been explained in plain English since at least the 70s:

https://www.amazon.com/Discipline-Programming-Edsger-W-Dijks...

https://www.amazon.com/Science-Programming-Monographs-Comput...

This is not some rocket science type verification with a dependently typed theorem prover language, it's fairly simple paper and pencil logic. It should not be hard to adapt it to Solidity specific concepts like running out of gas.

The reason these techniques are mostly ignored is that the techniques don't scale at all to large programs calling APIs with imprecise semantics (e.g. filesystem, network), and most people would rather publish imperfect software and iterate rather than spec everything up front. Well, unlike most software, contracts are not large, their semantics are meant to be 100% precise, and most people would rather take the time to make sure a contract does what it claims to do rather than discover a bug afterwards. I would hope.

It sure makes me wonder if Ethereum would do better with a less forgiving programming language. The fact that the syntax resembles Javascript is not reassuring, neither is the fact that the very first code snippet in "Solidity By Example" [1] is littered with comments like this:

        // Forward the delegation as long as
        // `to` also delegated.
        // In general, such loops are very dangerous,
        // because if they run too long, they might
        // need more gas than is available in a block.
        // In this case, the delegation will not be executed,
        // but in other situations, such loops might
        // cause a contract to get "stuck" completely.

[1]: https://solidity.readthedocs.io/en/develop/solidity-by-examp...

In general, the easier the code is to read and the harder it is to write, the better. (Force the programmer to think carefully, not the reader!) Anything that gets a comment like that in the Solidity examples should at the very least refuse to compile without the programmer adding some attention-grabbing _UNSAFE annotation. Better, there should be mechanisms to make sure the code is written in a way that everyone understands the consequences of e.g. running out of gas in the middle of a function.