@matthey

Quote:

matthey wrote: The OS is much more than the kernel. Has Darwin based macOS ever limited multitasking?

Why should macOS limid multitasking? And why shouldn't iOS limit multitasking in it's early version when it mad no sense on the limited HW?

IOS and macOS share far more then the kernel to the point where ARM based Macs can run iOS apps without emulation. To the point where you just need some few lines of extra code to build dedicated iOS and macOS apps from the same code.

You seem to think that "scaling the OS to different HW" means to just copy it all and hope for the best when in reality you always need to adapt it suit the needs and capabilities of the new target. And that is just what Apple did.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@an_overeducated_idiot

Quote:

an_overeducated_idiot wrote: @cdimauro Quote: As you can see, BOOPSI is really the worst OOP implementation. EVER. And it's really indefensible! Maybe not. Here's a valid example of Wirth-style Oberon: Quote: TYPE Figure = POINTER TO FigureRecord; TYPE FigureRecord = RECORD draw(self: Figure; canvas: Canvas); (* assume Canvas is defined *) END; TYPE Circle = POINTER TO CircleRecord; TYPE CircleRecord = RECORD(FigureRecord) x, y, radius: REAL; END; PROCEDURE draw(f: Figure; c: Canvas) BEGIN (* imagine something decent here *) END; PROCEDURE drawPerversely(f: Figure; c: Canvas) BEGIN (* imagine something indecent here *) END; VAR c1, c2: Circle; f1, f2: Figure; BEGIN (* main *) (* setup a canvas *) NEW(c1); NEW(c2); c1.draw = draw; c2.draw = drawPerversely; f1 = c1; f2 = c2; END; If you don't understand what's happening, here's a summary: even though c1 and c2 are both circles, and you can draw them with static typing via c1.draw(c1, canvas); or with dynamic typing via f1.draw(f1, canvas);, the outcome of drawing each will be different. This, because the programmer initialized the variables' type-bound procedures to different values. This, because Oberon provides no facility for automatically initializing an object, so the programmer has to do this oneself (even if via setting up an Init function. Short of examining every last line of the source code, you basically have no guarantee of any consistency in the code. It should be obvious that this opens the door to all manner of mischief, never mind mistakes. One can achieve this apex of confusion in other OO languages, but it is not standard practice, whereas it is one of the two major ways Oberon achieves achieve object-oriented programming. Sorry for the long setup, but: It's been a long time since I BOOPSI'd, so: is this perversion possible there, too? I didn't think that was the case, but maybe I misremember. If not, I'd say BOOPSI is not quite as bad as Oberon.

BOOPSI is still much worse than Oberon.

In fact, Oberon allowed to defined the methods and their signatures and check what you're doing them at runtime.

In fact, the last line of the code (f1 = c1; f2 = c2;) is only possible because the types are compatible (a figure is one ancestor of a circle). Plus, drawPerversely has a compatible (exact, in this case) signature for draw.

Compare it to BOOPSI, where you can do whatever you want because it's fully untyped. You can also "insert" (let's say this) a method with a completely different signature and of course cause immense issues.

And on the performances side Oberon is much better, because you can directly call a method in constant time O(1).

Whereas the chain of comparisons on BOOPSI takes O(n) time (where n is the number of method id's to check). It could take O(log2(s)) time with a binary search, but I never saw it (the code becomes A LOT more complicated and you should think about "sorting" the ids and take into account their ordinal number. Also inserting a new method could provoke a big change in the binary tree code). Anyway, it's much slower than the O(1) required on VMT's implementations.

What's even worse is that the comparisons on BOOPSI literally kill the processor's pipeline(s), because usually aren't predicatable. Whereas on a VMT implementation they are substantially static jumps and usually predicatable...


@Gunnar

Quote:

Gunnar wrote: Dear Cesare Di Mauro, Quote: BOOPSI is a complete crap as an OOP implementation which is also inefficient AND bloat. So, the exact opposite that you're claiming. This a clear and strong judgment from you.

I've provided FACTs about it on the previous and on this post.
Quote:

Help us understand on what experience you based this. How many Amiga programs using BOOBSI, did you write? Even how many Amiga programs in total did you write?

They are totally irrelevant. Again, logical fallacies.

You and logic are different twins...

@an_overeducated_idiot

Quote:

extreme OO enthusiasts

I love it. I used to call them something a lot less diplomatic. You can trace this back to languages like Java that mandated that a function could only exist as part of a class. An entire generation was reared thinking that procedural code is somehow old and bad, and not reflecting on the fact that a method is a function.

_________________
Doing stupid things for fun...

@all on OOP and BOOPSI
I didn't realize BOOPSI was such crap. I guess it never came up in the long ago forum wars about MUI vs Reaction/ClassACT and when talking about Datatypes. I guess we should have been discussing throwing them away instead and starting over maybe just rewriting the AmigaOS in C++. It looks to me like C++ programs start with about 10 times the program size, have more nasty indirect branches that are bad for performance and do more memory pointer chasing but what do I know. CISC x86-64 CPUs are memory munching monsters that can chase pointers in memory like no RISC CPUs and they have indirect branch prediction. On old small footprint hardware like the 68k Amiga, we have small caches, small and old memory, lack dual ported data caches and lack indirect branches. In my experience, C programs are much smaller and generally outperform C++ and OOP compiled programs. Most of the web browsers that are usable on the 68k Amiga are programmed in C. Modern code that tries to be more efficient is sometimes still programmed in C like Vulkan. I guess it doesn't matter if all the Amiga is is a virtual machine running on x86-64 hardware with GiBs of memory.

Which came first, the code or the data? Which came first, the chicken or the egg? Maybe both the chicken and egg DNA "data" came first. Still, did God give some consideration to what the DNA would create, do by instincts and do by reasoning? Is God a procedural or OOP programmer? It's funny that OOP descriptions often start with pics from nature as objects.



DNA is the code of everything living but it is data. I don't see a major distinction between OOP and procedural programming but what do I know?

Last edited by matthey on 02-Oct-2022 at 06:35 PM.

@matthey

Quote:

matthey wrote: Most of the web browsers that are usable on the 68k Amiga are programmed in C.

And all of them ended unmaintained before reaching 10% of the code base needed to make them useable with today's web (regardless of the underlying HW).

So yeah assembler was the best compromise for 8Bit and early 16Bit (think floppy only 512kb Amigas), C and other primitive compiler languages were the best compromise 32Bit Amigas and early 90s PC and modern languages are the best choice for today's HW.


Who would have thought.....

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@matthey

Quote:

matthey wrote: @all on OOP and BOOPSI I didn't realize BOOPSI was such crap. I guess it never came up in the long ago forum wars about MUI vs Reaction/ClassACT and when talking about Datatypes.

No, I've already had a discussion with Andy here, some years ago, on the same topic. And moved the same critics, of course.
Quote:

I guess we should have been discussing throwing them away instead and starting over maybe just rewriting the AmigaOS in C++. It looks to me like C++ programs start with about 10 times the program size, have more nasty indirect branches that are bad for performance and do more memory pointer chasing but what do I know.

This is generic and vague.

The point was/is about BOOPSI and a VMT-based OOP, comparing them on the implementation of the exactly the same problem.

So, we weren't talking about C++ and some big applications that may have seen: this is totally irrelevant about the topic / comparison.
Quote:

CISC x86-64 CPUs are memory munching monsters that can chase pointers in memory like no RISC CPUs and they have indirect branch prediction. On old small footprint hardware like the 68k Amiga, we have small caches, small and old memory, lack dual ported data caches and lack indirect branches.

Irrelevant as well.

You can compare BOOPSI a VMT-based OOP on the same 68k Amiga on exactly the same problem to be modeled and everything that we said about this comparison still applies.
Quote:

In my experience, C programs are much smaller and generally outperform C++ and OOP compiled programs. Most of the web browsers that are usable on the 68k Amiga are programmed in C. Modern code that tries to be more efficient is sometimes still programmed in C like Vulkan. I guess it doesn't matter if all the Amiga is is a virtual machine running on x86-64 hardware with GiBs of memory.

It doesn't matter in any case, because you cannot compare those things with BOOPSI: they are completely different things.

In fact, this a Red Herring: a logic fallacy.

The discussion was about BOOPSI a VMT-based OOP. With this only difference. Everything else is supposed to be exactly the same.
Quote:

Which came first, the code or the data?

The data. Because code is... data.
Quote:

Which came first, the chicken or the egg? Maybe both the chicken and egg DNA "data" came first. Still, did God give some consideration to what the DNA would create, do by instincts and do by reasoning? Is God a procedural or OOP programmer?

Undetermined, because god doesn't exist...
Quote:

It's funny that OOP descriptions often start with pics from nature as objects.

Because it's easy for people to understand the concepts.

But many times I've also seen graphic primitives used as examples.
Quote:

DNA is the code of everything living but it is data.

You see: data came first.
Quote:

I don't see a major distinction between OOP and procedural programming but what do I know?

Then you clearly don't know OOP...

@matthey

I don't say BOOPSI is terrible. It was a solution to a problem and specifically a tricky problem of runtime class definition and extension. It's not, however, a clean or performant one in retrospect. You do not need to take my or anyone else's word for this. You can prove it to yourself by defining a simple BOOPSI class and benchmarking a call to one of its methods versus a C function pointer or C++ virtual function that does the equivalent operation. You definitely won't have any doubts after that.

_________________
Doing stupid things for fun...

@cdimauro

Quote:

BOOPSI is still much worse than Oberon.

Excellent explanation. Thank you!

@Karlos

Quote:

I love it. I used to call them something a lot less diplomatic. You can trace this back to languages like Java that mandated that a function could only exist as part of a class. An entire generation was reared thinking that procedural code is somehow old and bad, and not reflecting on the fact that a method is a function.

Yep. I taught myself Java and Eiffel back in those days, and whereas I appreciated both of them (especially Eiffel's design-by-contract) I grew sick of the boilerplate really quickly. Worse, Java managed to establish itself as the "internet platform of choice" so quickly and thoroughly that it came to dominate the industry for a while, and to get a job in that you basically had to have certification. It was a cash cow for Sun, which still managed to go under.

Fortunately, Eiffel remained obscure, and its best ideas were picked off by Ada. A modern Ada compiler will statically check the contracts at compile time (cf. Ada 2012 / SPARK 2014), which Eiffel never got around to doing. Unfortunately, Ada also requires quite a bit of boilerplate, and back in the 80s was largely the province of "proprietary software" types who didn't understand that the future of software was open source, so it's mostly a niche industry these days, albeit a very important one where things have to be correct (transportation).

It makes no difference if its OO or function oriented, when it comes to speed.

a method is the same as a function, (with a ref to a struct.)
a virtual method is the same as a function pointer, (with a ref to a struct.)

with OO, you have methods and data in objects, in function oriented, only the data is in the (object) struct. A struct and class is the same thing in C++, well almost. Where OO goes wrong, is when you add methods to set and get the data, that’s how make something simple a fast into something slow and horrible.

OO kind forces you orient your fountains around the data, you easily see what belong to etch other, it also easy visualize someone code, generate UML diagrams. That’s not so easy on functional orianted code.

Last edited by NutsAboutAmiga on 02-Oct-2022 at 09:47 PM.
Last edited by NutsAboutAmiga on 02-Oct-2022 at 09:45 PM.
Last edited by NutsAboutAmiga on 02-Oct-2022 at 09:37 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Quote:

Where OO goes wrong, is when you add methods to set and get the data, that’s how make something simple a fast into something slow and horrible.

Maybe if your are using a language like Java where every method is inherently polymorphic this just isn't remotely true. In C++, simple getters and setters and indeed any non-virtual function will be inlined:

1. Always if declared directly in the class or explicitly inline
2. Almost always if declared outside the class

In fact the compiler can choose not to if the use case makes sense, e.g. invoking through pointer to member, while inlining in every other case.

The resulting code that is generated is no different than if you accessed the member directly. What you get in addition are compile time guarantees that this is done correctly.

_________________
Doing stupid things for fun...

@matthey

Quote:

I guess it never came up in the long ago forum wars about MUI vs Reaction/ClassACT and when talking about Datatypes.

FWIW I hated MUI, mainly because of the default palette (the NewIcons designer had a few choice words about it), but also because of how it seemed to take over everything. When it came to development, I thought it made things needlessly complicated. I came to appreciate it later when I wrote an AROS program or two.

I also wrote something with BOOPSI long ago, but don't remember the experience at all, aside from my initial frustration at trying to figure it out, but I experience that with everything.

Quote:

It looks to me like C++ programs start with about 10 times the program size, have more nasty indirect branches that are bad for performance and do more memory pointer chasing but what do I know.

That's generally true, or at least it was in the past. Some of it may be due to the processor architecture itself; for a long time I was programming in C++ on RISC architectures, and comparing the result to the C or Modula-2 that I wrote on Amigas. As the code density thread has much belabored, RISC architectures are not known for concise object code.

But some of it's simply due to a lack of link-time optimization. Historically, C++ handled generic programming via templates, and while that's a powerful mechanism and quite efficient in terms of time, you trade off efficiency in terms of space: it bloats the object files with an instantiation for every possible parameter. In principle, that should be cleaned up at link time, but I don't think most compilers did that until relatively recently (-flto in gcc).

FWIW, here's a comparison of binary sizes for a simple "Hello, world!" program on my machine (i5-8350U, Linux 5.19.12-100.fc35.x86_64):
- Ada: 783,600 (gnat community 2021)
- C: 17,352 (gcc 10.3.1)
- C++: 17,768 (g++ 10.3.1)
- Nim: 107,672 (nim 1.6.2)
- Oberon 2016: 26,944 (using obnc)
- Rust: 4,006,416 (rustc 1.65.0-nightly)

So C++ isn't doing so badly; it's basically equivalent to C.

The size of the Ada and Rust binaries is probably due to boilerplate code for safety checks that will diminish in a non-trivial program, and I'm pretty sure it can be removed; after all, both are actively used in embedded programming.

The size of the Rust surprised me enough that I dug into how to make it smaller. Using only a few tips on this page, I got it down to 1,663,480, and the strip command gets it down to 281,104. That's still way too large, but a "Hello, world!" program can't discard the standard library, while most OS software has to.

That made me wonder how much smaller the programs above could be made using strip:
Ada: 305,232
C: 6,960
C++: 6,984
Nim: 80,896
Oberon 2016: 15,304
Rust: 281,104

If I really cared about it, I could probably make all of these roughly the same size, though it would be interesting to see what would be sacrificed. For example, Ada, Nim, and Rust all check at runtime for things like integer overflow, invalid indices, etc. Shrinking their code to the size of the C/C++ would mean removing those checks... which leads to problems, sooner or later.

Quote:

I guess we should have been discussing throwing them away instead and starting over maybe just rewriting the AmigaOS in C++.

No, that would be pretty bad, too. C++ has basically spent the last 30 years giving C the features that Ada had 20-30 years ago, while keeping most of C's defects intact. You have to remember that C/C++ advocates really believe that crap programming is the only way to get efficiency, and if forgetting an equals sign in a comparison (if (a=b) instead of if (a==b)) takes down AT&T's entire east coast telephone network for half a day, well, that's the price you pay for a language that's so poorly designed that it lets you do that. Something like this actually happened back around 1990; I was in college & my supervisor, the wife of an AT&T bigwig, told me about it.

More recently, back in 2016 or 2017 I spent two weeks chasing down a C++ bug where the program worked fine when I compiled with -O0, but crashed with any higher level of optimization. Finally I found the culprit: I'd declared a function to return a bool type, but neglected to return the result at the end of the function. The compiler (gcc in fact) couldn't be bothered even to warn me. Go ahead and try to do that in a language like Ada or Rust and see what happens at compile time.

If you want to be really visionary, write it in Rust, a language born from Mozilla's frustrations with C++. My software team switched from Java to Rust about a year ago, and it's one of the best decisions we ever made. I still prefer Ada / SPARK, but there's a reason Rust is being accepted for the Linux kernel: like C, it's fast (and it can be faster than C); unlike C, it's truly high level, modern, and most importantly, safe. I realize the code sizes listed above won't inspire you, even after stripping, but as I pointed out above, it can be made smaller. The only downsides to Rust are the learning curve with the borrow checker, and the strange choice to make "move" the default for parameter passing, rather than "borrow", but the compiler messages are the best I've ever seen (following its hints almost always fixes the error!), the open-source ecosystem is fantastic (i.e., "cargo" and its crates), and the associated tools (e.g., clippy, fmt, etc.) make it a great environment. Unfortunately, it's llvm-only for now, so in reality you couldn't possibly do that.

As for whether God programs in a procedural or object-oriented language: neither. God doesn't change state, which strongly suggests functional programming.

added later: I should have linked to this page, which for a while was the focus of a lot of attention. Notice that a lot of languages beat out C++, and while C isn't mentioned I think the best C++ implementation is basically what you'd do in C.

Last edited by an_overeducated_idiot on 02-Oct-2022 at 10:02 PM.

@an_overeducated_idiot

Quote:

if (a=b) instead of if (a==b)) takes down AT&T's entire east coast telephone network for half a day,

That's a feature, not a bug

Modern compilers will give you a warmings when you do -wall.

Last edited by NutsAboutAmiga on 02-Oct-2022 at 10:16 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@an_overeducated_idiot

Rust, eh? I love to taunt those Johnny come lately loudmouth Rust evangelists that always compare it to languages that trusted the developer not to be an idiot, like C, or older versions of stricter languages.

I usually start by asking them what Rust solves that idiomatic modern C++ does not. This usually leads to a few surprises but typically involves a few iterations of them describing an issue that existed in ancient versions of C++ that have been fixed in 11, 14 or 17. Often the final response to that is that outside of a few minor examples, no significant application is written in modern idiomatic C++ anyway so it's not going live up to Rusts guarantees and anything written in it will still be riddled with defects.

I like to concede at this point and then go on to ask about Rusts compiler. We usually get to llvm where I point out this is one of those large, bug riddled C++ applications they are so strongly critical of. If it can't be trusted to function correctly then how can you guarantee a binary created in rust and compiled by something else doesn't have defects as a consequence?

It's a fun game.

_________________
Doing stupid things for fun...

@NutsAboutAmiga

Quote:

That's a feature, not a bug Modern compilers will give you a warmings when you do -wall.

I realize that C++ considers it a feature. I hold more to "premature optimization is the root of all evil."

In fact, modern gcc will warn you on that even when you don't ask for it, suggesting (IIRC) that you type if ((a=b)) or something like that.

@Karlos

You're joking, right? If you don't consider the borrow checker to be a huge improvement on pretty much anything C++ offers (and it doesn't in fact offer the borrow checker), along with the ability to avoid ever having to deallocate your own memory, then perhaps a guaranteed absence of data races in multithreaded operation will appeal to you? How about clean, readable generics that don't vomit pages and pages of illegible error messages when you try to do something entirely reasonable, but that C++'s designers think shouldn't be allowed? Helpful error messages that not only identify the problem, but in 90%+ of cases tell you how to solve it?

None of that appeals to you?

Yes, it's true that llvm is written in C and C++, and that brings the possibility of bugs. It's also true that a language that checks for errors and is designed both to minimize them and to prohibit poor programming practices is more likely to achieve that, as well as to scale safely to the immense sizes needed for, say a browser (to wit, Firefox, much of which is now written in Rust) than a language designed to facilitate abuse.

Perhaps I misunderstand you, but your argument sounds a lot like the arguments people used to make against programming in anything but assembly.

@Kronos

Quote:

Kronos wrote: @matthey Quote: matthey wrote: Most of the web browsers that are usable on the 68k Amiga are programmed in C. And all of them ended unmaintained before reaching 10% of the code base needed to make them useable with today's web (regardless of the underlying HW).

Most of the web browsers produced for the Amiga were barely usable at the time they were created. This had little to do with the programming language used and a lot to do with the skill of the programmers.

Then again, most 'modern' web browsers are not usable on all of today's web, and many are not at all usable on anything less than the latest hardware.

@Karlos

Quote:

Karlos wrote: @an_overeducated_idiot Rust, eh? I love to taunt those Johnny come lately loudmouth Rust evangelists that always compare it to languages that trusted the developer not to be an idiot, like C, or older versions of stricter languages. I usually start by asking them what Rust solves that idiomatic modern C++ does not.

The problem Rust solves is trusting the developer not to be an idiot. And there is nothing wrong with that. If we only accepted code from elite developers with brains like planets who know everything and never make a mistake, we wouldn't have nearly enough people to produce the code we need.

Stack Overflow 2022 developer survey: Most loved vs dreaded programming, scripting and markup languages
Quote:

Rust is on its seventh year as the most loved language with 87% of developers saying they want to continue using it. Rust also ties with Python as the most wanted technology... Rust 87.73% love, 13.27% dread C++ 48.39% love, 51.61% dread C 39.68% love, 60.32% dread Assembly 35.91% love, 65.09% dread

Every program that can be programmed in any language can also be programmed in asm, provided the developer has a brain like a planet. The reason languages become more 'idiot-proof' is so mere mortals can do programming. This was the case right from the beginning with languages like FORTRAN and BASIC, and continues today with Rust and Python. Sure there is a cost in bloat, but Moore's law took care of that.

Last edited by bhabbott on 03-Oct-2022 at 03:01 AM.

an_overeducated_idiot Quote:

FWIW I hated MUI, mainly because of the default palette (the NewIcons designer had a few choice words about it), but also because of how it seemed to take over everything. When it came to development, I thought it made things needlessly complicated. I came to appreciate it later when I wrote an AROS program or two.

MUI is slow, needlessly complex and I don't like the screen manager/opener. I wasn't impressed when I found it was copying memory continuously with CopyMemQuick() or CopyMem() when I wasn't even using the GUI. It has some cool GUI features but most of them I don't use. Reaction/ClassACT seemed more practical, faster and used less memory but wasn't very polished on the 68k. I haven't used the new 68k AmigaOS with updates though.

an_overeducated_idiot Quote:

That's generally true, or at least it was in the past. Some of it may be due to the processor architecture itself; for a long time I was programming in C++ on RISC architectures, and comparing the result to the C or Modula-2 that I wrote on Amigas. As the code density thread has much belabored, RISC architectures are not known for concise object code. But some of it's simply due to a lack of link-time optimization. Historically, C++ handled generic programming via templates, and while that's a powerful mechanism and quite efficient in terms of time, you trade off efficiency in terms of space: it bloats the object files with an instantiation for every possible parameter. In principle, that should be cleaned up at link time, but I don't think most compilers did that until relatively recently (-flto in gcc). FWIW, here's a comparison of binary sizes for a simple "Hello, world!" program on my machine (i5-8350U, Linux 5.19.12-100.fc35.x86_64): - Ada: 783,600 (gnat community 2021) - C: 17,352 (gcc 10.3.1) - C++: 17,768 (g++ 10.3.1) - Nim: 107,672 (nim 1.6.2) - Oberon 2016: 26,944 (using obnc) - Rust: 4,006,416 (rustc 1.65.0-nightly) So C++ isn't doing so badly; it's basically equivalent to C.

C++ isn't bad if certain things are avoided. Embedded C++ tried to eliminate some of the worst inefficiencies but it did not catch on. Apple uses a similar limited C++ subset though.

https://en.wikipedia.org/wiki/Embedded_C++ Quote:

Nevertheless, a restricted subset of C++ (based on Embedded C++) has been adopted by Apple Inc. as the exclusive programming language to create all I/O Kit device drivers for Apple's macOS, iPadOS and iOS operating systems of the popular Macintosh, iPhone, and iPad products. Apple engineers felt the exceptions, multiple inheritance, templates, and runtime type information features of standard C++ were either insufficient or not efficient enough for use in a high-performance, multithreaded kernel.

C++ has a few features that allow for better optimization than C too.

an_overeducated_idiot Quote:

The size of the Ada and Rust binaries is probably due to boilerplate code for safety checks that will diminish in a non-trivial program, and I'm pretty sure it can be removed; after all, both are actively used in embedded programming. The size of the Rust surprised me enough that I dug into how to make it smaller. Using only a few tips on this page, I got it down to 1,663,480, and the strip command gets it down to 281,104. That's still way too large, but a "Hello, world!" program can't discard the standard library, while most OS software has to. That made me wonder how much smaller the programs above could be made using strip: Ada: 305,232 C: 6,960 C++: 6,984 Nim: 80,896 Oberon 2016: 15,304 Rust: 281,104 If I really cared about it, I could probably make all of these roughly the same size, though it would be interesting to see what would be sacrificed. For example, Ada, Nim, and Rust all check at runtime for things like integer overflow, invalid indices, etc. Shrinking their code to the size of the C/C++ would mean removing those checks... which leads to problems, sooner or later.

They still look bloated to me for just a hello world program.

http://phoenix.owl.de/vbcc/docs/vbcc.pdf Quote:

A hello world using minstart could look like this: #include "proto/exec.h" #include "proto/dos.h" struct DosLibrary *DOSBase; main() { if(DOSBase=(struct DosLibrary *)OpenLibrary("dos.library",0)){ Write(Output(),"Hello, world!\n",14); CloseLibrary((struct Library *)DOSBase); } return 0; } This can yield an executable of under 256 bytes when compiled with -sc -sd and linked with minstart.o and amigas.lib (using vlink - may not work with other linkers).

The 68k Amiga Exec multitasking microkernel is only 13kiB and the original Amiga only had 256kiB of memory which is less than some of these hello world programs.

https://en.wikipedia.org/wiki/Exec_(Amiga)

The 68k Amiga is outdated though as it is only suited to run in emulators with GiB of memory where none of this matters. Maybe we are just as old and outdated.

an_overeducated_idiot Quote:

No, that would be pretty bad, too. C++ has basically spent the last 30 years giving C the features that Ada had 20-30 years ago, while keeping most of C's defects intact. You have to remember that C/C++ advocates really believe that crap programming is the only way to get efficiency, and if forgetting an equals sign in a comparison (if (a=b) instead of if (a==b)) takes down AT&T's entire east coast telephone network for half a day, well, that's the price you pay for a language that's so poorly designed that it lets you do that. Something like this actually happened back around 1990; I was in college & my supervisor, the wife of an AT&T bigwig, told me about it. More recently, back in 2016 or 2017 I spent two weeks chasing down a C++ bug where the program worked fine when I compiled with -O0, but crashed with any higher level of optimization. Finally I found the culprit: I'd declared a function to return a bool type, but neglected to return the result at the end of the function. The compiler (gcc in fact) couldn't be bothered even to warn me. Go ahead and try to do that in a language like Ada or Rust and see what happens at compile time. If you want to be really visionary, write it in Rust, a language born from Mozilla's frustrations with C++. My software team switched from Java to Rust about a year ago, and it's one of the best decisions we ever made. I still prefer Ada / SPARK, but there's a reason Rust is being accepted for the Linux kernel: like C, it's fast (and it can be faster than C); unlike C, it's truly high level, modern, and most importantly, safe. I realize the code sizes listed above won't inspire you, even after stripping, but as I pointed out above, it can be made smaller. The only downsides to Rust are the learning curve with the borrow checker, and the strange choice to make "move" the default for parameter passing, rather than "borrow", but the compiler messages are the best I've ever seen (following its hints almost always fixes the error!), the open-source ecosystem is fantastic (i.e., "cargo" and its crates), and the associated tools (e.g., clippy, fmt, etc.) make it a great environment. Unfortunately, it's llvm-only for now, so in reality you couldn't possibly do that.

Default compiler options and compiler error messages matter too. The GCC default is slop mode for C anyway. It doesn't even seem to follow a particular C standard and allows GCCisms as I call them. A lot of developers are used to this. It allows roughing in code quickly.

an_overeducated_idiot Quote:

As for whether God programs in a procedural or object-oriented language: neither. God doesn't change state, which strongly suggests functional programming.

lol

Last edited by matthey on 03-Oct-2022 at 03:19 AM.

FUNCTIONAL PADDING...

just kidding

@matthey

Quote:

Embedded C++ tried to eliminate some of the worst inefficiencies but it did not catch on.

Yeah, MISRA C tries to fix C, too, and yet... according to at least one study, adherence to the MISRA standard as a whole would have made the software less reliable.

Quote:

They still look bloated to me for just a hello world program.

Right -- but it's a hello world program. Once you get to non-trivial things, including embedded programming, high-level languages can be not just relatively small as the bloat is balanced out by code: the resulting binary can outperform hand-crafted C or even, dare one say it, assembly! (Really, read it and think about what they're saying there.)

As I say, Ada and Rust are pretty heavily used in embedded programming; the bloat can be eliminated when necessary, and in other cases it generally de-bloats and pays off.