"Why ISO C++ Is Not Enough for Heterogeneous Computing" by Intel

[Lynn McGuire]

"Why ISO C++ Is Not Enough for Heterogeneous Computing" by Intel

https://www.codeproject.com/Articles/5348333/Why-ISO-Cplusplus-Is-Not-Enough-for-Heterogeneous

That is a lot of custom code. One would hope for more compiler automation.

Lynn

[Öö Tiib]

They just want a programming language where all can be burdened upon programmer:
1) figure out what mixture of resources is available in system
2) split the algorithm into components that map well to available resources
3) spread the tasks to the resources
4) schedule it well so bottle-necks are minimal
5) take into account and adapt to different usage patterns of end user
6) be responsible for portability to next gen idiotic system they release year later
7) maintain the mess

They either implement compilers and standard libraries that take the heterogenous
nature of their garbage architecture into account (and C++ language all that is needed
for that) or software just runs weakly on it ... and system of competitor will be bought.

[Marcel Mueller]

Am 12.12.22 um 21:53 schrieb Lynn McGuire:

> "Why ISO C++ Is Not Enough for Heterogeneous Computing" by Intel

The Problem is Intel Alder Lake not C++.

The covered their problems in chip production by building CPUs that have
good single core performance and many cores with as little as possible
Silicon. Both parameters look pretty in Datasheets, but they are
mutually exclusive.
This may be just fine for many _multitasking_ requirements. But it is
definitely no good choice for number crunching or other parallel computing.

I would not spend much time on building a computer language around this
kind of CPU. Heterogeneous hardware should be up to the OS scheduler,
not a _multi-threading_ applications problem.


Marcel

[Juha Nieminen]

Time to create yet another new programming language that's a "better C++"!

And throw it in the same heap as the myriads of other such languages.

[Scott Lurndal]

What "kind of CPU"? The entire article wasn't about enhancing or changing
the C++ language. It's just a set of library functions and header files that
allow interacting with a GPU using OpenCL. Basically a C++ wrapper on
OpenCL/Cuda.

[Lynn McGuire]

Isn't that new programming language suppose to be Go and Rust ?

Lynn

[d thiebaud]

And D, among others. I wish D had caught on more.

[Lynn McGuire]

Looks like D is still hanging around.
https://dlang.org/

Lynn

[d thiebaud]

On 12/13/22 20:35, Lynn McGuire wrote:
> On 12/13/2022 4:03 PM, d thiebaud wrote:<snip>

>>
>> And D, among others. I wish D had caught on more.
>
> Looks like D is still hanging around.
>    https://dlang.org/
>
> Lynn
>

Yes, but it hasn't had the success I hoped for.

[Öö Tiib]

Oracle wants it is Java, Google wants it is Go, Apple wants it is Swift,
Microsoft wants it is C#.

So when they are not dealing with above argument they fight
against C, C++, D, Rust and Kotlin somewhat. No one
supports those languages any more than they need for
their own internal things.

[daniel...@gmail.com]

On Tuesday, December 13, 2022 at 11:06:36 PM UTC-5, Öö Tiib wrote:
> Oracle wants it is Java, Google wants it is Go, Apple wants it is Swift,
> Microsoft wants it is C#.
>
> So when they are not dealing with above argument they fight
> against C, C++, D, Rust and Kotlin somewhat. No one
> supports those languages any more than they need for
> their own internal things.

Google most decidedly supports Kotlin. Microsoft is poking
around with rust. Google is also putting resources into Carbon,
and pulling resources away from clang.

[Mut...@dastardlyhq.com]

Don't forget Dart. Another emanation from Google which no doubt they'll get
bored with in a few years and drop like most of their projects.

And on MacOS there's Swift which is supposed to be a better Objective C.
Frankly it couldn't be much worse. Why Apple don't just use modern C++ and
get all the benefits not to mention experienced devs on board is anyones guess.

[d thiebaud]

[Juha Nieminen]

Mut...@dastardlyhq.com wrote:
> And on MacOS there's Swift which is supposed to be a better Objective C.
> Frankly it couldn't be much worse. Why Apple don't just use modern C++ and
> get all the benefits not to mention experienced devs on board is anyones guess.

Having programmed quite a lot not only in Objective-C, but in Objective-C++,
I kind of like the language.

Its C, an object-oriented extension of C, and C++, all piled up in one
huge heap, which in theory sounds like it would be a huge mess... but
perhaps a bit surprisingly it worked quite well, IMO.

Objective-C adds to the language several things that C++ simply cannot
add (such as runtime introspection), and C++ adds things that Objective-C
does not add (such as RAII and templates), and combined they work
surprisingly well, even though it might sound like a huge mess.

But I suppose the people at Apple finally decided that it's too big of
a mess, so they decided to create their own "simpler and cleaner"
language, which is completely incompatible with C++. And that's the
point at which I completely lost interest.

[Michael S]

On Wednesday, December 14, 2022 at 6:18:04 AM UTC+2, daniel...@gmail.com wrote:
> On Tuesday, December 13, 2022 at 11:06:36 PM UTC-5, Öö Tiib wrote:
> > Oracle wants it is Java, Google wants it is Go, Apple wants it is Swift,
> > Microsoft wants it is C#.
> >
> > So when they are not dealing with above argument they fight
> > against C, C++, D, Rust and Kotlin somewhat. No one
> > supports those languages any more than they need for
> > their own internal things.

> Google most decidedly supports Kotlin. Microsoft is poking
> around with rust.

Cotlin and Rust are not direct competitors. One is for applications,
esp. UI applications, another is for systems, infrastructure, libraries.
I'd guess some people write big, complex applications in Rust, but that's
mostly because they are masochists.

> Google is also putting resources into Carbon,
> and pulling resources away from clang.

According to my understanding, Carbon is 100% reliant on LLVM
so if Google see a future in Carbon it can't abandon support
of LLVM. Which automatically helps clang as primary LLVM front end.

[Michael S]

On Wednesday, December 14, 2022 at 11:40:11 AM UTC+2, Mut...@dastardlyhq.com wrote:
> On Tue, 13 Dec 2022 17:03:13 -0500
> d thiebaud <thieba...@aol.com> wrote:
> >On 12/13/22 15:15, Lynn McGuire wrote:
> >> On 12/13/2022 2:37 AM, Juha Nieminen wrote:
> >>> Lynn McGuire <lynnmc...@gmail.com> wrote:
> >>>> "Why ISO C++ Is Not Enough for Heterogeneous Computing" by Intel
> >>>>
> >>>>
> >https://www.codeproject.com/Articles/5348333/Why-ISO-Cplusplus-Is-Not-Enough-fo
> >r-Heterogeneous
> >>>>
> >>>> That is a lot of custom code. One would hope for more compiler
> >>>> automation.
> >>>
> >>> Time to create yet another new programming language that's a "better
> >>> C++"!
> >>>
> >>> And throw it in the same heap as the myriads of other such languages.
> >>
> >> Isn't that new programming language suppose to be Go and Rust ?
> >>
> >> Lynn
> >>
> >
> >And D, among others. I wish D had caught on more.
> Don't forget Dart. Another emanation from Google which no doubt they'll get
> bored with in a few years and drop like most of their projects.
>

My impression from reading Wikipedia article is that Google as firm
got bored with Dart around 2014-2015. As a consequence, all senior
devs left a project and most of them left Google as well.
Despite that it seems that Google still willing to keep development
financed, if barely.
I could be wrong about it.

> And on MacOS there's Swift which is supposed to be a better Objective C.
> Frankly it couldn't be much worse. Why Apple don't just use modern C++ and
> get all the benefits not to mention experienced devs on board is anyones guess.

May be, because modern C++ is not particularly good language for 99% of
programming tasks?

[Mut...@dastardlyhq.com]

On Wed, 14 Dec 2022 12:34:59 -0000 (UTC)
Juha Nieminen <nos...@thanks.invalid> wrote:
>Mut...@dastardlyhq.com wrote:
>> And on MacOS there's Swift which is supposed to be a better Objective C.
>> Frankly it couldn't be much worse. Why Apple don't just use modern C++ and
>> get all the benefits not to mention experienced devs on board is anyones
>guess.
>
>Having programmed quite a lot not only in Objective-C, but in Objective-C++,
>I kind of like the language.
>
>Its C, an object-oriented extension of C, and C++, all piled up in one
>huge heap, which in theory sounds like it would be a huge mess... but
>perhaps a bit surprisingly it worked quite well, IMO.
>
>Objective-C adds to the language several things that C++ simply cannot
>add (such as runtime introspection), and C++ adds things that Objective-C

If you think having generic objects being thrown around similar to Javas
Object type is a good idea instead of knowing what they are at compile time then
I suppose introspection makes sense. Personally I think its a solution for a
problem that shouldn't exist in the first place.

[Mut...@dastardlyhq.com]

On Wed, 14 Dec 2022 05:56:36 -0800 (PST)
Michael S <already...@yahoo.com> wrote:
>On Wednesday, December 14, 2022 at 11:40:11 AM UTC+2, Mut...@dastardlyhq.com
>wrote:

>> And on MacOS there's Swift which is supposed to be a better Objective C.
>> Frankly it couldn't be much worse. Why Apple don't just use modern C++ and
>> get all the benefits not to mention experienced devs on board is anyones
>guess.
>
>May be, because modern C++ is not particularly good language for 99% of
>programming tasks?

I think you're in the wrong newsgroup. Python groups are that way ---->

[David Brown]

Maybe he thinks no one language is ideal for more than a few percent of
programming tasks? Maybe he thinks C++ is not good for 99% of
programming tasks, but the tasks /he/ does are in the 1%? Maybe he has
no choice but to use it despite it not being ideal? Maybe he likes C++
and uses it because he likes it, even if it is not good for the task in
hand? Maybe he thinks C++ is not particularly good, yet better than all
the rest?

There's lots of reasons to be in a C++ newsgroup and to use C++ even if
you think it is not a great language. I think most of the programming
done in C would be better done in other languages, and that most of the
people who program in C would be better off in other languages - but I
still enjoy C and write a lot of code in C and frequent comp.lang.c.

[Lynn McGuire]

Apple is all about minimizing their competition. Changing languages is
one way to do that.

Lynn

[Michael S]

On Wednesday, December 14, 2022 at 8:22:12 PM UTC+2, David Brown wrote:
> On 14/12/2022 17:35, Mut...@dastardlyhq.com wrote:
> > On Wed, 14 Dec 2022 05:56:36 -0800 (PST)
> > Michael S <already...@yahoo.com> wrote:
> >> On Wednesday, December 14, 2022 at 11:40:11 AM UTC+2, Mut...@dastardlyhq.com
> >> wrote:
> >>> And on MacOS there's Swift which is supposed to be a better Objective C.
> >>> Frankly it couldn't be much worse. Why Apple don't just use modern C++ and
> >>> get all the benefits not to mention experienced devs on board is anyones
> >> guess.
> >>
> >> May be, because modern C++ is not particularly good language for 99% of
> >> programming tasks?
> >
> > I think you're in the wrong newsgroup. Python groups are that way ---->
> >
> Maybe he thinks no one language is ideal for more than a few percent of
> programming tasks? Maybe he thinks C++ is not good for 99% of
> programming tasks, but the tasks /he/ does are in the 1%?

Actually, I think that C++ is either good or not bad for far more than 1%,
may be, for above 5% of programming tasks. But in the post above I wrote
specifically *modern* C++. My opinion about *modern* C++ and programming
practices that accompany it is not particularly favorable.
It does not mean that I don't like every single bit that was added to the language
in C++11 and later. I do find several new libraries quite useful even if for
some of them I'd personally prefer the same functionality presented in less
modern AP style.
Even 'auto' discussed is other thread, is not universally harmful, even outside
of templates.

> Maybe he has
> no choice but to use it despite it not being ideal? Maybe he likes C++
> and uses it because he likes it, even if it is not good for the task in
> hand? Maybe he thinks C++ is not particularly good, yet better than all
> the rest?

May be, use C++ because I am conservative?
May be, even when I learn a new language, like C# or Go, but do not use
it day in day out, I forget what I learned too quickly?
May be, it's my age telling?

>
> There's lots of reasons to be in a C++ newsgroup and to use C++ even if
> you think it is not a great language. I think most of the programming
> done in C would be better done in other languages, and that most of the
> people who program in C would be better off in other languages - but I
> still enjoy C and write a lot of code in C and frequent comp.lang.c.

C is better than its reputation.

[Lynn McGuire]

Every time you start your vehicle engine, millions of lines of C code is
controlling it. Toyota and Ford are reputedly at 30 million lines of
code in their EMS (engine management system).

Lynn

[Chris M. Thomasson]

The JSF:

https://www.stroustrup.com/JSF-AV-rules.pdf

MISRA... :)

[Lynn McGuire]

Wow ! That is a lot of rules.

Lynn

[Lynn McGuire]

On 12/14/2022 3:57 PM, Chris M. Thomasson wrote:

https://en.wikipedia.org/wiki/MISRA_C

Lynn

[Mut...@dastardlyhq.com]

C is good for low level where the C++ runtime couldn't be supported and
for smallish system programs/utilities that don't require complex data
structures. As soon as it looks like you need STL type functionality or black
boxing you're better off with C++. IMO, YMMV.

[Mut...@dastardlyhq.com]

There is that. As an owner of a Mac it annoys me that most of the mid and
high level MacOS specific non posix APIs can only be accessed via Obj-C. They
have provided C interfaces for a lot of the low level stuff such as sysctl and
dispatch queues but thats where it ends. Which means if you want to write GUI
apps on MacOS and don't know Obj-C you're screwed unless you go with an X
app with XQuartx but most Mac owners wouldn't have it installed so thats
pointless.

[Mut...@dastardlyhq.com]

On Wed, 14 Dec 2022 12:09:14 -0800 (PST)

Michael S <already...@yahoo.com> wrote:
>On Wednesday, December 14, 2022 at 8:22:12 PM UTC+2, David Brown wrote:
>> On 14/12/2022 17:35, Mut...@dastardlyhq.com wrote:
>> > On Wed, 14 Dec 2022 05:56:36 -0800 (PST)
>> > Michael S <already...@yahoo.com> wrote:
>> >> On Wednesday, December 14, 2022 at 11:40:11 AM UTC+2,
>Mut...@dastardlyhq.com
>> >> wrote:
>> >>> And on MacOS there's Swift which is supposed to be a better Objective C.
>
>> >>> Frankly it couldn't be much worse. Why Apple don't just use modern C++
>and
>> >>> get all the benefits not to mention experienced devs on board is anyones
>
>> >> guess.
>> >>
>> >> May be, because modern C++ is not particularly good language for 99% of
>> >> programming tasks?
>> >
>> > I think you're in the wrong newsgroup. Python groups are that way ---->
>> >
>> Maybe he thinks no one language is ideal for more than a few percent of
>> programming tasks? Maybe he thinks C++ is not good for 99% of
>> programming tasks, but the tasks /he/ does are in the 1%?
>
>Actually, I think that C++ is either good or not bad for far more than 1%,
>may be, for above 5% of programming tasks. But in the post above I wrote
>specifically *modern* C++. My opinion about *modern* C++ and programming
>practices that accompany it is not particularly favorable.

Just because people such as Bonita get carried away with obscure unintelligable
meta programming doesn't mean modern C++ is poor. It makes something things
much simpler and cleaner than C++98.

>May be, even when I learn a new language, like C# or Go, but do not use
>it day in day out, I forget what I learned too quickly?

Applies to everything in life. Use it or lose it. I have the same problem
with Python which I use intermittently and always end up googling how to do
something basic which I should remember but usually don't.

>> done in C would be better done in other languages, and that most of the
>> people who program in C would be better off in other languages - but I
>> still enjoy C and write a lot of code in C and frequent comp.lang.c.
>
>C is better than its reputation.

Its still in active use after half a century so it must be doing something
right.

[Mut...@dastardlyhq.com]

Which is way too much just to control spark and fuel injection times. That
should be a thousand lines at most with maybe the equivalent for an auto
gearbox controller as most of the important stuff would be dense mathematics
anyway. When I worked in defense the code to control actuators was never
more than a few thousand lines which given you had to write it to high SIL spec
was about as much as humanly possible to vet properly.

[David Brown]

Oh, I am quite happy to agree that C has its place, and is the best
choice of language for a number of things. Even when something like
C++, D, Rust, whatever, would be as efficient, the simplicity of C and
the convenience in connecting to other languages can make it the best
choice.

But often it is used even when it is /not/ the best choice. You see
people asking questions like "how do I write a parser for this kind of
text file in C?" - the answer is, "you don't". You use a language
better suited for the task. Even in the old days when C was the only
sane choice for something like a parser, you didn't write the code in C
- you used tools that generated the C for you.

There is nothing wrong with using C for tasks for which C is the best
choice - I only disapprove of using it for tasks where there are much
better alternatives.

[Scott Lurndal]

Like you, I find the 30 million lines in the EMS to be very unlikely.

Now if you add in the entertainment systems and other dashboard
display and control systems, it might get a bit closer.

Tesla's and other vehicles with partial or full self-driving capabilities
are a different story, with incredibly complicated and large SoC's
with several different grades of processor, safety islands and
redundancy.

[Mut...@dastardlyhq.com]

On Thu, 15 Dec 2022 11:49:01 +0100

David Brown <david...@hesbynett.no> wrote:
>On 15/12/2022 10:37, Mut...@dastardlyhq.com wrote:
>> On Wed, 14 Dec 2022 19:21:57 +0100
>> David Brown <david...@hesbynett.no> wrote:
>>> On 14/12/2022 17:35, Mut...@dastardlyhq.com wrote:
>>> people who program in C would be better off in other languages - but I
>>> still enjoy C and write a lot of code in C and frequent comp.lang.c.
>>
>> C is good for low level where the C++ runtime couldn't be supported and
>> for smallish system programs/utilities that don't require complex data
>> structures. As soon as it looks like you need STL type functionality or black
>
>> boxing you're better off with C++. IMO, YMMV.
>>
>
>Oh, I am quite happy to agree that C has its place, and is the best
>choice of language for a number of things. Even when something like
>C++, D, Rust, whatever, would be as efficient, the simplicity of C and
>the convenience in connecting to other languages can make it the best
>choice.
>
>But often it is used even when it is /not/ the best choice. You see
>people asking questions like "how do I write a parser for this kind of
>text file in C?" - the answer is, "you don't". You use a language
>better suited for the task. Even in the old days when C was the only

I disagree with you there. C's pointer abilities make it a first class
language in which to write a text parser. Doing the equivalent using array
indexing along with substr() and find() type functionality would be inefficient
and long winded.

>sane choice for something like a parser, you didn't write the code in C
>- you used tools that generated the C for you.

Lexx and yacc? Hmm, they were ok but limited and the code they generated could
often be described as a dogs dinner.

>There is nothing wrong with using C for tasks for which C is the best
>choice - I only disapprove of using it for tasks where there are much
>better alternatives.

People use what they know. Python might be the best language for quick and
dirty scripts but for a dev who only knows C it would be far quicker for them
to write it in C than spend 2 weeks learning python first.

[Mut...@dastardlyhq.com]

On Thu, 15 Dec 2022 15:04:46 GMT
sc...@slp53.sl.home (Scott Lurndal) wrote:
>Mut...@dastardlyhq.com writes:
>>On Wed, 14 Dec 2022 15:53:24 -0600
>>Lynn McGuire <lynnmc...@gmail.com> wrote:
>>>On 12/14/2022 2:09 PM, Michael S wrote:
>>>> C is better than its reputation.
>>>
>>>Every time you start your vehicle engine, millions of lines of C code is
>>>controlling it. Toyota and Ford are reputedly at 30 million lines of
>>>code in their EMS (engine management system).
>>
>>Which is way too much just to control spark and fuel injection times. That
>>should be a thousand lines at most with maybe the equivalent for an auto
>>gearbox controller as most of the important stuff would be dense mathematics
>>anyway. When I worked in defense the code to control actuators was never
>>more than a few thousand lines which given you had to write it to high SIL
>spec
>>was about as much as humanly possible to vet properly.
>>
>
>Like you, I find the 30 million lines in the EMS to be very unlikely.
>
>Now if you add in the entertainment systems and other dashboard
>display and control systems, it might get a bit closer.

True, but those arn't part of the engine ECU.

>Tesla's and other vehicles with partial or full self-driving capabilities
>are a different story, with incredibly complicated and large SoC's
>with several different grades of processor, safety islands and
>redundancy.

Shame they pinned everything on machine vision without radar and/or lidar
backup and cost a number of - admittedly idiots - their lives.

[David Brown]

The big question - vital, but probably impossible to answer - is how
many crashes or fatalities would there have been /without/ the automatic
systems? People have been crashing cars and killing themselves and
others for as long as cars have existed (longer, if you include wagons
and carts).

Driving aids are not perfect, and they get things wrong sometimes. But
maybe in the big picture (statistics, not individual cases) they are
still a win.

[daniel...@gmail.com]

On Thursday, December 15, 2022 at 5:49:17 AM UTC-5, David Brown wrote:
>
> But often it is used even when it is /not/ the best choice. You see
> people asking questions like "how do I write a parser for this kind of
> text file in C?" - the answer is, "you don't". You use a language
> better suited for the task. Even in the old days when C was the only
> sane choice for something like a parser, you didn't write the code in C
> - you used tools that generated the C for you.
>

My understanding is that many if not most parsers for computer languages are
hand written, _not_ generated by tools. A recursive descent parser is not that
difficult to write, and writing by hand gives more control in a number of areas
including syntax error reporting.

Daniel

[Lynn McGuire]

This article says that the new F-150 in 2016 has 150 million lines of C
code.
https://www.greencarcongress.com/2016/05/20160505-ford.html

"Software plays a growing role in new vehicles as demonstrated by the
all-new F-150 that features more than 150 million lines of code, whereas
a typical smartphone operating system has approximately 12 million
lines. Engineers are capitalizing on software to deliver precise control
over aspects of vehicle performance such as engine and transmission
calibration to improve fuel economy and for the connectivity experience
by giving customers hands-free access to their smartphones through SYNC 3."

Bill Ford gave a TED talk recently where he said that the average Ford
vehicle has over 100 cpus on the EMS and daughter boards in it.

This inforgraphic claims that the average car has 100 million lines of
code which blows my mind:
https://www.visualcapitalist.com/millions-lines-of-code/

Lynn

[Öö Tiib]

Yes, there is need for common errors to be diagnosed in form of easy to
understand to human so not "syntax error" and even not "unexpected
token [ after 'end' token" but something like "end can not be indexed".
That often takes some extra parsing after error has been met. Similar
issue is with parsers for syntax highlighting ... should not just underline
half of text red because of missing ) or something.

The textual formats are often contextual so meaning of >> may be
one "greater than" token or two "end of template argument list" tokens but
generated parsers can not typically shew through such cases.

Generated parsers can be also tricky to debug ... I can't imagine how fun
was to debug Boost.Wave C++ preprocessor. Person must be extra
motivated to do such work.

About common formats like JSON the parser making is like kind of
competition. There benchmarks are biased and it is hard to hand-optimize
generated parsers to be competitive with those biased inputs. At
the same time there are always plenty of competitors ... so why not
to use the fruits of their labor?

So generated parsers are typically used on cases when it is hard to
reason why stock syntax and parser of JSON, YAML, MD, MathML,
LaTeX etc. wasn't used.

[Mut...@dastardlyhq.com]

The problem is if you market a driver aid as "autopilot" then people get the
wrong idea and stop paying attention with the inevitable results especially
if the car "vision" is more falible than human vision in certain circumstances.
Other car companies call it Lane Assist or similar which makes it pretty clear
its not 100% autonomous.

[Mut...@dastardlyhq.com]

On Thu, 15 Dec 2022 18:44:50 -0600

Yet still does single digit mpg around town. If they really wanted to save fuel
they'd build it out of aluminium and literally save a ton of weight but that
wouldn't get the Kool Kids on board.

>by giving customers hands-free access to their smartphones through SYNC 3."
>
>Bill Ford gave a TED talk recently where he said that the average Ford
>vehicle has over 100 cpus on the EMS and daughter boards in it.

Ie there'll be a whole heap of faults and trouble awaiting the 3rd or 4th
owner 10 or 20 years down the line and it'll probably be uneconomic to repair
if too many modules fail.

>This inforgraphic claims that the average car has 100 million lines of
>code which blows my mind:
> https://www.visualcapitalist.com/millions-lines-of-code/

Quite ridiculous really compared to some of the other systems especially given
most of it is in the bloated ICE which many people don't use anyway because
they just pair their phone and use that instead.

Why do car companies design the interface of cars for teenagers these days
when the people buying them new are are usually 20+ years older? One of lifes
mysteries.

[David Brown]

Yes, I can see that as a problem - if the marketing or naming makes
people think it is significantly more automatic and reliable than it
actually is. I am not a Tesla driver, nor have I paid any attention to
their marketing, so I can't really comment here.

[Fred. Zwarts]

Op 15.dec..2022 om 20:09 schreef David Brown:

I think it was a Google member who said about their self-driving car
project: "If we succeed to reduce the number of yearly deaths in car
accidents from 300 per year (number of The Netherlands) to 3 per year,
then we will not receive 297 grateful letters per year from happy people
that are still alive, but we will be sued for those remaining deaths.".

[David Brown]

On 16/12/2022 14:15, Fred. Zwarts wrote:
> Op 15.dec..2022 om 20:09 schreef David Brown:

>> The big question - vital, but probably impossible to answer - is how
>> many crashes or fatalities would there have been /without/ the
>> automatic systems?  People have been crashing cars and killing
>> themselves and others for as long as cars have existed (longer, if you
>> include wagons and carts).
>>
>> Driving aids are not perfect, and they get things wrong sometimes.
>> But maybe in the big picture (statistics, not individual cases) they
>> are still a win.
>>
>
> I think it was a Google member who said about their self-driving car
> project: "If we succeed to reduce the number of yearly deaths in car
> accidents from 300 per year (number of The Netherlands) to 3 per year,
> then we will not receive 297 grateful letters per year from happy people
> that are still alive, but we will be sued for those remaining deaths.".
>

Yes. No matter how hard you try to show statistics, or calculate
micromort reductions, people always take death personally!

[Scott Lurndal]

They've been building the F150 out of Aluminum/Aluminium since 2015.

[Mut...@dastardlyhq.com]

Thats only the body. Its still a prehistoric steel ladder chassis underneath.

[Lynn McGuire]

...

Those single digit mpg days are way past for F-150s. My 2019 F-150 4x4
3.5L dual turbo V6 with the 4 inch lift kit gets 16 - 17 mpg around
town, 20 mpg at 70 mph, and 18 mpg at 80 mph (it is a brick after all).
I just replaced my AGM battery so my start-stop system started working
again so I am getting 17 mpg on this tank so far.

And my cab and bed are made out of aluminum. I know this for a fact
from throwing stuff in the bed and scratching the bed protector layer off.

Lynn

[Chris M. Thomasson]

For some damn reason this is reminding me of the lyrics of a song (still
alive) from Portal 2:

https://youtu.be/22vbhTi1ieI

Some people do not seem to care if some people die, as along as the
science gets done.

[Mut...@dastardlyhq.com]

On Fri, 16 Dec 2022 14:03:18 -0600
Lynn McGuire <lynnmc...@gmail.com> wrote:
>On 12/16/2022 4:24 AM, Mut...@dastardlyhq.com wrote:
>> Yet still does single digit mpg around town. If they really wanted to save
>fuel
>> they'd build it out of aluminium and literally save a ton of weight but that
>> wouldn't get the Kool Kids on board.

>....

>
>Those single digit mpg days are way past for F-150s. My 2019 F-150 4x4
>3.5L dual turbo V6 with the 4 inch lift kit gets 16 - 17 mpg around
>town, 20 mpg at 70 mph, and 18 mpg at 80 mph (it is a brick after all).

20mpg in 2022? BFD. My 14 year old tired diesel can do 35mpg at that speed
(admittedly UK gallons so probably ~ 30-32 US). Modern cars can do much better.

Though I suppose it begs the question of why americans feel the need to drive
around in absurdly large utility vehicles. Insecurity perhaps or maybe posing.
But thats an argument for another newsgroup.

[Chris M. Thomasson]

Ever had to tow a big boat before?

[Mut...@dastardlyhq.com]

Tow your megayacht every day do you? Ever heard of hire vehicles?

[Scott Lurndal]

Something that perhaps 15% of non-commercial pickup truck owners actually do.

[Chris M. Thomasson]

Towing a boat up and down to Lake Tahoe from Carson City, one needs a
vehicle than can do it.

[Chris M. Thomasson]

megayacht? No. Fishing in Lake Tahoe is fun.

[Jorgen Grahn]

On Wed, 2022-12-14, Michael S wrote:
...

> Actually, I think that C++ is either good or not bad for far more than 1%,
> may be, for above 5% of programming tasks. But in the post above I wrote
> specifically *modern* C++. My opinion about *modern* C++ and programming
> practices that accompany it is not particularly favorable.

What does "modern C++" mean to you?

There was a time, up until C++98 became established, when everyone
wrote their own container libraries, used Smalltalk-style inheritance
as much as possible, chased memory leaks and didn't get much actual
work done. To me "modern C++" is anything after that.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Lynn McGuire]

Merika !

Lynn

[Lynn McGuire]

I tow a 5,000 lb 35 foot boom lift two or three times a year. I also
manage to get myself in a foot or two of mud and water occasionally.
Dadgum feral hogs.

Lynn

[Scott Lurndal]

That covers about 0.005% of all large pickup drivers., but doesn't answer
the question posed above. That stretch of Highway 50 isn't typical,
even in california or nevada (hopefully your're not taking 207).

I drive that stretch of 50 annually during my labor day Yosemite-
Lee Vining/Mono Lake-Tahoe journey (although every couple years, I'll
take 89 or 207 from 395 just for a change of scenery).

[Mut...@dastardlyhq.com]

On Sat, 17 Dec 2022 13:15:04 -0800

"Chris M. Thomasson" <chris.m.t...@gmail.com> wrote:

Depends how big the boat is. A modern mini can tow 1.5 tons which will cover
a lot small boats + trailer. A lot of larger cars such as a 5 series can tow
2 tons. The only genuine reason for a pickup is if you need to carry a lot of
loose stuff in the bed, and frankly if you do you're probably better off with a
van anyway which will also have a large towing capacity.

[Mut...@dastardlyhq.com]

On Sat, 17 Dec 2022 19:20:11 -0600

A Ford Transit can pull up to 3.5 tons which is 7700lbs.

[Scott Lurndal]

And the difference in elevation between the two points and the
grade of the highway connecting the two points. Which in this
case, (Carson City to Lake Tahoe) is significant.

[Mut...@dastardlyhq.com]

On Mon, 19 Dec 2022 15:28:24 GMT
sc...@slp53.sl.home (Scott Lurndal) wrote:
>Mut...@dastardlyhq.com writes:
>>On Sat, 17 Dec 2022 13:15:04 -0800

>>>Towing a boat up and down to Lake Tahoe from Carson City, one needs a
>>>vehicle than can do it.
>>
>>Depends how big the boat is.
>
>And the difference in elevation between the two points and the
>grade of the highway connecting the two points. Which in this
>case, (Carson City to Lake Tahoe) is significant.

Yet in europe we have normal cars towing reasonably sized double axle
caravans. There are obviously SUVs doing it too but few people seems to need to
resort to driving a 2.5t pickup to do it and the pickups you do see are usually
work vehicles with company logos on the side. Oh and diesel for obvious
reasons which are probably beyond your average lifestyler.

[Lynn McGuire]

My F-150 can tow up to 13,000 lbs. And has a 38 USA gallon tank for the
resulting 8 mpg.

Lynn

[Chris M. Thomasson]

Have you ever towed a boat going down a decent grade? You do not want
the boat to be driving you, out of control. Fwiw, there was a big wreck
at the bottom of highway 50 going into Carson City. Right by Costco. The
big boat got out of control and the driver could not control it. I
cannot remember if he had breaks on his trailer or not. Iirc, this is a
report of the shit storm:

https://www.recordcourier.com/news/2021/nov/15/bail-remains-high-driver-fatal-carson-city-wreck/

An example of person that should not be towing anything!

[Chris M. Thomasson]

I cannot remember the model of the boat, a Cobalt perhaps?

[Mut...@dastardlyhq.com]

Another thing in which europe and the USA differ. You can't tow a 6 ton load
using a 2.5 ton vehicle in Europe for obvious control reasons no matter what
engine its got but then you guys also allow geriatrics with only a car license
to drive 10 ton converted buses (also known as RVs) and towing a car to boot!

I guess in the US safety comes a poor 2nd place to lifestyle.

[Mut...@dastardlyhq.com]

On Mon, 19 Dec 2022 19:28:53 -0800

"Chris M. Thomasson" <chris.m.t...@gmail.com> wrote:

No, but I have a Class 1 HGV license which means I can drive trucks up to 44
tons in the UK and I wouldn't let someone with only a car license anywhere near
those sorts of loads. But the safety rules are ... different ... in the US.

[Scott Lurndal]

"Chris M. Thomasson" <chris.m.t...@gmail.com> writes:

The article indicated it was a 37,000 pound yacht. 8 tons beyond the
towing capacity of the F350. Driver got 3 to 10.

[Lynn McGuire]

Wow, I used to pull a 28,000 lb gooseneck with a C30 dually and then a
F350 dually. The trailer was an incredible handful and the brakes were
definitely a serious concern. We were considering buying a Class 8
tractor when I left the group.

Lynn

[Lynn McGuire]

I've seen those geriatrics towing a boat AND a car behind an RV. The
whole train is about 60 to 70 feet long.

Lynn

[Chris M. Thomasson]

Some of the hard core science people actually do not seem to care if
their experiments cause hardcore pain!

https://youtu.be/AJtDema_aao?list=RDGMEMHDXYb1_DDSgDsobPsOFxpA

Cult? Damn...

[Chris M. Thomasson]

Well, shit happens! Argh!

[Malcolm McLean]

On Thursday, 15 December 2022 at 20:54:18 UTC, daniel...@gmail.com wrote:
> On Thursday, December 15, 2022 at 5:49:17 AM UTC-5, David Brown wrote:
> >
> > But often it is used even when it is /not/ the best choice. You see
> > people asking questions like "how do I write a parser for this kind of
> > text file in C?" - the answer is, "you don't". You use a language
> > better suited for the task. Even in the old days when C was the only
> > sane choice for something like a parser, you didn't write the code in C
> > - you used tools that generated the C for you.
> >
> My understanding is that many if not most parsers for computer languages are
> hand written, _not_ generated by tools. A recursive descent parser is not that
> difficult to write, and writing by hand gives more control in a number of areas
> including syntax error reporting.
>
The other issue is that often the parser is relatively small component of a much
larger program, consisting of source files in C or C++. If you write the parser using
a parser generator, then you have two sources. So you've got to attach the yacc
source to the program source, then you've got to specify how to invoke yacc to
generate the C. That adds considerable complication to the build system and
introduces several points at which it could break.

[Öö Tiib]

That is, yes, problem for small project where the toolchain was for example
just set up by Project -> New... of some IDE like Visual Studio, XCode or
QtCreator with sole purpose of trying something out.
The ways how to add some dependent library nothing to talk of more tools
to toolchain can feel rather arcane and take some learning.
In bigger project that anyway has multiple dependencies, targets multiple
toolchains, has several tools added to those and ultimately produces and
deploys multiple modules ... adding lex and yacc may be considered
relatively trivial task.

[Scott Lurndal]

Adding lex and yacc _are_ trival tasks.

acgram.c acgram.h: $A/acgram.y
$(YACC_CMD) $A/acgram.y
mv y.tab.c acgram.c
mv y.tab.h acgram.h
...

acgram.$o: acgram.c $(P1_H)
$(CC_CMD) $(YYDEBUG) acgram.c

aclex.c: $A/aclex.l
$(LEX) $(LFLAGS) $A/aclex.l
mv lex.yy.c aclex.c

aclex.$o: aclex.c acgram.h $(P1_H)
$(CC_CMD) aclex.c

[daniel...@gmail.com]

On Sunday, December 25, 2022 at 12:07:18 PM UTC-5, Scott Lurndal wrote:

> Adding lex and yacc _are_ trival tasks.
>
> acgram.c acgram.h: $A/acgram.y
> $(YACC_CMD) $A/acgram.y
> mv y.tab.c acgram.c
> mv y.tab.h acgram.h
> ...
>
> acgram.$o: acgram.c $(P1_H)
> $(CC_CMD) $(YYDEBUG) acgram.c
>
> aclex.c: $A/aclex.l
> $(LEX) $(LFLAGS) $A/aclex.l
> mv lex.yy.c aclex.c
>
> aclex.$o: aclex.c acgram.h $(P1_H)
> $(CC_CMD) aclex.c

Nonetheless, they don't appear to be widely used.

Most significant programming languages - JavaScript, Java Open JDK, PHP, C#, clang, gcc, Golang, Lua,
Swift, Julia, rust - use a handwritten parser, Ruby uses the Bison parser generator, PHP, and Python use
parser generators, Kotlin appears to use FLEX to tokenize and the rest is hand written.

Apart from programming language compilers, looking at implementations on github of XML, JSON,
and YAML for C++, Python and Ruby, most appear to use a handwritten parser.

Daniel