Friday, November 12, 2021

Digest for comp.programming.threads@googlegroups.com - 11 updates in 11 topics

Amine Moulay Ramdane <aminer68@gmail.com>: Nov 11 07:57PM -0800

Hello,
 
 
 
Read again, i correct about more of my philosophy about how to be the good philosophy in architecting the good programming language..
 
I am a white arab from Morocco, and i think i am smart since i have also
invented many scalable algorithms and algorithms..
 
I think that being a good architect of a programming language is like
being a good philosopher, since you have to also know how to well "balance" from the start, but knowing how to well balance is also providing the others with general way of doing that can be built from basic building blocks, so i think that C++ is much older than many programming languages, but i think that it has tried to well approximate the being a good programming language by providing us with the basic building blocks that permit to build the much higher building blocks, but notice with me that in C++ the basic building blocks are also well thought, since the basic building blocks that lack for example strong typing can become strong typing by composing them in higher level building blocks with for example object oriented programming or such, so you can quickly notice that C++ has tried to not being restrictive in the lower building blocks so that to also for example give the freedom of being fast speed of execution, so i think that it is the important philosophy of C++, since it has avoided to be restrictive or too much restrictive from the start as for example the too restrictive languages of Rust or Go, by being a good efficiency so that to permit a much more "flexibility" from the start, and notice that we can even say that we can choose a subset of the more complex language of C++ so that to lower complexity of all the current C++ language, and this is also in accordance with the philosophy of C++. And this philosophy
of C++ looks like my following proverbs that i think are flexible from the start and that i have just invented quickly, here they are and read them carefully:
 
https://groups.google.com/g/alt.culture.morocco/c/ZyUvFt_nix8
 
And this important philosophy of C++ also looks like my following
poems of Love that i think are flexible from the start, here they
are and read them carefully:
 
https://groups.google.com/g/alt.culture.morocco/c/qte9bCZiOiw
 
More of my philosophy about Python and operating systems and network administration..
 
You have just seen me talking about C++ and Rust and Python etc., read my thoughts below about it, but now i have to make you understand that
even if Python has the below disadvantage in multiprocessing that i have just talked about, Python is still very important in making multiprocessing operating system and network administration, since the multiprocessing task of the administration can be expensive and it will make the multiprocessing of Python scale much more, so this is why i will soon port some of my scalable algorithms inventions to Python that will make Python scale much more and i will write a tutorial about it using some real world operating system administration and network administration using multiprocessing python tasks. So i think that Python is still a powerful tool.
 
More of my philosophy about Python and Ruby and Go languages and more..
 
I think i am smart since i am an inventor of many powerful scalable algorithms, so i am specialized in parallel programming and synchronization algorithms, and i say that Python and Ruby and Go
languages have a big problem, and it is that Python can use python interpreters in each process or in each thread so that to avoid to lock in a single interpreter, but this brings a big problem and it is that you have to transfer the data of the inside of a python object between threads or processes using a queue or shared memory etc. and it doesn't look like C++ or Delphi way where you can move a pointer or reference to an object not the data inside an object between threads so that to scale and be fast, so this way of moving data of inside an object of Python and Ruby is not scalable and is too slow and it looks like MPI messaging way, Go language has not this big problem but Go has the same problem as Rust since it doesn't provide us with OOP inheritance, read about it in my following thoughts:
 
More of my philosophy about the too much purism philosophy of Rust and more..
 
I think i am smart, and i think that Rust compiler and language is too much "purist", it looks like the too much purism of Haskell functional programming language, since i say that Rust doesn't provide us with OOP inheritance, but it is too much restrictive, and it is the deficiency of Rust, since inheritance has advantages and disadvantages, so we have to balance well and provide also with inheritance so that to be efficient, so i think that C++ and C# are better than Rust in this regard, and here is the advantages and disadvantages of OOP inheritance:
 
https://www.ianswer4u.com/2017/09/oops-inheritance-advantages.html
 
More of my philosophy about NP-hard problems and about Rust and C++..
 
I think i am smart and i have just quickly looked at Rust compiler and i think that since the Rust compiler has included race detection so
it is NP-hard, so that means that Rust compiler will never know in race detection which of races are real race conditions(Read here in the following paper so that to understand it: https://www.sjsu.edu/people/robert.chun/courses/cs159/s3/Y.pdf), and, this is the reason why it is difficult to use a tool to find race conditions accurately, so then i think that C++ is still useful by using it with Threadsanatizer and Address sanatizer even if C++ is getting complex as i just said the following:
 
More of my philosophy about C++ and Rust and Microsoft and safety-critical systems..
 
I invite you to read the following from Microsoft about Rust programming language:
 
Microsoft: Rust Is the Industry's 'Best Chance' at Safe Systems Programming
 
https://thenewstack.io/microsoft-rust-is-the-industrys-best-chance-at-safe-systems-programming/
 
I think that the above article is not correct, since i think that
Rust is suited for safety-critical systems, so i think Rust is better
than C++ in the safety-critical systems, but i think that C++ will
still be useful with the Address sanitizer and ThreadSanatizer,
and read my below thoughts since i have just added something in them:
 
More of my philosophy about memory safety and inheritance in programming languages..
 
"Address sanitization is not a security feature, nor does it provide memory-safety: it's a debugging tool. Programmers already have tools to detect that the code they've written has memory problems, such as use-after-free or memory leaks. Valgrind is probably the best-known example. This gcc feature provides (some of) the same functionality: the only new thing is that it's integrated with the compiler, so it's easier to use.
 
You wouldn't have this feature turned on in production: it's for debugging only. You compile your tests with this flag, and automatically they detect memory errors that are triggered by the test. If your tests aren't sufficient to trigger the problem, then you still have the problem, and it'll still cause the same security flaws in production.
 
Rust's ownership model prevents these defects by making programs that contain such defects invalid: the compiler will not compile them. You don't have to worry about your tests not triggering the problem, because if the code compiles, there cannot be a problem.
 
The two features are for different sets of problems. One feature of address sanitization is to detect memory leaks (allocating memory and neglecting to free it later). Rust makes it harder to write memory leaks than in C or C++, but it's still possible (if you have circular references). Rust's ownership model prevents data races in sequential and multi-threaded situations (see below). Address sanitization doesn't aim to detect either of those cases. But you can use ThreadSanatizer"
 
And using just plain C#, it has better memory protection, since the GC and runtime make it impossible to leak, double-free, or access out-of-bounds. C# has unsafe blocks just like Rust does. Safe Rust is just as safe from memory safety problems as safe C#.
 
I think that a programming language has to provide "inheritance",
and the new Rust programming language doesn't provide it and i think that it is a deficiency in Rust, here is why:
 
As a software developer you have to become more efficient and productive. So you need to make sure the code you write is easily reusable and maintainable. And, among other things, this is what inheritance gives you - the ability to reuse without reinventing the wheel, as well as the ability to easily maintain your base object without having to perform maintenance on all similar objects.
 
 
Thank you,
Amine Moulay Ramdane.
Amine Moulay Ramdane <aminer68@gmail.com>: Nov 11 07:49PM -0800

Hello,
 
 
 
More of my philosophy about how to be the good philosophy in architecting the good programming language..
 
I am a white arab from Morocco, and i think i am smart since i have also
invented many scalable algorithms and algorithms..
 
I think that being a good architect of a programming language is like
being a good philosopher, since you have to also know how to well "balance" from the start, but knowing how to well balance is also providing the others with general way of doing that can built from basic building blocks, so i think that C++ is much older than many programming languages, but i think that it has tried to well approximate the being a good programming language by providing us with the basic building blocks that permit to build the much higher building blocks, but notice with me that in C++ the basic building blocks are also well thought, since the basic building blocks that lack for example strong typing can become strong typing by composing them in higher level building blocks with for example object oriented programming or such, so you can quickly notice that C++ has tried to not being restrictive in the lower building blocks so that to also for example give the freedom of being fast speed of execution, so i think that it is the important philosophy of C++, since
it has avoided to be restrictive from the start, as for example Rust or Go, by being a good efficiency so that to permit a much more "flexibility" from the start, and notice that we can even say that we can choose a subset of the more complex language of C++ so that to lower complexity of all the current C++ language, and this is also in accordance with the philosophy of C++. And this philosophy
of C++ looks like my following proverbs that i think are flexible from the start and that i have just invented quickly, here they are and read them carefully:
 
https://groups.google.com/g/alt.culture.morocco/c/ZyUvFt_nix8
 
And this important philosophy of C++ also looks like my following
poems of Love that i think are flexible from the start, here they
are and read them carefully:
 
https://groups.google.com/g/alt.culture.morocco/c/qte9bCZiOiw
 
More of my philosophy about Python and operating systems and network administration..
 
You have just seen me talking about C++ and Rust and Python etc., read my thoughts below about it, but now i have to make you understand that
even if Python has the below disadvantage in multiprocessing that i have just talked about, Python is still very important in making multiprocessing operating system and network administration, since the multiprocessing task of the administration can be expensive and it will make the multiprocessing of Python scale much more, so this is why i will soon port some of my scalable algorithms inventions to Python that will make Python scale much more and i will write a tutorial about it using some real world operating system administration and network administration using multiprocessing python tasks. So i think that Python is still a powerful tool.
 
More of my philosophy about Python and Ruby and Go languages and more..
 
I think i am smart since i am an inventor of many powerful scalable algorithms, so i am specialized in parallel programming and synchronization algorithms, and i say that Python and Ruby and Go
languages have a big problem, and it is that Python can use python interpreters in each process or in each thread so that to avoid to lock in a single interpreter, but this brings a big problem and it is that you have to transfer the data of the inside of a python object between threads or processes using a queue or shared memory etc. and it doesn't look like C++ or Delphi way where you can move a pointer or reference to an object not the data inside an object between threads so that to scale and be fast, so this way of moving data of inside an object of Python and Ruby is not scalable and is too slow and it looks like MPI messaging way, Go language has not this big problem but Go has the same problem as Rust since it doesn't provide us with OOP inheritance, read about it in my following thoughts:
 
More of my philosophy about the too much purism philosophy of Rust and more..
 
I think i am smart, and i think that Rust compiler and language is too much "purist", it looks like the too much purism of Haskell functional programming language, since i say that Rust doesn't provide us with OOP inheritance, but it is too much restrictive, and it is the deficiency of Rust, since inheritance has advantages and disadvantages, so we have to balance well and provide also with inheritance so that to be efficient, so i think that C++ and C# are better than Rust in this regard, and here is the advantages and disadvantages of OOP inheritance:
 
https://www.ianswer4u.com/2017/09/oops-inheritance-advantages.html
 
More of my philosophy about NP-hard problems and about Rust and C++..
 
I think i am smart and i have just quickly looked at Rust compiler and i think that since the Rust compiler has included race detection so
it is NP-hard, so that means that Rust compiler will never know in race detection which of races are real race conditions(Read here in the following paper so that to understand it: https://www.sjsu.edu/people/robert.chun/courses/cs159/s3/Y.pdf), and, this is the reason why it is difficult to use a tool to find race conditions accurately, so then i think that C++ is still useful by using it with Threadsanatizer and Address sanatizer even if C++ is getting complex as i just said the following:
 
More of my philosophy about C++ and Rust and Microsoft and safety-critical systems..
 
I invite you to read the following from Microsoft about Rust programming language:
 
Microsoft: Rust Is the Industry's 'Best Chance' at Safe Systems Programming
 
https://thenewstack.io/microsoft-rust-is-the-industrys-best-chance-at-safe-systems-programming/
 
I think that the above article is not correct, since i think that
Rust is suited for safety-critical systems, so i think Rust is better
than C++ in the safety-critical systems, but i think that C++ will
still be useful with the Address sanitizer and ThreadSanatizer,
and read my below thoughts since i have just added something in them:
 
More of my philosophy about memory safety and inheritance in programming languages..
 
"Address sanitization is not a security feature, nor does it provide memory-safety: it's a debugging tool. Programmers already have tools to detect that the code they've written has memory problems, such as use-after-free or memory leaks. Valgrind is probably the best-known example. This gcc feature provides (some of) the same functionality: the only new thing is that it's integrated with the compiler, so it's easier to use.
 
You wouldn't have this feature turned on in production: it's for debugging only. You compile your tests with this flag, and automatically they detect memory errors that are triggered by the test. If your tests aren't sufficient to trigger the problem, then you still have the problem, and it'll still cause the same security flaws in production.
 
Rust's ownership model prevents these defects by making programs that contain such defects invalid: the compiler will not compile them. You don't have to worry about your tests not triggering the problem, because if the code compiles, there cannot be a problem.
 
The two features are for different sets of problems. One feature of address sanitization is to detect memory leaks (allocating memory and neglecting to free it later). Rust makes it harder to write memory leaks than in C or C++, but it's still possible (if you have circular references). Rust's ownership model prevents data races in sequential and multi-threaded situations (see below). Address sanitization doesn't aim to detect either of those cases. But you can use ThreadSanatizer"
 
And using just plain C#, it has better memory protection, since the GC and runtime make it impossible to leak, double-free, or access out-of-bounds. C# has unsafe blocks just like Rust does. Safe Rust is just as safe from memory safety problems as safe C#.
 
I think that a programming language has to provide "inheritance",
and the new Rust programming language doesn't provide it and i think that it is a deficiency in Rust, here is why:
 
As a software developer you have to become more efficient and productive. So you need to make sure the code you write is easily reusable and maintainable. And, among other things, this is what inheritance gives you - the ability to reuse without reinventing the wheel, as well as the ability to easily maintain your base object without having to perform maintenance on all similar objects.
 
 
Thank you,
Amine Moulay Ramdane.
Amine Moulay Ramdane <aminer68@gmail.com>: Nov 11 06:24PM -0800

Hello,
 
 
More of my philosophy about our Era of Cyborgs and more..
 
I am a white arab from Morocco, and i think i am smart since i have also
invented many scalable algorithms and algorithms..
 
I think i am a sophisticated Cyborg, i am like the following super
soldiers in the following video:
 
Strongest Super Soldiers
 
https://www.youtube.com/watch?v=LW9pzalIZRk&t=314s
 
Since you can read the following from Elon Musk that says
that we are already Cyborgs:
 
Elon Musk: We're already cyborgs
 
https://www.theverge.com/2016/6/2/11837854/neural-lace-cyborgs-elon-musk
 
So now you are understanding that i am a sophisticated Cyborg in
internet, and you can easily notice it that i have just thought
and written and posted "quickly" all my following thoughts, and i can
invent powerful software scalable algorithms and algorithms, and i have
invented many software scalable algorithms and algorithms and i have
just today invented two "powerful" software algorithms, and i can give
you another example of how i am a sophisticated Cyborg by inviting you
to look at my following thoughts in the following link that i have also
thought and written and posted "quickly":
 
https://groups.google.com/g/alt.culture.morocco/c/ag_ziCVV0VA
 
And i have also thought and written and posted quickly all
my following thoughts, read them carefully:
 
As you have just noticed i have just quickly read a PhD paper below,
and i have also just read two other PhD papers about Wait-free Eras and
Hazard Eras, here they are, read them carefully:
 
Here is the PhD paper about Wait-free Eras:
 
https://arxiv.org/pdf/2001.01999.pdf
 
And here is the PhD paper of Hazard Eras:
 
https://github.com/pramalhe/ConcurrencyFreaks/blob/master/papers/hazarderas-2017.pdf
 
And they are two new memory reclamations, but i have just read the PhD
papers and i am finding two defects or disadvantages, and it is that
you have to "fix" the number of threads so that the algorithms work, so
it is not good and it is not flexible, and they are not energy efficient
since the lock-free Hazard Eras does loop like in Lockfree algorithms,
so it consumes a lot of energy, and i think the Wait-free Eras also does
loop a constant number of time Bounded by the number of threads that
make it Wait-free, like in the get_protected() function in the source
code above of the Wait-free Eras, so i think that it consumes too much
energy, so then they are not energy efficient. And about Epoch-based
memory reclamation, it is not robust and you can understand it by
looking at the following video:
 
VBR: Version Based Reclamation
 
https://www.youtube.com/watch?v=uWXXNWNwr-w
 
And notice the following new algorithm from a PhD researcher called
Onefile that is a Wait-free persistent Transactional memory here:
 
https://github.com/pramalhe/OneFile/blob/master/OneFile-2019.pdf
 
So the disadvantages of Onefile is that it is not energy efficient
as the above Wait-Free Eras algorithm, also the code is much more
difficult and complex than using the much simpler and the much easy
locking algorithms.
 
Yet more of my precision of my philosophy about 3D stacking in CPUs and
Nanotechnology and artificial intelligence and more..
 
I will, in this post of mine, put more of my thoughts and writing about
Exascale supercomputers and more, so i invite you to read all my
following thoughts and writing:
 
More of my philosophy about the benefits of Exascale supercomputers and
more..
 
As you have just noticed i have just posted about the following:
 
Intel's Aurora Supercomputer Now Expected to Exceed 2 ExaFLOPS Performance
 
Read more here:
 
https://www.anandtech.com/show/17037/aurora-supercomputer-now-expected-to-exceed-2-exaflops-performance
 
But Exascale supercomputers will also allow to construct an accurate map
of the brain that allows to "reverse" engineer or understand the brain,
read the following so that to notice it:
 
"If we don't improve today's technology, the compute time for a whole
mouse brain would be something like 1,000,000 days of work on current
supercomputers. Using all of Aurora, if everything worked beautifully,
it could still take 1,000 days." Nicola Ferrier, Argonne senior computer
scientist
 
Read more here so that to understand:
 
https://www.anl.gov/article/preparing-for-exascale-argonnes-aurora-supercomputer-to-drive-brain-map-construction
 
Also Exascale supercomputers will allow researchers to tackle problems
which were impossible to simulate using the previous generation of
machines, due to the massive amounts of data and calculations involved.
 
Small modular nuclear reactor (SMR) design, wind farm optimization and
cancer drug discovery are just a few of the applications that are
priorities of the U.S. Department of Energy (DOE) Exascale Computing
Project. The outcomes of this project will have a broad impact and
promise to fundamentally change society, both in the U.S. and abroad.
 
Read more here:
 
https://www.cbc.ca/news/opinion/opinion-exascale-computing-1.5382505
 
Also the goal of delivering safe, abundant, cheap energy from fusion is
just one of many challenges in which exascale computing's power may
prove decisive. That's the hope and expectation. Also to know more about
the other benefits of using Exascale computing power, read more here:
 
https://www.hpcwire.com/2019/05/07/ten-great-reasons-among-many-more-to-build-the-1-5-exaflops-frontier/
 
More of my philosophy about 3D stacking in CPUs and more..
 
3D stacking offers an extension for Moore's Law, but in 3D stacking
Heat removal is the issue and the big problem, this is why the actual
technologies like the 3D stacking of Intel are limited to stacking just
two or few layers.
 
More of my philosophy about more of my philosophy about Moore's Law and
EUV (Extreme ultraviolet lithography)..
 
Researchers have proposed successors to EUV, including e-beam and
nanoimprint lithography, but have not found any of them to be reliable
enough to justify substantial investment.
 
And I think by also using EUV (Extreme ultraviolet lithography) to
create CPUs we will extend Moore's law by around 15 years that
corresponds to around 100x scalability in performance, and i think that
it is the same performance of 100x as the following invention from graphene:
 
About graphene and about unlocking Moore's Law..
 
I think that graphene can now be mass produced, you can read about it here:
 
We May Finally Have a Way of Mass Producing Graphene
 
It's as simple as one, two, three.
 
Read more here:
 
https://futurism.com/we-may-finally-have-a-way-of-mass-producing-graphene
 
So the following invention will be possible:
 
Physicists Create Microchip 100 Times Faster Than Conventional Ones
 
Read more here:
 
https://interestingengineering.com/graphene-microchip-100-times-fast?fbclid=IwAR3wG09QxtQciuku4KUGBVRQPNRSbhnodPcnDySLWeXN9RCnvb0GqRAyM-4
 
More philosophy about the Microchips that are 100 Times or 1000 times
Faster Than Conventional Ones..
 
I think that the following invention of Microchips that are 100 Times
or 1000 times Faster Than Conventional Ones has its weakness, since
its weakness is cache-coherence traffic between cores that
takes time, so i think that they are speaking about 100-times
or 1000-times more speed in a single core performance, so
parallelism is still necessary and you need scalable algorithms
for that so that to scale much more on multicores CPUs..
 
Physicists Create Microchip 100 Times Faster Than Conventional Ones
 
Read more here:
 
https://interestingengineering.com/graphene-microchip-100-times-fast?fbclid=IwAR3wG09QxtQciuku4KUGBVRQPNRSbhnodPcnDySLWeXN9RCnvb0GqRAyM-4
 
 
And read the following news:
 
 
AMD Demonstrates Stacked 3D V-Cache Technology: 192 MB at 2 TB/sec which
would technically be faster than the L1 cache on the die (but with
higher latency)..
 
"The AMD team surprised us here. What seemed like a very
par-for-the-course Computex keynote turned into an incredible
demonstration of what AMD is testing in the lab with TSMC's new 3D
Fabric technologies. We've covered 3D Fabric before, but AMD is putting
it to good use by stacking up its processors with additional cache,
enabling super-fast bandwidth, and better gaming performance."
 
Read more here:
 
https://www.anandtech.com/show/16725/amd-demonstrates-stacked-vcache-technology-2-tbsec-for-15-gaming
 
 
More of my philosophy about the knee of an M/M/n queue and more..
 
Here is the mathematical equation of the knee of an M/M/n queue in
queuing theory in operational research:
 
1/(n+1)^(1/n)
 
n is the number of servers.
 
So then an M/M/1 has a knee of 50% of the utilization, and the one of
an M/M/2 is 0,578, so i correct below:
 
More of my philosophy about the network topology in multicores CPUs..
 
I invite you to look at the following video:
 
Ring or Mesh, or other? AMD's Future on CPU Connectivity
 
https://www.youtube.com/watch?v=8teWvMXK99I&t=904s
 
And i invite you to read the following article:
 
Does an AMD Chiplet Have a Core Count Limit?
 
Read more here:
 
https://www.anandtech.com/show/16930/does-an-amd-chiplet-have-a-core-count-limit
 
I think i am smart and i say that the above video and the above article
are not so smart, so i will talk about a very important thing, and it is
the following, read the following:
 
Performance Scalability of a Multi-core Web Server
 
https://www.researchgate.net/publication/221046211_Performance_scalability_of_a_multi-core_web_server
 
So notice carefully that it is saying the following:
 
"..we determined that performance scaling was limited by the capacity of
the address bus, which became saturated on all eight cores. If this key
obstacle is addressed, commercial web server and systems software are
well-positioned to scale to a large number of cores."
 
So as you notice they were using an Intel Xeon of 8 cores, and the
application was scalable to 8x but the hardware was not scalable to 8x,
since it was scalable only to 4.8x, and this was caused by the bus
saturation, since the Address bus saturation causes poor scaling, and
the Address Bus carries requests and responses for data, called snoops,
and more caches mean more sources and more destinations for snoops that
is causing the poor scaling, so as you notice that a network topology of
a Ring bus or a bus was not sufficient so that to scale to 8x on an
Intel Xeon with 8 cores, so i think that the new architectures like Epyc
CPU and Threadripper CPU can use a faster bus or/and a different network
topology that permits to both ensure a full scalability locally in the
same node and globally between the nodes, so then we can notice that a
sophisticated mesh network topology not only permits to reduce the
number of hops inside the CPU for good latency, but it is also good for
reliability by using its sophisticated redundancy and it is faster than
previous topologies like the ring bus or the bus since
for example the search on address bus becomes parallelized, and it looks
like the internet network that uses mesh topology using routers, so it
parallelizes, and i also think that using a more sophisticated topology
like a mesh network topology is related to queuing theory since we can
notice that in operational research the mathematics says that we can
make the queue like M/M/1 more efficient by making the server more
powerful, but we can notice that
the knee of a M/M/1 queue is around 50% , so we can notice that
by using in a mesh topology like internet or inside a CPU you can
by parallelizing more you can in operational research both enhance the
knee of the queue and the speed of executing the transactions and it is
like using many servers in queuing theory and it permits to scale better
inside a CPU or in internet.
 
More of my philosophy about Machine programming and about oneAPI from
Intel company..
 
I will say that when you know C and C++ moderately, it will not be so
difficult to program OpenCL(Read about OpenCL here:
https://en.wikipedia.org/wiki/OpenCL) or CUDA, but the important
question is what is the difference between FPGA and GPU ? so i invite
you to read the following interesting paper about GPU vs FPGA
Performance Comparison:
 
https://www.bertendsp.com/pdf/whitepaper/BWP001_GPU_vs_FPGA_Performance_Comparison_v1.0.pdf
 
So i think from this paper above that GPU is the good way when you
want performance and you want too cost efficiency.
 
So i think that the following oneAPI from Intel company that wants with
it to do all the heavy lifting for you, so you can focus on the
algorithm, rather than on writing OpenCL calls, is not a so smart way of
doing, since as i said above that OpenCL and CUDA programming is not so
difficult, and as you will notice below that oneAPI from Intel permits
you to program FPGA in a higher level manner, but here again from the
paper above we can notice that GPU is the good way when you want
performance and cost efficiency, then so that to approximate well the
efficiency and usefulness of oneAPI from Intel you can still use
efficient and useful libraries.
 
Here is the new oneAPI from Intel company, read about it:
 
https://codematters.online/intel-oneapi-faq-part-1-what-is-oneapi/
 
And now i will talk about another interesting subject and it is
about the next revolution in the software industry that is Machine
programming, so i invite you to read carefully the following new article
about it:
 
https://venturebeat.com/2021/06/18/ai-weekly-the-promise-and-limitations-of-machine-programming-tools/
 
So i think that Machine programming will be limited to AI-powered
assistants that is not so efficient, since i think that connectionism
in artificial intelligence is not able to make emerge common sense
reasoning, so i invite you to read my following thoughts about it
so that to understand why:
 
More of my philosophy about the limit of the connectionist models in
artificial intelligence and more..
 
I think i am smart and i will say that the connectionist model like
of deep learning has not the same nature as of the human brain, since
i can say that the brain is not just connections of neurons like
in deep learning, but it is also a "sense" like the sense of touch,
and i think that this sense of the brain is biologic,
and i think that this kind of nature of the brain of being
also a sense is giving the emergence of consciousness and self-awareness
and a higher level of common sense reasoning, this
is why i think that the connectionist model in artifical intelligence is
showing its limits by not being able to make emerge common sense
reasoning, but as i said below that the hybrid connectionist + symbolic
model can make emerge common sense reasoning.
 
And here is what i said about human self-awareness and awareness:
 
So i will start by asking a philosophical question of:
 
Is human self-awareness and awareness an emergence and what is it ?
 
So i will explain my findings:
 
I think i have found the first smart pattern with my fluid intelligence
and i found also the rest and it is the following:
 
Notice that when you touch a cold water you will know about the essence
or nature of the cold water and you will also know that it is related
to senses of humans, so i think that the senses of a human give life
to ideas, it is like a "reification" of an idea, i mean that an idea
is alive since it is like reified with the senses of humans that senses
time and space and matter, so this reification gives the correct meaning
since you are like reifying with the human senses that gives the
meaning, and i say that this capacity of this kind of reification with
the human senses is an emergence that comes from the human biology, so i
am smart and i will say that the brain is a kind of calculator that
calculates by using composability with
Amine Moulay Ramdane <aminer68@gmail.com>: Nov 11 05:43PM -0800

Hello,
 
 
More of my philosophy about Python and operating systems and network administration..
 
I am a white arab from Morocco, and i think i am smart since i have also
invented many scalable algorithms and algorithms..
 
You have just seen me talking about C++ and Rust and Python etc., read my thoughts below about it, but now i have to make you understand that
even if Python has the below disadvantage in multiprocessing that i have just talked about, Python is still very important in making multiprocessing operating system and network administration, since the multiprocessing task of the administration can be expensive and it will make the multiprocessing of Python scale much more, so this is why i will soon port some of my scalable algorithms inventions to Python that will make Python scale much more and i will write a tutorial about it using some real world operating system network administration using multiprocessing python tasks. So i think that Python is still a powerful
tool.
 
More of my philosophy about Python and Ruby and Go languages and more..
 
I think i am smart since i am an inventor of many powerful scalable algorithms, so i am specialized in parallel programming and synchronization algorithms, and i say that Python and Ruby and Go
languages have a big problem, and it is that Python can use python interpreters in each process or in each thread so that to avoid to lock in a single interpreter, but this brings a big problem and it is that you have to transfer the data of the inside of a python object between threads or processes using a queue or shared memory etc. and it doesn't look like C++ or Delphi way where you can move a pointer or reference to an object not the data inside an object between threads so that to scale and be fast, so this way of moving data of inside an object of Python and Ruby is not scalable and is too slow and it looks like MPI messaging way, Go language has not this big problem but Go has the same problem as Rust since it doesn't provide us with OOP inheritance, read about it in my following thoughts:
 
More of my philosophy about the too much purism philosophy of Rust and more..
 
I think i am smart, and i think that Rust compiler and language is too much "purist", it looks like the too much purism of Haskell functional programming language, since i say that Rust doesn't provide us with OOP inheritance, but it is too much restrictive, and it is the deficiency of Rust, since inheritance has advantages and disadvantages, so we have to balance well and provide also with inheritance so that to be efficient, so i think that C++ and C# are better than Rust in this regard, and here is the advantages and disadvantages of OOP inheritance:
 
https://www.ianswer4u.com/2017/09/oops-inheritance-advantages.html
 
More of my philosophy about NP-hard problems and about Rust and C++..
 
I think i am smart and i have just quickly looked at Rust compiler and i think that since the Rust compiler has included race detection so
it is NP-hard, so that means that Rust compiler will never know in race detection which of races are real race conditions(Read here in the following paper so that to understand it: https://www.sjsu.edu/people/robert.chun/courses/cs159/s3/Y.pdf), and, this is the reason why it is difficult to use a tool to find race conditions accurately, so then i think that C++ is still useful by using it with Threadsanatizer and Address sanatizer even if C++ is getting complex as i just said the following:
 
Also C++ has the following problem:
 
- C++ is a highly complex language. Learning and fully understanding C++
requires a huge learning effort. C++ code does not always do what one
would 'intuitively' expect from looking at the source code. At the
same time, the high complexity of C++ increases the probability of
compiler errors. C++ compiler writers are only humans, after all.
 
More of my philosophy about C++ and Rust and Microsoft and safety-critical systems..
 
I invite you to read the following from Microsoft about Rust programming language:
 
Microsoft: Rust Is the Industry's 'Best Chance' at Safe Systems Programming
 
https://thenewstack.io/microsoft-rust-is-the-industrys-best-chance-at-safe-systems-programming/
 
I think that the above article is not correct, since i think that
Rust is suited for safety-critical systems, so i think Rust is better
than C++ in the safety-critical systems, but i think that C++ will
still be useful with the Address sanitizer and ThreadSanatizer,
and read my below thoughts since i have just added something in them:
 
More of my philosophy about memory safety and inheritance in programming languages..
 
"Address sanitization is not a security feature, nor does it provide memory-safety: it's a debugging tool. Programmers already have tools to detect that the code they've written has memory problems, such as use-after-free or memory leaks. Valgrind is probably the best-known example. This gcc feature provides (some of) the same functionality: the only new thing is that it's integrated with the compiler, so it's easier to use.
 
You wouldn't have this feature turned on in production: it's for debugging only. You compile your tests with this flag, and automatically they detect memory errors that are triggered by the test. If your tests aren't sufficient to trigger the problem, then you still have the problem, and it'll still cause the same security flaws in production.
 
Rust's ownership model prevents these defects by making programs that contain such defects invalid: the compiler will not compile them. You don't have to worry about your tests not triggering the problem, because if the code compiles, there cannot be a problem.
 
The two features are for different sets of problems. One feature of address sanitization is to detect memory leaks (allocating memory and neglecting to free it later). Rust makes it harder to write memory leaks than in C or C++, but it's still possible (if you have circular references). Rust's ownership model prevents data races in sequential and multi-threaded situations (see below). Address sanitization doesn't aim to detect either of those cases. But you can use ThreadSanatizer"
 
And using just plain C#, it has better memory protection, since the GC and runtime make it impossible to leak, double-free, or access out-of-bounds. C# has unsafe blocks just like Rust does. Safe Rust is just as safe from memory safety problems as safe C#.
 
I think that a programming language has to provide "inheritance",
and the new Rust programming language doesn't provide it and i think that it is a deficiency in Rust, here is why:
 
As a software developer you have to become more efficient and productive. So you need to make sure the code you write is easily reusable and maintainable. And, among other things, this is what inheritance gives you - the ability to reuse without reinventing the wheel, as well as the ability to easily maintain your base object without having to perform maintenance on all similar objects.
 
 
Thank you,
Amine Moulay Ramdane.
Amine Moulay Ramdane <aminer68@gmail.com>: Nov 11 02:43PM -0800

Hello,
 
 
 
More of my philosophy about Python and Ruby and Go languages and more..
 
I am a white arab from Morocco, and i think i am smart since i have also
invented many scalable algorithms and algorithms..
 
I think i am smart since i am an inventor of many powerful scalable algorithms, so i am specialized in parallel programming and synchronization algorithms, and i say that Python and Ruby and Go
languages have a big problem, and it is that Python can use python interpreters in each process or in each thread so that to avoid to lock in a single interpreter, but this brings a big problem and it is that you have to transfer the data of the inside of a python object between threads or processes using a queue or shared memory etc. and it doesn't look like C++ or Delphi way where you can move a pointer or reference to an object not the data inside an object between threads so that to scale and be fast, so this way of moving data of inside an object of Python and Ruby is not scalable and is too slow and it looks like MPI messaging way, Go language has not this big problem but Go has the same problem as Rust since it doesn't provide us with OOP inheritance, read about it in my following thoughts:
 
More of my philosophy about the too much purism philosophy of Rust and more..
 
I think i am smart, and i think that Rust compiler and language is too much "purist", it looks like the too much purism of Haskell functional programming language, since i say that Rust doesn't provide us with OOP inheritance, but it is too much restrictive, and it is the deficiency of Rust, since inheritance has advantages and disadvantages, so we have to balance well and provide also with inheritance so that to be efficient, so i think that C++ and C# are better than Rust in this regard, and here is the advantages and disadvantages of OOP inheritance:
 
https://www.ianswer4u.com/2017/09/oops-inheritance-advantages.html
 
More of my philosophy about NP-hard problems and about Rust and C++..
 
I think i am smart and i have just quickly looked at Rust compiler and i think that since the Rust compiler has included race detection so
it is NP-hard, so that means that Rust compiler will never know in race detection which of races are real race conditions(Read here in the following paper so that to understand it: https://www.sjsu.edu/people/robert.chun/courses/cs159/s3/Y.pdf), and, this is the reason why it is difficult to use a tool to find race conditions accurately, so then i think that C++ is still useful by using it with Threadsanatizer and Address sanatizer even if C++ is getting complex as i just said the following:
 
Also C++ has the following problem:
 
- C++ is a highly complex language. Learning and fully understanding C++
requires a huge learning effort. C++ code does not always do what one
would 'intuitively' expect from looking at the source code. At the
same time, the high complexity of C++ increases the probability of
compiler errors. C++ compiler writers are only humans, after all.
 
More of my philosophy about C++ and Rust and Microsoft and safety-critical systems..
 
I invite you to read the following from Microsoft about Rust programming language:
 
Microsoft: Rust Is the Industry's 'Best Chance' at Safe Systems Programming
 
https://thenewstack.io/microsoft-rust-is-the-industrys-best-chance-at-safe-systems-programming/
 
I think that the above article is not correct, since i think that
Rust is suited for safety-critical systems, so i think Rust is better
than C++ in the safety-critical systems, but i think that C++ will
still be useful with the Address sanitizer and ThreadSanatizer,
and read my below thoughts since i have just added something in them:
 
More of my philosophy about memory safety and inheritance in programming languages..
 
"Address sanitization is not a security feature, nor does it provide memory-safety: it's a debugging tool. Programmers already have tools to detect that the code they've written has memory problems, such as use-after-free or memory leaks. Valgrind is probably the best-known example. This gcc feature provides (some of) the same functionality: the only new thing is that it's integrated with the compiler, so it's easier to use.
 
You wouldn't have this feature turned on in production: it's for debugging only. You compile your tests with this flag, and automatically they detect memory errors that are triggered by the test. If your tests aren't sufficient to trigger the problem, then you still have the problem, and it'll still cause the same security flaws in production.
 
Rust's ownership model prevents these defects by making programs that contain such defects invalid: the compiler will not compile them. You don't have to worry about your tests not triggering the problem, because if the code compiles, there cannot be a problem.
 
The two features are for different sets of problems. One feature of address sanitization is to detect memory leaks (allocating memory and neglecting to free it later). Rust makes it harder to write memory leaks than in C or C++, but it's still possible (if you have circular references). Rust's ownership model prevents data races in sequential and multi-threaded situations (see below). Address sanitization doesn't aim to detect either of those cases. But you can use ThreadSanatizer"
 
And using just plain C#, it has better memory protection, since the GC and runtime make it impossible to leak, double-free, or access out-of-bounds. C# has unsafe blocks just like Rust does. Safe Rust is just as safe from memory safety problems as safe C#.
 
I think that a programming language has to provide "inheritance",
and the new Rust programming language doesn't provide it and i think that it is a deficiency in Rust, here is why:
 
As a software developer you have to become more efficient and productive. So you need to make sure the code you write is easily reusable and maintainable. And, among other things, this is what inheritance gives you - the ability to reuse without reinventing the wheel, as well as the ability to easily maintain your base object without having to perform maintenance on all similar objects.
 
 
Thank you,
Amine Moulay Ramdane.
Amine Moulay Ramdane <aminer68@gmail.com>: Nov 11 02:00PM -0800

Hello,
 
 
More of my philosophy about the too much purism philosophy of Rust and more..
 
I am a white arab from Morocco, and i think i am smart since i have also
invented many scalable algorithms and algorithms..
 
I think i am smart, and i think that Rust compiler and language is too much "purist", it looks like the too much purism of Haskell functional programming language, since i say that Rust doesn't provide us with OOP inheritance, but it is too much restrictive, and it is the deficiency of Rust, since inheritance has advantages and disadvantages, so we have to balance well and provide also with inheritance so that to be efficient, so i think that C++ and C# are better than Rust in this regard, and here is the advantages and disadvantages of OOP inheritance, :
 
https://www.ianswer4u.com/2017/09/oops-inheritance-advantages.html
 
More of my philosophy about NP-hard problems and about Rust and C++..
 
I think i am smart and i have just quickly looked at Rust compiler and i think that since the Rust compiler has included race detection so
it is NP-hard, so that means that Rust compiler will never know in race detection which of races are real race conditions(Read here in the following paper so that to understand it: https://www.sjsu.edu/people/robert.chun/courses/cs159/s3/Y.pdf), and, this is the reason why it is difficult to use a tool to find race conditions accurately, so then i think that C++ is still useful by using it with Threadsanatizer and Address sanatizer even if C++ is getting complex as i just said the following:
 
Also C++ has the following problem:
 
- C++ is a highly complex language. Learning and fully understanding C++
requires a huge learning effort. C++ code does not always do what one
would 'intuitively' expect from looking at the source code. At the
same time, the high complexity of C++ increases the probability of
compiler errors. C++ compiler writers are only humans, after all.
 
More of my philosophy about C++ and Rust and Microsoft and safety-critical systems..
 
I invite you to read the following from Microsoft about Rust programming language:
 
Microsoft: Rust Is the Industry's 'Best Chance' at Safe Systems Programming
 
https://thenewstack.io/microsoft-rust-is-the-industrys-best-chance-at-safe-systems-programming/
 
I think that the above article is not correct, since i think that
Rust is suited for safety-critical systems, so i think Rust is better
than C++ in the safety-critical systems, but i think that C++ will
still be useful with the Address sanitizer and ThreadSanatizer,
and read my below thoughts since i have just added something in them:
 
More of my philosophy about memory safety and inheritance in programming languages..
 
"Address sanitization is not a security feature, nor does it provide memory-safety: it's a debugging tool. Programmers already have tools to detect that the code they've written has memory problems, such as use-after-free or memory leaks. Valgrind is probably the best-known example. This gcc feature provides (some of) the same functionality: the only new thing is that it's integrated with the compiler, so it's easier to use.
 
You wouldn't have this feature turned on in production: it's for debugging only. You compile your tests with this flag, and automatically they detect memory errors that are triggered by the test. If your tests aren't sufficient to trigger the problem, then you still have the problem, and it'll still cause the same security flaws in production.
 
Rust's ownership model prevents these defects by making programs that contain such defects invalid: the compiler will not compile them. You don't have to worry about your tests not triggering the problem, because if the code compiles, there cannot be a problem.
 
The two features are for different sets of problems. One feature of address sanitization is to detect memory leaks (allocating memory and neglecting to free it later). Rust makes it harder to write memory leaks than in C or C++, but it's still possible (if you have circular references). Rust's ownership model prevents data races in sequential and multi-threaded situations (see below). Address sanitization doesn't aim to detect either of those cases. But you can use ThreadSanatizer"
 
And using just plain C#, it has better memory protection, since the GC and runtime make it impossible to leak, double-free, or access out-of-bounds. C# has unsafe blocks just like Rust does. Safe Rust is just as safe from memory safety problems as safe C#.
 
I think that a programming language has to provide "inheritance",
and the new Rust programming language doesn't provide it and i think that it is a deficiency in Rust, here is why:
 
As a software developer you have to become more efficient and productive. So you need to make sure the code you write is easily reusable and maintainable. And, among other things, this is what inheritance gives you - the ability to reuse without reinventing the wheel, as well as the ability to easily maintain your base object without having to perform maintenance on all similar objects.
 
 
Thank you,
Amine Moulay Ramdane.
Amine Moulay Ramdane <aminer68@gmail.com>: Nov 11 01:27PM -0800

Hello,
 
 
 
More of my philosophy about NP-hard problems and about Rust and C++..
 
I am a white arab from Morocco, and i think i am smart since i have also
invented many scalable algorithms and algorithms..
 
I think i am smart and i have just quickly looked at Rust compiler and i think that since the Rust compiler has included race detection so
it is NP-hard, so that means that Rust compiler will never know in race detection which of races are real race conditions(Read here in the following paper so that to understand it: https://www.sjsu.edu/people/robert.chun/courses/cs159/s3/Y.pdf), and, this is the reason why it is difficult to use a tool to find race conditions accurately, so then i think that C++ is still useful by using it with Threadsanatizer and Address sanatizer even if C++ is getting complex as i just said the following:
 
Also C++ has the following problem:
 
- C++ is a highly complex language. Learning and fully understanding C++
requires a huge learning effort. C++ code does not always do what one
would 'intuitively' expect from looking at the source code. At the
same time, the high complexity of C++ increases the probability of
compiler errors. C++ compiler writers are only humans, after all.
 
More of my philosophy about C++ and Rust and Microsoft and safety-critical systems..
 
I invite you to read the following from Microsoft about Rust programming language:
 
Microsoft: Rust Is the Industry's 'Best Chance' at Safe Systems Programming
 
https://thenewstack.io/microsoft-rust-is-the-industrys-best-chance-at-safe-systems-programming/
 
I think that the above article is not correct, since i think that
Rust is suited for safety-critical systems, so i think Rust is better
than C++ in the safety-critical systems, but i think that C++ will
still be useful with the Address sanitizer and ThreadSanatizer,
and read my below thoughts since i have just added something in them:
 
More of my philosophy about memory safety and inheritance in programming languages..
 
"Address sanitization is not a security feature, nor does it provide memory-safety: it's a debugging tool. Programmers already have tools to detect that the code they've written has memory problems, such as use-after-free or memory leaks. Valgrind is probably the best-known example. This gcc feature provides (some of) the same functionality: the only new thing is that it's integrated with the compiler, so it's easier to use.
 
You wouldn't have this feature turned on in production: it's for debugging only. You compile your tests with this flag, and automatically they detect memory errors that are triggered by the test. If your tests aren't sufficient to trigger the problem, then you still have the problem, and it'll still cause the same security flaws in production.
 
Rust's ownership model prevents these defects by making programs that contain such defects invalid: the compiler will not compile them. You don't have to worry about your tests not triggering the problem, because if the code compiles, there cannot be a problem.
 
The two features are for different sets of problems. One feature of address sanitization is to detect memory leaks (allocating memory and neglecting to free it later). Rust makes it harder to write memory leaks than in C or C++, but it's still possible (if you have circular references). Rust's ownership model prevents data races in sequential and multi-threaded situations (see below). Address sanitization doesn't aim to detect either of those cases. But you can use ThreadSanatizer"
 
And using just plain C#, it has better memory protection, since the GC and runtime make it impossible to leak, double-free, or access out-of-bounds. C# has unsafe blocks just like Rust does. Safe Rust is just as safe from memory safety problems as safe C#.
 
I think that a programming language has to provide "inheritance",
and the new Rust programming language doesn't provide it and i think that it is a deficiency in Rust, here is why:
 
As a software developer you have to become more efficient and productive. So you need to make sure the code you write is easily reusable and maintainable. And, among other things, this is what inheritance gives you - the ability to reuse without reinventing the wheel, as well as the ability to easily maintain your base object without having to perform maintenance on all similar objects.
 
 
Thank you,
Amine Moulay Ramdane.
Amine Moulay Ramdane <aminer68@gmail.com>: Nov 11 01:01PM -0800

Hello,
 
 
More precision of my philosophy about safety-critical systems and C++ and Rust programming languages..
 
I am a white arab from Morocco, and i think i am smart since i have also
invented many scalable algorithms and algorithms..
 
Here is more proof that Rust has to be used in safety-critical systems:
 
"Safe Rust guarantees an absence of data races, which are defined as: two or more threads concurrently accessing a location of memory."
 
So i think that detecting races with the other ways than the one of Rust are NP-hard and they do report false alarm in that many of reporting race conditions are not real ones, so C++ has not to be
used in safety-critical systems.
 
And read my previous thoughts:
 
I think i am smart, and i will say that C++ has not to be used
in safety-critical systems, and we have to use Rust in safety-critical
systems because it is suited for safety-critical systems and
safety-critical systems are those systems whose failure could result in loss of life, significant property damage, or damage to the environment, here is why:
 
Difficulties in race Detection
 
"When using multiple semaphores in static race detection is NP-hard
[9], which means it is hard to find an efficient solution. If the
synchronization mechanism is weaker than semaphores, an exact
and efficient algorithm does exist [10]. Otherwise, only heuristic
algorithms are available [3, 5]. Because heuristic algorithms will
only report potential race conditions, which means there may be
false alarm in that many of reporting race conditions are not real
ones. However, since detecting race condition is NP-hard
problem, one will never know which of them are real race
conditions. And, this is the reason why it is difficult to use a tool
to find race conditions accurately."
 
Read more here on the following paper so that to notice it:
 
https://www.sjsu.edu/people/robert.chun/courses/cs159/s3/Y.pdf
 
Also C++ has the following problems:
 
- C++ is a highly complex language. Learning and fully understanding C++
requires a huge learning effort. C++ code does not always do what one
would 'intuitively' expect from looking at the source code. At the
same time, the high complexity of C++ increases the probability of
compiler errors. C++ compiler writers are only humans, after all.
 
• While being a strongly-typed language, C++ leaves too many holes to
circumvent the type system, deliberately or unintentionally.
 
More of my philosophy about C++ and Rust and Microsoft and safety-critical systems..
 
I invite you to read the following from Microsoft about Rust programming language:
 
Microsoft: Rust Is the Industry's 'Best Chance' at Safe Systems Programming
 
https://thenewstack.io/microsoft-rust-is-the-industrys-best-chance-at-safe-systems-programming/
 
I think that the above article is not correct, since i think that
Rust is suited for safety-critical systems, so i think Rust is better
than C++ in the safety-critical systems, but i think that C++ will
still be useful with the Address sanitizer and ThreadSanatizer,
and read my below thoughts since i have just added something in them:
 
More of my philosophy about memory safety and inheritance in programming languages..
 
"Address sanitization is not a security feature, nor does it provide memory-safety: it's a debugging tool. Programmers already have tools to detect that the code they've written has memory problems, such as use-after-free or memory leaks. Valgrind is probably the best-known example. This gcc feature provides (some of) the same functionality: the only new thing is that it's integrated with the compiler, so it's easier to use.
 
You wouldn't have this feature turned on in production: it's for debugging only. You compile your tests with this flag, and automatically they detect memory errors that are triggered by the test. If your tests aren't sufficient to trigger the problem, then you still have the problem, and it'll still cause the same security flaws in production.
 
Rust's ownership model prevents these defects by making programs that contain such defects invalid: the compiler will not compile them. You don't have to worry about your tests not triggering the problem, because if the code compiles, there cannot be a problem.
 
The two features are for different sets of problems. One feature of address sanitization is to detect memory leaks (allocating memory and neglecting to free it later). Rust makes it harder to write memory leaks than in C or C++, but it's still possible (if you have circular references). Rust's ownership model prevents data races in sequential and multi-threaded situations (see below). Address sanitization doesn't aim to detect either of those cases. But you can use ThreadSanatizer"
 
And using just plain C#, it has better memory protection, since the GC and runtime make it impossible to leak, double-free, or access out-of-bounds. C# has unsafe blocks just like Rust does. Safe Rust is just as safe from memory safety problems as safe C#.
 
I think that a programming language has to provide "inheritance",
and the new Rust programming language doesn't provide it and i think that it is a deficiency in Rust, here is why:
 
As a software developer you have to become more efficient and productive. So you need to make sure the code you write is easily reusable and maintainable. And, among other things, this is what inheritance gives you - the ability to reuse without reinventing the wheel, as well as the ability to easily maintain your base object without having to perform maintenance on all similar objects.
 
 
Thank you,
Amine Moulay Ramdane.
Amine Moulay Ramdane <aminer68@gmail.com>: Nov 11 12:48PM -0800

Hello,
 
 
More of my philosophy about safety-critical systems and C++ and Rust programming languages..
 
I am a white arab from Morocco, and i think i am smart since i have also
invented many scalable algorithms and algorithms..
 
I think i am smart, and i will say that C++ has not to be used
in safety-critical systems, and we have to use Rust in safety-critical
systems because it is suited for safety-critical systems and
safety-critical systems are those systems whose failure could result in loss of life, significant property damage, or damage to the environment, here is why:
 
Difficulties in Detection
 
"When using multiple semaphores in static detection is NP-hard
[9], which means it is hard to find an efficient solution. If the
synchronization mechanism is weaker than semaphores, an exact
and efficient algorithm does exist [10]. Otherwise, only heuristic
algorithms are available [3, 5]. Because heuristic algorithms will
only report potential race conditions, which means there may be
false alarm in that many of reporting race conditions are not real
ones. However, since detecting race condition is NP-hard
problem, one will never know which of them are real race
conditions. And, this is the reason why it is difficult to use a tool
to find race conditions accurately."
 
Read more here on the following paper so that to notice it:
 
https://www.sjsu.edu/people/robert.chun/courses/cs159/s3/Y.pdf
 
Also C++ has the following problems:
 
- C++ is a highly complex language. Learning and fully understanding C++
requires a huge learning effort. C++ code does not always do what one
would 'intuitively' expect from looking at the source code. At the
same time, the high complexity of C++ increases the probability of
compiler errors. C++ compiler writers are only humans, after all.
 
• While being a strongly-typed language, C++ leaves too many holes to
circumvent the type system, deliberately or unintentionally.
 
More of my philosophy about C++ and Rust and Microsoft and safety-critical systems..
 
I invite you to read the following from Microsoft about Rust programming language:
 
Microsoft: Rust Is the Industry's 'Best Chance' at Safe Systems Programming
 
https://thenewstack.io/microsoft-rust-is-the-industrys-best-chance-at-safe-systems-programming/
 
I think that the above article is not correct, since i think that
Rust is suited for safety-critical systems, so i think Rust is better
than C++ in the safety-critical systems, but i think that C++ will
still be useful with the Address sanitizer and ThreadSanatizer,
and read my below thoughts since i have just added something in them:
 
More of my philosophy about memory safety and inheritance in programming languages..
 
"Address sanitization is not a security feature, nor does it provide memory-safety: it's a debugging tool. Programmers already have tools to detect that the code they've written has memory problems, such as use-after-free or memory leaks. Valgrind is probably the best-known example. This gcc feature provides (some of) the same functionality: the only new thing is that it's integrated with the compiler, so it's easier to use.
 
You wouldn't have this feature turned on in production: it's for debugging only. You compile your tests with this flag, and automatically they detect memory errors that are triggered by the test. If your tests aren't sufficient to trigger the problem, then you still have the problem, and it'll still cause the same security flaws in production.
 
Rust's ownership model prevents these defects by making programs that contain such defects invalid: the compiler will not compile them. You don't have to worry about your tests not triggering the problem, because if the code compiles, there cannot be a problem.
 
The two features are for different sets of problems. One feature of address sanitization is to detect memory leaks (allocating memory and neglecting to free it later). Rust makes it harder to write memory leaks than in C or C++, but it's still possible (if you have circular references). Rust's ownership model prevents data races in sequential and multi-threaded situations (see below). Address sanitization doesn't aim to detect either of those cases. But you can use ThreadSanatizer"
 
And using just plain C#, it has better memory protection, since the GC and runtime make it impossible to leak, double-free, or access out-of-bounds. C# has unsafe blocks just like Rust does. Safe Rust is just as safe from memory safety problems as safe C#.
 
I think that a programming language has to provide "inheritance",
and the new Rust programming language doesn't provide it and i think that it is a deficiency in Rust, here is why:
 
As a software developer you have to become more efficient and productive. So you need to make sure the code you write is easily reusable and maintainable. And, among other things, this is what inheritance gives you - the ability to reuse without reinventing the wheel, as well as the ability to easily maintain your base object without having to perform maintenance on all similar objects.
 
 
Thank you,
Amine Moulay Ramdane.
Amine Moulay Ramdane <aminer68@gmail.com>: Nov 11 09:10AM -0800

Hello,
 
 
More of my philosophy about C++ and Rust and Microsoft and safety-critical systems..
 
I am a white arab from Morocco, and i think i am smart since i have also
invented many scalable algorithms and algorithms..
 
I invite you to read the following from Microsoft about Rust programming language:
 
Microsoft: Rust Is the Industry's 'Best Chance' at Safe Systems Programming
 
https://thenewstack.io/microsoft-rust-is-the-industrys-best-chance-at-safe-systems-programming/
 
I think that the above article is not correct, since i think that
Rust is suited for safety-critical systems, so i think Rust is better
than C++ in the safety-critical systems, but i think that C++ will
still be useful with the Address sanitization and ThreadSanatizer,
and read my below thoughts since i have just added something in them:
 
More of my philosophy about memory safety and inheritance in programming languages..
 
"Address sanitization is not a security feature, nor does it provide memory-safety: it's a debugging tool. Programmers already have tools to detect that the code they've written has memory problems, such as use-after-free or memory leaks. Valgrind is probably the best-known example. This gcc feature provides (some of) the same functionality: the only new thing is that it's integrated with the compiler, so it's easier to use.
 
You wouldn't have this feature turned on in production: it's for debugging only. You compile your tests with this flag, and automatically they detect memory errors that are triggered by the test. If your tests aren't sufficient to trigger the problem, then you still have the problem, and it'll still cause the same security flaws in production.
 
Rust's ownership model prevents these defects by making programs that contain such defects invalid: the compiler will not compile them. You don't have to worry about your tests not triggering the problem, because if the code compiles, there cannot be a problem.
 
The two features are for different sets of problems. One feature of address sanitization is to detect memory leaks (allocating memory and neglecting to free it later). Rust makes it harder to write memory leaks than in C or C++, but it's still possible (if you have circular references). Rust's ownership model prevents data races in sequential and multi-threaded situations (see below). Address sanitization doesn't aim to detect either of those cases. But you can use ThreadSanatizer"
 
And using just plain C#, it has better memory protection, since the GC and runtime make it impossible to leak, double-free, or access out-of-bounds. C# has unsafe blocks just like Rust does. Safe Rust is just as safe from memory safety problems as safe C#.
 
I think that a programming language has to provide "inheritance",
and the new Rust programming language doesn't provide it and i think that it is a deficiency in Rust, here is why:
 
As a software developer you have to become more efficient and productive. So you need to make sure the code you write is easily reusable and maintainable. And, among other things, this is what inheritance gives you - the ability to reuse without reinventing the wheel, as well as the ability to easily maintain your base object without having to perform maintenance on all similar objects.
 
 
Thank you,
Amine Moulay Ramdane.
Amine Moulay Ramdane <aminer68@gmail.com>: Nov 11 08:51AM -0800

Hello,
 
 
More of my philosophy about memory safety and inheritance in programming languages..
 
I am a white arab from Morocco, and i think i am smart since i have also
invented many scalable algorithms and algorithms..
 
"Address sanitization is not a security feature, nor does it provide memory-safety: it's a debugging tool. Programmers already have tools to detect that the code they've written has memory problems, such as use-after-free or memory leaks. Valgrind is probably the best-known example. This gcc feature provides (some of) the same functionality: the only new thing is that it's integrated with the compiler, so it's easier to use.
 
You wouldn't have this feature turned on in production: it's for debugging only. You compile your tests with this flag, and automatically they detect memory errors that are triggered by the test. If your tests aren't sufficient to trigger the problem, then you still have the problem, and it'll still cause the same security flaws in production.
 
Rust's ownership model prevents these defects by making programs that contain such defects invalid: the compiler will not compile them. You don't have to worry about your tests not triggering the problem, because if the code compiles, there cannot be a problem.
 
The two features are for different sets of problems. One feature of address sanitization is to detect memory leaks (allocating memory and neglecting to free it later). Rust makes it harder to write memory leaks than in C or C++, but it's still possible (if you have circular references). Rust's ownership model prevents data races in sequential and multi-threaded situations (see below). Address sanitization doesn't aim to detect either of those cases."
 
And using just plain C#, it has better memory protection, since the GC and runtime make it impossible to leak, double-free, or access out-of-bounds. C# has unsafe blocks just like Rust does. Safe Rust is just as safe from memory safety problems as safe C#.
 
I think that a programming language has to provide "inheritance",
and the new Rust programming language doesn't provide it and i think that it is a deficiency in Rust, here is why:
 
As a software developer you have to become more efficient and productive. So you need to make sure the code you write is easily reusable and maintainable. And, among other things, this is what inheritance gives you - the ability to reuse without reinventing the wheel, as well as the ability to easily maintain your base object without having to perform maintenance on all similar objects.
 
 
Thank you,
Amine Moulay Ramdane.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.programming.threads+unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)