thomasmg

Lacking a large study, we can't know. Of course the CO2 meter companies benefit if people believe it is true.

There are studies that show cancer risk is higher near a nuclear plant. The reason is likely that poorer people live near a nuclear plant; it's _probably_ not because of radiation. My point is: Just having nuclear plants nearby lowers the market price of the property. If there _is_ an accident, the market price of many properties drops to zero. That's why no insurance company will insure the full risk of a nuclear accident: the remaining risk is on the population and land owners. (Property owners may get compensated - paied by taxes.)

In Switzerland there is now again the idea to build nuclear plants, by some (I'm pretty sure the political party that initiated this gets a lot of money from the nuclear lobby - unfortunately the money flow is intransparent in Switzerland.) A recent study in Switzerland [1] has shown nuclear plant are not competitive with solar, wind, hydro, and batteries, not even taking into account that accidents are not fully insured.

[1] https://www.20min.ch/story/akw-debatte-neue-atomkraftwerke-l...

Solar, wind and hydro are all much cheaper, far safer and more efficient these days.

I don't have a strong opinion what is better in this case, but my view is:

document and express intent clearly

Arguably, the void* does that as well?

Any seasoned C++ developer seeing this knows what this reinterpret_cast means.

Same for void*?

it's a bit more text to read

If you have to call it many times, this adds up.

Some might also say it complexifies and uglifies the code

I think the point is that it adds security, which the other options don't. And, it doesn't add complexity on the caller, but only at one place: the implementation.

makes it non-portable on top of that.

This can be solved.

I choose to use Python because I am productive with it.

That, I fully understand. I think many developers are productive in one language: in the one that they know best. Which is probably the one they use most. It might happen that this is is a "fast" language by accident (like Java or Go), or a language like Python. And then there is never enough reason to switch.

"Most engineers would kill for a 5% speedup"

I think this is very rare - maybe a heavily used app in Facebook or Google, where 5% could mean a lot of money. But a factor of 10 speedup is much more common (and possible sometimes).

there is an allure to performance optimization due to the fact that it can be so easily quantified.

That's true. I also think simplicity is quantifiable, and so my personal hobby is to write something impressive in few lines. Like a chess engine, QR code reader, editor, data compression tool, compiler, in 500 lines. But this is mostly for hobbies I guess. For work, it's mostly about features, and then performance, I guess.

I'm not trying to criticize, but Python is known to be much slower than eg. Java or Go etc. So for performance-critcal code, why use Python? I find Python to be very good because it is concise and simple, but I have not used it for production so far.

I understand what you mean; Claude is a tool and does not have feelings, thats clear to me. But how else can I describe what I did? "Wrote to Claude" has the same issue. Posted, typed, inputed?

Well... actually, it isn't. I'm also writing my own programming language (named "Bau"). I asked Claude to convert a minesweeper game from C to that language. I only gave some example programs in my language and the grammar. This worked on the first try (Claude didn't even have access to the compiler).

It is not quite as rare. I calculated it to be less common than being hit by a meteorite, and added a section about that and the Birthday Paradox to Wikipedia, to the article about UUIDs. It got removed / replaced a few years ago however. (If my source was correct, there was actually a woman hit by a meteorite, but she survived, with a leg injury.)

If you do have a UUID collision, chances are extremely high that it's either a software bug, or glitch in the computer. It could be a cosmic ray. Cosmic rays messing with the computer memory or CPU are actually relatively common.

Well there is Google Sheets, Microsoft Office, Figma, and some other heavier web apps.

Sure. But it does save you one instruction: "tee", "get" instead of "set", "get", "get".

You could use "local.tee". It is kind of is "store" + "duplicate".

Well that is how it mostly worked until recently... unless if the developer copied and pasted from stackoverflow without understanding much. Which did happen.

I think the main issue with nuclear reactors is the cost, but yes I agree.

It depends on the use case, but do you consider NaN to be equal to NaN? For an assert macro, I would expect so. Also, your code works differently for very large and very small numbers, eg. 1.0000001, 1.0000002 vs 1e-100, 1.0000002e-100.

For my own soft-floating point math library, I expect the value is off by a some percentage, not just off by epsilon. And so I have my own almostSame method [1] which accounts for that and is quite a bit more complex. Actually multiple such methods. But well, that's just my own use case.

[1] https://github.com/thomasmueller/bau-lang/blob/main/src/test...

For the few days without wind, natural gas is cheaper than nuclear. There is also biogas and hydro. Nuclear is not cheap to turn on off. Also, the insurance cost of nuclear power is not accounted for: basically, there is no insurance, and the state (the population) just have to live with the risk.

So if I understand correctly, you are saying the observer doesn't feel like he is in a superposition (multiple states at once). Sure: I agree that observers never experience being in a superposition.

But don't think that necessarily means we are in a Many-Worlds. I rather think that we don't have enough knowledge in this area. Assuming we live in a simulation, an alternative explanation would be, that unlikely branches are not further simulated to save energy. And in this case, superposition is just branch prediction :-)

(This is way beyond my area of expertise so excuse me that this might be a stupid idea.)

I assume the following happens: while a (small) subsystem is in "pure state" (in quantum coherence), no information flows out of this subsystem. Then, when measuring, information flows out and other information flows in, which disturbs the pure state. This collapses of the wave function (quantum decoherence). For all practical purposes, it looks like quantum decoherence is irreversible, but technically this could still be reversible; it's just that the subsystem (that is in coherence) got much, much larger. Sure, for all practical purposes it's then irreversible, but for us most of physics anyway looks irreversible (eg. black holes).

Why do you think so? The code example shows that you can do RLE (run length encoding) without noise / additional space. I'm pretty sure you can do zip as well. It would just be very hard to implement, but it wouldn't necessarily require that the output contains noise.

[1] https://topps.diku.dk/pirc/?id=janusP

Yes you can do compression, if the text is compressible. The playground [1] has a "run length encoding" example.

Maybe you meant sorting. You can implement sorting algorithms, as long as you store the information which entries were swapped. (To "unsort" the entries when running in reverse). So, an array that is already sorted doesn't need much additional information; one that is unsorted will require a lot of "undo" space. I think this is the easiest example to see the relation between reversible computing and thermodynamics: in thermodynamics, to bring "order" to a system requires "unorder" (heat) somewhere else.

There are also examples for encryption / decryption, but I find compression and sorting more interesting.

[1] https://topps.diku.dk/pirc/?id=janusP

There is a programming language that is reversible: Janus [1]. You could write a (lossless) data compression algorithm in this language, and if run in reverse this would uncompress. In theory you could do all types of computation, but the "output" (when run forward) would need to contain the old state. With reversible computing, there is no erased information. Landauer's principle links information theory with thermodynamics: putting order to things necessarily produces heat (ordering something locally requires "disorder" somewhere else). That is why Toffoli gates are so efficient: if the process is inherently reversible, less heat need to be produced. Arguably, heat is not "just" disorder: it is a way to preserve the information in the system. The universe is just one gigantic reversible computation. An so, if we all live in a simulation, maybe the simulation is written in Janus?

[1] https://en.wikipedia.org/wiki/Janus_(time-reversible_computi...

The problem of XPath 3.1 is that it is very complex [1] - this is a long page. Compared to the 1.0 spec, it is just too complex in my view. For the open source project I'm working on, I never felt that the "old" XPath version is painful.

I think simplicity is better. That's why Json is used nowadays, and XML is not.

[1] https://www.w3.org/TR/xpath-31/ [2] https://jackrabbit.apache.org/oak/docs/query/grammar-xpath.h...

more overloaded than Perl by someone who maybe isn't so great at clear communications.

I have the same feeling. The root of K is APL, but to avoid special characters (I assume), the same symbol has multiple meanings (overloaded), depending on eg. the position, the data type, and the context. The idea is that "programs should be short enough to fit in your head." The challenge is, similar to Perl and Regex syntax, it's very hard and often cryptic to read.

I do think a concise syntax is useful, for a programming language. But at the same time, the syntax should be readable, and that probably means that each symbol or operator must only have one meaning, and that meaning should be (more or less) obvious.

K is an array language. Even an integer is actually an array of one element. I think that makes sense for a tiny language: This is the simplest possible type system. You can even support strings, when using eg. metadata or using a heuristic like "a string is always zero terminated" (which is what I used for my tiny language).

The point is that you don't need the very latest version. The 20 years old version is enough.

The syntax in Kotin is: "val name: String? = getName(); if (name != null) { println(name.length) // safe: compiler knows it's not null }" So, there is no explicit type conversion needed.

I'm arguing for integer / and %, there is no need for an explicit "non-zero integer" type: the divisor is just an integer, and the compiler need to have a prove that the value is not zero. For places where panic is fine, there could be a method that explicitly panics in case of zero.

I agree an annotation / effect system would be useful, where you can mark sections of the code "panic-free" or "safe" in some sense. But "safe" has many flavors: array-out-of-bounds, division by zero, stack overflow, out-of-memory, endless loop. Ada SPARK allows to prove absence of runtime errors using "pragma annotate". Also Dafny, Lean have similar features (in Lean you can give a prove).

I think it's fine for division to be exposed as a panicking operation by default

That might be true. I think division (by non-constants) is not very common, but it would be good to analyze this in more detail, maybe by analyzing a large codebase... Division by zero does cause issues sometimes, and so the question is, how much of a problem is it if you disallow unchecked division, versus the problems if you don't check.

Thanks a lot! I wasn't aware of Gleam, it really seems simple. I probably wouldn't say "learn in a day", any I'm not sure if it's simpler than Python, but it's statically typed, and this adds some complexity necessarily.

I would be very interested in this research... I'm trying to write a language that is simple and concise like Python, but fast and statically typed. My gutfeeling is that more concise than Python (J, K, or some code golfing language) is bad for readability, but so is the verbosity of Rust, Zig, Java.

Well, the parent wrote "I honestly just don't believe that Rust is more complex to onboard to compared to languages like Python." And you wrote "The language itself is not more complex to onboard." So... to contract Rust with Scala, I think it's clearer to write "The language itself is not more complex to onboard _than Scala_."

To that, I completely agree! Scala is one of the most complex languages, similar to C++. In terms of complexity (roughly the number of features) / hardness to onboard, I would have the following list (hardest to easiest): C++, Scala, Rust, Zig, Swift, Nim, Kotlin, JavaScript, Go, Python.

the article was not intended to users but to other language designers.

That might be true, but it shows the direction that Rust is talking: put in the kitchen sink, just like C++ and Scala did. And _that_ is very much important for users.

Hm, you claim that Rust and Scala are not more complex to onboard than Python... but then you say you never used Python? If that's the case, how do you know? Having used both, I do think Rust is harder to onboard, just because there is more syntax that you need to learn. And Rust is a lot more verbose. And that's before you are exposed to the borrow checker.