On 6/27/2020 8:49 AM, dwight via cctalk wrote:
Hi Stan
It sounds a little like the way most good Forth programmers deal with
problems. Forth is all about semantics. Every thing is a word. The complexity
of the program is left to the low level stuff. When the program is done, it
isn't a program written in Forth, it is a program written in the application.
At the highest levels one should not see the language it was written in one
should only see the application. Well written Forth at the upper levels has
only : and ; of the language showing through. The rest are just the words in a
sentence like structure telling what the application is doing.
It is too bad that people insist on using languages that even at the highest
level is still just a program in that particular language. All the boiler plate
is still in the way of the program.
Although, taking a little more time to get used to, Lisp is something like that
as well. At least well written Lisp is. One can see what the intent is at the
higher levels of coding. It is just learning to read the sentences. The lower
level language part is how you move the bits and bytes around. The application
should tell you what it does and why. Comments should only be needed at the
more confusing lower levels. At the higher levels comments would and should be
redundant. The words should tell you what is being done.
Dwight
At what point do variable names end being comments?
There needs to be more work on proper documenting and writing
programs and modules. I am not a fan of objects and operator overloading
because I never know just what the program is doing.
apples + oranges gives me what ? count of fruits, liters of fruit punch,
a error?
It would be nice if one could define a new language for problem
solving and run it through compiler-compiler processor for interesting
problems.
Ben.
