[Gambas-user] Reply to personal rant...
cedron at exede.net
Sat Apr 27 17:31:39 CEST 2019
Separate email because I don't want to hijack the originating thread.
I just added a PrintAt(R,C,String) method to my NiceTerm class. I was going to do it originally, but I don't really have a problem with using two statements.
Lines of code is not a good metric for either code complexity or code efficiency.
I've seen programmers reduce "lines of code" by calling external routines, which in turn, load tons of baggage code, actually take longer to execute, and add an external dependency just to avoid writing a few lines of code that would do the same task.
I've also seen programmers who overload statements with incredibly complex calculations which would be much more clear if they introduced a few temporary variables and broke the calculation into a few lines. Coding for clarity and coding for fewest number of lines are often conflicting goals. I strongly favor the former.
I happen to like Left, Right, and Mid as they are, but I also like Python's approach of treating strings as character arrays and having range specification capability in subscripting. That is very similar to the Sinclairean syntax you noted.
In fact, I would really like to see Gambas adopt the Python range specification convention for all arrays. This includes negative values for wraparound specifications.
I wrote NiceTerm because I want to develop a bunch of console apps and I really don't like ncurses. So this isn't merely nostalgic, these are issues for consideration today.
Personally, I always hated the awkward Microsoftean way to LOCATE things to PRINT. Two statements? Why?
Instead, always loved the british Sinclairean way, which uses:
PRINT AT <line>, <column>
Simple, elegant, shorter, it has it all... and even looks more VT100 oriented, where you put coordinate/color/etc. codes right before the payload. Same way to handle attributes (color, etc):
PRINT AT 3, 10; INK 7; PAPER 0; FLASH 1; INVERSE 0; BRIGHT 1; OVER 0;"Hello world."
Could go on with replacing the also Microsoftean LEFT$, RIGHT$ and MID$ abominations with the simpler and more readable Sinclairean syntax
VAR$(<startIndex> TO <endIndex>)
but enough nostalgia trip...
More information about the User