Does quiche have stringy vegetables in it?
(if you don't understand the Quiche reference, look up Niklaus Wirth Quiche eater on google)
One of the important features that is essential to have in any programming language that is taken seriously today is a string type.
When I look into oberon/modula/componentpascal I see this ARRAY of CHAR nonsense.
In fact I even see things like ARRAY 2048 CHAR.
In order to be taken seriously, all modern languages must have a string that does not require fixed length or kludges like this:
^ARRAY OF CHAR
A pointer to an array of char is not enough. That's far worse than even Standard Pascal back from 1970... Oberon is going downhill, not making any progress in the strings department. Time to buy some spinach, Wirth?
One of the things any language should advertise on the first sales page is:
THIS LANGUAGE HAS A AUTOMATIC STRING WITHOUT LIMITATIONS
This is also known as an ansistring or built in string.
I don't care about all the quiche eaters who think we should know our string length ahead of time.. and I don't care what you call it.. an array of chars or a string.. preferably it is called a STRING since that is what it is.. but.. does quiche have strings in it? I don't think they put enough spinach in quiche because these languages produced by the institutions and universities of Switzerland seem to be lacking any information on strings.
PCHARS are not enough.. nor are pointers to arrays of characters. Nor is making a getmem or a stralloc call enough. There must be a decent string type in a language, and it must be advertised all over the internet and in books that the string is easy to work with in the language.. otherwise people ain't gonna take your language for a spin or even consider it for serious use.
You literally have to be a psychic to know whether 2048 characters is enough for your string type (if you are writing a library or tool for many people to use, HOW do you know they don't need 1024 characters or 255 or 2048? The answer is you don't know! Maybe on an airplane control software or embedded programming you would know, but in general software development (that most people do, i.e. the real world)?)
It's almost like taking your car out for a drive with a passenger in the right hand seat constantly asking you : EXACTLY how many miles is it to the next location? I need to know EXACTLY right now. You don't know the answer, a string is a flexible thing that grows dynamically, just like a road trip can change depending on the traffic (who is using your library? how can you be a psychic and predict that your library users will need exactly 1024 characters of space for their programs?)
You don't know your strength lengths a lot of the time: this is bottom up design, whereas Wirth is stuck in top down design mode. Imagine designing an SQL database where they DEMAND to know how big, in exact kilobytes, is your database going to be. How can you possibly know? Your data grows and you don't know the answer. Sometimes you know that you want to limit people to only 10 characters long, but tell me EXACTLY how big your database will be! It's a joke, you simply don't know. Sure on a boeing airplane you may know that only 1024 characters will be available on your limited hardware, but what about general purpose programming on computers, not airplanes or space ships? No one cares whether their PHP strings or ruby strings are 1024 characters long, nor does any delphi programmer care - caring about these details is a distraction from actually getting programming done (except like I said in the case of an embedded system where you only have 1024 bytes to work with in your limited memory space).
Ada has unbounded strings but..
ADA has an unbounded string however when I read the manual about unbounded strings it floods me with useless information.. the first peice of information it should give is HOW THE HECK DO I SIMPLY CONCATENATE THE DARN STRING. Somewhere hidden on the page it says 'you can use the & to concatenate strings and you can assign with :='. This should be the first thing advertised in the manual.. it should not be hidden away as if string concatenations are the least important thing in the world.
In fact one of the reasons so many idiots use perl and php is because they have something called strings in their language.. and yes I realize that not all airplanes require the use of unbounded unlimited strings.. but a language will not be taken seriously without lots of string advertisement and if unbounded strings are the least important thing in the world for airplanes then the language is going to fade away in obscurity since not everyone programs for airplanes or embedded systems.
Plus, embedded systems are getting better with regards to space requirements (an iPhone or android phone is actually like a modern embedded device when in fact it really is a full fledged computer with gigabytes of space!), so designing something based on 255 characters or 1024 character maximums could be shooting yourself in the foot for the future when your code is expanded to bigger strings later on newer hardware with more space. Consider the limit of 8 character file names in dos... That went over well (not). People like Niklaus Wirth think "8 characters should be enough for anyone" and then realize a few years later that, Oops.. I guessed wrong (we are not psychics).
No Quiche Eater Here
I would make it quite clear on the front spinach advertisement page that you can do this in the language:
s := somevar + 'blah' + 'more' + someotherstring;
Without having to make a call to GetMem() or StrAlloc() or New() and without having to declare the range limits of the string.
It is of course useful to also have the ability to declare a range end on the string too. For example:
string[2000];
array [1..2000] of char;
..would be nice since some languages only offer:
string[255]
But for most work people care about the open string or unbound string.. and having these other fixed length arrays or strings is just a language bonus. It seems to me the quiche eaters think that having the fixed length strings is the main focus and having things like open arrays is just a bonus that is used some times. Too much quiche, them eat. They don't seem to want to create an abstract string data type and want us to use other things inferior to strings... It's sort of like how C language doesn't offer you a BOOLEAN in old versions, because they think there is no need for a boolean type (not a useful abstraction?). Or it's kind of like going back to programming in C where you had pointers to chars as your string, which was painful to work with as you had to allocate memory for chars... While GoLang these days solves all those problems. Oberon, on the other hand, is almost as bad as working in plain C, worse than C++, worse than even Standard Pascal's 255 characters in some ways. At least Standard Pascal had strings!
Got stringy spinach in your quiche?
Niklaus Wirth just can't get strings right.. (he gets some other things right though). He didn't get them right in Standard Pascal.. and it's how many years later now? While tools like Delphi and FPC got strings right, Oberon got them wrong again?
When talking to some russian oberon programmers, their comments were:
"I don't know if an elegant solution is possible, because the Str currently deals with all sorts of Oberon strings instead of providing an abstract data type."
Really? While GoLang takes over, oberon dies and fades away in academic obscurity. There was a reason that C won over Pascal, and there is a reason GoLang will beat oberon, at current date of writing. Yeah, oberon has like 5 or 10 serious people using it... okay and maybe 200 people that use it as a "hobby" once a year. GoLang has *censored*.... nevermind. Don't want to embarrass oberon programmers with how many GoLang gophers are popping out for GroundHog Day.
See also:
Is-Lisp-the-Same-as-String-Theory
|
