Kranar

No disagreement on your point, but this is a different argument than claiming that macros are an ugly hack to workaround lack of reflection.

Because Rust lacks reflection macros are used to provide some kind of ad-hoc reflection support, that much we agree... but macros are also used to provide a lot of language extensions other than reflection support. Macros in general exist to give users some ability to introduce new language features and fill in missing gaps, and yes reflection is one of those gaps. Variadics are another gap, some error handling techniques is yet another, as are domain specific languages like compile time regex! and SQL query macros.

Of course you could perceive it, measure it and record it. The entropy of your body or your brain is not necessarily increasing, nor is the entropy of your computer or other information storage systems.

Entropy only statistically tends towards an increase in closed systems and neither your computer or your brain are closed systems. They are both constantly getting energy from an external source of power and in turn dispersing previously consumed energy out into their environment.

And yet you still manage to perceive things just fine... in fact your perception of the world is unlikely to change whether or not the entropy in your brain increases or decreases by some bounded amount (of course too much of either an increase or decrease will destroy your brain).

Your claim about remembering an event, which likely alludes to Laplace's demon [1], requires an overall increase in entropy in the system as a whole, but does not require an increase in entropy in the specific part of the system that is recording the event.

Every time your computer calls a function like memset(dst, 0), or sorts a list, or arranges data into some kind of structured binary tree, your computer is decreasing its own internal entropy by taking a statistically likely arrangement of bits and transforming it into a very unlikely arrangement of bits. The decrease in the internal entropy of your computer is more than offset by an increase in global entropy but that global entropy is radiating way out into the cosmos and has no impact on your computer's ability to register information.

[1] https://en.wikipedia.org/wiki/Laplace%27s_demon

There's a perfectly good explanation for why though, in fact the explanation is what motivated the formalism of entropy to begin with. There are significantly more ways that the energy contained within a closed system can spread throughout that system than there are ways for energy contained within a closed system to condense, so that if you observe the state of a system at two different moments in time, you will expect to see it evolve towards the statistically more likely outcome than the statistically less likely outcome.

And from first principles, that's what entropy is, a measure of how energy is dispersed throughout a system. Of course once you have that first principle understanding of entropy then you can come up with more rigorous formalisms to properly quantify what it means for energy to be distributed throughout a system, such as measuring the number of microstates that correspond to a macrostate, and other various formalisms that are more or less equal to each other... but fundamentally they all start from this basic principle.

Strictly speaking, modern cosmology does not treat the Big Bang as the beginning of all of existence, it's what happens when you take observations about large scale cosmology and run them backwards in time.

Based on the information we have available about our universe, we can't make predictions or formally model anything prior to a certain point in time, consequently it's convenient to treat this moment as the earliest point in time in which physics as we know it makes any sense. So while there may have been some kind of existence prior to the Big Bang, we have no way to make sense of it even at a conceptual level. Given that, we may as well treat this special point in time as the beginning of the universe as we understand it and can explain it using physics, as opposed to some absolute beginning of all of existence.

I used to think the models got worse over time as well but then I checked my chat history and what I noticed isn't that ChatGPT gets worse, it's that my standards and expectations increase over time.

When a new model comes out I test the waters a bit with some more ambitious queries and get impressed when it can handle them reasonably well. Over time I take it for granted and then just expect it to be able to handle ever more complex queries and get dissappointed when I hit a new limit.

I don't understand your follow up, are you still maintaining your claim that almost every other exchange in the world has been stagnant or declining?

Worth noting that a stock exchange becoming defunct is not the same as the value of the index associated with the stocks listed on that exchange going to zero.

For example numerous US stock exchanges also go defunct. Nevertheless the value of the stocks that traded on those exchanges remains unaffected. It's not like if NASDAQ went out of business tomorrow that Google and Microsoft would all declare bankruptcy.

>Note that almost every exchange outside the US has been flat or negative for decades.

As someone who works in finance this struck me as a remarkable claim. Upon inspection it turns out to be spectacularly incorrect. After adjusting for inflation it's actually the opposite, the vast majority of countries have seen their own version of the S&P 500 grow over a 30 year period, after adjusting for inflation, not stagnation or decline. Developing countries, particularly those in Asia, have seen incredible returns over a 30 year period, albeit with a great deal of volatility involved.

Our neighbor to the north, Canada, has seen gains that are slightly below the U.S., but our neighbor to the south, Mexico has seen about the same growth as our own, once again accounting for Mexico's own inflation.

Europe has also experienced a great deal of growth with many European countries even growing moreso than the U.S., for example Germany.

While there are examples of decline, they are in countries that are both poor and have unstable governments. Most countries that are strictly poor but don't suffer from instability have for the most part seen growth rather than stagnation.

So I don't know exactly what led you to believe your claim that "almost every exchange" has been flat or negative, but it's certainly not correct.

Oh that's fair. I am not actually an LLM expert so I could have some misunderstanding about this. I remember hearing this explanation given for why previous ChatGPT models failed to answer "How many "r"s are in strawberry?", but perhaps this was an over simplification.

Forget single character tokens, you can just go on OpenAI's own tokenizer website [1] and construct tokens and ask ChatGPT to count how many tokens there are in a given string. For example hello is a single token and if I ask ChatGPT to count how many times "hello" appears in "hellohellohellohellohellohellohellohellohellohellohellohellohellohellohellohellohellohellohellohellohello" or variations thereof it gets it right.

Be careful that you structure your query so that all of the "hello" are in their own token, because you could inadvertently ask it where the first or last hello gets chunked into the text just before or just after.

[1] https://platform.openai.com/tokenizer

This is true, in general LLMs are not great at counting because they don't see individual characters they see tokens.

Imagine you spoke perfect English, but you learned how to write English using Mandarin characters, basically using the closest sounding Mandarin characters to write in English. Then someone asks you how many letter o's are in the sentence "Hello how are you?". Well you don't read using English charaters, you read using Mandarin characters so you read it as "哈咯，好阿优？" because using Mandarin letters that's the closest sounding way to spell "Hello how are you?"

So now if someone asks you how many letter o's are in "哈咯，好阿优？", you don't really know... you are familiar conceptually that the letter o exists, you know that if you spelled the sentence in English it would contain the letter o, and you can maybe make an educated guess about how many letter o's there are, but you can't actually count out how many letter o's there are because you've never seen actual English letters before.

The same thing goes for an LLM, they don't see characters, they only see tokens. They are aware that characters do exist, and they can reason about their existence, but they can't see them so they can't really count them out either.

It seems like people think dereferencing an unengaged optional results in a crash or exception, but ironically you are actually less likely to get a crash from an optional than you would from dereferencing an invalid pointer. This snippet of code, for example, is not going to cause a crash in most cases, it will simply return a garbage and unpredictable value:

    auto v = std::optional<int>();
    std::cout << *v << std::endl;

While both are undefined behavior, you are actually more likely to get a predictable crash from the below code than the above:

    int* v = nullptr;
    std::cout << *v << std::endl;

I leave it to the reader to reflect on the absurdity of this.

There is no reason that ambiguities or paradoxes can't be expressed analytically and formally. Math and computer science are full of such things and they are celebrated.

Being hard to communicate is precisely why it's important to communicate rigorously and formally.

Not a quibble at all. The redshift I'm referring to is the kind of redshift due to gravity, as opposed what you're describing which is redshift due to the Doppler effect.

Most languages you mention let you import the individual names that you want, and you can resolve potential clashes at the point of import. In C++ you basically ```#include``` a file and with it comes a flood of names that are often times unpredictable.

It can be a general-purpose C++ IDE and also very tightly coupled to Qt at the same time.

Visual Studio is also a general-purpose C++ IDE and yet I don't think anyone would say it's independent of Windows.

Which is why that advice confuses the metric for the principle.

This is your exact quote:

"We write code once, but read it many times, so shorter names (incl. namespaces) seems like a poor efficiency choice."

And the point being made is that there are cases where shorter names are actually more readable than longer names and one of those cases is when every name shares a common prefix. By prefixing everything with something common code becomes more uniform, and names become less distinctive and consequently less readable because it's harder to identify and differentiate sections of code. Code ends up looking like a soup of std::s everywhere.

It would be like a chess player who only tries to control the center because someone told them that controlling the center is important, but then repeatedly loses to the King's Indian Defense [1] because they never took the time to fundamentally understand why the center is important and so they don't realize how the King's Indian Defense is used precisely to destabilize the center of the board with sharp angles of attack.

They just blindly apply what they hear... and let me tell you there are plenty of mediocre chess players who do just that.

In almost any field from programming to chess to sports, you can find guidelines and good rules of thumb and I do not want to discourage people from knowing those rules because having heuristics certainly improves productivity. But don't ever let those rules become dogma; at some point it's worth understanding what the principles behind those rules are, when do they apply and when don't they apply.

>Are you even a developer?

Note that you keep trying to make this discussion personal whereas I have kept this discussion about the topic and the argument.

I would respectfully ask you to do the same, let's discuss the topic and avoid making this personal. It's irrelevant how long you've been programming for or how long I've been programming for or even if I am a programmer at all.

Trying to justify arguments on the basis of who you are or who I am is a poor way to go about engineering best practices.

What matters is whether your points can be justified.

[1] https://en.wikipedia.org/wiki/King%27s_Indian_Defence

I like to present questions to people to justify their position so that others reading the advice can better evaluate it, understand the reasons and make a more informed judgement on it.

I am also principled in critiquing an argument and never critiquing a person. I said that the advice you gave is a form of cargo culting, but I also said in the very first sentence that "I am not saying you are cargo cult programming".

I don't think there is anything wrong with getting into the subtleties of whether the advice is what you originally said it was, which is that longer names are better than shorter names, or whether the advice you learned was that descriptive names are better than non-descriptive names.

I think the subtlety between those two statements is not being appreciated and without a clear distinction other people may read that advice and take away the wrong conclusion.

Take care.

There is no such thing as slow photons, photons always travel at the speed of light.

When light enters a medium there are two mostly (but not entirely) equal ways to think about what happens, one is to view light as a purely electromagnetic wave that interacts with atoms and causes the atoms to oscillate. This oscillation produces its own electromagnetic wave that interferes with the original wave. The result of this interference will be an electromagnetic wave with the same frequency, same amplitude, and travelling in the same direction as the incoming light but shifted backwards and it's that shift backwards that gives the appearance of light slowing down.

That explanation is pretty good and accounts for almost everything except for the latency of light through a medium.

If that's what you want to model, then it's better to think of light as made up of photons instead of being a wave, and then when photons enter a material they no longer exist as independent particles but through a process of absorption and reemission by electrons in the material become particles called polaritons. Polaritons do have mass and hence travel slower than the speed of light.

Neither of these explanations are perfect, but the full explanation is ridiculously complicated and there's no suitable metaphor for it. If you are interested in knowing the edge latency of light through a medium, then the polariton explanation is appropriate. If you want to know the "bandwidth" explanation of light through a medium, then the wave explanation is appropriate.

This is some absolutely crazy idea. I mean I'm in no position to analyze it critically but that is pretty mind blowing.

Almost everything you said is correct. Photons do not have a reference frame, so time does not advance because for a photon there is no time coordinate system in the first place. It's not simply that photons don't experience time, it's that time and space don't exist for photons.

>They cannot change between emission and absorption, no matter the distance.

From the point of view of a photon, neither time or space exist. They have no reference frame at all. However, from an outside frame of reference that is travelling less than the speed of light, photons do change for example they get red shifted as they move through stronger gravitational fields.

I am not saying you are cargo cult programming, but being a cargo cult programmer has nothing to do with seniority. There are plenty of people who have been programming for decades who blindly follow rules because that's how they learned things, that's what they were taught is good practice, and they never bothered to question it, reflect on it, and they go along with it because of cultural reasons rather than because they have a genuine understanding of the principles.

>I might be wrong, but these are the lessons I've learnt over the decades working on a variety of projects of different size and durations ...

But what lesson did you learn? That long names are better than short names, which is what I called cargo cult programming and an instance of mixing up the metric for the principle? Or did you instead learn that descriptive names are better than non-descriptive names?

If it's that long names are better than short names, then by all means continue using std:: everywhere. If instead it's that descriptive names that communicate purpose or intention or actual information are better than non-descriptive names, then having a bunch of std:: everywhere doesn't do much of anything to help readability, it just adds noise.

Now people can and do justify the use of std:: but I've never heard it on the basis of making code more readable. There is nothing self documenting about a bunch of names that all share a common prefix.

And this doesn't even touch on how ironic it is that std is itself non-descriptive jargon that is an abbreviation of standard, but I am almost certain that if everyone had to liter their codebase with standard:: everywhere, no one would think twice about what the right thing to do is.

OP is making a dig at C++ the language. A lot of people, most likely OP included, consider the language to be a monstrosity, so how can the person who developed such a monstrosity possibly share good advice on programming?

That said, I sometimes get the impression that Bjarne recognizes the monstrosity that he created and a large part of his talks and his book is how to make use of the good parts of C++ without making use of the bad parts.

>We write code once, but read it many times, so shorter names (incl. namespaces) seems like a poor efficiency choice.

I think it's fascinating how different people can interpret this so differently. I feel like it's precisely because we read code so much more than we write it that we should prefer using names that get to the point, instead of having so much noise and repetitive boilerplate.

Reading a soup of std::this, std::that, std::foo, std::bar is so difficult to parse through. Especially if you're like me and you sound things out in your head, which I recently learned is not how everyone reads.

The only justification for writing all those std::'s is because compilers can't disambiguate names from their context, but you're not going to find a human who comes across a use of vector<Foo>, or sort(...) and throw their hands up in confusion wondering what was meant.

>We write code once, but read it many times, so shorter names (incl. namespaces) seems like a poor efficiency choice.

This to me seems like a cargo cult justification, where you've heard the argument that descriptive names are helpful for readability, so we should name our variables in a way that conveys their intention as opposed to 1 letter names or obfuscated abbreviations, but instead of genuinely understanding the principle behind the rule, you think the rule is simply that it's better to have long names over short names.

Descriptive names that can be used to disambiguate variables from one another on the basis of their purpose... yes, please do that. Writing long names just so that they are long, especially by giving everything a shared prefix like std::... no, that's a misunderstanding of the justification behind the rule.

It's similar to that saying along the lines of when a principle becomes a metric, it ceases to be a useful principle.

Qt Creator makes working with Qt a heck of a lot easier in a way that working with Visual Studio or vim does not. It comes with an integrated Qt form designer, Quick Designer for QML, supports Qt's moc syntax out of the box, integrated support for Qt Test Integration, native support for Qt Assistant and documentation and integration with Qt's internationalization tools.

The idea that "QtCreator" is some totally independent IDE that just coincidentally happens to have the letters Qt at the beginning in the same way that Java and JavaScript are independent of one another, but otherwise has no relationship to Qt the library is just patently absurd HN pedantry.

Fascinating, you went from saying this has nothing to do with postmodern philosophy to describing constructive postmodern philosophy.

I love it!

Time travel is required for this thought experiment. The single electron moves forwards and backwards in time so that at any slice of time it can appear at multiple locations simultaneously. Just like a time traveller can go back in time and there would be two of them, this electron travels back and forth in time so that there are numerous instances of it.

You can't just set c = 1 as a pure number and conclude that E = m, the units won't match.

Natural units are very useful when doing math, but they don't reduce constants down to plain numbers, they still retain their units. Once you factor this in the rest of your argument falls apart.

>A simulation of that would be training materials for LEA or forensics teams to practice their craft.

You are laughably misinformed on this matter in a way that is quite incomprehensible. You are welcome to refer to the legal definition as per the actual legal text instead of continuing to make rather bizarre claims on a topic where it's clear you know nothing about:

https://www.congress.gov/bill/108th-congress/senate-bill/151...

Even without having to refer to the actual text, I am confident most reasonable minded people understand the meaning of the term "simulated" and can take a position on whether it should be legal or not without arguing whether simulation means training materials or whether the term is legally meaningless.

The fact that you don't is all I need to know that continuing this conversation with you is entirely pointless.

Yeah, good luck simulating a terrorist attack at an airport, or simulating legal tender, or simulating a police officer.

There are plenty of laws that make it an offense to perform a simulation. Nitpicking the term simulation as being meaningless, whether in a legal context or otherwise, isn't a particularly noteworthy discussion to have. I think most people understand the meaning of simulated CSAM and can have an opinion on whether it should be legal or illegal without being pedantic about the word "simulated".

No dispute about that, antisemitism as a term to describe persecution of Jews certainly is used to apply to instances that took place 1000s of years ago. That does not mean that antisemitism didn't change, with different forms emerging with different excuses. Hatred of a group of people often precedes rationales for that hatred, excuses are made after the fact.

That doesn't change the fact that hatred towards Jews as a race, hatred towards them on the basis of their birth, their intrinsic nature, as opposed to on the basis of their religion or as a culture, emerged in the 19th century. In almost all of the instances you mention prior to the 19th century, with the exception of the Cossack uprising, conversion from Judaism to Christianity would have spared you. The Cossack uprising and in particular the Khmelnytsky Uprising was not on racial grounds, it was on mercantile grounds and opposed to Jews on the basis of their status as tax collectors as well as propaganda about their collaboration with Polish nobility. Certain Jewish communities seen to have not been involved in either aspect were spared, indicating that the hatred towards Jews was not based on race.

In Nazi Germany, if you were considered a Jew by race, nothing you did could have spared you. Nothing.