The documentation is correct in that Linecount( only counts carriage return separated lines.
When I count the number of lines, I count the number of lines without regard to LF or CR. Microsoft Word counts the number of lines without regard to whether they are LF or CR separated.
I’d like that Linecount( should count the number of lines, rather than the number of carriage return separated lines.
In my imagination, most people will count the number of lines regardless of whether a CR or a LF was involved.
Unless we were to get a LineFeedCount(, determining the number of lines becomes unnecessarily difficult unless I am missing some easy way to count the number of linefeeds.
I had spent too much time attempting to resolve some lost data that had occurred with my presumption that the Linecount was counting lines. In that frustration, I did overlook your suggestion.
Perhaps the documentation can be enhanced to make this limitation more clear and your suggestion for the workaround to get the results that the user may most likely desire.
The key question here is - what exactly is a line? There is no universal standard for what constitutes a line that applies to all computer systems over the past 60 years. In fact, even the Macintosh has used two different definitions of what is a line over the years.
Before computers, teletype machines used the carriage return and line feed characters between each line. The carriage return character caused the print head to move to the beginning of the current line. The line feed character caused the paper to roll forward one line. So to advance to the next line, you needed two characters - first character return, then line feed.
When computers came along, it wasn’t really necessary to have two characters anymore. But which character to choose? Some systems, for example Windows, still use both the carriage return and the line feed characters. The original Macintosh computer used only the carriage return. UNIX uses only the line feed character.
When the Macintosh became a UNIX based system with the introduction OS X, the Mac switched from using carriage return to line feed between lines. But Panorama stuck with carriage returns. This was done so that existing Panorama programs would continue to work without modification. However, this isn’t fool proof, because a Panorama program can always load files generated by other programs, which may have line feeds, carriage returns or any combination. In those cases, you have to explicitly code your program to handle the data you get, using a technique like the one David suggested.
Keep in mind that the linecount( function is really just a simplified version of the arraysize( function. So the formula
linecount(text)
Is basically the same as
arraysize(text,cr())
So if you wanted to count based on line feeds, you could use
arraysize(text,lf())
But the solution suggested by David is better because it will work with carriage returns OR line feeds, or even a mixture of both,
Bottom line - there is no one universally correct solution. So Panorama X picks the solution that is most compatible with Panorama 6 and earlier.
So we’re sticking with the way it was done a decade ago and not recognizing that things do and should change?
In my world, people matter. And what appears visually should be replicated in code. If my customer or I count 7 lines, there should be a count of 7 regardless of how it was coded.
But that is just me. And who am I. Tomorrow I may not exist.
So we’re sticking with the way it was done a decade ago and not recognizing that things do and should change?
In this case, yes.
When you make a change to a programming language that will BREAK existing code that has run for decades, you had better have a VERY compelling reason. If there is no compelling reason, then I believe that programming language developers should have a very strong bias towards stability. Being able to run the same code for years and decades is a very valuable feature, in my opinion.
And what appears visually should be replicated in code. If my customer or I count 7 lines, there should be a count of 7 regardless of how it was coded.
First of all, “visually” has nothing to do with it. Programming isn’t horseshoes.
Secondly, many users would argue that whether it counts CR or LF characters, line break wouldn’t match the number of lines that they “see”. Text is usually displayed with word wrap enabled, so the number of lines visually displayed has nothing to do with the separator characters in the code. Depending on the view width and font size, a single “line” may display as one line, 5 lines, 50 lines or more. So there is no case where what “appears visually” corresponds to the number returned by this function.
Put another way, the linecount( function doesn’t return the number of visually appearing lines in the text, it returns the number of separator characters (plus one). And for Panorama, the separator character is defined as a carriage return. This has been stable for 42 years, and Panorama developers rely on this being stable.
Programming languages aren’t human languages. Instead, they are precise technical constructs. When used in a programming language, the word line may not have quite the same definition that it has in English. Perhaps it would have been more accurate to originally call this function crcount() or carriagereturncount(). But I think that would have seemed nonsensical 35 years ago. The word “line” here is used as a metaphor, and I think a useful one. But it’s well known that naming things is one of the hardest problems in computer science.
It used to be that way, as I recall, in a very early version of Panorama (or was it Overvue) and it drove everyone insane. Especially people who owned printers!
You’d be surprised what developers have to consider besides code quality and efficiency.
I could be wrong about this, but I think Jim had to consider potential ramifications from the bible belt when he chose the Yin/Yang symbol for New Generation.
Once I submitted “to the masses,” what I thought was a well-designed user Interface for a hobby routine. The first reply was that colorblind people wouldn’t be able to discern the status of buttons because of my color scheme.
