Love this podcast and the whole series. Please keep an eye out for small font size. In long stretches of this there is relevant code on the screen that is unreadable even in full screen and max resolution.
Multithreading fundamentally isn't platform independent; it restricts your platforms to ones where threading exists, and it's platform dependent how they function as well. E.g. most GPUs implement lock-step SIMD threads, preferring to have small cores in thousands of instances, while an XMOS XS1 processor requires a minimum of 4 threads to run at full instruction rate, but cannot host more than 8. Few languages implement a model of their own for it, e.g. multiuser Forth. Most thinly wrap system level APIs. That said, OpenMP is widely supported in C compilers and provides language level multiprocessing. Concurrency is yet another topic (see e.g. AIO, nonblocking IO, select and poll). The core strength of C always was the ability to port programs to different machines. Shoving in too much platform specific stuff into the language is counter to this.
Green threads can always be implemented regardless of platform since they context switch entirely in software within a single operating system process. Erlang/OTP demonstrates this pretty effectively. But I do agree with your final point that the wide applicability of C is due to its minimalism and being a low level of abstraction just above assembly language.
I disagree with the focus on things in stdlib here. The stdlib model makes sense for older languages before packaging, but package managers have changed what's considered effectively part of the "base" language. Also, as another note, basing this example on what C can do at a starting point while not allowing external libraries is extremely limiting from a real code base. As a major example, the lack of a hash map limits you heavily. I think you should likely reconsider this spec to allow some base external libraries to then let the C version use a hashmap.
Point taken, but for my part I do not agree. A language's standard library is called "standard" for that very reason: every implementation that conforms to its specification must provide was it declares as standard. No such guarantee is made for additional externally packaged and imported libraries. Add to that, the competition between different packages for the same functionality makes it untenable to decide which is most representative. Although we must pick a particular implementation for each language that we write BBHW for, our focus will remain on each programming language in general as the number of different implementations is much greater than the standards, as is the case with Scheme, for example. Notice that for the later APL episodes we have included alternative implementations for Dyalog APL, provided by Adám Brudzewsky, and there are significant differences between the Dyalog and GNU APL code.
Love this podcast and the whole series. Please keep an eye out for small font size. In long stretches of this there is relevant code on the screen that is unreadable even in full screen and max resolution.
Agreed; we have been improving bit by bit as we go.
@@proglangbase I noticed, much appreciated.
Multithreading fundamentally isn't platform independent; it restricts your platforms to ones where threading exists, and it's platform dependent how they function as well. E.g. most GPUs implement lock-step SIMD threads, preferring to have small cores in thousands of instances, while an XMOS XS1 processor requires a minimum of 4 threads to run at full instruction rate, but cannot host more than 8.
Few languages implement a model of their own for it, e.g. multiuser Forth. Most thinly wrap system level APIs. That said, OpenMP is widely supported in C compilers and provides language level multiprocessing. Concurrency is yet another topic (see e.g. AIO, nonblocking IO, select and poll).
The core strength of C always was the ability to port programs to different machines. Shoving in too much platform specific stuff into the language is counter to this.
Green threads can always be implemented regardless of platform since they context switch entirely in software within a single operating system process. Erlang/OTP demonstrates this pretty effectively. But I do agree with your final point that the wide applicability of C is due to its minimalism and being a low level of abstraction just above assembly language.
I disagree with the focus on things in stdlib here. The stdlib model makes sense for older languages before packaging, but package managers have changed what's considered effectively part of the "base" language. Also, as another note, basing this example on what C can do at a starting point while not allowing external libraries is extremely limiting from a real code base. As a major example, the lack of a hash map limits you heavily. I think you should likely reconsider this spec to allow some base external libraries to then let the C version use a hashmap.
Point taken, but for my part I do not agree. A language's standard library is called "standard" for that very reason: every implementation that conforms to its specification must provide was it declares as standard. No such guarantee is made for additional externally packaged and imported libraries. Add to that, the competition between different packages for the same functionality makes it untenable to decide which is most representative. Although we must pick a particular implementation for each language that we write BBHW for, our focus will remain on each programming language in general as the number of different implementations is much greater than the standards, as is the case with Scheme, for example. Notice that for the later APL episodes we have included alternative implementations for Dyalog APL, provided by Adám Brudzewsky, and there are significant differences between the Dyalog and GNU APL code.
@@c4tubo Fair point and makes sense here. These are great videos btw, thanks for putting them up!