Array problems

[Tdarcos]

Hugo doesn't like this:

Code: Select all

 array Pies[40]

   Pies[1] = "Almond Ave."
   Pies[2] = "Ambrosia Ave."
   Pies[3] = "Apple Ave."

Hugo suffers from what I call "The Implementer Problem" in which a processor suffers from the language background of its implementer.

Implementers who have a background in languages with strong string capability such as Pascal or Basic will develop processors that have good string support.

Implementers who have a background in languages with either very weak or no string capability like C will develop processors that have weak string support.

Hugo shows its roots come from weak string support languages such as C.

[Ice Cream Jonsey]

Hugo doesn't like this:

Code: Select all

 array Pies[40]

   Pies[1] = "Almond Ave."
   Pies[2] = "Ambrosia Ave."
   Pies[3] = "Apple Ave."

Hugo suffers from what I call "The Implementer Problem" in which a processor suffers from the language background of its implementer.

Implementers who have a background in languages with strong string capability such as Pascal or Basic will develop processors that have good string support.

Implementers who have a background in languages with either very weak or no string capability like C will develop processors that have weak string support.

Hugo shows its roots come from weak string support languages such as C.

Wait, what? I was able to do exactly that in my games.

What error are you getting?

Ok, wait, I think I may know what is up. I remember this, I think. Try this, Commander:

- declare your array where you have already done so. No change there.

And then create something like this:

routine InitializePies()
{
Pies[1] = "Almond Ave."
Pies[2] = "Ambrosia Ave."
Pies[3] = "Apple Ave."
}

And then call InitializePies() in init().

[Ice Cream Jonsey]

Also, and this is sort of off-topic: what languages do you consider to be good with strings? Not being snarky, honestly curious.

Off the top of my head, like if aliens crashed and started tediously asking computer programmer questions, I'd say that the following languages handle strings WELL:

- Perl
- Ruby
- COBOL (sort of kidding, but at least you always know where you stand with a COBOL string)

I would say the following languages handle them poorly:

- LOGO
- Pascal


But I am curious as to your take.

[Tdarcos]

Also, and this is sort of off-topic: what languages do you consider to be good with strings? Not being snarky, honestly curious.

Off the top of my head, like if aliens crashed and started tediously asking computer programmer questions, I'd say that the following languages handle strings WELL:

- Perl
- Ruby
- COBOL (sort of kidding, but at least you always know where you stand with a COBOL string)

I would say the following languages handle them poorly:

- LOGO
- Pascal

But I am curious as to your take.

No, you have it backwards. C handles strings poorly. You can't have a string in C that has a binary zero in it, and your program has to remeasure a string every time it needs to know how long the string is.

Pascal, Basic, Cobol, and even Fortran don't care what your strings contain. I used one mainframe system where they had really good string support libraries that you could use Fortran to do applications requiring string support.

Pascal has very good string processing, equal to Basic and as good or better than Cobol. Now, by 'Pascal' I am referring to Object Pascal, which is any current compiler including Free Pascal or any older one starting with Turbo Pascal 6 and Delphi. The original Jensen & Wirth Pascal from 1970 is as weak on strings as C.

In fact, the string processing in Pascal is strong enough (along with other features) that you can use Pascal to implement a Cobol compiler; the reverse is not true. In fact, all Pascal compilers being released today are self-hosting, the compiler is itself written in Pascal.

The libraries for PHP give much better string support than the C language (of which it is a descendant).

One of my favorite languages I use for writing quick tools is Free Basic. It has an IDE and creates console applications on Windows or Linux. What is the compiler and the IDE written using? Free Basic.

[Tdarcos]

Ok, wait, I think I may know what is up. I remember this, I think. Try this, Commander:

- declare your array where you have already done so. No change there.

And then create something like this:

routine InitializePies()
{
Pies[1] = "Almond Ave."
Pies[2] = "Ambrosia Ave."
Pies[3] = "Apple Ave."
}

And then call InitializePies() in init().

I only need to display the items, so I created

Routine Pie_Name(I)
{
select I
case 1
return "Almond Ave."
case 2
return "Ambrosia Ave."
case 3
return "Apple Ave."
}

Then I do

Print Pie_Name(12)

This solved the problem.

[Kent]

Well, you made me actually log in and answer this. Like some sort of puppetmaster.

Hugo suffers from what I call "The Implementer Problem" in which a processor suffers from the language background of its implementer.

Implementers who have a background in languages with strong string capability such as Pascal or Basic will develop processors that have good string support.

Implementers who have a background in languages with either very weak or no string capability like C will develop processors that have weak string support.

Hugo shows its roots come from weak string support languages such as C.

By "processor" I'll assume you mean...language? Compiler? We'll go with language.

As for "string capability", I'm not sure what your benchmark is. Microsoft Word, for instance, was programmed in C/C++. I'm pretty sure it does a bit of string handling here and there. In fact, pretty much every major piece of software ever written was programmed in C/C++.

Anyway, I talked to the guy who wrote Hugo and he said that when he initially designed the language, he didn't know C at all. In fact, the first pass at Hugo was written in BASIC (Microsoft QuickBASIC, to be exact, for its ability to be compiled). Hugo was subsequently rewritten in -- or essentially ported to -- C. And after that time, the guy went on to pick up experience doing more Hugo and some other little things in C++, Java, Javascript, Perl, Python, PHP, etc. etc.

But the basics of Hugo's design were established well before that, and Hugo's internal, engine-level text/string handling is nothing like C's.

Water held: none.

That said, Hugo's internal, engine-level text/string handling (and its library-level string handling) isn't anything like BASIC's, either. It's most like Inform/Z-machine text handling, where a piece of text (what Hugo calls a "dictionary word") is encoded exactly once, so that every reference to it can be a small number instead of a string. It's fast, and as compact as it gets. (Note that this doesn't apply to text explicitly for printing via 'print' or a standalone "This is some text to be printed." line.)

And actually, if you want the truth, when you dig into the technical documentation you'll see that a "dictionary word" in Hugo is stored in a manner much more akin to length-first Pascal string than a null-terminated C string.

But it's probably best if we're going to have this conversation in 2011 that we leave COBOL, FORTRAN, and even Pascal out of it.

I'll give you this: I wish Hugo were better at string manipulation.

The existing system works/worked extremely well on limited memory devices, including older PCs, older Macs, and older Palms. These days, even a cheap phone has many times the memory of the computer Hugo was created on, so memory concerns are...well, different. Making sure that an application never uses more memory than it was originally allocated is no longer an issue that is, shall we say, on the radar.

Maybe something will be done at some point.

[Tdarcos]

Well, you made me actually log in and answer this. Like some sort of puppetmaster.

Hugo suffers from what I call "The Implementer Problem" in which a processor suffers from the language background of its implementer.

Implementers who have a background in languages with strong string capability such as Pascal or Basic will develop processors that have good string support.

Implementers who have a background in languages with either very weak or no string capability like C will develop processors that have weak string support.

Hugo shows its roots come from weak string support languages such as C.

By "processor" I'll assume you mean...language? Compiler? We'll go with language.

As for "string capability", I'm not sure what your benchmark is. Microsoft Word, for instance, was programmed in C/C++. I'm pretty sure it does a bit of string handling here and there.

And I will tell you that I would say that there is a complete separate library they either bought or built to compensate for the abismally poor and woefully deficient string processing capabilities in the C language. Whether C++ has better string processing, I don't know; I avoid C++ the way I try to avoid toxic waste or brain damage. I think C++ was made overly complicated and is very dangerous to use because it lacks sanity checks that 3rd Generation and 4th Generation languages should have.

In fact, pretty much every major piece of software ever written was programmed in C/C++.

Over what time frame? For PCs, maybe. One of the most powerful application packages was ACP, Airlines Control Program, it was developed in Assembly language by IBM for their mainframe computers to allow airlines to run reservation systems. At the time it was very fast and was rated to handle upwards of 1600 transactions a second, which, back in the days of the older mainframes was a fairly high volume of transactions.

ACP morphed into the runtime system CICS, which was for mainframes was Windows was for PCs; it allowed the operating of multiple demand-driven terminal applications which could be written in Assembly, PL/1 or Cobol. Use any large bank's atm machines where they aren't stand-alone terminals, and chances are you're using what would be called a "dumb terminal" running as a CICS job on that bank's mainframe.

Or with the huge reduction in costs to send data back and forth,that might not be the case, they might have converted to standalone ATMs these days.

But since the software market for programs intended for public use and resale is about 5% of all software developed, I'd personally say the #1 language used to develop computer programs is: Cobol.

The internet is all nice, and new, and sexy, but when you're running a $500 billion bank you're probably still using the same applications you had back in the 1970s, with the thousands of upgrades, that most likely are still CICS applications running on your mainframe, supported by PCs that talk to the various screens that are generated.

Because you're not likely to throw away a mainframe system that works satisfactorily and a set of 20,000 applications that run your bank that cost the bank something like $30 million in purchases, maintenance and upgrades over the last 45 years.

Go into the financial world and they do arbitrage matching by finding where someone is offering a buy price lower than a sell price, and then take it. Or the reverse. This requires scanning millions of potential trades and requires huge arrays to index the interconnections of price. And the amount of arbitrage might not be much, in some cases it's only a couple cents But when you're talking about making 2c on several billion transactions a day, that's a lot of money. This requires some sophisticated processing and capacity, and you're not going to find that in C or C++. It requires the most powerful computer programming language ever developed. I don't know if you've heard of it, but its name is APL. And APL is the language of choice for those types of systems.

I'll give you this: I wish Hugo were better at string manipulation.

Okay, I'll bow to your superior knowledge since you spoke to the guy. But, my opinion that it was based on C was based on Hugo's really bad sting processing and the fact it uses the C style of block constructs, with the { to begin a block, and } to end one. It's interesting that SQL has gone "Pascal" style block constructs, using "Begin" / "End" for block code in SQL stored procedures and such.

The existing system works/worked extremely well on limited memory devices, including older PCs, older Macs, and older Palms. These days, even a cheap phone has many times the memory of the computer Hugo was created on, so memory concerns are...well, different. Making sure that an application never uses more memory than it was originally allocated is no longer an issue that is, shall we say, on the radar.

Actually one of the most serious issues in computer security is the use of memory not allocated to a program. This is where memory contamination, buffer overflows and other such attack vectors come from.

What is more important is programs being designed to take advantage of the huge amounts of memory which are now available. At one point, having a gigabyte of memory in a mainframe computer was a significant event. (Back in the late 1970s and early 1980s we ran a Univac 90/60 mainframe at my junior college with 16 terminals and a card reader supporting over 300 students, on a machine with 500K of real memory.) This machine I'm using right now has 3 gigabytes of memory.

Maybe something will be done at some point.

It would be nice if programmers figured ways to use increased resources to make their programs run faster or do more, but often increased speed or capacity isn't taken advantage of and the apps are just as bloated and slow, only they use ten times as much resources as before.

[Official judge]

I'm sorry, that answer is incorrect.