I guess if the AI is good enough, your point makes some sense.
It's a good programming habit to doc your code as you write it.
If you do this in a structured way and code folding is used
the comments should get out of the way from the main code.
Why could you not create a comment block above the code section in question and fold it. All IDE's nowadays support folding, including comment block folding.
To see what a section of code does, you unfold the comment block above it, read it, then fold it back.
Emacs is a great editor if you don't want to have to use the mouse
and once you get familiar with its command set.
What I'm working on is creating a keyboard-input only GUI SDK
that enables you to build something like Emacs easily.
A keyboard based IDE for a keyboard based GUI for PCs.
Common PC GUIs are WIMP based (Windows, Icons, Menus, Pointers).
They require the usage of a mouse and are pretty complicated.
I find the usage of the mouse in a PC GUI "unnatural".
So I set out designing a keyboard-input only based GUI.
It turned out, that wasn't as difficult as I initially thought.
Then I started writing an IDE for designing apps using this new GUI approach.
I call it EngageUI, since it is user activity based.
https://github.com/Rohit-Agarwal-Khitchdee/EngageUI/
FWIW,
A sitar also has a 12 note scale, but the frets are moveable so you can tune by ear. The drawback is, you only play melodies on the top string and there are no chords.
It's possible to design a guitar where the frets are spaced at harmonic intervals
and not equal tempered, but then, you can only play in one key, the key of E and you can't capo or play barre chords. However, if you do play such a redesigned guitar in the key of E, it will sound sweeter because all your notes will be harmonic and you could play chords.
I'm thinking more in terms of what you put into that interface.
Do you add features that you might need later?
My approach would be no.
You design your first interface with only what you need right now.
And if you don't need an interface to do that, you bring in the interface later.
Generality leads to bloat in software systems
and increases complexity unnecessarily.
As a general rule of thumb,
software should be designed with the specific use-case in mind
that applies to the current needs of the user.
Generalisation should be delayed as long as possible
in the design process.
This is because the process itself reveals what would benefit
from generalisation.
No virtual fns means no inheritance.
Also, you can blame the implementation and not the language.
But real-world it is slower. Can't say by how much. Why bother?
C++ adds a layer of functional indirection above the level of the C structure. This is what causes the bloat. The implementation of the C++ object vs. the C struct.
Iostream is implemented as an object.
C++ is definitely more convenient and that was the intent of its creators. It does not replace C but provides a more convenient alternative to using C structs and fn pointers at the cost of a small performance penalty (maybe slow and bloated is over-expressing the penalty).
Execution is about engineers.
Intel can't retain their engineers.
Without good engineers you can't compete.
So you downsize and try compete only on one thing -- better x86.
Pat Gs return as CEO does help with engineer retention though.
If you translate, you do face performance issues.
Apple or some other vendor cannot make an ARM chip so fast at a competitive cost
that beats an x86 chip in emulation mode.
The underlying acceleration techniques for both ARM and x86 are the same.
Apple will always be niche because they are too expensive.
ARM based PC client processors accounted for about 9% of the total market.
But I don't expect that number will grow a lot higher due to cost of Macs.
Also, you can't bring out a desktop PC based on Linux because that a very slowly growing market segment and MacOS is proprietary. Don't think Apple will start another PowerComputing type scenario where they open their platform to others.
It's not a matter of performance for this reason (price).
So, on Windows, assuming Macs don't take away any more market share from Windows,
they need to beat AMD+TSMC.
Intel should double down on its core business which is selling x86 chips for Windows PCs. If it loses to AMD+TSMC here, there's nowhere left to hide. IFS is very long term and a new business opportunity in a market where Intel is not the leader. x86 for Windows is their bread and butter. They need to throw everything else out and downsize to just excelling at what they've always done. My guess is AXG is a separate division than the division that makes the graphics for their core microprocessors.
Here is an editor for C I'm in the process of writing with a Modal, keyboard-only interface.
It features a 3 column source code display format which is different from the traditional single column format.
Also, there are on-screen controls such as menus, toolbars, navigation windows etc.
The entire screen is used to display source code and
keystroke sequences are used for navigation.
In particular code folding is very efficient.
https://github.com/Rohit-Agarwal-Khitchdee/Modal-GUIs
I've defined a couple of source code navigation constructs above the language level that are embedded inside comment blocks.
While I've written this editor for my own use, I've made it available as an open-source repository Github.
It is experimental. The source code is well documented and easy to modify for your own purposes.
Equal temperament makes it easier to design simple musical instruments.
Older music and current music in other genres (e.g. Indian Classical) is based on a harmonic scale, taking its roots in vocal music.