abainbridge

I don't think centuries is long enough. We don't seem to have finished evolving our coping strategies for alcohol and lactose and it is probably 20,000 years since those were added to our environment. And in both cases, we already had a head start - there has been trace amounts of alcohol in overripe fruit and lactose in breast milk, basically forever.

That's not what I see. With uBlock Origin installed, if I visit news.bbc.co.uk, for example, I still get the accept cookies banner.

Impressive bug hunting skills.

When was this bug introduced? Does anyone maintain a list of when all the known Linux kernel bugs were introduced? I'd love to know how many bugs are added to the kernel each year, and if the rate is changing.

I'm not trying to troll. I think the Linux kernel is an amazing piece of software engineering. I just think this would be an interesting metric.

I can't find anything about the EU implementing this. Here is a UK document from July 2021 discussing why the UK might want to do it, and thus implying that it hadn't yet - https://assets.publishing.service.gov.uk/government/uploads/...

You're right.

Their expression (simplified) was: *target = pixels[j] << 24, where pixels contains items of type unsigned char.

I hadn't realized that the pixels[j] was being promoted to an int rather than unsigned int. Eeep.

> I really dislike the promotion logic in C.

Agreed. I'll add that to my list of C dislikes.

I still think that even with manually promoting to the appropriate unsigned type isn't sufficient. Because target has type long*, so coercing the result of (unsigned int)pixels[j] << 24 to long still causes overflow and therefore UB... unless there's yet more I've missed.

Edit: Damn it, again, that's what the discussion says (https://github.com/glfw/glfw/pull/1986#issuecomment-95800024...).

I've always thought that the "obfuscated C competition" is proof that it is quite hard to obfuscate C. There'd be no challenge in most other languages. (I haven't got enough knowledge of Zig to know if it is as easy to understand as C in general).

Agreed. I think it was only a problem because of ubsan. I guess ubsan added checks to the generated code that looked at the value being shifted left 24 and saw that overflow occurred and therefore raised its undefined behaviour signal.

The code would never fail on a two's compliment machine. What ubsan is saying is that the rules of C don't guarantee this code to work - it only works because the overflow writes into the sign bit, which is where the next thing expected it to be anyway.

If the above is true, I don't think their "fix" helps: https://github.com/glfw/glfw/pull/1986/files. I would have thought that the important part is to change the longs to unsigned longs. Edit: Ah, right, that's what the discussion says: https://github.com/glfw/glfw/pull/1986

I disagree. A simplified version of the problem expression is:

unsigned char foo = 0x80; long bar = foo << 24;

It overflows and bar is set to -2147483648. If foo was initialized with 0x7f, there'd be no overflow and bar would be set to 2130706432.

In the original problem, the value of foo isn't known at compile time.

I was expecting a compile time warning and thought ubsan shouldn't be necessary. But CUViper explains why the UB can only be caught at runtime.

The article discusses some undefined behaviour resulting from shifting an unsigned char left by 24 places. Any idea why the compiler wasn't warning about that? It seems like it would be easy to implement that warning in the compiler. I feel that I'm missing something.

Excellent link to the Huffman example. I think it will take me a lot of study to grok it. I'll consider investing that effort.

> I tend to see lots of structs, bit-packing, and bitwise operations that don't make as much sense in APL.

That's why I mentioned "performance matters". Those things are common in algorithms where performance matters. If APL isn't interested, then it isn't good for most algorithmic work. Those operations aren't some quirk of current CPU architecture. It is less work in our universe to do bit shifts than multiplies. And bit packing reduces storage and IO, which also saves work at a fundamental level. The same operations are used in FPGA/ASIC designs where the architecture is much more free. Maybe quantum or analogue computers would change that picture a little but that's not what APL is for.

I'd say the main use for a symbolic thought notation is when working on performance critical stuff. If performance isn't critical then I use a simple algorithm and a simple implementation. Higher level system design stuff is usually better done as diagrams than symbolic notation. I guess when working on a large codebase I'm using the structure of the symbolic programming language to help me think about how distant parts of the code interact. But that doesn't sound like something APL would be good at either.

That's interesting. I was thinking of going down the same route. Which Allwinner board? And how fast did it boot?

And another: types. They seem to be under emphasised in APL. In my bilinear example the original code had lots of "(pixel >> 8) & 0xff" kinds of things to access the colour components. I created a type to allow those to become "pixel.g". That immediately made the code feel easier to understand. (Pleasingly it made the code run faster too).

One possible reason for me not thinking APL is a good notation is that it seems to avoid assigning names to things. I believe good names are a vital tool for a thinking notation. In my bilinear upscaler example, I was initially struggling to understand the code I had found on the web. The variable names were all things like "x1a", "x2". I changed them to things like "srcX" and "weightX". That helped a lot.

> I love the typesetting of the math in these old papers

I agree except that the first thing the paper does is define "1" to be a function that "produces a vector of the first N integers". Highly confusing. It turns out that symbol isn't a "1" and rather is a weird squiggle that unfortunately looks like one.

> 3. When people think about algorithms, they write code or pseudo-code.

Or draw boxes and arrows on a whiteboard or pieces of paper. But I agree, they usually don't write APL or anything like it.

I think this is a fascinating subject that touches on how human general purpose intelligence works. I've spent decades working with C like languages and by now I find them hugely helpful thinking tools.

I did some optimization work on a bilinear bitmap upscaler recently [1]. There were times in the middle of that work where I felt like I was sitting watching someone else do it for me. Not physically watching, but more like a part of my brain was doing it automatically. The amount of state in scope at once is too big to fit into my working memory (maybe I'm weak at this), so the work has to be symbolic manipulation. It feels like there are patterns in the symbol manipulation that my brain can do with minimal effort. Somehow the result is that I can write (hopefully) correct code that is beyond my ability to comprehend without the notation. The fact that I don't understand how I understand it contributes to the feeling that someone else wrote it for me.

The problem I have looking at APL is that it doesn't look like it would help with this kind of work. The examples in the paper are all mathematical and abstract. I'd like to see some real-world practical examples, where performance matters, IO is fiddly and memory layout is part of the API. And instead of the problem domain being "differentiating a polynomial", I'd rather it was decoding the Huffman data out of a JPEG, or implementing a video game's collision detection system. My feeling is that C like notations are better for that type of thing. Maybe that isn't what APL is supposed to be good at. However, the paper starts by saying APL is needed because maths notation is not universal.

[1] https://stackoverflow.com/a/69633678/66088

Ah, OK, 1947.

"The plan which is, recommended by the United States provides for certain discrete frequencies, with appropriate guard bands, for those industrial scientific and medical devices which cannot be shielded effectively. This assures a minimum disruption of vital communication services. The allocation of frequencies for this purpose is justified because of the tremendous investments in equipment and the public demand for the various services performed, together with the harmful interference to radio communications which would result if such devices were scattered indiscriminately throughout the spectrum. The frequencies proposed are:

13660 kHz

27320 kHz

40980 kHz

2450 MHz"

http://handle.itu.int/11.1004/020.1000/4.62.51.en.108, page 628.

A review of the history of microwave cooking implies that the interaction of 10 GHz microwave radiation with water was understood by WWII.

"effective penetration and heating favors wavelengths in the cm range (1–30 GHz). Higher frequencies cannot penetrate sufficiently, and much lower frequencies require very high fields, and can have poor coupling unless making use of direct contact or inductive heating. In the years following WWII, emphasis was thus placed on frequencies in the low GHz region, where both the historic development of microwave power sources and serendipity converged."

https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=9393469

Not really an answer, but here's some context...

In 1952, a paper called Tubes for dielectric heating at 915 megacycles said this, "Dielectric heating can be much faster at microwave frequencies. Because leakage radiation is large enough to interfere with communications, heating is best done at assigned frequencies. The bands at 915 and 2,450 megacycles are most useful."

https://ieeexplore.ieee.org/abstract/document/6371890

Isn't Intel's loss of the lead largely because their fabs don't produce as many square metres of chips as TSMC and Samsung's fabs? Once those guys had more scale it was only a matter of time until their fabs became better than Intel's. Once they took the lead, the problem only compounds, since people are switching to AMD or ARM based chips and that moves even more of Intel's scale to TSMC and Samsung. It seems like a vicious circle for Intel.

Admittedly Intel having its own fabs looks good while everyone else is struggling for capacity, but I assume that will be fixed eventually. When it is, I expect Intel's decline to hasten.

Intel are already experimenting with using other people's fabs. I think this is their best path.

I read the article and found myself saying "No, no, no!". Then I read your response here and completely agree with it. How does this difference come about? There's no way to prove who is right. Maybe people's experience of different domains is part of the cause. But mainly I believe the difference comes about due to the different way people's brains work. I think the most harmful thing you can do to a team is mix people together who naturally have different approaches. This aspect never seems to be tackled directly by the interview process.

Nice. Is anyone doing the same but with more focus on Europe? Lake Geneva or Lake Garda with the surrounding mountains would make a nice scene.

I read it as Q ovary, which after a moments thought my brain turned into queer ovary (taking inspiration from the Q in LGBTQ). That still didn't make any sense.

Yeah. And it fails the "make the easy way the right way" test of language design.

I have great hope for Zig. I agree with Andrew Kelley on most of the design decisions I've paid attention to.

>for loop can only be used to iterate over elements of an array, if you want to just execute a block N times, you need while…

The Zig docs suggest something like this:

    var i: usize = 0;
    while (i < 10) {
        i += 1;
    }

Is there a plan to provide a mechanism to stop "i" from remaining in scope after the end of the loop? I couldn't find anything relevant with a quick web search.

I use integer iterating for-loops a lot in C. I just checked a 5000 line project of mine that deals with bitmaps. There are 100 occurrences of something like:

    for (int i = 0; i < 10; i++) {

I think these would all become while-loops in Zig. Exposing 100 variables to a larger scope than they need to be sounds like a source of bugs to me.

I can't think of a good one. Graph-like data structures is a common example of something that's a bit difficult in Rust - see https://stackoverflow.com/questions/34747464/implement-graph.... But the answers there seem reasonable and I'm not a Rust expert. I guess my point is that nobody would even need to ask this question if the implementation was in C.

> I posit that the second set stays the same size: there’s no reason or evidence to think that porting C++ to a memory-safe language results in additional SQL injection.

I think I disagree, although I prefer C to C++ these days. I posit that memory safe programming languages are more complex than C and sometimes cause code that would be simple in C to be written in a more complex way to allow the memory safety to be maintained. I posit that complexity is one of the causes of security vulnerabilities.

Haha. True. Some parts of physics are way shakier than others though. For example, the whole big bang, dark matter, dark energy area needs the qualifier of, "We know we've got something wrong here, but its the best we've got". (eg see https://en.wikipedia.org/wiki/Big_Bang#Problems_and_related_...). I'm trying not to be controversial here. I'm just using this as an example of physics with well known problems.

Regarding, "Quarks are the fundamental building blocks", do we actually think that? If so, why? I'm genuinely curious. Is it just because we haven't seen anything more fundamental? That would violate your "We now think that" qualifier - ie if that is the reason, the qualifier should be "We have NO reason to think that...".

> Whenever you have abstraction, you have lost what it means to be an engineer.

That's an interesting observation. I'd say engineering does have abstractions, but they're much better. For example, treating an RSJ as a simple uniform piece of material is an abstraction. In reality it is a crazily complex mesh of crystals. But the abstraction is simple and well studied, so it can be used reliably.

Programming abstractions are less reliable. Even commonly used ones like "the filesystem" and "the heap" are vastly more complex. It is almost impossible to remember all the possible hazards when you use them.