~ wrote:
What is unclear to you because you're still learning...
Son, I've had a (close) look at Literate Programming in the early 1990's.
Don't condescend on me.
~ wrote:
...it's highly useful to visualize chances of big optimizations at the code level, which will further be helped by the compiler optimizations, more than code without this feature.
You're still looking at it from a beginner's perspective. Yes, a beginner might make optimization opportunities obvious (to an expert) if he is expressing intent verbosely. But that's 101 stuff you are talking about. Something that happens on StackOverflow or CodeReview.SE daily, without pamphlets surrounding the code. By the time you graduate, I'd fully expect you to write code that
doesn't provide "chances of big optimizations at the code level", because you've had the stupid hammered out of you by that time.
~ wrote:
Try it a few times and you will see how you can easily come up with extremely good natural optimizations that without the comments look as obscure as many compiler optimizations, despite being part of an average well-formed English sentence.
You are still afraid of the state of the art, and want to drag it down to your level of understanding. I know that phase. Most aspiring developers run through it at some point. Some, sadly, stay forever stuck in there.
~ wrote:
Who knows what would result if we translated all keywords to another language, who knows if writing code in other natural languages would result in other sorts or better optimizations for code written as regular technical document sentences.
Not trying to put too fine a point to it, but you haven't even understood how a compiler
works, let alone an optimizing one. As we've established rather clearly elsewhere, this is probably
the best understood field of Computer Science.
It's like you proposing to NASA a radically new way to build a rocket from the things you found in your cupboard...
~ wrote:
With this style we are practically writing a technical paper designed to be compiled, so the comments and the code need to be updated at all times for anything to even make sense as the text is so dense that it's just designed to be read and only execute a few key points, but they all have some syntactical structure so the text needs to be rewritten whenever a change is made, but the compiled result is simply superior to just write brief machine code fast that will later become rapidly unreadable for a human.
So you're massively increasing the workload (and chance for error) for any refactoring or design change. You'd be surprised how often
those happen, in the real world, compared to "clean slate" implementation.
~ wrote:
It's just another win of the lay-man level at programming...
Lay-mans have no business at programming other than becoming better at it.
Consider something like encryption software, or the software running the security systems in your car. There are things to be considered here that go
way over the head of any layman, verbosely commented / explained or not. Or a compiler itself. If you don't
understand the basics involved, no amount of literate programming will help you. I can't write a full-blown essay on cache timing side-channel attacks, known-plaintext attacks etc. etc. pp. ad nauseam when I implement an encryption algorithm. Or explain the various approaches to parsing when implementing a Bison (or Spirit) grammar. One, that's not what I'm being payed for. Two, the seminal works on the subject have already been written. Which is how I know about what I am doing.
You're still sitting there and waiting for some easier-to-understand technology to pick you up where you are sitting. It doesn't work that way. You have to get up and
go to where the technology
is.