Topic: [neㄘcash, ᨇcash, net⚷eys, or viᖚes?] Name AnonyMint's vapor coin? - page 13. (Read 95279 times)

The reason it became popular is because of what I wrote before bolded, underlined above for emphasis. The reason C++ become popular is because it promised those benefits plus OOP.

I know because I coded WordUp in assembly then switched to C by version 3.0 and was amazed at the increase in my productivity. And the delayed switch away from assembly afair revolved around which good compilers were available for the Atari ST. Then for CoolPage I chose C++ for precisely that underlined reason and the integration with MSVC++ (Visual Studio) Model View framework for a Windows GUI application.

C was adopted for a use case for which it is not the best suited, because there was nothing better around and thus it was the best suited at that time. Language technology was very immature at that time. There was more out there as research which hadn't yet been absorbed into mainstream languages and experience.

We are in a different era now where we have a lot of experience with the different programming paradigms and programming language design is an art now of being able to distil all the existing technology and experience in the field to an ideal design.


Apparently you did not read my implied point that the mass market is not the only possible target market a language is designed for. As I wrote before, Haskell was design for an academic, math geek market. It is very popular and extremely successful within that tiny market.

It will be very difficult for you to find an Ivy league computer science graduate who hasn't learned Haskell and who doesn't wish to use it on some projects. That is what is called mindshare. Any language hoping to be the future of multi-paradigm has to capture some of that mindshare. Which Scala attempted to do, but it unfortuately bit down too hard on that anti-pattern subclassing.


And crashing my browser and transcoding hell of a non-unified typesystem which is headed to a clusterfuck. I have recognized how the Internet browser "App" will die. I will finally get my "I told you so" (in a positive way) on that totalitarian Ian Hickson and that rigor mortis of totalitarianism at the W3C.


Clearly Sun Microsystems was trying to disrupt Microsoft's challenge in server computing and so Java was designed to co-opt Microsoft Windows on the general client so Microsoft couldn't dictate their servers on everyone. What Sun didn't anticipate was Linus Torvalds and Tim Berners-Lee.


Windows is a dead man walking. Cross-platform, open source .Net (forgot the name) isn't gaining momentum. One good language to succeed the current crop, will put the final nail in the coffin.


It was an attempt to defeat Sun's strategy of co-opting the client. And it helped to do that, but the more salient disruption came from the Internet browser, Linux, and LAMP.


I think it is much more deterministic as explained above. The programming language designer really needs to understand his target market and also anticipate changes in the market from competing technologies and paradigm shifts.


The challenge we've had since graduating from C, has been to find a good language for expressing higher-level semantics. As you lamented upthread, all attempts have improved some aspects while worsening others. Python's main goal was to be very in tune with readability of the code and the semantics the programmer wants to express.

Thus it became a quick way to code with a high degree of expression. Even Eric Raymond raves about that aspect of Python.

But the downside of Python is the corner cases because afaik the type system is not sound and unified.

So it works for small programs but for large scale work it can become a clusterfuck of corner cases that are difficult to optimize and work out.

So I am arguing that Python was not designed solely for scripting but also for programmer ease-of-expression and readability and this has a natural application for some simpler applications, i.e. that aren't just scripts. This seems to have been a conscious design consideration.


Because that is what programmers were taught. So that is what they knew how to use. That doesn't apply anymore. My first programming was in BASIC on an Apple II because that was all that was available to me in 1983. I messed around some years before that with a TRS-80 but not programming (because I didn't know anyone who owned one and I could only play around with it for a few minutes at a time in the Radio Shack store). My first exposure to programming was reading the Radio Shack book on microprocessor design and programming when I was 13 in 1978 (afair due to being relegated to my bed for some days due to a high ankle sprain from football). Perhaps that is why I can program in my head, because I had to program only in my head from 1978 to 1983.

I must mea culpa that around that age my mother caught me (as we were leaving the mall) having stolen about $300 of electronic goods from inside the locked glass display case of Radio Shack. I had reached in when the clerk looked the other direction. (Later in teenage hood I became an employee of Radio Shack but I didn't steal). I had become quite the magician and I was eager to have virtually everything in Radio Shack to play with or take apart for parts (for my various projects and experiments in my room). She made me return everything to the store, but couldn't afford to buy any of it for me apparently. I think we were on food stamps and we were living in poverty stricken neighborhoods for example in Baton Rouge where my sister and I were the only non-negro kids in the entire elementary school. Then my mom got angry when my sister had a black boyfriend in high school.  


Agreed.

C was most certainly not designed as a language for all sorts of business applications, Windows desktop applications (of course such a thing did not exist at the time it was designed, but conceptually it was not intended for that), etc. as was most of its usage when it became the most popular language.


Has never really been widely used for anything (at least not yet) so irrelevant to my point.


And yet it is widely used for this (and growing rapidly for all sorts of uses), supporting my point.


Good counterexample.


Somewhat. It was designed for write-once run everywhere on the web (originally interactive TV and maybe PDAs since the web didn't quite exist yet, but the same principle). None of the business software use case where it became dominant was remotely part of the original purpose (nor do these business software deployments commonly even make use of code that is portable and "runs everywhere").


C# is not dead, it is still quite popular for Windows development (and some cross-platform development). But as you say it was designed to copy Java after Java was already successful so in that sense it is a counterexample, but a "cheat" (if you copy something that has already organically found a strong niche, chances are your copy will serve a similar niche).


Sometimes, but often not. It is of course relevant, it just doesn't mean that what it will end up being used for (if anything) is the same as what it was designed to be used for.

Further examples:

Python: designed for scripting, but is now the most used (I think) language for scientific and math computing (replacing fortran). Of course it is used for other things too, but most are also far removed from scripting.

BASIC: Designed for teaching, but became widely used for business software on minicomputers, and then very widely used for all sorts of things on PC.

COBOL and FORTRAN: counterexamples; used as designed.

Perl: had a bit of a golden age beyond its scripting purpose, but mostly seems a counterexample, often used as intended

Ruby: Not really sure about this one. Seems to be getting used for quite a few things now, mostly web development of course, but some others. This one is mostly off my radar so I don't really know the history.

I sort of disagree with you at least in terms of the exemplary examples of greatest success if not entirely disagree.

C was definitely designed for low-level operating systems programming and it was the most popular language ever bar none because it provided just the necessary abstraction of assembly needed for portability and no more. For example, it didn't try to make pointers safe or other structure.

Haskell was designed to express math in programming tersely without extraneous syntax and thus the very high priority placed on global type inference, which is why they haven't implemented first-class disjunctions (aka unions) that happens to be the one feature missing from Haskell that makes it entirely unsuitable for my goals. Haskell forsaked practical issues such as the non-determinism of lazy evaluation and its impact on for example debugging (e.g. finding a memory leak). Haskell is by far the most successful language for its target use case.

Javascript was designed to be lightweight for the browser because you don't need a complex type system for such short scripts, and thus you can edit it with a text editor and don't even need a debugger (alert statements worked well enough). Javascript is the most popular language for web page scripts. But the problem is web pages changed to Apps and Javascript was ill designed for this use case. Transcoding to Javascript is a monkey patch that must die because it is a non-unified type system!

PHP was designed to render LAMP web pages on the server and became the most popular language for this use case, except the problem is server Apps need to scale and PHP can't sale, thus Node.js and Java, etc..

Java was designed write once, run everywhere, and it gained great popularity for this use case, but the problem was Java has some stupid design decisions which made it unsuitable as the language to use every where for applications.

C# was designed to be a better Java to run on Microsoft .Net and thus it died with .Net.

C++ was designed to be a marriage of C and OOP and it is dying with the realization that OOP (subclassing) is an anti-pattern and because C++ did not incorporate any elegance from functional programming languages.

All the other examples of languages had muddled use-cases for which they were designed and thus were not very popular.

So I think it is definitely relevant what a language was designed for.

That often does not matter.

Java was designed to display games and animated advertisements on web pages. It hardly ever did that and instead became the dominant language for enterprise software, a huge pivot.

Such attempts at central planning rarely succeed. (Most languages designed to be ____ end up being used for nothing at all, of course.)

Build something interesting and let it free to find its place.


Nothing wrong with that, but most people just reference named releases.

C++ is a painful, fugly marriage of high-level and low-level, which loses the elegance of high-level semantics. I think it hasn't died because no other language could do C low-level combined generics (templates). Perhaps something like Rust (perhaps with my ideas of extensions to Rust) will be the death blow to C++ and also Java/Scala/C# (probably Python, Ruby, PHP, and Node.js as well). And also perhaps Javascript...


Which appears to me to be a great tragedy of inertia (it was originally designed to be for short inline scripts for simple DHTML on web pages ... then Google Maps and webmail clients arrived...). I am in the process of attempting to prove this.

I believe there is no reason we can't marry high-level, low-level, static typing, and fast JIT compilation and still be able to write programs with a text editor without tooling (for as long as tooling is in the debugger in the "browser").

This low degrees-of-freedom crap of being forced to fight with bloated IDEs such as Eclipse needs to be reverted.

This dilemma of needing to place the modules of your project all in the same Git repository needs to be replaced with a good package manager which knows how to build from specific changesets in orthogonal repositories, where the relevant changeset hashes from the referenced module are accumulated in this referencing module so that merging DVCS remains sane. In other words, the package manager (module system) needs to be DVCS aware.

@AlexGR I'm still puzzled at what the hell you are going off about. It seems almost entirely strawman to me.

Very few new applications are being written in C afaik (and I do have somewhat of an idea). It is only being done by a few fetishists such as jl777.

Most development now is being done in higher level languages which are exactly what you just proposed: a small (maybe) speed concession for greater expressiveness and friendliness (though that word is quite vague) and in some sense (though not in others) simpler than C.  The odd exception here is C++. Not surprisingly C++ is very much on the way out.

The language that is eating (almost) everything is JavaScript, so if you want to comment on the current state of languages I would start there, not with something that is relegated to being largely a legacy tool (other than low level). Of course other languages are being used too, so they're also worthy of comment, but ignoring JavaScript and fixating on C is insane.

What I'm trying to say is something to that effect: We have to differentiate between
a) C as a language in terms of what we write as source (the input so to speak)
and
b) the efficiency of binaries that come out from the compiler.

The (b) component changes throughout time and is not constant (I'm talking about the ratio of performance efficiency versus the hardware available at each given moment).

When C was created back in the 70's, every byte and every clock cycle were extremely important. If you wanted to write an operating system, you wouldn't do that with a new language if it was like n times slower (in binary execution) than writing it in assembly. So the implementation, in order to stand on merit, *HAD* to compile efficient code. It was a requirement because inefficiency was simply not an option. 1970 processing power was minimal. You couldn't waste that.

Fast forward 45 years later. We have similar syntax and stuff in C but we are now leaving a lot of performance on the table. We are practically unable to produce speed-critical programs (binaries) from C alone. A hello world program might be of a similar speed with a 1980's hello world, but that's not the issue anymore... Processors now have multiple cores, hyperthreading, multiple math coprocessors, multiple SIMD units, etc. Are we properly taking advantage of these? No.

Imagine trying to create a new coin with a new hash or hash-variant that is written in C. You can almost be certain that someone else is doing at least 2-3-5x in speed by asm optimizations and you are thus exposed to various economic and mining attack vectors. Why? Because the compilers can't produce efficient vectorized code that properly uses the embedded SIMD instruction sets. Someone has to do it by hand. That's a failure right there.

I'm not really proposing to go assembly all the way. No. That's not an option in our era. What we need is far better compilers but I don't think we are going to get them - at least not from human programmers.

So, I'm actually saying the opposite, that since C (which is dependent upon the compilers in order to be "fast") is now fucked up by the inefficient compilers in terms of properly exploiting modern hardware (and not 3-4 decades old hardware - which it was good at), and is also "abrasive" in terms of user-interfacing / mentality of how it is syntaxed/constructed, perhaps using friendlier, simpler and more functional languages while making speed concessions may not be such a disaster, especially for non-speed critical apps.

My presumption was incorrect. Apparently Rust outputs to the LLVM:

https://play.rust-lang.org/?code=fn main() {
    println!("Hello, world!");
}

AlexGR, it is possible that what you were trying to say is that C is too low-level to be able to reduce higher-level semantic driven bloat and that C doesn't not produce the most optimum assembly code, so might as well use assembly for low-level and a higher-level language otherwise.

In that case, I would still disagree that we should use assembly in every case where we need lower-level expression instead of a low-level language that is higher-level than assembly. Every situation is different and we should use the semantics that best fit the scenario. I would agree with the point of using higher-level languages for scenarios that require higher-level semantics as the main priority.

I would also agree that the higher-level languages we have today do lead to bloat because they are all lacking what I have explained upthread. That is why I am and have been for the past 6 years contemplating designing my own programming language. I also would like to unify low-level and higher-level capabilities in the same language. Rust has advanced the art, but is not entirely what I want.

You are again talking half-truths with half-lies.

If one were to write an entire application in assembly, they would miss high-level semantic optimizations.

You erroneously think the only appropriate tool for the job of programming is a low-level machine code semantics. You don't seem to grasp that we build higher-level semantics, so we can express (and reason about) what we need to. Example, if I really want to iterate List, then I want to say List.map() and not a few hundred lines of assembly code. The higher-level semantics of how I can employ category theory functors on that List impact more my optimization than recoding in assembly language. For example, in a non-lazy, inductive language (e.g. where Top is at that top of all types and not Haskell where Bottom populates all types) then I will need to manually do deforestation when chaining functors which terminate in the middle of the list.


While it is true that for any given higher-level program code, that hand coding it in assembly can typically make it a few percentage faster and leaner (and in the odd case a significant percentage), this belies the reality that programming code is not static. It is being studied by others and improved. So that hand-coded assembly would have to be scrapped and rewritten each times edits are made to the higher-level program code, which is too much tsuris and too much of a waste of expert man-hours in most scenarios. If we didn't code in the higher-level programming language, then we couldn't express and optimize higher-level semantics.

Your comprehension of the art of programming is simpleton and incorrect.


Why are you offended or surprised that double-wide integers consume double the space, and that a newer platform is less optimized   Progress is not free.

A Model T had resource-free airconditioning. I prefer the modern variant, especially here in the tropics.


Yes and no. That is why they designed Rust to help them get better optimization and expression over the higher-level semantics of their program.


YouTube seems to be a culprit. And other Flash videos such as NBA.com. Other times it is a bad script.



Mozilla Firefox is ostensibly not sufficiently modularly designed to have all bloat associated with supporting rich media and scripting disappear when you disable certain plugins and features.

The is a higher-level semantics problem which belies your erroneous conceptualization of everything needing to be optimized in assembly code.


The solution is not to go backwards to lower-level semantics but to go even higher-level semantic models that C can't express, thus can't optimize.

Your conceptualization of the cause of the bloat and its solution is incorrect.


C is more low-level and less structured than Pascal, which enables it to do more tricks (which can also be unsafe). Also you may prefer verbose words instead of symbols such as curly braces. Also you may prefer that Pascal makes explicit in the syntax what is implicit in the mind of the C programmer. You would probably hate Haskell with a deep disgust. I actually enjoy loading it all in my head and visualizing it as if I am the compiler.

Note I have argued that Haskell's use of spaces instead of parenthesis to group function inputs at the use-site, means the programmer has to keep the definition site declaration in his head in order to read the code. Thus I have argued parenthesis are superior for readability. There are counter arguments and especially parenthesis can't group arguments when the function name is used in the infix position.

Note I got a very high grade in both Pascal and Fortran, so it isn't like a skill in C is mutually exclusive with a skill in those other more structured languages, although that I'm not a counter-example to the converse.

It's not propaganda. It's, let's say, the mainstream practice. Yes, there are things which are constantly getting optimized more and more, but every time I see serious optimizations needed, they all have to go down to asm. Why? Because c, as a source, is just a textfile. The actual power of the language is the compiler. And the compilers we have suck badly - even the corporate ones like Intel's icc - which is better in vectorizing and often a source for ripping off its generated code, but still.


With firefox I don't have flash, I have ipc container off, I block javascript (and the pages look like half-downloaded shit) and still the bloat is there.


My problem is with unnecessary complexity. In any case, the problem is not to dumb down programming languages. I explicitly said that you can let the language be tunable to anything the programmer designs but you can also make it work out of the box with concessions in terms of speed.

In a way, even C is acting that way because where it is slow you have to go down to asm. But that's 2 layers of complexity instead of 1 layer of simplicity and 1 of elevated complexity.


Kurzweil's problem is not his "small" opinions on subject A or B. It's his overall problematic vision of what humanity should be, or, to put it better, what humanity should turn into (transhumanism / human+machine integration). This is fucked up.

That is the propaganda but it isn't true. There are many scenarios where optimization is still critical, e.g. block chain data structures, JIT compilation so that web pages (or in my goal Apps) can start immediately upon download of device-independent code, cryptography algorithms such as the C on my github.


We almost never should ignore optimization for mobile Apps because otherwise it consumes the battery faster.

You want to wish away the art of programming and have it replaced by an algorithm, but I am sorry to tell you that you and Ray Kurzweil have the wrong conceptualization of knowledge (<--- I wrote that "Information Is Alive!").


There are still people in this world who can't afford 32 GB of RAM and if we forsake optimization, then a power user such as myself with 200 tabs open on my browser will need 256 GB of RAM. A typical mobile phone only has 1 GB.

I have to daily reboot my Linux box because I only have 16 GM of RAM and the garbage collector of the browser totally freezes my machine.


I am thinking you are just spouting off without actually knowing the technical facts. The reason is ostensibly because for example Javacript forces the use of garbage collection, which is an example of an algorithm which is not as accurate and performant as expert human designed memory deallocation. And because memory allocation is a hard problem, which is ostensibly why Mozilla funded the creation of Rust with its new statically compiled memory deallocation model to aid the human with compiler enforced rules.


Man haven't you noticed that the capabilities of webpages have increased. You had no DHTML then thus nearly no Javascript or Flash on the web page.

Above you argued that bloat doesn't matter and now you argue it does.  


Because the 100 were populated by more natural hackers (e.g. as a kid I took apart all my toys instead of playing with them) who discovered the obscure field because of their interest. The 1000 was probably advertized to people who shouldn't be pursuing programming, which ostensibly includes yourself.


Absolutely not. Knowledge is serendipitiously and accretively formed.

If you have the natural inclination to some field, then you can absorb the existing art and add to it serendipitiously and accretively. If you don't have the natural inclination, no amount of pounding books on your head will result in any traction.


Agreed you do not appear to have the natural inclination for C. But C is not bullshit. It was a very elegant portable abstraction of assembly that radically increased productivity over assembly.


What you are describing is that fact that C abstracts assembly language. You must lift you mind into a new machine model which is the semantics of C. The semantics are no less rational than assembly.

You apparently don't have an abstract mind. This was also evident by our recent debate about ethics, wherein you didn't conceive of objective ethics.

You probably are not very good at abstract math as well.

Your talent probably lies else where. I don't know why you try to force on yourself something that your mind is not structured to do well.


I strongly suggest you stop blaming your handicaps and talents on others:


You are not an expert programmer, ostensibly never will be, and should not be commenting on the future of programming languages. Period. Sorry. Programming will never be reduced to an art form for people who hate abstractions, details, and complexity.

Designing an excellent programming language is one of the most expert of all challenges in computer science.


Sorry never! You and Ray Kurzweil are wrong and always will be. Sorry, but frankly. I don't care if you disagree, because you don't have the capacity to understand.

The time when programmers tried to save every possible byte to increase performance is long gone because the bytes and the clock cycles aren't that scarce anymore. So we are in the age of routinely forsaking performance just because we can, and we do so despite using - theoretically, very efficient languages. The bloat is even compensating for hardware increases - and even abuses the hardware more than previous generations of software.

You see some programs like, say, Firefox, Chrome, etc etc, that should supposedly be very efficient as they are written in C (or C++), right? Yet they are bloated like hell, consuming gigabytes of ram for the lolz. And while some features, like sandboxing processes so that the browser won't crash, do make sense in terms of ram waste, the rest of the functionality doesn't make any sense in terms of wasting resources. I remember in the win2k days, I could open over 40-50 netscape windows without any issue whatsoever.

Same bloat situation for my linux desktop (KDE Plasma)... It's a piece of bloated junk. KDE 4 was far better. Same for windows... Win7 wants 1gb ram just to run. 1gb? For what? The OS? Are they even thinking when they make the specs?

Same for our cryptocurrency wallets. Slow as hell and very resource-hungry.

In any case, if better languages don't exist, the code that should be written won't be written because there will be a lack of developers to do so. Applications that will never be written won't run that fast... they won't even exist!

Now that's a prime corporate problem. "We need able coders to develop X, Y, Z". Yeah well, there are only so many of them and the corporations won't be able to hire as many as they want. So...

In the 80's they thought if they train more coders they'll solve the problem. In the 90's they discovered that coders are born, not educated - which was very counterintuitive. How can you have a class of 100 people and 10 good coders and then have a class of 1000 people and 20 good coders instead of 100? Why aren't they increasing linearly but rather the number of good coders seem to be related to some kind of "talent" like ....music? Well, that's the million dollar question, isn't it?

I searched for that answer myself. I'm of the opinion that knowledge is teachable so it didn't make any sense. My mind couldn't grasp why I was rejecting C when I could write asm. Well, after some research I found the answer to the problem. The whole structure of C, which was somehow elevated as the most popular programming language for applications, originates from a certain mind-set that C creators had. There are minds who think like those who made it, and minds who don't - minds who reject this structure as bullshit.

The minds who are rejecting this may have issues with what they perceive as unnecessary complexity, ordering of things, counter-intuitive syntax, etc. In my case I could read a line of asm and know what it did (like moving a value to a register or calling an IRQ) and then read a line of C and have 3 question-marks on what that fuckin line did. I've also reached the conclusion that it is impossible to have an alignment with C-thinking (preferring it as a native environment) without having anomalies in the way one thinks in life, in general. It's similar to the autism drawback of some super-intelligent people, but in this case it is much milder and doesn't need to be at the level of autism. Accepting the rules of the language, as this is, without much internal mind-chatter objection of "what the fuck is this shit" and just getting on with it, is, in a way, the root cause why there are so few people using it at any competent level globally. If more people had rejected it then we'd probably have something far better by now, with more popular adoption.

There are so many languages springing up but they are all trying to be the next C instead of being unique. For sure, programmer's convenience in transitioning is good, but it should be abandoned in favor of much friendlier languages.

While all this is nice in theory the problem will eventually be solved by AI - not language authors. It will ask what we want in terms of execution and we'll get it automatically by the AI-programming bot who will then be sending the best possible code for execution.

AI-Generic interface: "What do you want today Alex?"
Alex: "I want to find the correlation data of soil composition, soil appearance, minerals and vegetation, by combining every known pattern recognition, in the data set I will be uploading to you in a while".
AI-Generic interface: "OOOOOOK, coming right up" (coding it from the specs given)
AI-Generic interface: "You are ready... do you want me to run the program with the data in the flash drive you just connected?"
Alex: "Sure".

This means that the only thing we need to program is a self-learning AI. Once this is done, it will be able to do everything that a coder can do, even better and faster. It will be able to do what an if-then-else idiotic compiler does today, but far better in terms of optimizations and hardware exploitation. Most of the optimizations that aren't done, is because the if-then-else compiler doesn't recognize the logic behind the program and if the optimization would be safe or not. But if programmer and compiler are the same "being" then things can start ...flying in terms of efficiency.

This got futuristic very fast, but these aren't so futuristic anymore. They might have been 10 years ago but now it's getting increasingly closer.

Your Language Sucks Because...lol.

I'm formulating a theory that the worsening is due to ideological decisions that were not based on the pragmatic science of utility and practicality.

Examples:

1. Rust abandoning Typestate (as I warned in 2011) which was originally motivated by the desire to assert every invariant in the program. But of course infinite assertion is 0 performance and 0 degrees-of-freedom. Rather you choose a type system that meets the practical balance between utility and expression. And Typestate was not holistically unified with the type system of the language, thus it was doomed (as I had warned).

2. Scala was started as an ideological experiment (grown out of the Pizza project which added generics to Java) to marry functional programming concepts and OOP. Problem is that subclassing is an anti-pattern because for example the Liskov Substitution Principle is easily violated by subsclasses. Here is my Scala Google group post where I explained that Scala 3's DOT is trying to unify (the anti-pattern) subclassing and abstract types. Here is my post where I explained why I think Rust-like interfaces (Haskell Typeclasses) with first-class unions (that I had proposed for Scala) instead of subclass subsumption is the correct practical model of maximum utility and not an anti-pattern. Oh my, I was writing that when I was 4 days into my 10-day water only fasting that corresponded with my leap off the health cliff last year. Here is my post from April 2012 (right before my May hospitalization that started the acute phase of my illness) wherein I explained that "the bijective contract of subclassing is undecidable". Note Scala's complexity (generics are Turing complete thus generally undecidable same as for C++) means the compiler is uber slow making it entirely unsuitable for JIT compilation.

3. James Gosling's prioritization of simplification as the ideological justification for the train wreck that is Java's and JVM's lack of unsigned types (and for originally lacking generics and still no operator overloading).

4. Python's ideology (or ignorance) to remove the shackles of a unified type system which means not only does it have corner case gotchas, but it can never be statically checked compiled language thus can't be JIT optimized.

5. C++'s ideology of marrying backward compatibility with C (which is not entirely achieved) with OOP (including the subclassing anti-pattern on steroids with multiple diamond inheritance) is a massive clusterfuck of fugly complexity and corner cases.

P.S. I need to revisit the ideology of category theory applied to programming to try to analyze its utility more practically.

Impossible unless you want to forsake performance and degrees-of-freedom. There is a tension between infinite capability that requires 0 performance and 0 degrees-of-freedom.

Sorry some of the details of programming that you wish would disappear, can't.