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.
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.
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/
I feel like if you advertise this to the various "Mechanical Keyboard" communities they'd lose their shit in a positive way. r/mechanicalkeyboard is a main public one
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.
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.
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.
> Generality leads to bloat in software systems and increases complexity unnecessarily.
This is missing some qualifiers methinks. An interface is generic in that you don't have a concrete implementation, surely that can be used to decrease complexity rather than bloat it?
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.
C++ is a language, while iostream is one of the many C++ tools available to write to the standard output. It’s available by default, it’s part of the standard library, but you don’t have to use it. printf is also available, and will be as fast as using it from C.
Note that in most cases, the speed of writing to standard output is irrelevant unless you are implementing cat or some command line text processing tool.
I find iostream very convenient and type safety is a big plus compared to printf. It’s also very easy to implement your own handlers for your own types.
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).
This "bloat" of C objects you mention is only there if you use virtual functions. Same as using function pointers in a C struct. But in some cases C++ can avoid the dynamic indirection thanks to templates like in std::sort while C's qsort gets passed a function pointer, called for each comparison.
Iostream do use virtual functions but it’s not the reason of its suboptimal performance. The main reason is that some strings will be copied, allocated and freed during the construction of the whole expression while printf can do its processing with minimal dynamic allocations.
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?
I don't believe anyone tries to hide it. Except a couple of well-known cases, C++ is (relatively slightly) slower than C, but it's far more powerful. You can argue about compile times - yes, there is a huge difference here; also some specific features like virtual methods are slow - but overall, C++ is one of the fastest languages available.
