More of my philosophy about how to be the good philosophy in architecti
From Amine Moulay Ramdane@21:1/5 to All on Thu Nov 11 19:49:33 2021
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:
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:
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
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
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.