abainbridge

I read the first few pages. It was riddled with problems.

1. Section 1.1 shows an APL program "1 2 2 2 2 2 ⊤ n" and says, "The confusion here lies in the fact that you might not know what ⊤ means.". Nope. The confusion is that I don't know what any of the symbols do or how an APL program is structured. I expect this is the case for most readers.

2. There are 3 examples here. The discussions of the examples are not next to the examples. It is all jumbled up and hard to read.

3. The Java example spells main as mian.

4. Section 2 says, "programmers write a lot more code than they read". That is incorrect. For example, normally I read several of the solutions on Stackoverflow before I decide which one to copy and paste :-)

Good points. A 737 costs about $90M and seats about 162 people. Let's say it lasts 10 years and does 4 journeys per day, that's 14600 journeys in its life. So $38 per journey is needed to pay for the plane. A train costs $15M and has about twice as many seats. So, yeah train wins.

According to https://www.withouthotair.com/c20/page_121.shtml Trains are about 8.5x more energy efficient than planes. So yeah, trains win that too. For context, planes do about 80 MPG per passenger.

On the other hand, building HS2 might cost £75 billion. It might carry 100 trains per day, so 32000 passengers per day, if all the trains were full. That's 11.7M per year. If it runs for 25 years without costing anything more, that's 292M passenger journeys, so £256 per passenger journey.

I _think_ that demonstrates that the infrastructure costs are larger than the costs of extra energy requirements and airframes. But we're clearly into "it's complicated" territory, so I concede.

Isn't transport by plane just cheaper to provide than rail? You don't need to maintain railway lines, bridges, tunnels, points, overhead power lines, signalling or intermediate stations. Routing congestion is reduced because planes can move in 3D. There is no rolling resistance and air friction is reduced due to flying high-up where the air is thin. Airports are built away from city centres, where land is cheap. The natural monopolies of rail-track providers are avoided. I think it would be amazing if train travel was as cheap as air travel.

I think the EU regs have tried to avoid that by specifying the requirements of spares availability case by case. For example, the requirements for washing machines are in C(2019) 2124, annex II. It says:

manufacturers, importers or authorised representatives of household washing machines and household washer-dryers shall make available to professional repairers at least the following spare parts, for a minimum period of ten years after placing the last unit of the model on the market:

* motor and motor brushes;

* transmission between motor and drum;

* pumps;

* shock absorbers and springs;

* washing drum, drum spider and related ball bearings (separately or bundled);

* heaters and heating elements, including heat pumps (separately or bundled);

* piping and related equipment including all hoses, valves, filters and aquastops (separately or bundled);

* printed circuit boards;

Because that requires investment. If they make that investment and are wildly successful at taking market share from x86 then ARM will become a much more valuable company. Buying ARM allows Nvidia to capture that value.

This is a real problem when some of that investment is porting/tuning various open source projects to make them run well on ARM. Such work would benefit the whole ARM ecosystem, including competitors who sell ARM based chips. At which point, owning ARM starts to look sensible.

I wish Amazon would implement filter-by-warranty-length.

A question I asked that springs to mind is https://stackoverflow.com/questions/37554058/fast-display-of...

It was down voted to a negative score initially. People posted irrelevant/unhelpful comments that I had to hurriedly refute before the question was closed and deleted.

To be fair, I have tweaked the question since, so it probably makes more sense than it did when I initially asked it. But I feel that is something the community should help with.

Related: Asking performance questions at the design stage is not a form of Premature Optimization.

OK, that makes sense. I error in my head was imagining a situation where the user was responsible for knowing which openssl .so file to download and where to put it.

> I prefer to have things clearly separated in functionality and easily upgradeable.

What is your thinking here? Are you talking about a use case where you have an application that uses a library and a bug fix is issued for that library, so you want to just get the new .so for the library and have the application use it? That feels like a niche use case to me. Maybe there is another benefit, or this use case is more common than I realize. I'd be interested in further opinions/info.

I've never been that impressed with the Mac Mini's battery life or touchpad :-)

This case, I think: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3313753/

It looks like she was getting 600,000 IU injections every week for three months. That's 85,714 IU per day. The NHS recommends maintenance does of 400 IU per day, others recommend up to 2000 IU.

Agreed. But in the case of Primodos, there were cover-ups with government involvement for decades. The end result was that Matt Hancock apologized. That was it. No holding to account. No fixing the system so it wouldn't happen again. That's what undermines my confidence in the system.

Or Primodos (https://en.wikipedia.org/wiki/Primodos). Or Sodium Valproate (https://www.bbc.co.uk/news/world-europe-39657139). These cases really undermine my confidence in the system.

Interesting. The westbound cables on that map all look like the are going too far South too. It would be interesting to know why.

Looking at the map of the Amitié cable, maybe they try to keep as much of the cable as possible in deep water. https://www.submarinenetworks.com/en/systems/trans-atlantic/...

Does anyone know if the paths shown for the transatlantic cables are anything like accurate? I would have expected them to follow "great circle" routes since they are the shortest. For example, the shortest path from Long Island to the Bristol Channel goes through Newfoundland and the southern tip of Ireland. There are several cables on the map with those end points but none of them are shown as taking that route. I guess this is poetic license that ignores the distortion of the map projection. Is there a map that shows the routes more accurately?

Surely inspired by Roobarb and Custard (1974): https://www.youtube.com/watch?v=I4aVXeDg3U4

I have a theory that large fleets of self-driving taxis will make congestion worse (compared to private cars). They have to drive to you, then drive wherever you want to go, turning one vehicle journey into two ( * ). There are lots of other factors to consider but that seems to be a fundamental problem with the taxi model. I'd be interested in replies that explain the flaw in this theory. I assume it is wrong because I haven't heard anyone else say it.

* It could be even worse. Imagine the morning rush - thousands of taxis have driven to peoples' homes and then driven them to their work/school. Then most will have to park until the next peak of demand in the evening. Either they park in the city, or they drive to an out-of-city parking lot, then drive back in to collect, then drive people home, then drive somewhere else to park until the morning rush. What would have been two vehicle journeys using a private car became six.

Agreed, but self-driving cars would enable self driving buses and they could be great.

One problem with buses is that paying the drivers is expensive. As a result buses need to be big to amortize the cost of the driver across lots of users. But big buses don't work well in low demand times of the day. The only option is to run them less frequently, which sucks for users. And big buses don't fit down small streets. And fewer larger buses means fewer routes. Self driving buses could solve all these problems.

I'd still prefer to walk or cycle, but I'm probably biased because I live in a warm, dry and flat part of the UK and don't have kids.

Yup. I've had that blank stare interview. I've decided that the next time it happens, I'm going to attempt to patiently explain to the interviewer why that isn't going to get them the information they want. Last time it happened I was hired anyway because this was only one interview of many. It turns out the bad interviewer was a nice chap and very clever, but with no understanding of how humans work. I've found that such people are often interested to know why their interactions are failing. They want to learn new rules that they can add to the personality simulator they run in their head :-)

One reason is that programming languages generally try to provide backwards compatibility and doing so limits their ability to fix design problems.

There's an interesting dynamic here; it is hard to see the design flaws of a language until it is widely used and common practices are established. Once that happens it is too late to change the design.

People occasionally try to fork languages to so they can break the backwards compatibility requirement, but I haven't seen many of those gain wide adoption (maybe you could say Python 3 is an example?). Instead there seems to be more success for languages that attempt to create a better version of an existing language but move far enough away from it to be an obviously different beast. I'm not sure why.

OK. That does match what the compiler experts told me. So is the rule that it is OK to cast a pointer back to its "original" type and dereference it? If so, I feel this rule breaks the abstraction mechanisms C provides. eg now when I'm implementing that xor512b() function, I need to know about the invisible "original" type of the arguments.

And in the case of malloc, I don't know what type the data was "originally" before it returned it to me. I guess I have to treat malloc as a special case where I can cast its void* to anything safely. That would seem morally wrong.

I don't understand. Compiler experts have told me that the Godbolt example I posted at the start of the thread (https://godbolt.org/z/ugSDmr) is incorrect C code because casting void* to uint64_t* is UB.

I modified the code to ensure that the data is 8-byte aligned (I think I've done this correctly). It still goes "wrong". https://godbolt.org/z/Pnxnb8

In either case, adding -fno-strict-aliasing fixes it.

> You can use memcpy or unions.

I know. I think the reason that this an area that causes lots of debate is because the majority of C programmers from 20 years ago would not have thought the memcpy or unions approach was a better idea than casting and dereferencing void* . The casting approach used to "just work" unless you violated the alignment requirements on your platform, and that was a problem 20 year-ago C programmers were happy to take on.

For next time this discussion comes up, I'll try to think of a good example of when the void* approach yields easier to maintain code :-)

BTW, you can also use -fno-strict-aliasing to make the C compiler sort-of work like it did 20 years ago. I believe this is what the Linux Kernel does but I couldn't be certain that it is for exactly this reason.

> The reasons for that are performance. So that one doesn't have to assume everything aliases everything else.

Can you expand on that? I don't understand.

Edit: I see the answer in one of your other comments:

> If len and array are both of the same type then the compiler must assume they can alias (or one of them is char*). One has to explicitly state with restrict that they cannot alias.

I'd happily take that hit. I can put restrict in the hot paths of my code. I'm tempted to say I want restrict to be the default, but I haven't thought that through.

No. Letting the hardware just do its thing. Like an out of bounds memory access or divide by zero.

Editing here because it looks like we've hit the max reply depth. This wouldn't be like UB in the same way that code that could generate an out-of-bounds memory accesses is not UB. The critical thing is that the compiler should assume that the hardware error does not occur.

You are correct. However, C programmers expect to be able to cast a void* to something other than a char* and use it. It is kind of necessary because the language doesn't support generics. I feel that the reasons for calling this UB are not as good as the reasons for making it valid code.

> How do you cover that in the spec?

OK, how about, "dereferencing a pointer that isn't correctly aligned doesn't work on some hardware". I see that this is a hard area for the spec to do well. But the current situation isn't viable. I can't tell whether I can safely use fread for heavens sake.

I feel like dereferencing an incorrectly aligned pointer could be a runtime error, just like divide by zero or accessing memory that doesn't exist. Maybe that would be an improvement from the current status. Although I'm not sure the spec _could_ be changed like this at this point in time.

With this machine I propose, that requires 4-byte alignment for int32_t, then even if I wrote the code in assembly, I'd just get a unaligned access fault from the hardware. So my code still wouldn't work. I'd rather the spec was changed to reflect this reality. Instead of calling it undefined behaviour, it should say something more specific, like, "dereferencing a pointer that isn't correctly aligned may cause your program to abort".

The key difference is that the alignment (usually) cannot be determined at compile time, so the compiler would still have to generate code that worked if the alignment was correct at run time. I think this is what many people either expect or would like the compiler to do.

With that change to the spec, I could continue to write my code in portable C, and I'd only get an abort on the target with this alignment constraint.

People tell me that the problem with this code is that casting one pointer type to another and then dereferencing is undefined behaviour. The problem is that C code seems to do this all the time. For example, fread() in the standard library takes a void* as its first parameter. So at first glance, most code that uses fread() must exhibit undefined behaviour. eg this function:

    int foo(FILE *f) {
        int val;
        fread(&val, sizeof(val), 1, f);
        return val;
    }

Closer reading of the spec says something about it being fine to cast, say, an int* to a float* and then cast back before dereferencing it. In this example, we're OK, because we don't reference via the void* . But the fread implementation must do, right?

I'm left feeling like it is impossible to implement fread() in C and that the standard library's API is no longer considered a good example of how to construct an API.

I guess the original motivation for it being UB to cast is to do with alignment constraints on some hardware. For example, a machine might be able to read an int8_t from any alignment but might require 4-byte alignment for int32_t. If so, then casting a non-aligned int8_t* to int32_t* and deferencing it would indeed fail on that hardware.

But some would argue that it is not right that GCC 7 breaks such code on a machine where that problem doesn't exist.