|
When code is lengthy or complex summary text/comment is easy to read
for short code block it's easy to read code instead of comments/text
|
|
|
|
|
If the piece of code does exactly what I need or subset of it, then textual description is enough. That happens rarely. Most of the time, the code do too much and cannot be used without some hacking. That is where I go to details and read the implementation. A correct textual description does not give the details.
|
|
|
|
|
G'day Folks,
I would like to see someone tell me that Hex codes are easy to read, unless you can read and speak the Hex Language, which few can. (must be showing my age telling you this)
This goes for any actual Code parameters and their interpretation. Reading them does not mean that the "Reader" understands them.
Codes may be verbalized, i.e. read like text, however this does not mean that they are Text as interpreted in the meaning of the English language.
Codes are a separate language of their own.
If you object to my “Candour”, read another post !
"BENE DICTUM, BENEDICTE !"
|
|
|
|
|
Hex is easy to read and write - the problem is that the interpretation of the sequence of bytes then depends on so many factors that it will usually be fairly useless.
I think you're confusing "Hex language" (it really doesn't qualify as a language - its a number encoding scheme using base 16) with machine language.
Years ago I used to hand-code in hexadecimal for a Z80 on a Spectrum, but thankfully Assemblers, then C and C++ saved me having to sink that low.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
G'day Rob Grainger,
HEX is a multi-paradigm programming language that supports both static and dynamic types, and was designed with the core principles of simplicity, readability, versatility and scalability to allow developers to create a diversity of types of computer programs with modern language features, succinct syntax and semantics that are built into the core of the language construct.
http://www.hexlang.org/[^]
I may be silly at times, however never stupid as most if not all programing codes are referred to as Languages, i.e. either Programing Language or Code Language depending of where in point of time you started using them. For me it was 1979 or 1980.
Good Luck with your Programing Language.
|
|
|
|
|
My apologies, I hadn't come across HEX before (as you probably guessed). They could have chosen a less confusing name
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Text for the purpose of the code.
Code for the implementation of the text.
But as text is normally not well written and code buggy ... it's a gamble
|
|
|
|
|
|
Agree.
Don't mind those people who say you're not HOT. At least you know you're COOL.
I'm not afraid of falling, I'm afraid of the sudden stop at the end of the fall! - Richard Andrew x64
|
|
|
|
|
But with the advantage of being more structured and formal. Natural languages (English at least) is terrible at that.
|
|
|
|
|
Have you ever been working in APL?
"Text"???
|
|
|
|
|
The text documentation might be the correct version. If it was written by the process owner, it would be correct. Whereas the code might not follow what the process owner intended.
|
|
|
|
|
Which is the map? Which is the terrain?
Is code "the real thing" (the terrain), with the documentation text being the description of it, the map?
Or is the definition of the problem to be solved (represented by the text) the real thing, the terrain, and the code is an approximation to the real soloution, a map of how the real solution would be?
I have seen too many examples of programmers who treat their code as the hard rock mountain that should not be moved even half an inch - and certainly not because some silly "user requirement" demands it. Users will have to adapt, learn how to use the system as it is built! Change both text and user requirements if it doesn't fit the code.
In most cases, however, the platforms with a marketing focus on customer needs rather than developer preferences will have the greatest commercial success. The text is the master, the terrain. Code is the approximate drawing, the map. It may take more effort to learn from the terrain, but the quality of the information is always more reliable.
|
|
|
|
|
It would depend on my objective. In either case I could derive the requisite understanding from the code.
Thanks
JD
http://www.seitmc.com/seitmcWP
|
|
|
|
|
I'll scan someone's "text about code" and take it with a grain of salt, then go to the code. There's no rule in physics that says the text representation has to be accurate in any way.
If I need to understand it, I need to be responsible for understanding what it actually is, not what $predecessor says it is.
|
|
|
|
|
There is no rule in physics that says the code will do what the text specification says it should do.
|
|
|
|
|
|
Polymorphism, for instance, is all about lying.
(not to mention Dim instruction of VB6 )
Veni, vidi, vici.
|
|
|
|
|
is obsolete as soon as it's published.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
Or, "Specifications are obsolete as soon as a programmer has delivered code that fails to implement them".
|
|
|
|
|
Unless one goes back to the days of programming with numbers code is just text for a compiler to turn into numbers.
I was always told to comment my code so that others might understand it when I left, but I'm still here.
Now we have a whole plethora of documents to fill which I secretly believe is for the accountants so that they can pretend programmers are doing something to justify their salaries.
|
|
|
|
|
(1) code implementing an algorithm/a protocol stack/ :
It requires special knowledge before understanding the implementation.
Much emphasis is put to optimization rather than readability
(2) OS level ( The kernel )/Device driver code :
Same as above.
+ have to learn the device/machine interface from other sources
Datasheet/Specification/Design document/Technical papers /Books/Literature/newsgroup threads
are must-read before understanding the code.( Not Simply API doc.)
modified 15-Apr-14 3:21am.
|
|
|
|
|
I'd prefer to "Visualise" - therefore pictures are best...on a whiteboard
|
|
|
|
|
Surely someone out there must have some better suggestions?...
"How useful do you find the recent surveys?"
* Vital to my career
* Useful, but I can sleep fine without them
* I am of the opinion that I have no opinion
* Not helpful in the slightest
* The bane of my life, I only come here to complain about how bad they are
|
|
|
|
|
You forgot one:
I only answer for the rep points.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|