Which is best?
GloryBlaze
I've been wanting to create a text adventure for some time now, but I'm not
sure which of the programs for making them is best (TADS, Inform, etc.). So
far, I've had the best luck with AGT, but I'd like to get some other opinions.
-----
Codeman (aka GloryBlaze)
"Stealing? No! I prefer the phrase 'permenant borrowing'."
--Wren Yunin, Rogue of Chesterwark
michael...@ey.com
In article <199805072255...@ladder01.news.aol.com>,
glory...@aol.com (GloryBlaze) wrote:
>
> I've been wanting to create a text adventure for some time now, but I'm not
> sure which of the programs for making them is best (TADS, Inform, etc.). So
> far, I've had the best luck with AGT, but I'd like to get some other
opinions.
I'm a big fan of Inform myself. It's easy to learn, easy to read, and the
designer's manual is well-written (though a bit incomplete). TADS has many
loyal supporters as well, although I think TADS has a more "technical" feel to
it. I've heard a number of people say that it's structured more like C++,
which is a big pro for real programmers but a massive con for English majors
such as myself. I've looked at some sample code and I just feel more
comfortable with Inform. If you've had more of a technical background, you
might like TADS better.
I've never messed with HUGO or AGT -- I don't think I've even played any game
written with them. So I don't have any input on that.
--M.
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
okbl...@usa.net
In article <199805072255...@ladder01.news.aol.com>,
glory...@aol.com (GloryBlaze) wrote:
>
> I've been wanting to create a text adventure for some time now, but I'm not
> sure which of the programs for making them is best (TADS, Inform, etc.). So
> far, I've had the best luck with AGT, but I'd like to get some other
opinions.
You really can't write a decent text adventure these days without using
Assembler. 6502 Assembler is preferable.
(Spoof!)
Check out the newsgroup for the past few weeks to find recent discussions of
the "Which is best?" debate. Or look at the FAQ.
[ok]
Matt Kimball
michael...@ey.com wrote:
: I'm a big fan of Inform myself. It's easy to learn, easy to read, and
: the designer's manual is well-written (though a bit incomplete). TADS
: has many loyal supporters as well, although I think TADS has a more
: "technical" feel to it. I've heard a number of people say that it's
: structured more like C++, which is a big pro for real programmers but
: a massive con for English majors such as myself. I've looked at some
: sample code and I just feel more comfortable with Inform. If you've
: had more of a technical background, you might like TADS better.
Frankly, I'm baffled by this paragraph. Admittedly, I haven't written
a complete work in either, but I have written small programs in both,
and it seems to me that TADS has a much cleaner design, has a simpler
language and would be much easier to learn for someone who isn't used
to hacking C code. (But then again, since I am a programmer by
profession, I might be out of touch with exactly what is and isn't
easy to learn and use for the non-programmer. Since you found Inform
easier to use, I guess that speaks for itself).
(And Anchorhead looks promising, BTW).
--
Matt Kimball
mkim...@xmission.com
Dan Shiovitz
In article <6ivhis$mto$1...@news.xmission.com>,
Matt Kimball <mkim...@xmission.com> wrote:
>michael...@ey.com wrote:
>: I'm a big fan of Inform myself. It's easy to learn, easy to read, and
>: the designer's manual is well-written (though a bit incomplete). TADS
>: has many loyal supporters as well, although I think TADS has a more
>: "technical" feel to it. I've heard a number of people say that it's
>Frankly, I'm baffled by this paragraph. Admittedly, I haven't written
>a complete work in either, but I have written small programs in both,
>and it seems to me that TADS has a much cleaner design, has a simpler
>language and would be much easier to learn for someone who isn't used
>to hacking C code. (But then again, since I am a programmer by
>profession, I might be out of touch with exactly what is and isn't
>easy to learn and use for the non-programmer. Since you found Inform
>easier to use, I guess that speaks for itself).
I suspect a large part of it is just the look of the language. TADS
does use and/or/not instead of &&/||/!, but it still has much less
english than Inform, which has "with" and "has" and "give" scattered
all through the code. On first impression to a non-programmer who's
not used to this sort of thing, this might look less
friendly/accessible. I'm not sure. I know there are some
non-programmer people using TADS out there .. maybe one of them could
post and give their initial impressions of the languages or something?
(there's also the possibility of writing some sort of preprocessor
front end to TADS that would let people use more english-language
commands. I dunno. It might be worth it.)
>Matt Kimball
>mkim...@xmission.com
--
(Dan Shiovitz) (d...@cs.wisc.edu) (look, I have a new e-mail address)
(http://www.cs.wisc.edu/~dbs) (and a new web page also)
(the content, of course, is the same)
David A. Cornelson
I've been working for 13 years in the computer industry and I've run into
the "to C or not to C" argument many a time.
I believe it's simple. Some of were trained to be engineers of systems and
some of were trained to solve problems quickly.
People who sway towards C/C++ or TADS like languages are concerned about
'how' they produce results. They're engineers. They care about the
foundation and want complete control of the product they create.
People who sway away from these languages are more concerned about 'what'
and 'when' they produce results. They see a problem and really care more
about the implementation from the user's point of view than anything else.
In other words, if they could get their job done without coding, they
probably wouldn't code at all.
In my experience, lower level languages like C or TADS (it's my opinion that
TADS is a level down from Inform) require a discipline in programming that
many people don't care to achieve. That's why Visual Basic and now Web
Development is so popular. It's easy.
Your argument that TADS is easy is funny since you yourself say that you're
out of touch with being a new programmer.
I know C too (not C++). I have tried to use TADS (bought it from Mike
Roberts when High-Energy was still in business) and I believe C and TADS are
cryptic and very un-english like.
Inform in it's basic implementation is far simpler to 'learn' than TADS. Of
course when you get into more complicated aspects of developing an IF game
it's probably a wash which language you use because that sort of development
requires much of the discipline I spoke of earlier.
So here's my thought. If you're not interested in becoming a
super-programmer and may end up handing off some of the more difficult
problems to someone else, then Inform is your language.
If you're in no hurry, have a disciplined nature, and want to learn how to
do the really complicated things in your game development, then choose TADS
or Inform. At that point, there equal tools.
Jarbigruen
Matt Kimball wrote in message <6ivhis$mto$1...@news.xmission.com>...
>michael...@ey.com wrote:
>: I'm a big fan of Inform myself. It's easy to learn, easy to read, and
>: the designer's manual is well-written (though a bit incomplete). TADS
>: has many loyal supporters as well, although I think TADS has a more
>: "technical" feel to it. I've heard a number of people say that it's
>: structured more like C++, which is a big pro for real programmers but
>: a massive con for English majors such as myself. I've looked at some
>: sample code and I just feel more comfortable with Inform. If you've
>: had more of a technical background, you might like TADS better.
>
>Frankly, I'm baffled by this paragraph. Admittedly, I haven't written
>a complete work in either, but I have written small programs in both,
>and it seems to me that TADS has a much cleaner design, has a simpler
>language and would be much easier to learn for someone who isn't used
>to hacking C code. (But then again, since I am a programmer by
>profession, I might be out of touch with exactly what is and isn't
>easy to learn and use for the non-programmer. Since you found Inform
>easier to use, I guess that speaks for itself).
>
Matt Kimball
David A. Cornelson <dcorn...@placet.com> wrote:
: In my experience, lower level languages like C or TADS (it's my opinion that
: TADS is a level down from Inform) require a discipline in programming that
: many people don't care to achieve. That's why Visual Basic and now Web
: Development is so popular. It's easy.
With good reason. If your project can be done well with high level
tools, then it probably should be done with high level tools. I don't
dispute any of this. The argument that TADS is a level down from
Inform, well, that I am really confused about. To me, it seems Inform
allows much lower level access to things than TADS. (Inform allows
you to use arbitrary pointers, where TADS doesn't, for instance).
: Your argument that TADS is easy is funny since you yourself say that you're
: out of touch with being a new programmer.
Well, I am not arguing that TADS is easier for non-programmers to
learn. (As I said, I am paid to program C++, so my opinion isn't
worth the bandwith used to propagate it, in this matter). I am just
trying to understand why Inform is easier to learn than TADS for the
non-programmer, because it isn't what I would expect.
: I know C too (not C++). I have tried to use TADS (bought it from Mike
: Roberts when High-Energy was still in business) and I believe C and TADS are
: cryptic and very un-english like.
This is funny to me, because I slightly prefer Inform, ***because it
reminds me of C***. TADS reminds me much more of one of those
procedural languages with a Smalltalk inspired object model, Java,
Objective C, or TOM, for instance.
: Inform in it's basic implementation is far simpler to 'learn' than TADS.
So you say. I am trying to understand why. Is it, as Dan Shovitz
suggested, the English-like syntax?
: If you're in no hurry, have a disciplined nature, and want to learn how to
: do the really complicated things in your game development, then choose TADS
: or Inform. At that point, there equal tools.
Agreed. It is largely a matter of personal taste. (And don't forget
Hugo. It seems to be as capable as the other two).
--
Matt Kimball
mkim...@xmission.com
Ola Sverre Bauge
Dan Shiovitz wrote...
>(there's also the possibility of writing some sort of preprocessor
>front end to TADS that would let people use more english-language
>commands. I dunno. It might be worth it.)
Doesen't C allow you to define, say, 'begin' as a constant synonymous
to, for instance, '{' (I seem to remember this was suggested in a book I
read ages ago to ease the transition for Pascal programmers...). Would
doing Constant not='!=', or whatever that would be in TADS, work? Or is
there some sort of reserved keyword restriction on that, or you can't
define constants as string or whatever...
This is just a hazy memory though, and I've ever only scanned TADS
source briefly some time ago, so I don't really know what I'm talking
about, but isn't that what makes Usenet voluminous?
Anyway, as an Inform newbie, I can confirm that using English words
heightened the appeal for me to use Inform; once I saw the 'n_to
any_room', 'lamp in player' and similiar bits in advent.inf, I was sold.
Incidentally, in the little Inform I've written, I've used '~=', and not
'not'. Then again, I knew the basic basics of C before I started
learning Inform.
Oh, and the TADS cabal in raif might want to make a 'definite' web page
for getting hold of / learning TADS if you want to attract more newbies,
because I was kind of stumped as to which one to surf to reading the FAQ
last winter... still am, actually.
Hmm. Maybe the reason TADS isn't quite as popular as Inform is that has
no 'central administration' that sucks up IF writer wannabes and outputs
TADS newbies like Nelson's Inform page does? Because that's what
happened to me.
Ola Sverre Bauge
o...@bu.telia.no
http://w1.2327.telia.com/~u232700165
Suzanne Skinner
Ola Sverre Bauge <o...@bu.telia.no> wrote:
> Oh, and the TADS cabal in raif might want to make a 'definite' web page
> for getting hold of / learning TADS if you want to attract more newbies,
> because I was kind of stumped as to which one to surf to reading the FAQ
> last winter... still am, actually.
I tend to think of the tela design site as the "canonical" TADS guide on
the web, if there is such a thing. You can find it at
http://www.tela.bc.ca/tela/tads/. (the server there is behaving a bit
weird, so if you get a 404 not found error, try reloading).
-Suzanne
--
http://dominion.cba.csuohio.edu/~tril/
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS d- s--:- a-- C++$ ULHOIS+++$>++++ P+++ L>++ E W+++$ N++(+) !o K++ w---()
!O M-- V-- PS+@ PE@ Y+() PGP- t+ 5+ X+ R !tv(+) b++@ DI++ D--- G++ e++* h->---
r++>+++ x*?
------END GEEK CODE BLOCK------
okbl...@usa.net
In article <6j32c1$j...@newsops.execpc.com>,
> the "to C or not to C" argument many a time.
I have a few years on you. I suspect there are many here who have programmed
for over a decade, in many languages.
> I believe it's simple. Some of were trained to be engineers of systems and
> some of were trained to solve problems quickly.
Some of us were trained, or perhaps more accurately, *learned* to be both.
> People who sway towards C/C++ or TADS like languages are concerned about
> 'how' they produce results. They're engineers. They care about the
> foundation and want complete control of the product they create.
Caring about the foundation and having complete control are not synonymous.
Some would argue that none of the aforementioned languages gives you a proper
foundation on which to work.
> People who sway away from these languages are more concerned about 'what'
> and 'when' they produce results. They see a problem and really care more
> about the implementation from the user's point of view than anything else.
> In other words, if they could get their job done without coding, they
> probably wouldn't code at all.
You mean, they might not be concerned with C's propensity toward obscurity?
With it's poor portability (an int is *how* big)? With the idea that saving a
few characters typing is not worth the easy-to-miss side-effects?
> In my experience, lower level languages like C or TADS (it's my opinion that
> TADS is a level down from Inform) require a discipline in programming that
> many people don't care to achieve. That's why Visual Basic and now Web
> Development is so popular. It's easy.
Programming requires discipline. Some forms allow you to produce results with
very little work (and therefore discipline) but *any* project of *any* size
soon dwarfs the language-level issues for those of greater design, management,
administration, etc., etc., etc.
Yes, it takes more effort (and perhaps therefore discipline) to code a
tic-tac-toe game in C than it does in BASIC. But it takes even *more*
discipline to code one in Assembler. The line you're drawing between BASIC
and C is arbitrary.
So one language requires more discipline than another: All that means is that
whatever work is done by the secretary or the
student-who's-just-fooling-around is maintained by a highly paid programmer.
Regardless of whether the language was COBOL or C.
> I know C too (not C++). I have tried to use TADS (bought it from Mike
> Roberts when High-Energy was still in business) and I believe C and TADS are
> cryptic and very un-english like.
I learned (and used) in order: BASIC, Assembler, PL/I, Pascal, C, REXX,
Smalltalk, C++, Java and a few others too obscure to mention here. I've
studied (and used to a lesser extent) other langauges as well (Eiffel, Oberon,
dBase, etc.). I've met disciplined and (more often) undisciplined
programmers. I've met managers who didn't care about analysis and design--and
more often than not, their decision to use C was based on a desire to "play it
safe" rather than an actual analysis of the problems at hand.
Having lurked here for a while what I've observed about those who work in IF
is that they care about what they do. Probably, as any artist, the IF author
is primarily concerned with results. But this group is smart enough to look
at what the impact of their tools on these results is.
I've been impressed by the responses to "which language is best" here,
personally. They've probably been the most consistenly mature of any
programming forum I've ever seen.
But I ramble.
Darin Johnson
"Ola Sverre Bauge" <o...@bu.telia.no> writes:
> once I saw the 'n_to any_room', 'lamp in player' and similiar bits
> in advent.inf, I was sold.
You like "n_to any_room" better than "north=any_room"?
(Also, you can use "and", "or", and "not" in TADS.)
--
Darin Johnson
da...@usa.net.delete_me
Neil K.
"Ola Sverre Bauge" <o...@bu.telia.no> wrote:
> Hmm. Maybe the reason TADS isn't quite as popular as Inform is that has
> no 'central administration' that sucks up IF writer wannabes and outputs
> TADS newbies like Nelson's Inform page does? Because that's what
> happened to me.
Uh. I put together a TADS page over two years ago:
http://www.tela.bc.ca/tela/tads/
Naturally I'm too close to it to have an objective opinion, but I'd like
to think it does a pretty good job of presenting the most important bits
of TADS info to the novice user in an accessible fashion. Comments are, of
course, always welcome.
- Neil K.
--
t e l a computer consulting + design * Vancouver, BC, Canada
web: http://www.tela.bc.ca/tela/ * email: tela @ tela.bc.ca
JC
[I didn't get David's post on my server, so I'm replying to it here]
On 10 May 1998 02:46:58 GMT, Matt Kimball <mkim...@xmission.com> wrote:
>David A. Cornelson <dcorn...@placet.com> wrote:
>: In my experience, lower level languages like C or TADS (it's my opinion that
>: TADS is a level down from Inform) require a discipline in programming that
>: many people don't care to achieve. [...]
As a language, Inform is has more lower level features than TADS, and
having used both -- abeit Inform less -- I can't see how you could call
TADS lower-level.
>: Your argument that TADS is easy is funny since you yourself say that you're
>: out of touch with being a new programmer.
>
>Well, I am not arguing that TADS is easier for non-programmers to
>learn. (As I said, I am paid to program C++, so my opinion isn't
>worth the bandwith used to propagate it, in this matter). I am just
>trying to understand why Inform is easier to learn than TADS for the
>non-programmer, because it isn't what I would expect.
I think that Inform is probably easier to learn for the non-programmer *at
first*, because it is so set up for making Infocom-like IF. Stuff like
having the special room for thedark, objects having a single deamon
routine, etc. Because you have a lot of IF concepts made explicit in the
libraries it is easier to learn the simple tasks. However, the price to
pay for this is realised when you want to do something of decent size with
it which will no-doubt have have non-default behaviour.
>: I know C too (not C++). I have tried to use TADS (bought it from Mike
>: Roberts when High-Energy was still in business) and I believe C and TADS are
>: cryptic and very un-english like.
More cryptic? I honestly can not see how TADS could be described as being
more cryptic than Inform. Inform seems to be full of cryptic syntax, and
worse, syntax which depends on context. What is more cryptic about TADS
than Inform?
I also question the value of a language being "english like". I don't
think this plays much of a part in how easy a language is to use or learn;
that sort of view is rather simplistic, IMO. Cobol is quite "english
like".
[...]
>: Inform in it's basic implementation is far simpler to 'learn' than TADS.
Basic implementation, I'm not sure what you mean? As I said above, I think
that Inform is easier to learn at first (but at first only), because it is
very "set up" for Infocom-like IF.[...]
';';James';';
Darin Johnson
jrc...@netspace.net.au (JC) writes:
> As a language, Inform is has more lower level features than TADS, and
> having used both -- abeit Inform less -- I can't see how you could call
> TADS lower-level.
Yeah, I was wondering about that too. I think maybe if people see
"has" and "give", they think it's high level?
Inform is *very* close to the Z-machine level. The amount of
abstraction is much less than with TADS. This is *not* necessarily
good or bad. Of course, TADS is probably close to its machine level,
but the TADS virtual machine is much higher level than the Z machine.
TADS isn't really high level though, it's a medium level language
(I still wish TADS had closures :-).
Now, whether a language is high level or low level says very little
about how easy it is to learn or use. High level languages usually
require the programmer to think more abstractly, and many people have
trouble with that, while it comes naturally to others.
--
Darin Johnson
da...@usa.net.delete_me
David Glasser
Ola Sverre Bauge <o...@bu.telia.no> wrote:
> Dan Shiovitz wrote...
> >(there's also the possibility of writing some sort of preprocessor
> >front end to TADS that would let people use more english-language
> >commands. I dunno. It might be worth it.)
>
> Doesen't C allow you to define, say, 'begin' as a constant synonymous
> to, for instance, '{' (I seem to remember this was suggested in a book I
> read ages ago to ease the transition for Pascal programmers...). Would
> doing Constant not='!=', or whatever that would be in TADS, work? Or is
> there some sort of reserved keyword restriction on that, or you can't
> define constants as string or whatever...
Here's the thing. In C or TADS, you can do
#define := =
and have all :='s replaced by the = operator. (Yes, I realize TADS
already uses :=.) Inform only allows Constants to be the equivalent of
a Constant variable, not a preprocessor command.
Constant := =;
will not replace all :='s with ='s; it will simply make Inform choke.
One thing I'd like in Inform is a better preprocessor.
<RANT>
Here's my problem with Inform (which I do, for various reasons,
currently prefer for writing to TADS). In TADS, you define objects.
Once in a while you define standalone functions. There are a few
assorted statements like compoundword, and a good preprocesor.
Inform has dozens of different "Directives", and a horrible
preprocessor. It feels so...proprietary. (I disliked the fact that you
can't get from 'Foo' to &verDoFoo yourself in TADS, but Inform is crazy
this way!)
</RANT>
> This is just a hazy memory though, and I've ever only scanned TADS
> source briefly some time ago, so I don't really know what I'm talking
> about, but isn't that what makes Usenet voluminous?
>
> Anyway, as an Inform newbie, I can confirm that using English words
> heightened the appeal for me to use Inform; once I saw the 'n_to
> any_room', 'lamp in player' and similiar bits in advent.inf, I was sold.
Of course, this just tricks you. Because "in" doesn't really determine
'in-ness'; if a lamp is in a bag which is in the player, (lamp in
player) ~= true.
> Incidentally, in the little Inform I've written, I've used '~=', and not
> 'not'. Then again, I knew the basic basics of C before I started
> learning Inform.
That's probably because you can't use not.
> Oh, and the TADS cabal in raif might want to make a 'definite' web page
> for getting hold of / learning TADS if you want to attract more newbies,
> because I was kind of stumped as to which one to surf to reading the FAQ
> last winter... still am, actually.
Try http://www.tela.bc.ca/tela/tads/. Very good.
> Hmm. Maybe the reason TADS isn't quite as popular as Inform is that has
> no 'central administration' that sucks up IF writer wannabes and outputs
> TADS newbies like Nelson's Inform page does? Because that's what
> happened to me.
What ever happened to Graham, anyway? You still here?
--David Glasser
gla...@NOSPAMuscom.com | dgla...@NOSPAMfcs.pvt.k12.pa.us
http://onramp.uscom.com/~glasser | http://www.geocities.com/SoHo/6028
DGlasser @ ifMUD : fovea.retina.net:4000 (webpage fovea.retina.net:4001)
Interactive Fiction! MST3K! David Eddings! Macintosh!
Andrew Plotkin
David Glasser (gla...@NOSPAMuscom.com) wrote:
> Here's the thing. In C or TADS, you can do
>
> #define := =
>
> and have all :='s replaced by the = operator. (Yes, I realize TADS
> already uses :=.)
Actually, this doesn't work in C. C preprocessor macros have to be C
identifiers (letters, digits, and underscores, and you can't start with a
digit.) No punctuation.
> Inform only allows Constants to be the equivalent of
> a Constant variable, not a preprocessor command.
> Constant := =;
> will not replace all :='s with ='s; it will simply make Inform choke.
> One thing I'd like in Inform is a better preprocessor.
Inform doesn't *have* a preprocessor at all. Directives like ifdef are
part of the language, not an earlier step.
It's a lot less powerful than the C preprocessor. On the other hand, you
could easily rig a Makefile to use cpp on your Inform files. (In Unix,
anyway.) If it floats your boat, go for it.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Neil K.
jrc...@netspace.net.au (JC) wrote:
> More cryptic? I honestly can not see how TADS could be described as being
> more cryptic than Inform. Inform seems to be full of cryptic syntax, and
> worse, syntax which depends on context. What is more cryptic about TADS
> than Inform?
Well.. my take on this... I think it has a lot to do with which language
you learnt first. I think TADS and Inform are both somewhat cryptic. TADS
has more {}s, and Inform looks tidier in that respect. But really, battles
over which is easier to read is a bit like whether it makes more sense to
put the hot tap on the left or the right.
That isn't to say there aren't genuine functional differences between the
two systems that manifest themselves in terms of strengths and weaknesses.
But I think that most of the quibbling over style has a lot more to do
with familiarity and personal inclination than anything else.
David A. Cornelson
Thank you Neil. I should have said this myself. It constantly amazes me that
some people find C an easy language and I laugh when people say that Basic
(and it's derivitives) is a waste of time.
Why? Because I see it the exact opposite way.
Go figure.
Jarbigruen
Neil K. wrote in message ...
> jrc...@netspace.net.au (JC) wrote:
>
>> More cryptic? I honestly can not see how TADS could be described as
being
>> more cryptic than Inform. Inform seems to be full of cryptic syntax, and
>
> Well.. my take on this... I think it has a lot to do with which language
>you learnt first. I think TADS and Inform are both somewhat cryptic. TADS
>
> - Neil K.
Gunther Schmidl
>some people find C an easy language and I laugh when people say that Basic
>(and it's derivitives) is a waste of time.
>Why? Because I see it the exact opposite way.
>Go figure.
Yay!
I can only agree.
--
+------------------------+----------------------------------------------+
+ Gunther Schmidl + "I want a Blorb compatible interpreter. Now. +
+ Ferd.-Markl-Str. 39/16 + Please. Come on. Do it. Now." -- myself +
+ A-4040 LINZ +----------------------------------------------+
+ Tel: 0732 25 28 57 + http://gschmidl.home.ml.org - new & improved +
+------------------------+---+------------------------------------------+
+ sothoth (at) usa (dot) net + please remove the "xxx." before replying +
+----------------------------+------------------------------------------+
Adam J. Thornton
In article <erkyrathE...@netcom.com>,
Andrew Plotkin <erky...@netcom.com> wrote:
>It's a lot less powerful than the C preprocessor. On the other hand, you
>could easily rig a Makefile to use cpp on your Inform files. (In Unix,
>anyway.) If it floats your boat, go for it.
More generally, m4. That'd be my choice if I wanted a versatile
preprocessing front end.
Adam
--
ad...@princeton.edu
"There's a border to somewhere waiting, and a tank full of time." - J. Steinman
Allen Garvin
In article <6j32c1$j...@newsops.execpc.com>,
David A. Cornelson <dcorn...@placet.com> wrote:
In my experience, lower level languages like C or TADS (it's my
opinion that TADS is a level down from Inform) require a discipline
A peculiar opinion, as Inform gives you much more control. In TADS, the
parser is hidden away deep in the source of the compiler, but in Inform
it's in the libraries and modifiable by the advanced Inform programmer;
Inform allows you to use very low level Z-machine assembly code. TADS may
look a bit more cryptic, but Inform is much closer to giving one the
power of C.
Crypticity (fun new word!) is not necessarily directly related to power.
You won't find many more cryptic languages than APL, but it's definitely
on a higher level than (and not nearly as powerful in general as) C.
--
Allen Garvin kisses are a better fate
--------------------------------------------- than wisdom
eare...@faeryland.tamu-commerce.edu
http://faeryland.tamu-commerce.edu/~earendil e e cummings
Trevor Barrie
In article <3558179...@news.netspace.net.au>,
JC <jrc...@netspace.net.au> wrote:
>I also question the value of a language being "english like". I don't
>think this plays much of a part in how easy a language is to use or learn;
>that sort of view is rather simplistic, IMO. Cobol is quite "english
>like".
I think being "English like" can certainly help a language be easy to learn,
but it doesn't do a thing to make it easier to use (often the opposite). Of,
course "ease of use" and "ease of learning" are often treated as the same
thing, which confuses these sorts of discussions (in practice, the two are
often in conflict.)
David A. Cornelson
I think I will retract my statements about TADS being lower-level. It's just
cryptic. To me. For all of you, I'm sure it's a beautiful and elegant
programming language.
Jarb
David Glasser
JC <jrc...@netspace.net.au> wrote:
> [I didn't get David's post on my server, so I'm replying to it here]
>
> On 10 May 1998 02:46:58 GMT, Matt Kimball <mkim...@xmission.com> wrote:
>
> >David A. Cornelson <dcorn...@placet.com> wrote:
> >: In my experience, lower level languages like C or TADS (it's my opinion
> >: that TADS is a level down from Inform) require a discipline in
> >: programming that many people don't care to achieve. [...]
>
> As a language, Inform is has more lower level features than TADS, and
> having used both -- abeit Inform less -- I can't see how you could call
> TADS lower-level.
I could argue this both ways. On one hand, Inform/ZMachine is
higher-level, because of all its Directives and statements that do
high-level things (it has an internal object tree, directives that
change how the status line is defined, preprocessor part of the
Directives, etc.). On the other hand, it is low level: you frequently
have to "typecast" variables in print strings, and can mess with memory
(sort of). And TADS is high enough to have lists (as opposed to arrays)
and a (proprietary!) built-in parser.
> >: Your argument that TADS is easy is funny since you yourself say that you're
> >: out of touch with being a new programmer.
> >
> >Well, I am not arguing that TADS is easier for non-programmers to
> >learn. (As I said, I am paid to program C++, so my opinion isn't
> >worth the bandwith used to propagate it, in this matter). I am just
> >trying to understand why Inform is easier to learn than TADS for the
> >non-programmer, because it isn't what I would expect.
>
> I think that Inform is probably easier to learn for the non-programmer *at
> first*, because it is so set up for making Infocom-like IF. Stuff like
> having the special room for thedark, objects having a single deamon
> routine, etc. Because you have a lot of IF concepts made explicit in the
> libraries it is easier to learn the simple tasks. However, the price to
> pay for this is realised when you want to do something of decent size with
> it which will no-doubt have have non-default behaviour.
Same with TADS, really.
> >: I know C too (not C++). I have tried to use TADS (bought it from Mike
> >: Roberts when High-Energy was still in business) and I believe C and
> >: TADS are cryptic and very un-english like.
>
> More cryptic? I honestly can not see how TADS could be described as being
> more cryptic than Inform. Inform seems to be full of cryptic syntax, and
> worse, syntax which depends on context. What is more cryptic about TADS
> than Inform?
>
> I also question the value of a language being "english like". I don't
> think this plays much of a part in how easy a language is to use or learn;
> that sort of view is rather simplistic, IMO. Cobol is quite "english
> like".
To agree with you, here's a quote from everybody's favorite source, the
New Hacker's Dictionary (aka Jargon File; you can get to its web page
from http://sagan.earthspace.net/~esr; version 4.0.0, physical edition
3): candygrammar.
A programming-language grammar that is mostly syntactic sugar; the term
is also a play on 'candygram'. COBOL, Apple's Hypertalk language, and a
lot of the so-called '4GL' database languages share this property. The
usual intent of such designs is that they be as English-like as
possible, on the theory that they will be easier for unskilled people to
program. This intention comes to grief on the reality that syntax isn't
what makes programming hard; it's the mental effort and organization
required to specify and algorithm precisely that costs. Thus the
invariable result is that 'candygrammar' languages are just as difficult
to program in as terser ones, and far more painful for the experienced
hacker.
(snip SNL/Jaws reference)
Also, the built-in object tree *really* annoys me. TADS allows you to
do something like this:
location = {
if (self.hasbeenfoobarred)
return here;
else return there;
}
Inform requires that every time you set hasbeenfoobarred, you must do a
"move" command. This is anti-OO, IMHO. Though I suppose a
object.doallfoobarstuff can be done.
Oh, and TADS encourages (forces, in the default library and WorldClass)
a base "Thing" class for objects, so if you want to give every object a
certain property, simply add it to the Thing definition. In Inform,
this is possible (I do that), but added to the fact that
foo.undefinedproperty crashes the ZMachine, it is annoying. Plus,
people talk about how great Inform's parser and libraries are, because
they are written in Inform code and can be changed. Not quite. Not
only are some key things hard-coded in ZMachine (text entry not at the
prompt is a million times easier in TADS; and @tokenize is built-in,
too), but massive changes in the library require massive changes in the
parser. In TADS, a new library (WorldClass, for instance) doesn't
require changing the parser. And there are many places where you can
"jump in" in the TADS parsing cycle. It's just that they aren't
documented well enough, and can be buggy.
Even though there is all that, I do prefer Inform for several reasons.
TADS is slightly buggy, and many features (more than even Inform) are
counter-intuitive. And vocabulary is evil (why can't it just be a
[list] of 'word's? though Inform is tricky there, too). And I've
learned too much Inform lately.
This has been a presentation of DGlasser Public Rants.
David Glasser
Andrew Plotkin <erky...@netcom.com> wrote:
> David Glasser (gla...@NOSPAMuscom.com) wrote:
>
> > Here's the thing. In C or TADS, you can do
> >
> > #define := =
> >
> > and have all :='s replaced by the = operator. (Yes, I realize TADS
> > already uses :=.)
>
> Actually, this doesn't work in C. C preprocessor macros have to be C
> identifiers (letters, digits, and underscores, and you can't start with a
> digit.) No punctuation.
Ok, yes. But it still is better in TADS than in Inform.
> > Inform only allows Constants to be the equivalent of
> > a Constant variable, not a preprocessor command.
>
> > Constant := =;
>
> > will not replace all :='s with ='s; it will simply make Inform choke.
> > One thing I'd like in Inform is a better preprocessor.
>
> Inform doesn't *have* a preprocessor at all. Directives like ifdef are
> part of the language, not an earlier step.
Yeah, I understand that, and that's my point.
> It's a lot less powerful than the C preprocessor. On the other hand, you
> could easily rig a Makefile to use cpp on your Inform files. (In Unix,
> anyway.) If it floats your boat, go for it.
"In Unix" is the key point. I suppose if the source to the Mac inform
was public, I could rig up my own preprocessor to it.
JC
>Thank you Neil. I should have said this myself. It constantly amazes me that
>some people find C an easy language and I laugh when people say that Basic
>(and it's derivitives) is a waste of time.
>Why? Because I see it the exact opposite way.
>Go figure.
>Jarbigruen
Err, excuse me, I did not say that C is an easy language. I find this
insulting because that is the last thing I would think or say; I know the
difficulties C can give beginners, and experienced programmers, very well.
Now, if we would please address the question at hand, whether TADS is more
cryptic than Inform.
>Neil K. wrote in message ...
>> jrc...@netspace.net.au (JC) wrote:
>>> More cryptic? I honestly can not see how TADS could be described as
>>>being more cryptic than Inform. Inform seems to be full of cryptic
>>>syntax, and
>> Well.. my take on this... I think it has a lot to do with which language
>>you learnt first. I think TADS and Inform are both somewhat cryptic. TADS
I agree that both TADS and Inform are both somewhat cryptic, but Inform has
far more cryptic syntax than TADS. Plus it is more inconsistant.
';';James';';
JC
On Wed, 13 May 1998 gla...@NOSPAMuscom.com (David Glasser) wrote:
>JC <jrc...@netspace.net.au> wrote:
>> >David A. Cornelson <dcorn...@placet.com> wrote:
>> As a language, Inform is has more lower level features than TADS, and
>> having used both -- abeit Inform less -- I can't see how you could call
>> TADS lower-level.
>I could argue this both ways. On one hand, Inform/ZMachine is
>higher-level, because of all its Directives and statements that do
>high-level things (it has an internal object tree, directives that
>change how the status line is defined, preprocessor part of the
>Directives, etc.).
I question a lot of these things being used to call the language
higher-level.
>On the other hand, it is low level: you frequently
>have to "typecast" variables in print strings, and can mess with memory
>(sort of). And TADS is high enough to have lists (as opposed to arrays)
>and a (proprietary!) built-in parser.
You yourself don't mention any low-level features for TADS, or which Inform
does have.
>> >: Your argument that TADS is easy is funny since you yourself say that you're
>> >: out of touch with being a new programmer.
>> >Well, I am not arguing that TADS is easier for non-programmers to
>> >learn. (As I said, I am paid to program C++, so my opinion isn't
>> >worth the bandwith used to propagate it, in this matter). I am just
>> >trying to understand why Inform is easier to learn than TADS for the
>> >non-programmer, because it isn't what I would expect.
>> I think that Inform is probably easier to learn for the non-programmer *at
>> first*, because it is so set up for making Infocom-like IF. Stuff like
>> having the special room for thedark, objects having a single deamon
>> routine, etc. Because you have a lot of IF concepts made explicit in the
>> libraries it is easier to learn the simple tasks. However, the price to
>> pay for this is realised when you want to do something of decent size with
>> it which will no-doubt have have non-default behaviour.
>Same with TADS, really.
Yes, but to no-way near the same extent.
';';James';';
JC
On Wed, 13 May 1998 03:02:07 GMT, fake...@anti-spam.address (Neil K.)
wrote:
> jrc...@netspace.net.au (JC) wrote:
>> More cryptic? I honestly can not see how TADS could be described as being
>> more cryptic than Inform. Inform seems to be full of cryptic syntax, and
>> worse, syntax which depends on context. What is more cryptic about TADS
>> than Inform?
> Well.. my take on this... I think it has a lot to do with which language
>you learnt first. I think TADS and Inform are both somewhat cryptic. TADS
>has more {}s, and Inform looks tidier in that respect.
There is a difference between 'looks tidier' and 'less cryptic'.
> But really, battles
>over which is easier to read is a bit like whether it makes more sense to
>put the hot tap on the left or the right.
> That isn't to say there aren't genuine functional differences between the
>two systems that manifest themselves in terms of strengths and weaknesses.
>But I think that most of the quibbling over style has a lot more to do
>with familiarity and personal inclination than anything else.
We aren't talking about style, but how cryptic a language is. How many
people here would say that C and Pascal are equally cryptic? I'd say most
would disagree. This aspect of a language *is* important -- functionailty
is not the only thing -- and it is quantifiable to an extent.
Weird syntax for printing special characters cryptic; inconsistant syntax
is cryptic; context dependant syntax is cryptic, etc. All these things are
going to make it harder to learn the language, to write programs in it, and
are inducing to errors.
';';James';';
Darin Johnson
> > Well.. my take on this... I think it has a lot to do with which language
> >you learnt first. I think TADS and Inform are both somewhat cryptic. TADS
> >has more {}s, and Inform looks tidier in that respect.
>
> There is a difference between 'looks tidier' and 'less cryptic'.
True. Lisp is a very tidy language, yet is chock full of
parentheses.
Last time I toyed with the idea of writing an IF engine, I also toyed
with the idea of making the syntax lisp-like. But then I realized I'd
have to put up with all the people who think TADS is cryptic wanting
to lynch me...
> > But really, battles
> >over which is easier to read is a bit like whether it makes more sense to
> >put the hot tap on the left or the right.
I think a big issue some people may be confusing, is how difficult a
language is in order to learn the "model" behind it. This is
unrelated to readability, cryptic keywords, punctuation, etc.
If the language's "model" is straightforward, then once novices learn
the model, they won't be completely stumped when they run across an
unfamiliar concept. If the model is too difficult to pick up, or
involves too many special cases, then many programmers will be
programming via patterns, templates, and skeleton code, rather than
expanding upon existing ideas.
For instance, take C's "for" statement. Many novices use a pattern
such as "for (i=0; i<10; i++)", but are unable to extend the idea of a
"for" statement for different purposes (traversing a list, etc).
In my view, TADS has a simpler model in most areas.
--
Darin Johnson
da...@usa.net.delete_me
Allen Garvin
In article <6jd4op$g...@newsops.execpc.com>,
Nah, I think it's kind of ugly. Everyone knows Lisp is the only beautiful
programming language. Sort of like everyone knows rec.arts.int-fiction'ers
are a quarrelsome bunch of nitpickers whenever anyone brings up one of our
traditional religious wars.
David A. Cornelson
JC wrote in message <355a3329...@news.netspace.net.au>...
>On Wed, 13 May 1998 03:02:07 GMT, fake...@anti-spam.address (Neil K.)
>wrote:
>
>> jrc...@netspace.net.au (JC) wrote:
<snip>
>Weird syntax for printing special characters cryptic; inconsistant syntax
>is cryptic; context dependant syntax is cryptic, etc. All these things are
>going to make it harder to learn the language, to write programs in it, and
>are inducing to errors.
Cryptic is subjective. What I was saying was this. What is understandable
and easy for some, is cryptic and difficult to others and vice versa.
You cannot define cryptic to all of us any more than you could be the judge
of all of our games.
Again. To me. C and Tads are cryptic and Inform is less cryptic.
And I was _not_ saying C is easy. It was an analogy.
Jarb
Magnus Olsson
In article <1d8zcfh.1wujg5nsmrdraN@[209.186.16.240]>,
David Glasser <gla...@NOSPAMuscom.com> wrote:
>Andrew Plotkin <erky...@netcom.com> wrote:
>> It's a lot less powerful than the C preprocessor. On the other hand, you
>> could easily rig a Makefile to use cpp on your Inform files. (In Unix,
>> anyway.) If it floats your boat, go for it.
>
>"In Unix" is the key point. I suppose if the source to the Mac inform
>was public, I could rig up my own preprocessor to it.
There really shouldn't be any need to hack the Inform sources: what
you need is some way of automatically running the preprocessor on your
source code, and then running the Inform compiler on the output, all
with one command (or one click).
--
Magnus Olsson (m...@df.lth.se, zeb...@pobox.com)
------ http://www.pobox.com/~zebulon ------
rc...@my-dejanews.com
In article <tvy7m3p...@cn1.connectnet.com>,
Darin Johnson <da...@usa.net.removethis> wrote:
>
> Last time I toyed with the idea of writing an IF engine, I also toyed
> with the idea of making the syntax lisp-like. But then I realized I'd
> have to put up with all the people who think TADS is cryptic wanting
> to lynch me...
>
If you want a Lisp-like IF engine, look at GINAS (located on GMD). It was
written several years ago by a coworker of mine, Jeff Standish, and I don't
think any games have ever been completed for it. He said he had almost
completed a port of Adventure, though.
--Randy
Erik Max Francis
rc...@my-dejanews.com wrote:
> If you want a Lisp-like IF engine, look at GINAS (located on GMD). It
> was
> written several years ago by a coworker of mine, Jeff Standish, and I
> don't
> think any games have ever been completed for it. He said he had
> almost
> completed a port of Adventure, though.
I was also exploring the possibility of making a LISP-like adventure
generating system, and then I found advsys, and lost my steam . . .
--
Erik Max Francis, &tSftDotIotE / mailto:m...@alcyone.com
Alcyone Systems / http://www.alcyone.com/max/
San Jose, California, United States / icbm:+37.20.07/-121.53.38
\
"Since when can wounded eyes see / If we weren't who we were"
/ Joi
peter....@natinst.com
Erik Max Francis <m...@alcyone.com> writes:
There's also Drool by David Betz (I think). Which was supposed to become
an adventure authoring system for his little daughter but apparently it
never made it beyond its humble beginnings in Dr Dobbs. The language is
working however and it looks like object-oriented scheme.
Peter
> rc...@my-dejanews.com wrote:
>
> > If you want a Lisp-like IF engine, look at GINAS (located on GMD). It
> > was
> > written several years ago by a coworker of mine, Jeff Standish, and I
> > don't
> > think any games have ever been completed for it. He said he had
> > almost
> > completed a port of Adventure, though.
-- Peter Ilberg <peter....@natinst.com>
David Glasser
Magnus Olsson <m...@bartlet.df.lth.se> wrote:
> In article <1d8zcfh.1wujg5nsmrdraN@[209.186.16.240]>,
> David Glasser <gla...@NOSPAMuscom.com> wrote:
> >Andrew Plotkin <erky...@netcom.com> wrote:
> >> It's a lot less powerful than the C preprocessor. On the other hand, you
> >> could easily rig a Makefile to use cpp on your Inform files. (In Unix,
> >> anyway.) If it floats your boat, go for it.
> >
> >"In Unix" is the key point. I suppose if the source to the Mac inform
> >was public, I could rig up my own preprocessor to it.
>
> There really shouldn't be any need to hack the Inform sources: what
> you need is some way of automatically running the preprocessor on your
> source code, and then running the Inform compiler on the output, all
> with one command (or one click).
That's my point. That type of thing doesn't work well on the Mac, but
if the MacOS source was open, I could stick in a call to a preprocessor
before compilation.
Darin Johnson
rc...@my-dejanews.com writes:
> If you want a Lisp-like IF engine, look at GINAS (located on GMD).
I didn't want it lisp-like solely to have a lisp-like engine.
I wanted it so that I didn't have to worry about syntax issues,
changing the parser if I added new constructs or keywords, etc.
There were others ideas for the engine itself independent of the
syntax.
I think also DDL was very lisp-ish.
--
Darin Johnson
da...@usa.net.delete_me
David Glasser
Allen Garvin <eare...@faeryland.tamu-commerce.edu> wrote:
> In article <6j32c1$j...@newsops.execpc.com>,
> David A. Cornelson <dcorn...@placet.com> wrote:
> In my experience, lower level languages like C or TADS (it's my
> opinion that TADS is a level down from Inform) require a discipline
>
> A peculiar opinion, as Inform gives you much more control. In TADS, the
> parser is hidden away deep in the source of the compiler, but in Inform
> it's in the libraries and modifiable by the advanced Inform programmer;
> Inform allows you to use very low level Z-machine assembly code. TADS may
> look a bit more cryptic, but Inform is much closer to giving one the
> power of C.
However, much of TADS can be extended through various entry points.
Also, the Inform Library does not love having its parser tweaked too
much; and some of the parser is built in to the ZMachine (@tokenize, for
instance).
> Crypticity (fun new word!) is not necessarily directly related to power.
> You won't find many more cryptic languages than APL, but it's definitely
> on a higher level than (and not nearly as powerful in general as) C.
And some languages, like Perl, can end up both ways. You can write Perl
code that people who have never programmed in Perl can understand, and
you can write Perl code without using a single alphanumeric character.
(Other languages can do this too, of course.)
One question: am I correct to believe that the lower the level, the more
a statement translates directly into assembly/the lowest level? In that
case, TADS is definitely lower, as (I believe) TADS files are stored in
OO form, but all objects are lost when converted to ZCode. (Well, there
still is an object tree, but the objects don't contain as much as in the
source, right?)
(One note. Dan Shiovitz has wondered about my anti-Inform posts in the
past few days. The thing is, TADS is a better language. Inform works
better, though. Programming in Inform tends to be full of hacks, and
TADS on a better level. No language is perfect, of course. This is all
IMHO.)
Matthew T. Russotto
In article <1d912zi.135...@usol-phl-pa-060.uscom.com>,
David Glasser <gla...@NOSPAMuscom.com> wrote:
}> There really shouldn't be any need to hack the Inform sources: what
}> you need is some way of automatically running the preprocessor on your
}> source code, and then running the Inform compiler on the output, all
}> with one command (or one click).
}
}That's my point. That type of thing doesn't work well on the Mac, but
}if the MacOS source was open, I could stick in a call to a preprocessor
}before compilation.
Three letters. 'M' 'P' 'W'.
Most of the Inform goofing around I've done has been with the MPW
version, compiled more or less directly from Graham's sources. And
it's easy to add a preprocessor that way.
--
Matthew T. Russotto russ...@pond.com
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."
Darin Johnson
peter....@natinst.com writes:
> There's also Drool by David Betz (I think). Which was supposed to become
> an adventure authoring system for his little daughter but apparently it
> never made it beyond its humble beginnings in Dr Dobbs. The language is
> working however and it looks like object-oriented scheme.
David wrote an OO version of Lisp called XLisp. I think Drool was
an extension of that. I've never seen it though.
--
Darin Johnson
da...@usa.net.delete_me
GLYPH
David Glasser wrote:
> However, much of TADS can be extended through various entry points.
> Also, the Inform Library does not love having its parser tweaked too
> much; and some of the parser is built in to the ZMachine (@tokenize, for
> instance).
It depends on how you tweak it :)
- GLYPH
JC
On Thu, 14 May 1998 "David A. Cornelson" <dcorn...@placet.com> wrote:
>JC wrote in message <355a3329...@news.netspace.net.au>...
>>On Wed, 13 May 1998 03:02:07 GMT, fake...@anti-spam.address (Neil K.)
>>wrote:
>>
>>> jrc...@netspace.net.au (JC) wrote:
>
><snip>
>
>>Weird syntax for printing special characters cryptic; inconsistant syntax
>>is cryptic; context dependant syntax is cryptic, etc. All these things are
>>going to make it harder to learn the language, to write programs in it, and
>>are inducing to errors.
>
>Cryptic is subjective.
Rubbish. Are you trying to say that Assembler or C are more cryptic than
Pascal for purely subjective matters? Subjectivity plays a small part, but
how cryptic something is can be quantified to an extent.
>What I was saying was this. What is understandable
>and easy for some, is cryptic and difficult to others and vice versa.
>
>You cannot define cryptic to all of us any more than you could be the judge
>of all of our games.
>Again. To me. C and Tads are cryptic and Inform is less cryptic.
>
>And I was _not_ saying C is easy. It was an analogy.
What are you talking about? Where did I say that you had?
';';James';';
Andrew Plotkin
David Glasser (gla...@NOSPAMuscom.com) wrote:
> Also, the Inform Library does not love having its parser tweaked too
> much;
Depends, as someone said, on the tweaks. Tweaking any piece of complex
code is hard. But it's never impossible.
> and some of the parser is built in to the ZMachine (@tokenize, for
> instance).
You can bypass the built-in @tokenize if you want.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
David A. Cornelson
JC wrote in message <355c3e1...@news.netspace.net.au>...
>On Thu, 14 May 1998 "David A. Cornelson" <dcorn...@placet.com> wrote:
>
>>JC wrote in message <355a3329...@news.netspace.net.au>...
>>>On Wed, 13 May 1998 03:02:07 GMT, fake...@anti-spam.address (Neil K.)
>>>wrote:
>>>
>>>> jrc...@netspace.net.au (JC) wrote:
>>
>><snip>
>>
>>
>>Cryptic is subjective.
>
>Rubbish. Are you trying to say that Assembler or C are more cryptic than
>Pascal for purely subjective matters? Subjectivity plays a small part, but
>how cryptic something is can be quantified to an extent.
Poppycock. I know a few coders that fear C/Basic/Pascal more than anything
in the whole world. They see a world without Assembly language or even raw
1's and 0's as a world without purpose and meaning.
What is difficult to one person may be inherent to another.
You make a lot of assumptions based on _your own_ preconceived ideas and
learning habits. Please. Put yourself in the shoes of a programmer who knows
nothing but binary encoding and assembly language. A person like that would
rather learn the opcodes for the z-machine and code a whole game with a hex
editor.
Nothing personal, but you need to open your mind to _other_ possibilities.
But I'm sure to you, none of this is subjective. that's your _opinion_. Not
mine.
Jarb
Allen Garvin
In article <tvyyaw4...@cn1.connectnet.com>,
There's a copy of it at GMD. I remember reading about it in Dr. Dobb's
a few years ago, and excitedly downloading it from their ftp site, but I
never got it to compile at the time. I think I remember it having too
many Mac'isms. Then Tads and Inform came out shortly afterwards, so it
didn't matter.
Didn't he also write another adventure creation language in the 80's that
was rather simplistic?
John Elliott
Darin Johnson <da...@usa.net.removethis> wrote:
>TADS isn't really high level though, it's a medium level language
>(I still wish TADS had closures :-).
I once wrote an adventure game of sorts in a functional language (Orwell).
Functional languages are very high level, but that didn't mean it was
remotely suitable for implementing IF.
I did it for a Computation practical in 1993, which required me to write
a program finding the shortest, lowest cost etc. path between vertices of
a connected graph. Having some time spare, I added an adventure-game style
interface and portable objects. The result is a large empty map around
which you could wander creating objects, picking them up and putting them
down again. Rather than use compass directions, you used "GO <adjacent room>";
the shortest-path and cheapest-path functions were available as
"SGO <any room>" and "MGO <any room>" respectively.
The game's only use is a proof that you can write IF in a functional
language. Or as the basis for a port of "Detective" to Orwell.
------------- http://www.seasip.demon.co.uk/index.html --------------------
John Elliott |BLOODNOK: "But why have you got such a long face?"
|SEAGOON: "Heavy dentures, Sir!" - The Goon Show
:-------------------------------------------------------------------------)
David Glasser
Matthew T. Russotto <russ...@wanda.pond.com> wrote:
> In article <1d912zi.135...@usol-phl-pa-060.uscom.com>,
> David Glasser <gla...@NOSPAMuscom.com> wrote:
>
> }> There really shouldn't be any need to hack the Inform sources: what
> }> you need is some way of automatically running the preprocessor on your
> }> source code, and then running the Inform compiler on the output, all
> }> with one command (or one click).
> }
> }That's my point. That type of thing doesn't work well on the Mac, but
> }if the MacOS source was open, I could stick in a call to a preprocessor
> }before compilation.
>
> Three letters. 'M' 'P' 'W'.
>
> Most of the Inform goofing around I've done has been with the MPW
> version, compiled more or less directly from Graham's sources. And
> it's easy to add a preprocessor that way.
The problem is, each of the four or more times I have downloaded and
installed MPW (a few weeks ago, last), I end up deleting it to make room
for something else. Maybe when I get more storage.
Greg Ewing
Matthew T. Russotto wrote:
>
> }That's my point. That type of thing doesn't work well on the Mac, but
> }if the MacOS source was open, I could stick in a call to a preprocessor
> }before compilation.
>
> Three letters. 'M' 'P' 'W'.
Or Applescript, if the preprocessor and compiler are
both scriptable. I don't know whether the Mac Inform
compiler is, but if it isn't, it should be!
Another cool idea might be a version of Inform as
a CodeWarrior IDE plug-in...
--
Greg Ewing, Computer Science Dept, | The address below is
spam-protected.
University of Canterbury, | To decode it, replace "splodge" with "."
Christchurch, New Zealand | and "curly" with "@".
greg curly cosc splodge canterbury splodge ac splodge nz
Greg Ewing
David A. Cornelson wrote:
>
> Again. To me. C and Tads are cryptic and Inform is less cryptic.
I think maybe the reason some people are saying
Tads is cryptic is because of the naming conventions
used in the library. Let's face it, all those
method names like verDoBlarg and so forth are
pretty mystifying at first.
I haven't had much experience with Inform, but
from what I've seen it seems to have less of this
sort of crypticality. Although it more than makes
up for it in its creative uses of punctuation...
If you want to see a language which is absolutely
and unequivocally *not* cryptic, consider Alan.
I'd wager that you could give a piece of Alan
code to someone who had never seen the language
before, and they would understand about 95% of
what was going on. They might not be able to write
in the language, but they'd be able to read it.
Try that with Tads or Inform and see how far
they get!
David Glasser
JC <jrc...@netspace.net.au> wrote:
> On Thu, 14 May 1998 "David A. Cornelson" <dcorn...@placet.com> wrote:
>
> >JC wrote in message <355a3329...@news.netspace.net.au>...
> >>On Wed, 13 May 1998 03:02:07 GMT, fake...@anti-spam.address (Neil K.)
> >>wrote:
> >>
> >>> jrc...@netspace.net.au (JC) wrote:
> >
> ><snip>
> >
> >>Weird syntax for printing special characters cryptic; inconsistant syntax
> >>is cryptic; context dependant syntax is cryptic, etc. All these things are
> >>going to make it harder to learn the language, to write programs in it, and
> >>are inducing to errors.
> >
> >Cryptic is subjective.
>
> Rubbish. Are you trying to say that Assembler or C are more cryptic than
> Pascal for purely subjective matters? Subjectivity plays a small part, but
> how cryptic something is can be quantified to an extent.
Not that I disagree with you, but there are some problems with your
example. For instance, in a Pascal function Foobar,
Foobar := Foobar + 1
does not add one to the value of Foobar; it recursively calls Foobar,
adds one to the return value, and sets that to the Foobar on the left,
which is the sort-of-return-value-eventually thing. So the two Foobars
are completely different.
And here's something subjective: the ;'s in Pascal vs. C and others
(including TADS and Inform). I've never figured out where they should
go in Pascal; others can easily.
Darin Johnson
gla...@NOSPAMuscom.com (David Glasser) writes:
> And here's something subjective: the ;'s in Pascal vs. C and others
> (including TADS and Inform). I've never figured out where they should
> go in Pascal; others can easily.
They're easy, *if* one knows what they're for. The problem is, very
often this is not taught. It's all part of the language's model.
To me, part of the criteria for a good programming language is that
non-expert programmers can use it without always having to worry about
minor rules. If a programmer can't make much headway without first
starting with canned chunks of skeleton code, then things probably
need to be simplified in the language. (Note: when I say "programmer"
I mean someone who's experienced with programming in some language,
not necessarily the one in question. A novice to programming will
have these sorts of difficulties in all languages.)
[PS: in C, a ";" terminates statements, in Pascal, they separate statements.]
--
Darin Johnson
da...@usa.net.delete_me
JC
David Glasser wrote:
[...]
>One question: am I correct to believe that the lower the level, the more
>a statement translates directly into assembly/the lowest level? In that
>case, TADS is definitely lower, as (I believe) TADS files are stored in
>OO form, but all objects are lost when converted to ZCode. (Well, there
>still is an object tree, but the objects don't contain as much as in the
>source, right?)
No. Internal details, such as what the code is translated to, are a
pointless metric; the stuff that matters is on the "external" level of the
programmer using the language. The "level" of the language relates to the
mapping between it and it's "problem domain". That is, the level of
abstraction it provides for the tasks it is being used for. A higher level
language embodies more of the concepts of what it is being used for. A
lower-level language doesn't. (It's important to remember that a language
can attempt to embody more of the concepts but can do so in a poor manner;
AGT for example. Also, it's important to distinguish between simple in
capabilities and high-level; two things which are often mixed-up.)
For example, lists in TADS are quite high-level. They don't have a fixed
size to worry about, the can be concatenated or whatever together, and you
don't have to worry about pointers. You're only dealing with concepts
related to the list ADT, and not any other stuff like pointers. Trying to
write a windows program in Assembler would be pointless -- you'd want
something which embodies more of the appropriate concepts -- but writing a
device driver in Assembler isn't.
A myth that many people belive is that if something is higher-level it must
be less flexible. This is quite often true, but it doesn't have to be. A
good abstraction can be used without losing any flexibility, or, in other
cases, a small loss of flexibiltiy which doesn't really matter.
';';James';';
GLYPH
JC <jrc...@netspace.net.au> wrote:
> Rubbish. Are you trying to say that Assembler or C are more cryptic than
> Pascal for purely subjective matters? Subjectivity plays a small part, but
> how cryptic something is can be quantified to an extent.
I hate to break it to you, but I have formally proven that "cryptic" is
100% subjective. This runs along with the fact that "random", "close",
"related", "redundant", and even "pattern" are all 100% subjective. I
proved these for information theoretic purposes, specifically for data
compression.
- GLYPH
Adam J. Thornton
In article <355E2E...@hotmail.com>,
GLYPH <graham...@hotmail.com> wrote:
>I hate to break it to you, but I have formally proven that "cryptic" is
>100% subjective. This runs along with the fact that "random", "close",
>"related", "redundant", and even "pattern" are all 100% subjective. I
>proved these for information theoretic purposes, specifically for data
>compression.
My apologies if I missed the implicit smiley. I just can't see it up
there, unless it's the obvious fallacy in the last statement: namely, a
data compression algorithm that is good at reducing the redundancy of its
input--by, for example, compressing repeated patterns efficiently--will
produce smaller output than a an algorithm that does so less well.
If you've looked at any information theory whatsoever, you've read Claude
Shanno's seminal 1948 paper, "A Mathematical Theory of Communication."
And therefore you know that information and entropy are, in fact, rigorous
concepts, and from this "redundant" and "random" can be rigorously defined,
modulo the philosophical question of whether there is, in fact, such a
thing as a random sequence of digits, which comes down to a question of
determinism. In any event, "pattern" is not too far behind these in terms
of rigor: a patterned sequence of bits is one with low entropy.
I can't speak about "close" or "related" with any assurance, but I suspect
that one could evolve a similar metric with respect to the amount of
information required to convert one string of digits into another.
Which leaves "cryptic". I think there, your point is well taken: it would
seem on the face of it to be a subjective judgment. I suppose if one
wanted, one could analyze the redundancy, in a strictly
information-theoretic sense, in a TADS program and an Inform program that
did the same thing. But I suspect the variation between different coders'
solutions to the problems would dwarf any variation in the languages.
Followups to rec.arts.nit-piction.
Adam
--
ad...@princeton.edu
"There's a border to somewhere waiting, and a tank full of time." - J. Steinman
GLYPH
Adam J. Thornton wrote:
> GLYPH <graham...@hotmail.com> wrote:
> >I hate to break it to you, but I have formally proven that "cryptic" is
> >100% subjective.
...
> for example, compressing repeated patterns efficiently--will
> produce smaller output than a an algorithm that does so less well.
The subjectiveness comes in when you try to define "pattern" or
"redundancy". It cannot be done without making subjective assumptions.
> If you've looked at any information theory whatsoever, you've read Claude
> Shanno's seminal 1948 paper, "A Mathematical Theory of Communication."
Of course.
> And therefore you know that information and entropy are, in fact, rigorous
> concepts, and from this "redundant" and "random" can be rigorously defined
Shannon knew full well that the entropy achieved by his methods depends
entirely on the chosen probability model. This model cannot be chosen
objectively in the general case.
> Which leaves "cryptic". I think there, your point is well taken: it would
> seem on the face of it to be a subjective judgment. I suppose if one
> wanted, one could analyze the redundancy, in a strictly
> information-theoretic sense, in a TADS program and an Inform program that
> did the same thing.
If we could objectively analyze redundancy, we would already have the
Perfect Universal Compressor, which we don't. It simply cannot exist.
> Followups to rec.arts.nit-piction.
How about comp.compression ?
See my web page at
http://www.geocities.com/CollegePark/9315/infofaq.htm
for further information and informal / semiformal proofs.
See yah!
- GLYPH
Adam J. Thornton
In article <355F75...@hotmail.com>,
GLYPH <graham...@hotmail.com> wrote:
>Shannon knew full well that the entropy achieved by his methods depends
>entirely on the chosen probability model. This model cannot be chosen
>objectively in the general case.
>> Which leaves "cryptic". I think there, your point is well taken: it would
>> seem on the face of it to be a subjective judgment. I suppose if one
>> wanted, one could analyze the redundancy, in a strictly
>> information-theoretic sense, in a TADS program and an Inform program that
>> did the same thing.
>If we could objectively analyze redundancy, we would already have the
>Perfect Universal Compressor, which we don't. It simply cannot exist.
OK, then how about: what is the minimal-length Inform program to do X?
What is the minimal-length TADS program to do X? Of course, this does not
take into account that what Doing X means is determined also by the runtime
systems. Nor does it take into account the fact that nobody would ever
write the minimal-length program if they were actually trying to write
source code they could use. Nor that there is no way to recognize the
minimal-length program.
There are two different threads going on here.
I think, if I am disentangling them right, that what you are arguing is
that there is no One True Compression method that works best for all types
of input. That is, if you know what features you can expect in an input
stream, you can design a compressor to exploit that regularity with a good
deal of efficiency. But this compressor may fall apart on other sorts of
files. I would imagine finding a compromise, a compressor that behaves
well on almost all types of input and behaves very badly on just a few, is
the tricky part.
This does not mean that you can't analyze a string of digits for regular
features, even in the general case.
I have no idea how this relates to TADS vs. Inform any more. When I write
Inform code it tends to be terser than TADS code. But that may just be my
programming style.
JC
On Fri, 15 May 1998 David A. Cornelson <dcorn...@placet.com> wrote:
>JC wrote in message <355c3e1...@news.netspace.net.au>...
>>On Thu, 14 May 1998 "David A. Cornelson" <dcorn...@placet.com> wrote:
>>
>>>Cryptic is subjective.
>>Rubbish. Are you trying to say that Assembler or C are more cryptic than
>>Pascal for purely subjective matters? Subjectivity plays a small part, but
>>how cryptic something is can be quantified to an extent.
>Poppycock. I know a few coders that fear C/Basic/Pascal more than anything
>in the whole world. They see a world without Assembly language or even raw
>1's and 0's as a world without purpose and meaning.
Again I ask my obligatory question when replying to David Cornelson: What
the hell does this have to do with what I wrote?!?
>What is difficult to one person may be inherent to another.
Correct. However, we aren't just talking about difficulty. One person
might find C harder than another, but that doesn't mean a thing about how
cryptic C is. And just because something might be fairly cryptic doesn't
mean that there won't be people who will have no trouble with it
whatsoever.
>You make a lot of assumptions based on _your own_ preconceived ideas and
>learning habits. Please. Put yourself in the shoes of a programmer who knows
>nothing but binary encoding and assembly language. A person like that would
>rather learn the opcodes for the z-machine and code a whole game with a hex
>editor.
David is barking up the wrong tree here. He's talking about someone
familar with one thing looking at something which is different. This
doesn't have anything to do with something being cryptic.
>Nothing personal, but you need to open your mind to _other_ possibilities.
If you knew me then you'd know how incredibly ironic that statement is.
>But I'm sure to you, none of this is subjective. that's your _opinion_. Not
>mine.
Lets see what you have to say after you read the following.
Here's what "Pratt T. W., Zelkowitz M. V. (1996) 'Programmming Languages:
Design and Implementation' (Third edition) Prentice Hall" have to say on
the matter.
In section "1.3.1 Attributes of a Good Language"
The first item is "Clarity, simplicity, and unity", and the second
paragraph of this is:
<begin_quote>
The syntax of a language affects the ease with which a program may be
written, tested, and later understood and modified. The _readability_ of
programs in a language is a central issue here. A syntax that is
particularly terse or cryptic orften makes a program easy to write (for the
experienced programmer) but difficult to read when the program must be
modified later. APL programs are often so cryptic that their own designers
cannot easily decipher them a few months after they are completed. Many
languages contqain syntactic constructs that encourable misreading by
making two almost identical statements actually mean radically different
things. For example, the presence of a blank chrqacter, which is an
operator, in a SNOBOL4 statement may entirely alter its meaning. A
language should have the property that constructs that _mean_ different
things look different; i.e., semantic differences should be mirrored in the
language syntax.
</end_quote>
and on the matter of readability (which cryptic roughly translates to):
<begin_quote>
Readability. A program is readable if the underlying structure of the
algorithm and data represented by the program is apparent from inspection
of the program text. A readable programs is often said to be
_self-documenting_, it is understandable without any separate documentation
(although this goal is seldem achieved in practice). Readability is
enhanced by such language features as natural statement formats, structured
statements, liberal use of keywords and noise words, provision for embedded
comments, unrestricted length identifiers, mnemonic operator symbols,
free-field formats, and complete data declarations. Readability, of
course, cannot be guranteed by the design of the language, because even the
best design may be circumvented by poor programming. On the other hand,
syntactic design can force even the best-intentioned programmer to write
unreadable programs (as is often the case in APL). The COBOL design
emphasises readability most heavily, often at the expense of of ease of
writing and ease of translation.
Readability is enhanced by a program syntax in which syntactic differences
reflect underlying semantic differences so that program constructs that do
similar things look similar, and program constructs that do radically
different things look differnt. In general, the greater the variety of
syntactic constructs used, the more easily the program structure may be
made to reflect different underlying semantic structures.
Languages that provide only a few different syntactic constructs in general
lead to less readable programs. In APL or SNOBOL4, for example, only one
statement format is provided. The differences among an assignment
statement, a subprogram call, a smple goto statement, a subprogram return,
a multiway conditional branch, and various other common protram structures
are reflected syntactically only by differences in one or a few operator
symbols within a complex expression. It often requires a detailed analysis
of a program to determine even its gross control strucuture. Moreover, a
simply syntax error, such as a single incorrect character in a statement,
may radically alter the meaning of a statement without rendering it
syntactically incorrect. In LISP, errors in matching parentheses cause
simliar problems; one of Scheme's extensions to LISP is to circumvent this
problem."
</end_quote>
Anybody still think that how cryptic a language is is 100% subjective?
Anybody still think that how cryptic a language is isn't that important,
and it's really just the functionality that matters?
What really annoys me about this thread, and many other things on this
newsgroup, is people who use the argument
"You can't say that, this is a subjective matter, and everything is
personal opinion"
because they don't really know what they are talking about and, with their
limited understanding, they see it as a subjective matter.
';';James';';
okbl...@usa.net
In article <355e3531...@news.netspace.net.au>,
jrc...@netspace.net.au (JC) wrote:
>
>Trying to
> write a windows program in Assembler would be pointless -- you'd want
> something which embodies more of the appropriate concepts -- but writing a
> device driver in Assembler isn't.
>
Mis-posted from rec.arts.nit-piction:
okblacke wrote:
Actually, that's not true. Writing programs for these ultra-loaded OS's in
assembler is much easier than writing assembler programs for DOS, because the
abstraction is already handled by the OS. Where in DOS you had to do
something like:
LEA DX,STR
MOV AH,09H
INT 21H
In one of these other systems, you just have to do something like:
CALL PutUpAWindowWithScrollbarsAndADancingRhinoceros
It's *much* easier to read, write, abstract, etc. Actually, the OS handles
context switching and memory management and a lot of other things that mean
even though you're apparently writing "to the metal", you're really working
with an abstract machine. :-)
(Generally, though, I agree with your message.)
[ok]
JC
On Sat, 16 May 1998 David Glasser wrote:
>JC <jrc...@netspace.net.au> wrote:
>> On Thu, 14 May 1998 "David A. Cornelson" <dcorn...@placet.com> wrote:
>> >>Weird syntax for printing special characters cryptic; inconsistant syntax
>> >>is cryptic; context dependant syntax is cryptic, etc. All these things are
>> >>going to make it harder to learn the language, to write programs in it, and
>> >>are inducing to errors.
>> >Cryptic is subjective.
>> Rubbish. Are you trying to say that Assembler or C are more cryptic than
>> Pascal for purely subjective matters? Subjectivity plays a small part, but
>> how cryptic something is can be quantified to an extent.
>Not that I disagree with you, but there are some problems with your
>example.
>
>For instance, in a Pascal function Foobar,
>Foobar := Foobar + 1
>does not add one to the value of Foobar; it recursively calls Foobar,
>adds one to the return value, and sets that to the Foobar on the left,
>which is the sort-of-return-value-eventually thing. So the two Foobars
>are completely different.
>And here's something subjective: the ;'s in Pascal vs. C and others
>(including TADS and Inform). I've never figured out where they should
>go in Pascal; others can easily.
How are they problems with my example? How do these show that C or
Assembler are equally cryptic as Pascal? I also never said that Pascal was
devoid of anything cryptic. Neither did I ever say I that subjectivity
doesn't play a part in how cryptic something is to someone.
';';James';';
JC
On Sun, 17 May 1998 01:24:13 +0100, GLYPH <graham...@hotmail.com> wrote:
>JC <jrc...@netspace.net.au> wrote:
>> Rubbish. Are you trying to say that Assembler or C are more cryptic than
>> Pascal for purely subjective matters? Subjectivity plays a small part, but
>> how cryptic something is can be quantified to an extent.
>I hate to break it to you, but I have formally proven that "cryptic" is
>100% subjective. This runs along with the fact that "random", "close",
>"related", "redundant", and even "pattern" are all 100% subjective. I
>proved these for information theoretic purposes, specifically for data
>compression.
I thought you were joking at first, but seeing as you aren't, have a look
at my reply to David Cornelson; the long one. Whatever you've proven
doesn't mean nothing in the context of a person using a programming
language.
';';James';';
David A. Cornelson
JC wrote in message <35603d0...@news.netspace.net.au>...
>On Fri, 15 May 1998 David A. Cornelson <dcorn...@placet.com> wrote:
>
>>JC wrote in message <355c3e1...@news.netspace.net.au>...
>>>On Thu, 14 May 1998 "David A. Cornelson" <dcorn...@placet.com> wrote:
>>>
>
>>>>Cryptic is subjective.
<snip>
>>You make a lot of assumptions based on _your own_ preconceived ideas and
>>learning habits. Please. Put yourself in the shoes of a programmer who
knows
>>nothing but binary encoding and assembly language. A person like that
would
>>rather learn the opcodes for the z-machine and code a whole game with a
hex
>>editor.
>
>David is barking up the wrong tree here. He's talking about someone
>familar with one thing looking at something which is different. This
>doesn't have anything to do with something being cryptic.
>
>>Nothing personal, but you need to open your mind to _other_ possibilities.
>
>If you knew me then you'd know how incredibly ironic that statement is.
>
>>But I'm sure to you, none of this is subjective. that's your _opinion_.
Not
>>mine.
>
>Lets see what you have to say after you read the following.
>
>
>Here's what "Pratt T. W., Zelkowitz M. V. (1996) 'Programmming Languages:
<snip>
>What really annoys me about this thread, and many other things on this
>newsgroup, is people who use the argument
>
>"You can't say that, this is a subjective matter, and everything is
>personal opinion"
>
>because they don't really know what they are talking about and, with their
>limited understanding, they see it as a subjective matter.
This reminds me of the beginning of "Dead Poets Society" where Robin
Williams tells his students to rip out the introduction to their poetry
book.
I'm sure many people respect the _opinion_ of Mr. Zelkowitz, but again, why
is his opinion any more important or relative than mine or yours or anybody
elses?
Because subjectively, some people have decided he's really smart and then
someone else published his opinion and someone else put it in a place where
you could read it. And then you read it and thought about and bought it.
That's an incredible chain of decision making that leads me to reiterate.
It's subjective.
This is not something you can write a formula for JC!
I'm not trying to convince you either. We obviously will never agree on this
subject.
(:
Jarb
GLYPH
Okay, this is -really- slipping away from int-fiction, but...
JC wrote:
> Lets see what you have to say after you read the following.
>
> Here's what "Pratt T. W., Zelkowitz M. V. (1996) 'Programmming Languages:
> Design and Implementation' (Third edition) Prentice Hall" have to say on
> the matter.
...
> and on the matter of readability (which cryptic roughly translates to):
>
> <begin_quote>
> Readability. A program is readable if the underlying structure of the
> algorithm and data represented by the program is apparent from inspection
> of the program text. A readable programs is often said to be
> _self-documenting_, it is understandable without any separate documentation
> (although this goal is seldem achieved in practice).
There is a small fallacy here. Nothing can be self-descriptive. To
understand ANYTHING, there must be some prior assumptions made, or
documentation in an already known language. Thus, readability depends
on the knowledge of the reader, and is therefore subjective.
..
> Anybody still think that how cryptic a language is is 100% subjective?
(GLYPH raises his right hand)
> Anybody still think that how cryptic a language is isn't that important,
> and it's really just the functionality that matters?
Okay, I think we're getting mixed up, now. I'm saying there's no way to
objectively quantify readability. I did not say there are no useful
subjective methods. In information theory, it turns out that nearly
everything is subjective, but that doesn't mean that nothing can be
useful or relevant!
> ';';James';';
- GLYPH
GLYPH
JC wrote:
> I thought you were joking at first, but seeing as you aren't, have a look
> at my reply to David Cornelson; the long one. Whatever you've proven
> doesn't mean nothing in the context of a person using a programming
> language.
>
> ';';James';';
Well, you're right that what I've proven won't affect how anybody
programs. It's not really relevant at all, in fact. I've only proven
that the term "cryptic" is 100% subjective. That's all.
- GLYPH
GLYPH
Adam J. Thornton wrote:
>
> In article <355F75...@hotmail.com>,
> GLYPH <graham...@hotmail.com> wrote:
> >Shannon knew full well that the entropy achieved by his methods depends
> >entirely on the chosen probability model. This model cannot be chosen
> >objectively in the general case.
>
> >> Which leaves "cryptic". I think there, your point is well taken: it would
> >> seem on the face of it to be a subjective judgment. I suppose if one
> >> wanted, one could analyze the redundancy, in a strictly
> >> information-theoretic sense, in a TADS program and an Inform program that
> >> did the same thing.
>
> >If we could objectively analyze redundancy, we would already have the
> >Perfect Universal Compressor, which we don't. It simply cannot exist.
>
> OK, then how about: what is the minimal-length Inform program to do X?
> What is the minimal-length TADS program to do X?
You mean the Solomonoff-Kolmogorov-Chaitin complexity of x in those
languages? This measure is often thought to approximate some intrinsic
size associated with X independant of any language, and that languages
which are closer to this value will be more "perfect" or something.
This was never proven by Kolmogorov; it was only suggested. I have a
disproof of it on my web page:
http://www.geocities.com/CollegePark/9315/kcaccy.htm
> Of course, this does not
> take into account that what Doing X means is determined also by the runtime
> systems. Nor does it take into account the fact that nobody would ever
> write the minimal-length program if they were actually trying to write
> source code they could use. Nor that there is no way to recognize the
> minimal-length program.
It is possible to construct a table of minimal length programs for
strings, but it takes a while. (just start with the smallest possible
program, see what it does, write it down, then continue running all the
possible programs from small to big until the string you want is
produced. There you go.)
> There are two different threads going on here.
>
> I think, if I am disentangling them right, that what you are arguing is
> that there is no One True Compression method that works best for all types
> of input.
Well, yes.
> That is, if you know what features you can expect in an input
> stream, you can design a compressor to exploit that regularity with a good
> deal of efficiency.
Righto.
> But this compressor may fall apart on other sorts of
> files.
Yup.
> I would imagine finding a compromise, a compressor that behaves
> well on almost all types of input and behaves very badly on just a few, is
> the tricky part.
It is not possible, in fact. This has been proven in several ways. The
"counting argument" is a favorite on comp.compression. I think it's in
their FAQ.
> This does not mean that you can't analyze a string of digits for regular
> features, even in the general case.
Sure it does. Just go ahead and try to define "regular features" in a
completetly unbiased, universally objective way without involving
humans, Earth or whatnot.
> I have no idea how this relates to TADS vs. Inform any more. When I write
> Inform code it tends to be terser than TADS code. But that may just be my
> programming style.
Yeah, we've sort of lost sight of int-fiction here. I personally don't
care who uses what language. Just try them all and use your favorite!
> Adam
- GLYPH
David Glasser
Greg Ewing <not.t...@see.below> wrote:
> Matthew T. Russotto wrote:
> >
> > }That's my point. That type of thing doesn't work well on the Mac, but
> > }if the MacOS source was open, I could stick in a call to a preprocessor
> > }before compilation.
> >
> > Three letters. 'M' 'P' 'W'.
>
> Or Applescript, if the preprocessor and compiler are
> both scriptable. I don't know whether the Mac Inform
> compiler is, but if it isn't, it should be!
>
> Another cool idea might be a version of Inform as
> a CodeWarrior IDE plug-in...
I've been thinking about that. Do you know where documentation for
making plugins can be found?
David Einstein
On Mon, 18 May 1998 14:44:48 GMT, jrc...@netspace.net.au (JC) wrote:
>Here's what "Pratt T. W., Zelkowitz M. V. (1996) 'Programmming Languages:
>Design and Implementation' (Third edition) Prentice Hall" have to say on
>the matter.
>
>In section "1.3.1 Attributes of a Good Language"
>The first item is "Clarity, simplicity, and unity", and the second
>paragraph of this is:
>
><begin_quote>
>The syntax of a language affects the ease with which a program may be
>written, tested, and later understood and modified. The _readability_ of
>programs in a language is a central issue here. A syntax that is
>particularly terse or cryptic orften makes a program easy to write (for the
>experienced programmer) but difficult to read when the program must be
>modified later. APL programs are often so cryptic that their own designers
>cannot easily decipher them a few months after they are completed. Many
>languages contqain syntactic constructs that encourable misreading by
>making two almost identical statements actually mean radically different
>things. For example, the presence of a blank chrqacter, which is an
>operator, in a SNOBOL4 statement may entirely alter its meaning. A
>language should have the property that constructs that _mean_ different
>things look different; i.e., semantic differences should be mirrored in the
>language syntax.
></end_quote>
I'm very curious as to whether they have actually have
anything more than opinion to back this up.
>
>and on the matter of readability (which cryptic roughly translates to):
>
><begin_quote>
>Readability. A program is readable if the underlying structure of the
>algorithm and data represented by the program is apparent from inspection
>of the program text. A readable programs is often said to be
>_self-documenting_, it is understandable without any separate documentation
>(although this goal is seldem achieved in practice). Readability is
>enhanced by such language features as natural statement formats, structured
>statements, liberal use of keywords and noise words, provision for embedded
>comments, unrestricted length identifiers, mnemonic operator symbols,
>free-field formats, and complete data declarations. Readability, of
>course, cannot be guranteed by the design of the language, because even the
>best design may be circumvented by poor programming. On the other hand,
>syntactic design can force even the best-intentioned programmer to write
>unreadable programs (as is often the case in APL). The COBOL design
>emphasises readability most heavily, often at the expense of of ease of
>writing and ease of translation.
This is, umm..., not exactly a universally held belief. I
would rather attempt to read a simplex algorithm implermented in APL
than one in COBOL.
>Readability is enhanced by a program syntax in which syntactic differences
>reflect underlying semantic differences so that program constructs that do
>similar things look similar, and program constructs that do radically
>different things look differnt. In general, the greater the variety of
>syntactic constructs used, the more easily the program structure may be
>made to reflect different underlying semantic structures.
>Languages that provide only a few different syntactic constructs in general
>lead to less readable programs. In APL or SNOBOL4, for example, only one
>statement format is provided. The differences among an assignment
>statement, a subprogram call, a smple goto statement, a subprogram return,
>a multiway conditional branch, and various other common protram structures
>are reflected syntactically only by differences in one or a few operator
>symbols within a complex expression. It often requires a detailed analysis
>of a program to determine even its gross control strucuture. Moreover, a
>simply syntax error, such as a single incorrect character in a statement,
>may radically alter the meaning of a statement without rendering it
>syntactically incorrect. In LISP, errors in matching parentheses cause
>simliar problems; one of Scheme's extensions to LISP is to circumvent this
>problem."
This, I find puzzling. About all I can think that he means
here is that scheme has only one name space, but whether or not this
is a win is still hotly contested. Lexical scoping probably helped
readability more, but I cannot see how it would help mismatched
parentheses.
>
>
>Anybody still think that how cryptic a language is is 100% subjective?
>Anybody still think that how cryptic a language is isn't that important,
>and it's really just the functionality that matters?
>
Ooooh Ooooh... Pick me. Pick me!!!
>What really annoys me about this thread, and many other things on this
>newsgroup, is people who use the argument
>
>"You can't say that, this is a subjective matter, and everything is
>personal opinion"
>
Welcome to usenet. I've heard tell that everything hereabouts may not
be gospel.
>because they don't really know what they are talking about and, with their
>limited understanding, they see it as a subjective matter.
I's usually more entertaining if noone knows what they're talking
about.
-----------------------------------------------------
Lord grant me the companionship of those who seek the
truth and protection from those who have found it
Greg Ewing
David Glasser wrote:
>
> > Another cool idea might be a version of Inform as
> > a CodeWarrior IDE plug-in...
>
> I've been thinking about that. Do you know where documentation for
> making plugins can be found?
Haven't looked closely yet, but I'm pretty sure
there's info about the plugin API in one of the
manuals you get on the CodeWarrior CD.
--
Greg Ewing, Computer Science Dept, | The address below is not spam-
University of Canterbury, | protected, so as not to waste
Christchurch, New Zealand | the time of Guido van Rossum.
gr...@cosc.canterbury.ac.nz
David Given
In article <tvyaf8k...@cn1.connectnet.com>,
Darin Johnson <da...@usa.net.removethis> wrote:
>rc...@my-dejanews.com writes:
>
>> If you want a Lisp-like IF engine, look at GINAS (located on GMD).
>
>I didn't want it lisp-like solely to have a lisp-like engine.
>I wanted it so that I didn't have to worry about syntax issues,
>changing the parser if I added new constructs or keywords, etc.
>There were others ideas for the engine itself independent of the
>syntax.
>
>I think also DDL was very lisp-ish.
I heard somewhere that the language Infocom wrote their adventure games in
was vaguely Lisp-ish (that then got compiled to Z-code, of course).
--
+- David Given ----------------+
| Work: d...@tao.co.uk | Reality is for people who can't cope
| Play: d...@freeyellow.com | with science fiction.
+- http://wiredsoc.ml.org/~dg -+
David Given
>If we could objectively analyze redundancy, we would already have the
>Perfect Universal Compressor, which we don't. It simply cannot exist.
Oh, no? Take a look at:
Then panic.
John Francis
In article <895585376.16564.0...@news.demon.co.uk>,
David Given <dg@> wrote:
>In article <355F75...@hotmail.com>,
>GLYPH <graham...@hotmail.com> wrote:
>[...]
>>If we could objectively analyze redundancy, we would already have the
>>Perfect Universal Compressor, which we don't. It simply cannot exist.
>[...]
>
>Oh, no? Take a look at:
>
> http://www.pacminc.com
>
>Then panic.
OOoohh! It's the modern-day equivalent of a perpetual-motion machine!
I just love the pseudo-scientific 'justification' of the algorithm in the
appendix (debunking myth #1).
--
John Francis jfra...@sgi.com Silicon Graphics, Inc.
(650)933-8295 2011 N. Shoreline Blvd. MS 43U-991
(650)933-4692 (Fax) Mountain View, CA 94043-1389
Unsolicited electronic mail will be subject to a $100 handling fee.
GLYPH
David Given wrote:
>
> In article <355F75...@hotmail.com>,
> GLYPH <graham...@hotmail.com> wrote:
> [...]
> >If we could objectively analyze redundancy, we would already have the
> >Perfect Universal Compressor, which we don't. It simply cannot exist.
> [...]
>
> Oh, no? Take a look at:
>
> http://www.pacminc.com
>
> Then panic.
A quick (4 second) look at this page led me to believe it is like every
other "compresses everything" compressor, ALL OF WHICH HAVE BEEN SHOWN
TO BE FRAUDULANT.
A longer look at the page confirmed this. IT IS PROVEN, VERY EASILY
that there is no perfect universal compressor! This topic comes up
about 4 times a year on comp.compression and *EVERY TIME* it is proven
false, either due to a mistake / misunderstanding on the author's part,
or to a deliberate attempt at swindling people.
Please read the comp.compression FAQ.
See yah!
- GLYPH
GLYPH
GLYPH wrote:
>
> David Given wrote:
> > Oh, no? Take a look at:
> >
> > http://www.pacminc.com
> A quick (4 second) look at this page led me to believe it is like every
> other "compresses everything" compressor, ALL OF WHICH HAVE BEEN SHOWN
> TO BE FRAUDULANT.
30 seconds later, I managed to pinpoint the exact location of their
error. They claim to be using bit strings of length 1 to n-1 to
represent numbers from 1 to 2^n. THIS IS A COMMON CLAIM. The fallacy
is that the LENGTH of these strings also needs to be encoded somehow,
and AT BEST it exactly outweighs any gains from the method.
If you want to argue further, post your arguments on comp.compression
and brace yourself.
- GLYPH
Darin Johnson
GLYPH <graham...@hotmail.com> writes:
> 30 seconds later, I managed to pinpoint the exact location of their
> error. They claim to be using bit strings of length 1 to n-1 to
> represent numbers from 1 to 2^n. THIS IS A COMMON CLAIM. The fallacy
> is that the LENGTH of these strings also needs to be encoded somehow,
> and AT BEST it exactly outweighs any gains from the method.
In a graduate CS theory course, the professor presented a somewhat
dubious claim, then proved it false (I forget what the claim was).
His proof to the contrary, one of the longest I've seen, actually
involved showing that a comparison of (or operation on) integers was
really O(logn), where n was the number of digits needed to represent
them. That was something usually glossed over and ignored, except in
grad school...
On the other hand, for every dubious claim, there never seems to be a
working prototype that can demonstrate the claim. For a compression
claim, can't the person just write a program that shows the gains?
--
Darin Johnson
da...@usa.net.delete_me
Adam J. Thornton
In article <35608C...@hotmail.com>,
GLYPH <graham...@hotmail.com> wrote:
>> I would imagine finding a compromise, a compressor that behaves
>> well on almost all types of input and behaves very badly on just a few, is
>> the tricky part.
>It is not possible, in fact. This has been proven in several ways. The
>"counting argument" is a favorite on comp.compression. I think it's in
>their FAQ.
I've got enough weasel words in there, actually. Burrows-Wheeler
block-sorting text compression plus Huffman coding (cribbing from the bzip2
man page) seems to give reasonably good compression ratios across a wide
variety of input strings, and I haven't run into the pathological cases
where it blows up yet, which is if nothing else reasonable anecdotal
evidence that it does OK with most input. Bzip2 seems to be a pretty good
compromise between generality and maximal compression.
I never claimed that a Universal Perfect Compressor was possible.
>> This does not mean that you can't analyze a string of digits for regular
>> features, even in the general case.
>
>Sure it does. Just go ahead and try to define "regular features" in a
>completetly unbiased, universally objective way without involving
>humans, Earth or whatnot.
Well, I guess I do have to concede that the choice of what medium you're
detecting state changes in to provide information, and what qualifies as a
state change, cannot be utterly objective; the mere notion of making the
choice introduces an observer.
But that seems to be in the detection of the sequence. Once granted the
existence of a sequence, I don't see how the detection of a pattern in it
necessarily implies anything about the observer. "123123123123..." *is* a
cyclic pattern of length three, whether it's occurring as a string of ASCII
digits--which I guess is some cyclical pattern of voltages somewhere, or as
timed pulses of black-body radiation, or whatever.
But now we're about to get into a whole Platonic Preexistent Forms versus
Aristotelean Abstracted-From-Experience Forms argument. And we don't want
to go *there*.
IF relevance? Errr, I bet it's easier to write a compression algorithm in
Inform than it is in TADS. So there.
A
Adam J. Thornton
In article <3560ec18....@news.std.com>,
David Einstein <Dei...@world.std.com> wrote:
>On Mon, 18 May 1998 14:44:48 GMT, jrc...@netspace.net.au (JC) wrote:
>>Here's what "Pratt T. W., Zelkowitz M. V. (1996) 'Programmming Languages:
>>Design and Implementation' (Third edition) Prentice Hall" have to say on
>>the matter.
>>In section "1.3.1 Attributes of a Good Language"
>>The first item is "Clarity, simplicity, and unity", and the second
>>paragraph of this is:
>><begin_quote>
>>The syntax of a language affects the ease with which a program may be
>>written, tested, and later understood and modified. The _readability_ of
>>programs in a language is a central issue here. A syntax that is
>>particularly terse or cryptic orften makes a program easy to write (for the
>>experienced programmer) but difficult to read when the program must be
>>modified later. APL programs are often so cryptic that their own designers
>>cannot easily decipher them a few months after they are completed.
They misspelled "APL programs are usually so cryptic that if their
designers need to change them and haven't been working with the code daily,
they're better off just to throw them away and start over, but fortunately,
the solution, however complex, will be a single line of APL."
> I'm very curious as to whether they have actually have
>anything more than opinion to back this up.
Highly context-dependent gramamrs do tend to suck in terms of figuring out
what went wrong, and if you've ever seen real APL, it's pretty
horrifying....but I doubt there are actual metrics.
>>unreadable programs (as is often the case in APL). The COBOL design
>>emphasises readability most heavily, often at the expense of of ease of
>>writing and ease of translation.
> This is, umm..., not exactly a universally held belief. I
>would rather attempt to read a simplex algorithm implermented in APL
>than one in COBOL.
Well, OK, but then there's the matter of using the right tool for the job.
COBOL is great for things like payroll tasks: relatively simple math
repeated over a reasonably big but structurally straightforward data set.
Which is what it was designed to do.
APL is absolutely ass-kicking for matrix algebra. I'm willing to bet there
is no other language that lets you do as much matrix algebra as atomic
operations as APL. But I'd rather drill a hole in my skull with a rusty
Nikita cordless than write a payroll app--or a regular expression
parser--in it. For *real math* it's wonderful and COBOL is singularly
inappropriate.
Sure, both are Turing-complete (I guess...are they?), but one tool is *way*
more appropriate for problems in certain domains than the other. Would
anybody sane try to write system-administration glue--the kind of thing
that, for instance, Perl is terrific at--in APL? Or even in Scheme?
>>Anybody still think that how cryptic a language is is 100% subjective?
>>Anybody still think that how cryptic a language is isn't that important,
>>and it's really just the functionality that matters?
>Ooooh Ooooh... Pick me. Pick me!!!
Oh, come on. If it were just the functionality that mattered, we'd all be
writing our adventures in C. But the convenience of having Inform or TADS
or Hugo or Alan, or even AGT, is such that it makes it a better idea to use
a tool more specifically crafted for the problem at hand.
Adam
Adam J. Thornton
Or, more concisely:
COBOL:
PROGRAM FOOTICIDE.
APPLICATION-DIVISION.
PERFORM SHOOT-SELF IN FOOT USING HANDGUN.
APL:
There is a headsplitting bang, and a huge hole has appeared in your foot.
It hurts a lot. You can't remember enough linear algebra to figure out how
it got there, but you're pretty sure you must have typed the wrong
character for the "give me the determinant of a matrix and go brew the
coffee" glyph.
Adam J. Thornton
In article <895585376.16564.0...@news.demon.co.uk>,>Then panic.
Yeah, I particularly like:
"The MINC universal lossless data compression system is based on this
simple foundation. Of course, this leaves open the question of how to
accommodate the representation of the length of these strings and still
realize net compression.
The MINC algorithm has solved this problem. Once again this
contradicts the pundits, since to evaluate this issue one must know
just how MINC resolves it."
IOW, "We have a SOOPER MAGIC ALGORITHM! AND YOU DON'T GET TO SEE IT! SO
IT MUST BE RIGHT!"
Sheesh.
Greg Ewing
David Given wrote:
>
> I heard somewhere that the language Infocom wrote their adventure games in
> was vaguely Lisp-ish (that then got compiled to Z-code, of course).
One of the past competition entries contained a Scheme
interpreter implemented on the Z-machine.
Maybe if it were enhanced a bit and provided with a
library, it could become a Lisp-like Z-machine based
IF language...
Greg Ewing
David Einstein wrote:
>
> On Mon, 18 May 1998 14:44:48 GMT, jrc...@netspace.net.au (JC) wrote:
>
> >Here's what "Pratt T. W., Zelkowitz M. V. (1996) 'Programmming Languages:
> >Design and Implementation' (Third edition) Prentice Hall" have to say on
> >the matter.
> >
> >simliar problems; one of Scheme's extensions to LISP is to circumvent this
> >problem."
>
> This, I find puzzling.
I think he's referring to the way that Scheme lets you
use both round and square brackets and complains if you
don't match them up properly.
I haven't very often seen Scheme code which uses this
feature, though. Perhaps it's not widely known, or maybe
it's been found not to be as useful as anticipated?
Andrew Plotkin
GLYPH (graham...@hotmail.com) wrote:
> Well, you're right that what I've proven won't affect how anybody
> programs. It's not really relevant at all, in fact. I've only proven
> that the term "cryptic" is 100% subjective. That's all.
As a corrolary, I've proven that the word "proof" is 100% subjective.
--Z (next up: "cheese")
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Iain Merrick
GLYPH wrote:
> GLYPH wrote:
>
> > David Given wrote:
> >
> > > Oh, no? Take a look at:
> > >
> > > http://www.pacminc.com
>
> > A quick (4 second) look at this page led me to believe it is like every
> > other "compresses everything" compressor, ALL OF WHICH HAVE BEEN SHOWN
> > TO BE FRAUDULANT.
>
> 30 seconds later, I managed to pinpoint the exact location of their
> error. They claim to be using bit strings of length 1 to n-1 to
> represent numbers from 1 to 2^n. THIS IS A COMMON CLAIM. The fallacy
> is that the LENGTH of these strings also needs to be encoded somehow,
> and AT BEST it exactly outweighs any gains from the method.
>
> If you want to argue further, post your arguments on comp.compression
> and brace yourself.
Um, I think Dave meant 'panic at how stupid people can be, including
patent clerks, Einstein notwithstanding'. It's pretty obvious that the
Pacminc stuff is just as kooky as Alex Chiu's theories of Life, the
Universe and Everything. (www.alexchiu.com). At least I _hope_ it's
pretty obvious to most people.
I include 'patent clerks' above, but perhaps we should be fairer on the
poor folk who have to deal with these nuts. If someone does try to
patent an invention which mathematically can't work, charging them
several thousand dollars for the sole rights to any working models seems
reasonable enough. :)
--
Iain Merrick
Den of Iniquity
On Wed, 20 May 1998, Andrew Plotkin wrote:
>GLYPH (graham...@hotmail.com) wrote:
>>I've only proven that the term "cryptic" is 100% subjective.
>
>As a corrolary, I've proven that the word "proof" is 100% subjective.
:)
Just like Zarf to undermine the basis of just about all of modern and
ancient philosophy and the sciences that thus ensue.
>--Z (next up: "cheese")
Whoo! The big one! I look forward to that. I've been arguing with a good
mate of mine for the last five years on the relative cheesy merits of
mascarpone and stilton. I think cheesiness is subjective but I realise
that my opinion on the matter is purely subjective too.
--
Den
David M Einstein
Adam J. Thornton (ad...@princeton.edu) wrote:
: Sure, both are Turing-complete (I guess...are they?), but one tool is *way*
: more appropriate for problems in certain domains than the other. Would
: anybody sane try to write system-administration glue--the kind of thing
: that, for instance, Perl is terrific at--in APL? Or even in Scheme?
See comp.lang.scsh for people doing Perlish things in scheme.
It's not as bad as you might think.
: >>Anybody still think that how cryptic a language is is 100% subjective?
: >>Anybody still think that how cryptic a language is isn't that important,
: >>and it's really just the functionality that matters?
: >Ooooh Ooooh... Pick me. Pick me!!!
: Oh, come on. If it were just the functionality that mattered, we'd all be
: writing our adventures in C. But the convenience of having Inform or TADS
: or Hugo or Alan, or even AGT, is such that it makes it a better idea to use
: a tool more specifically crafted for the problem at hand.
Ok, I'd probably agree with this, if the convenience is not
included with functionality. (but just about anything is turing complete)
I was mainly curious about the scheme comment, and that has been
answered.
: Adam
: --
: ad...@princeton.edu
: "There's a border to somewhere waiting, and a tank full of time." - J. Steinman
--
David M Einstein | Lord, grant me the companionship of those who seek
| the truth, and protection from those who have found
| it.
David Given
In article <3562C2...@cs.york.ac.uk>,
Iain Merrick <i...@cs.york.ac.uk> wrote:
[...]
>Um, I think Dave meant 'panic at how stupid people can be, including
>patent clerks, Einstein notwithstanding'. It's pretty obvious that the
>Pacminc stuff is just as kooky as Alex Chiu's theories of Life, the
>Universe and Everything. (www.alexchiu.com). At least I _hope_ it's
>pretty obvious to most people.
Uh, yes, I did. Thank-you. Let me state categorically that the thought of
being associated with these people in any way other than pointing at them
and laughing my head off fills me with horror.
>I include 'patent clerks' above, but perhaps we should be fairer on the
>poor folk who have to deal with these nuts. If someone does try to
>patent an invention which mathematically can't work, charging them
>several thousand dollars for the sole rights to any working models seems
>reasonable enough. :)
I believe there's a special rule in patent offices that anyone wishing to
patent a perpetual motion machine must provide a working model.
>Iain Merrick
Oh, hello, what a surprise to see you here...
--
+- David Given ----------------+
| Work: d...@tao.co.uk | Eat the rich. The poor are tough and
| Play: d...@freeyellow.com | stringy.
+- http://wiredsoc.ml.org/~dg -+
David Given
In article <Pine.SGI.3.95L.98052...@ebor.york.ac.uk>,
Den of Iniquity <dms...@york.ac.uk> wrote:
[...]
>Whoo! The big one! I look forward to that. I've been arguing with a good
>mate of mine for the last five years on the relative cheesy merits of
>mascarpone and stilton. I think cheesiness is subjective but I realise
>that my opinion on the matter is purely subjective too.
But --- and this is the *really* important one --- is subjectivity
subjective? I know that to some people, subjective data counts as
objective, and to us, their objective data is objective. But does that
mean we can generalise and say that whether something is subjective or not
is, in fact, subjective?
L. Ross Raszewski
In article <erkyrathE...@netcom.com>,
erky...@netcom.com (Andrew Plotkin) wrote:
>
> GLYPH (graham...@hotmail.com) wrote:
>
> > Well, you're right that what I've proven won't affect how anybody
> > that the term "cryptic" is 100% subjective. That's all.
>
> As a corrolary, I've proven that the word "proof" is 100% subjective.
Furthermore, I've proven that the word "corrolary" is 70% cotton, 30% acrylic
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
okbl...@usa.net
In article <356189...@hotmail.com>,
GLYPH <graham...@hotmail.com> wrote:
>
> 30 seconds later, I managed to pinpoint the exact location of their
> error. They claim to be using bit strings of length 1 to n-1 to
> represent numbers from 1 to 2^n. THIS IS A COMMON CLAIM. The fallacy
> is that the LENGTH of these strings also needs to be encoded somehow,
> and AT BEST it exactly outweighs any gains from the method.
>
I came to the same conclusion. Yes, you can use a binary 2^19 to represent all
the words in the English language--if you have a dictionary that maps them
out, said dictionary being larger than a dictionary without the 2^19 key.
I suppose that the absence of a program that proved the compression would work
was indication of its validity: After all, you wouldn't want to have someone
disassemble this and steal your idea.
I also thought it was interesting that every 8 passes gave 25% reduction,
regardless of how many times you did it. But I guess it would have to in
order for the rest of the premise to be true. What didn't make sense, then,
was why you couldn't reduce everything down to a single bit. :-) This was sort
of glossed over.
I wonder if this is a comp.compression "TextFire"-like thing.
[ok]
Darin Johnson
okbl...@usa.net writes:
> I also thought it was interesting that every 8 passes gave 25% reduction,
> regardless of how many times you did it. But I guess it would have to in
> order for the rest of the premise to be true. What didn't make sense, then,
> was why you couldn't reduce everything down to a single bit. :-) This was sort
> of glossed over.
There was an implication that they had a minimum buffer size for
compression. Thus, if you compress smaller than the buffer size, you
need to stick more data in. Thus, they can easily counter arguments
of "but you obviously can't compress down to a single bit".
The amusing part, is that it looks clearly like a con or scam. Lots
of "send us money, and we'll tell you how". If it was a real product,
then get a patent and publish a paper. Or publish a paper anyway so
you can claim prior knowledge. There's not even much of an attempt to
refute the obvious arguments. I can think of anything important ever
starting life as "license with us to learn more".
Who would be most interested in this? Engineers. Who would be most
likely to laugh the whole thing off without paying for a license to
learn more? Engineers. Given that, *who* do they expect to buy
licenses?
--
Darin Johnson
da...@usa.net.delete_me
Darin Johnson
Greg Ewing <gr...@cosc.canterbury.ac.nz> writes:
> I haven't very often seen Scheme code which uses this
> feature, though. Perhaps it's not widely known, or maybe
> it's been found not to be as useful as anticipated?
It's not very useful. It only helps if you have an editor that can't
match parentheses for you, and those are rare. Even with such an
editor, sticking on a "]" will leave it in the code, and it just looks
damned ugly.
The "]" feature was much more useful for typing in lisp code directly
to the interpreter.
--
Darin Johnson
da...@usa.net.delete_me
Darin Johnson
Greg Ewing <gr...@cosc.canterbury.ac.nz> writes:
> One of the past competition entries contained a Scheme
> interpreter implemented on the Z-machine.
>
> Maybe if it were enhanced a bit and provided with a
> library, it could become a Lisp-like Z-machine based
> IF language...
In 64K? I'd buy that for a dollar.
--
Darin Johnson
da...@usa.net.delete_me
Bill
Darin Johnson wrote in message ...
>Greg Ewing <gr...@cosc.canterbury.ac.nz> writes:
>
>> One of the past competition entries contained a Scheme
>> interpreter implemented on the Z-machine.
>>
>> Maybe if it were enhanced a bit and provided with a
>> library, it could become a Lisp-like Z-machine based
>> IF language...
>
>In 64K? I'd buy that for a dollar.
Infocom's language was Lisp-like. Not all that different from ADVSYS if
memory serves me.
Of course they used larger machines running LISP (a MIT variant) to compile
to Z-code.
Bill
Matt Kimball
Darin Johnson <da...@usa.net.removethis> wrote:
:> One of the past competition entries contained a Scheme
:> interpreter implemented on the Z-machine.
:>
:> Maybe if it were enhanced a bit and provided with a
:> library, it could become a Lisp-like Z-machine based
:> IF language...
: In 64K? I'd buy that for a dollar.
Well, you could do small-ish things Lisp-y things in 64K. I have been
investigating just such a possibility, and I came up with a scheme
which used atomic memory chunks of 6-bytes each. In those six bytes
chunks, I could store, for instance, a cons cell, or a symbol or a
numerical value pointed to by a cons cell. All the information I
needed for garbage collection was in those six bytes too. Strings
take up a variable number of these six-byte chunks, depending on their
length.
With such a scheme, you could have 10K or so objects available for
allocation from the heap, and you can store lots of constant stuff
above the 64K barrier in the code you compile. So, it might enough
for some limited tasks.
--
Matt Kimball
mkim...@xmission.com
GLYPH
Darin Johnson wrote:
> On the other hand, for every dubious claim, there never seems to be a
> working prototype that can demonstrate the claim. For a compression
> claim, can't the person just write a program that shows the gains?
> --
> Darin Johnson
> da...@usa.net.delete_me
Yes. But, in all the cases of "universal compressors", the author was
either "still working on it", keeping it secret for "patent reasons", or
in a case where the program is actually tested, it has always been found
to -not- work. A common sequence of events is for someone on
comp.compression to offer to arrange, and even pay for, a public
demonstration of the compressor, with full non-disclosure of the
algorithms. In all cases, the author has either disagreed to the
demostration, or has remained mysteriously silent...
- GLYPH
GLYPH
Adam J. Thornton wrote:
> GLYPH <graham...@hotmail.com> wrote:
> >It is not possible, in fact. This has been proven in several ways. The
> >"counting argument" is a favorite on comp.compression. I think it's in
> >their FAQ.
> I've got enough weasel words in there, actually. Burrows-Wheeler
> block-sorting text compression plus Huffman coding (cribbing from the bzip2
> man page) seems to give reasonably good compression ratios across a wide
> variety of input strings, and I haven't run into the pathological cases
> where it blows up yet, which is if nothing else reasonable anecdotal
> evidence that it does OK with most input. Bzip2 seems to be a pretty good
> compromise between generality and maximal compression.
Bzip is not the mother of all compressors, though. I took "almost all
types of input" to mean "almost all types of input", I took "just a few"
to mean "just a few", and I take "most input" to mean "most input". In
this case no such compressor is possoble, and provably so. (Bzip does
well on an *extremely small* portion of ALL FILES, but the very few that
it does well on happen to be the kind that people like to use)
> I never claimed that a Universal Perfect Compressor was possible.
I'm glad to hear that :)
> >> This does not mean that you can't analyze a string of digits for regular
> >> features, even in the general case.
> >Sure it does. Just go ahead and try to define "regular features" in a
> >completetly unbiased, universally objective way without involving
> >humans, Earth or whatnot.
> Well, I guess I do have to concede that the choice of what medium you're
> detecting state changes in to provide information, and what qualifies as a
> state change, cannot be utterly objective; the mere notion of making the
> choice introduces an observer.
Kinda, yeah.
> But that seems to be in the detection of the sequence. Once granted the
> existence of a sequence, I don't see how the detection of a pattern in it
> necessarily implies anything about the observer. "123123123123..." *is* a
> cyclic pattern of length three, whether it's occurring as a string of ASCII
> digits--which I guess is some cyclical pattern of voltages somewhere, or as
> timed pulses of black-body radiation, or whatever.
Yes. But, our choosing to put that kind of pattern into the "relevant"
pile (as opposed to the "irrelevant" pile) is subjective. It is
impossible to make a compressor which takes advantage of ALL types of
patterns. When constructing a compressor (or a measure of redundancy)
we must choose a finite set of patterns to look for. The more patterns
we look for, the less we can take advantage of any particular one. That
is why it is subjective.
See yah,
- GLYPH
Giles Boutel
L. Ross Raszewski <rras...@hotmail.com> wrote in article
<6jv18o$sbg$1...@nnrp1.dejanews.com>...
> In article <erkyrathE...@netcom.com>,
> erky...@netcom.com (Andrew Plotkin) wrote:
> >
> > GLYPH (graham...@hotmail.com) wrote:
> >
> > > Well, you're right that what I've proven won't affect how anybody
> > > programs. It's not really relevant at all, in fact. I've only
proven
> > > that the term "cryptic" is 100% subjective. That's all.
> >
> > As a corrolary, I've proven that the word "proof" is 100% subjective.
>
> Furthermore, I've proven that the word "corrolary" is 70% cotton, 30%
acrylic
>
In addition, I've proven that black is white, and been killed by a roving
band of copyright lawyers
-Giles
John Francis
In article <u4H81.763$Kx3.1...@news.rdc1.sdca.home.com>,
Bill <bv...@inetworld.net> wrote:
>
>Infocom's language was Lisp-like. Not all that different from ADVSYS if
>memory serves me.
>
>Of course they used larger machines running LISP (a MIT variant) to compile
>to Z-code.
MDL was, indeed, very LISP-like. But the compilation was done on their
36-bit DEC boxes, which ran ITS and/or Tenex. The MDL compiler also ran on
a standard DECSystem-10 or 20 running TOPS10 or TOPS20. LISP didn't come
into the picture.
--
John Francis jfra...@sgi.com Silicon Graphics, Inc.
(650)933-8295 2011 N. Shoreline Blvd. MS 43U-991
(650)933-4692 (Fax) Mountain View, CA 94043-1389
Unsolicited electronic mail will be subject to a $100 handling fee.
John Francis
In article <tvyu36k...@cn1.connectnet.com>,
Darin Johnson <da...@usa.net.removethis> wrote:
[snip, snip]
>The amusing part, is that it looks clearly like a con or scam. Lots
>of "send us money, and we'll tell you how". If it was a real product,
>then get a patent and publish a paper. Or publish a paper anyway so
>you can claim prior knowledge. There's not even much of an attempt to
>refute the obvious arguments. I can think of anything important ever
>starting life as "license with us to learn more".
Iterated Function Systems' fractal image compression stuff started off
this way, and remains so to this day. While I don't know if that meets
your criteria for "important", it is a reasonable commercial success.
>Who would be most interested in this? Engineers. Who would be most
>likely to laugh the whole thing off without paying for a license to
>learn more? Engineers. Given that, *who* do they expect to buy
>licenses?
It doesn't seem to have stopped IFS. Michael Barnsley had a spot at
SIGGRAPH where he was expected to describe fractal image compression.
Instead he gave a content-free commercial plug for his new company,
which royally pissed off practically the entire audience.
All this shows is that the engineers don't sign the checks. Not only
that - the people who *do* sign the checks don't listen to engineers.
JC
On Mon, 18 May 1998 14:45:07 GMT, okbl...@usa.net wrote:
>In article <355e3531...@news.netspace.net.au> I wrote:
>>Trying to
>> write a windows program in Assembler would be pointless -- you'd want
>> something which embodies more of the appropriate concepts -- but writing a
>> device driver in Assembler isn't.
>Mis-posted from rec.arts.nit-piction:
And so is this reply ;-)
>Actually, that's not true. Writing programs for these ultra-loaded OS's in
>assembler is much easier than writing assembler programs for DOS, because the
>abstraction is already handled by the OS. [...]
All I said was that it would be pointless to do so -- nothing about whether
it'd be easier in Windows/DOS -- and I don't think you're disagreeing with
that, or saying that it wouldn't still be very difficult.
';';James';';
JC
On Mon, 18 May 1998 20:11:50 +0100, GLYPH <graham...@hotmail.com> wrote:
>Okay, this is -really- slipping away from int-fiction, but...
>JC wrote:
>
>> Lets see what you have to say after you read the following.
>>
>> Here's what "Pratt T. W., Zelkowitz M. V. (1996) 'Programmming Languages:
>> Design and Implementation' (Third edition) Prentice Hall" have to say on
>> the matter.
>...
>> and on the matter of readability (which cryptic roughly translates to):
>>
>> <begin_quote>
>> Readability. A program is readable if the underlying structure of the
>> algorithm and data represented by the program is apparent from inspection
>> of the program text. A readable programs is often said to be
>> _self-documenting_, it is understandable without any separate documentation
>> (although this goal is seldem achieved in practice).
>
>There is a small fallacy here. Nothing can be self-descriptive. To
>understand ANYTHING, there must be some prior assumptions made, or
>documentation in an already known language.
No disagreement from me. However, you can't just say that because nothing
is completely self-descriptive everything is on the same level. One
programming language can be far more self-descriptive than another.
>Thus, readability depends on the knowledge of the reader, and is therefore >subjective.
Again, no argument from me. I never said that subjectivity doesn't come
into it. I said that it isn't 100% subjective, as David Cornelson is
arguing.
>> Anybody still think that how cryptic a language is is 100% subjective?
>(GLYPH raises his right hand)
>> Anybody still think that how cryptic a language is isn't that important,
>> and it's really just the functionality that matters?
>Okay, I think we're getting mixed up, now. I'm saying there's no way to
>objectively quantify readability.
No, I'm not getting mixed up. That was for the people in this thread who
seemed to think it was silly to use how cryptic a language is in comparing
them. I don't think you were one of them.
>I did not say there are no useful subjective methods. In information theory,
>it turns out that nearly everything is subjective, but that doesn't
>mean that nothing can be useful or relevant!
Well then it isn't 100% subjective (in the situation where it is useful or
relevant) is it ?
Say we take a group of people from a particular culture, say, Australians.
Most of these people will have shared cultural knowledge between them, from
being taught similar stuff in school and growing up in the similar cultural
situations, etc. From this, these people know that + means addition and -
means subtraction, and so if we swap the meanings of these in a programming
language then it's going to make the language more cryptic for these
people. The meaning of + and - might be 100% subjective in a vaccumm -- if
people had never encountered them before -- but that's not the reality of
the situation. Anyone who is going to be doing programming will know what
+ and - means. This means that we can define a principal about the usage
of + and - and how this effects how cryptic a language is. Once a
principal/rule can be defined (it doesn't matter if there are some
excaptions to it; there are exceptions to everything), then it isn't 100%
subjective.
';';James';';
JC
[...]
I'd like to add that the common usage of cryptic assumes the cultural
influences, to an extent. The common usage of cryptic doesn't specifically
imply "cryptic in a vaccumm".
';';James';';