Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: what do forthers think of shen?
46 views
Skip to first unread message
Rod Pemberton
May 30, 2012, 4:30:01 PM5/30/12
to
"quiet_lad" <gavc...@gmail.com> wrote in message
news:dfb3beba-f641-4064...@b5g2000pbm.googlegroups.com...
> [inSubject: What do forthers think of shen?]
>
> [link to Shen's history]
http://www.shenlanguage.org/motivation.html
Well, "casual_spam," it must be time to change your nickname again. It
seems that almost no one has responded to you... I was hoping no one would
do so for a week or so. Then, I'd post. Oh, well...
Maybe, you should subscribe to comp.lang.misc and post there?
I've added it.
Well, Shen (or Qi) looks like Lisp to me... It has abundant - some would
say excessive - parentheses. Other than very minimal surface exposure, I'm
not familiar with Lisp. Also, I'm not familiar with the "many of the
advantages of ML" that Dr. Tarver wished he could bring to Lisp. So, should
I really posit an opinion of "what [I] think of Qi (or Shen)" ... ?
It seems Dr. Tarver is working with mostly non-mainstream languages, i.e.,
academic. Apparently, he worked for the same University where ML was
created, which was probably why he is familiar with it. The claims that
"'Qi' was a ground-breaking language" seem absurd given that no one, i.e.,
everyone outside academia, was aware of this language until you posted a
link to it...
I did think it is interesting that Dr. Tarver _eventually_ stumbled onto a
good idea for preserving and promoting his Qi language, i.e., make it more
portable. Both C and Forth were rewarded for being portable. His
implementation of the idea of a more portable Qi apparently was comprised
entirely of recoding Qi using a small subset of the language. He probably
needs to add a few bootstrap-only operations to the language too. Of
course, we don't have the myriad of computing platforms we once did. But,
today, we do have a variety of browser languages, embedded environments, and
cloud computing, where it could be used.
However, the fact that there are places where Shen could be used glosses
over the fact that Shen still *looks* like Lisp. Have you ever seen anyone
jump up and down to learn Lisp? Yeah, I didn't think so... The point
being: there are some languages programmers enjoy programming, and others
that they don't or won't. That's mostly a function of syntax, but also of
capability. Pascal and BASIC's syntax was acceptable, but their capability
was limited. Fortran's capability was fine, but it's syntax was beyond
horrible, to the point of being nightmarish. So, even if Shen is superior
to *all* other programming languages, not very many people are going to be
willing to program it. The syntax reminds them of Lisp ... which most
programmer's know as "Lost In Stupid Parentheses". Despite rebuttals here
by skilled Forth programmers, Forth's lack of syntax has created much the
same image problem for it. People need structure and order, i.e., syntax.
Lisp also has the image problem that one needs an understanding of "lambda
calculus" to effectively program in it. That perception definately doesn't
help.
Should Dr. Tarver have renamed Qi to Shen afterwards? No, probably not.
Personally, I think that was a blatant mistake. It's very likely that the
original and current base of Qi users won't ever hear or learn of Shen...
Or, if they do, they'll think it is too radical a change, e.g., like C to
C++. In general, people don't like change. They'll accept equivalence or
slight improvement, but major change - even if provably superior - scares
them away. If you're designing a language for popular and widespread use,
then average people need to be comfortable programming it. It would be wise
if below-average people would be willing to program it too.
As you know or should, various Forths over the years have been bootstrapped
or implemented using a small subset of their total functionality, i.e.,
Forth-in-Forth. Various Lisps have done so too. In fact, I stumbled
across three Lisps that claimed to have done so which were posted to Usenet
archives. Two bootstrapped from eight operations and one from fourteen.
So, Dr. Tarver was far from the first to recode Lisp-in-Lisp using a small
subset. With "50 or less" Shen operations, the size of his subset is
comparable to what's needed to implement a useable Forth, not just a Forth
which is bootstrapped. So, it's entirely feasible that Shen is useable too.
For those rare few who are interested in Lisp, I listed those three
bootstrap Lisp's and their language elements here:
http://groups.google.com/group/comp.lang.forth/msg/10872cb68edcb526
Rod Pemberton
news:dfb3beba-f641-4064...@b5g2000pbm.googlegroups.com...
> [inSubject: What do forthers think of shen?]
>
> [link to Shen's history]
http://www.shenlanguage.org/motivation.html
Well, "casual_spam," it must be time to change your nickname again. It
seems that almost no one has responded to you... I was hoping no one would
do so for a week or so. Then, I'd post. Oh, well...
Maybe, you should subscribe to comp.lang.misc and post there?
I've added it.
Well, Shen (or Qi) looks like Lisp to me... It has abundant - some would
say excessive - parentheses. Other than very minimal surface exposure, I'm
not familiar with Lisp. Also, I'm not familiar with the "many of the
advantages of ML" that Dr. Tarver wished he could bring to Lisp. So, should
I really posit an opinion of "what [I] think of Qi (or Shen)" ... ?
It seems Dr. Tarver is working with mostly non-mainstream languages, i.e.,
academic. Apparently, he worked for the same University where ML was
created, which was probably why he is familiar with it. The claims that
"'Qi' was a ground-breaking language" seem absurd given that no one, i.e.,
everyone outside academia, was aware of this language until you posted a
link to it...
I did think it is interesting that Dr. Tarver _eventually_ stumbled onto a
good idea for preserving and promoting his Qi language, i.e., make it more
portable. Both C and Forth were rewarded for being portable. His
implementation of the idea of a more portable Qi apparently was comprised
entirely of recoding Qi using a small subset of the language. He probably
needs to add a few bootstrap-only operations to the language too. Of
course, we don't have the myriad of computing platforms we once did. But,
today, we do have a variety of browser languages, embedded environments, and
cloud computing, where it could be used.
However, the fact that there are places where Shen could be used glosses
over the fact that Shen still *looks* like Lisp. Have you ever seen anyone
jump up and down to learn Lisp? Yeah, I didn't think so... The point
being: there are some languages programmers enjoy programming, and others
that they don't or won't. That's mostly a function of syntax, but also of
capability. Pascal and BASIC's syntax was acceptable, but their capability
was limited. Fortran's capability was fine, but it's syntax was beyond
horrible, to the point of being nightmarish. So, even if Shen is superior
to *all* other programming languages, not very many people are going to be
willing to program it. The syntax reminds them of Lisp ... which most
programmer's know as "Lost In Stupid Parentheses". Despite rebuttals here
by skilled Forth programmers, Forth's lack of syntax has created much the
same image problem for it. People need structure and order, i.e., syntax.
Lisp also has the image problem that one needs an understanding of "lambda
calculus" to effectively program in it. That perception definately doesn't
help.
Should Dr. Tarver have renamed Qi to Shen afterwards? No, probably not.
Personally, I think that was a blatant mistake. It's very likely that the
original and current base of Qi users won't ever hear or learn of Shen...
Or, if they do, they'll think it is too radical a change, e.g., like C to
C++. In general, people don't like change. They'll accept equivalence or
slight improvement, but major change - even if provably superior - scares
them away. If you're designing a language for popular and widespread use,
then average people need to be comfortable programming it. It would be wise
if below-average people would be willing to program it too.
As you know or should, various Forths over the years have been bootstrapped
or implemented using a small subset of their total functionality, i.e.,
Forth-in-Forth. Various Lisps have done so too. In fact, I stumbled
across three Lisps that claimed to have done so which were posted to Usenet
archives. Two bootstrapped from eight operations and one from fourteen.
So, Dr. Tarver was far from the first to recode Lisp-in-Lisp using a small
subset. With "50 or less" Shen operations, the size of his subset is
comparable to what's needed to implement a useable Forth, not just a Forth
which is bootstrapped. So, it's entirely feasible that Shen is useable too.
For those rare few who are interested in Lisp, I listed those three
bootstrap Lisp's and their language elements here:
http://groups.google.com/group/comp.lang.forth/msg/10872cb68edcb526
Rod Pemberton
quiet_lad
Jun 3, 2012, 5:46:32 PM6/3/12
to
On May 30, 1:30 pm, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
wrote:
> "quiet_lad" <gavcom...@gmail.com> wrote in message
ever check out www.paulgraham.com ?
wrote:
> "quiet_lad" <gavcom...@gmail.com> wrote in message
Rugxulo
Jun 4, 2012, 6:46:15 AM6/4/12
to
Hi,
Not much to contribute here, but I'll chime in anyways,
On May 30, 3:30 pm, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
wrote:
> "quiet_lad" <gavcom...@gmail.com> wrote in message
what people think of xyz languages, etc. Though I doubt even
comp.lang.lisp is (barely) suitable for this one.
> Well, Shen (or Qi) looks like Lisp to me... It has abundant - some would
> say excessive - parentheses.
It was supposedly originally written in Common Lisp, so that's no
surprise.
> Other than very minimal surface exposure, I'm
> not familiar with Lisp.
Ditto.
> Also, I'm not familiar with the "many of the
> advantages of ML" that Dr. Tarver wished he could bring to Lisp.
Strong typing??? (Dunno.)
> So, should I really posit an opinion of "what [I] think of Qi (or Shen)" ... ?
Why the hell not? ;-)
> It seems Dr. Tarver is working with mostly non-mainstream languages, i.e.,
> academic. Apparently, he worked for the same University where ML was
> created, which was probably why he is familiar with it.
Probably, yes, though again, I take issue with the idea that "ML"
means anything (Standard? OCaml?) without qualifications.
BTW, it's completely useless trivia, but I feel compelled to mention
Luca Cardelli, who wrote the first ML compiler, later moved on to help
co-design Modula-3, and now works at Microsoft Research in Cambridge
messing around with F# (OCaml-based?).
And since I don't grok any ML dialect, that's pretty much all I know
about it. ;-)
> The claims that
> "'Qi' was a ground-breaking language" seem absurd given that no one, i.e.,
> everyone outside academia, was aware of this language until you posted a
> link to it...
Well, yes, but all languages overhype themselves: Java, C#, C++, etc.
etc.
BTW, a quick glance the other day showed that Qi seems to have been
released in 2005, so it's not very old. (And Qi II was 2009. The
website is still up, and there's quite a long page on Wikipedia about
it. The Shen page is much much smaller.)
> I did think it is interesting that Dr. Tarver _eventually_ stumbled onto a
> good idea for preserving and promoting his Qi language, i.e., make it more
> portable.
Portable subsetting isn't really that innovative (ahem, Pascal-S), but
yes, sorely needed. Why more people don't do that is beyond me.
Bootstrapping and portability is a bane of HLLs, ironically, at least
in my limited experience.
> Both C and Forth were rewarded for being portable.
Both are standardized and with many implementations, so yes, that's
very good.
> His implementation of the idea of a more portable Qi apparently was comprised
> entirely of recoding Qi using a small subset of the language. He probably
> needs to add a few bootstrap-only operations to the language too. Of
> course, we don't have the myriad of computing platforms we once did.
We still have quite a few, e.g. PPC or ARM, but most mainstream users
only see IA32 or x64.
> But, today, we do have a variety of browser languages, embedded environments, and
> cloud computing, where it could be used.
(puke) Sorry, couldn't resist. ;-)
> However, the fact that there are places where Shen could be used glosses
> over the fact that Shen still *looks* like Lisp. Have you ever seen anyone
> jump up and down to learn Lisp? Yeah, I didn't think so...
Doesn't matter, it seems popular enough, at least in certain circles.
At least programmers often praise it (but never use it, similarly
Smalltalk, Haskell). I think one Modula-3 dude (Kalsow?) wrote his own
Lisp-y mini language (in M3). Also one FreeBASIC guy did similarly.
It's a popular pasttime, too bad most implementations leave much to be
desired. (And that's coming from a guy who doesn't grok Lisp either,
sheesh.)
> The point
> being: there are some languages programmers enjoy programming, and others
> that they don't or won't.
http://lang-index.sourceforge.net/
Doesn't look like there is much consensus for any language, honestly.
It's quite a big hodgepodge, one big melting pot. Of course, I don't
quite believe those statistics, there's no way Objective-C is more
popular than C++, not even close. I'd honestly be surprised if even
10% of programmers knew Java. (I still don't see why it's so popular.
Sure, allegedly it has some minor advantages or conveniences, but
otherwise it doesn't seem too unique. I guess it's just got lots of
corporate momentum.)
> That's mostly a function of syntax, but also of
> capability. Pascal and BASIC's syntax was acceptable, but their capability
> was limited.
There have been various Pascal dialects, mostly ignored these days,
but it is good. Limited? What language isn't? You can't cram
everything (although some like to try!).
As for BASIC, I've never seen a more fragmented language family. There
is very little compatibility, so it's almost not worth even lumping
together. (And ironic because some people still split off Pascal and
Delphi yet all BASICs are alike?? Not quite.)
> Fortran's capability was fine, but it's syntax was beyond
> horrible, to the point of being nightmarish.
I'm not fluent in Fortran either, but a lot changed with F90 (and 95,
03, 08). So there's that.
> So, even if Shen is superior
> to *all* other programming languages, not very many people are going to be
> willing to program it.
Well, that's what they all say. And it's true to some extent. Why fix
what ain't broken? But still, how can you know unless you try?
> The syntax reminds them of Lisp ... which most
> programmer's know as "Lost In Stupid Parentheses". Despite rebuttals here
> by skilled Forth programmers, Forth's lack of syntax has created much the
> same image problem for it.
I barely tried (and failed) learning Forth a few years ago. I would
much much rather learn that instead of Lisp, it looks loads easier and
more reasonable to my mind. Common Lisp and Scheme seem ultra
confusing.
> People need structure and order, i.e., syntax.
Not really. ;-)
> Lisp also has the image problem that one needs an understanding of "lambda
> calculus" to effectively program in it. That perception definately doesn't
> help.
There's always dark corners in any language, just about. It's a
complicated field. Still fun to tinker with, I guess, but you gotta
limit yourself or you'll never get anything done. Unfortunately,
almost nobody can agree on a minimal subset of anything. Creeping
featurism, I guess.
> Should Dr. Tarver have renamed Qi to Shen afterwards? No, probably not.
> Personally, I think that was a blatant mistake.
Well, he already had "Qi II", circa 2009, so should Shen have been "Qi
III"?? At some point you have to admit that the language is nothing
like its predecessors. Maybe not in this particular case, but if
enough changes, it's more friendly to just change the name. (Think
"Van Halen". A lot of controversy could've been avoided if they
changed it, though obviously it would have been a bit silly since
that's the brothers' surname.)
> It's very likely that the
> original and current base of Qi users won't ever hear or learn of Shen...
The Qi website points to the Shen one, so don't worry about that.
Besides, apparently Qi isn't that old anyways, so there's little shift
to worry about.
> Or, if they do, they'll think it is too radical a change, e.g., like C to
> C++. In general, people don't like change. They'll accept equivalence or
> slight improvement, but major change - even if provably superior - scares
> them away. If you're designing a language for popular and widespread use,
> then average people need to be comfortable programming it. It would be wise
> if below-average people would be willing to program it too.
Well ... Modula-2 was different enough to Pascal to warrant a name
change. It did (sorta) "improve" things. Sometimes it's easier to
rethink things from scratch. Even Oberon changed quite a bit from
Modula-2 (though in some ways not as much). Well, we all know Pascal
did better with average programmers than those, but they still had a
lot of their own successes and are still used.
It's a weird field. New languages come out all the time, and new
features and OSes and things make things more complicated. If
anything, most languages don't really die, people just end up
preferring similar languages that have extra features (e.g. C++,
Java). Or they have to drop their favorite compiler because it won't
work on their new OS (or similar).
> As you know or should, various Forths over the years have been bootstrapped
> or implemented using a small subset of their total functionality, i.e.,
> Forth-in-Forth. Various Lisps have done so too.
So why don't more languages do this? Why is it so hard to bootstrap
things these days? Why are compilers themselves never strictly
compliant??
> In fact, I stumbled
> across three Lisps that claimed to have done so which were posted to Usenet
> archives. Two bootstrapped from eight operations and one from fourteen.
Great, but were they "standard" in any way? A random Lisp that doesn't
comply to anyone else is fairly useless, IMHO. Well, not really, but
you catch my drift, we don't really "need" ten bazillion incompatible
dialects. Maybe it's unrealistic to have a "full" ANSI Common Lisp or
R6RS in "strictly conformant" ANSI C89, but it seems no one even tries
anymore.
> So, Dr. Tarver was far from the first to recode Lisp-in-Lisp using a small
> subset. With "50 or less" Shen operations, the size of his subset is
> comparable to what's needed to implement a useable Forth, not just a Forth
> which is bootstrapped. So, it's entirely feasible that Shen is useable too.
Probably. It seems Shen now runs atop CLisp, SBCL, Clojure (JVM), and
Javascript.
> For those rare few who are interested in Lisp, I listed those three
> bootstrap Lisp's and their language elements here:http://groups.google.com/group/comp.lang.forth/msg/10872cb68edcb526
Yeah, seen your list before, very very interesting. Though I still
argue that those are too minimal, and that as such most Lisp
implementations always go well beyond that (and add a bunch of OS-
specific crud, blech, stupid Autotools).
Not much to contribute here, but I'll chime in anyways,
On May 30, 3:30 pm, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
wrote:
> "quiet_lad" <gavcom...@gmail.com> wrote in message
>
> news:dfb3beba-f641-4064...@b5g2000pbm.googlegroups.com...> [inSubject: What do forthers think of shen?]
>
> > [link to Shen's history]
>
> http://www.shenlanguage.org/motivation.html
>
> Well, "casual_spam," it must be time to change your nickname again. It
> seems that almost no one has responded to you... I was hoping no one would
> do so for a week or so. Then, I'd post. Oh, well...
>
> Maybe, you should subscribe to comp.lang.misc and post there?
> I've added it.
Admittedly, comp.lang.forth isn't really the best place to be asking
> news:dfb3beba-f641-4064...@b5g2000pbm.googlegroups.com...> [inSubject: What do forthers think of shen?]
>
> > [link to Shen's history]
>
> http://www.shenlanguage.org/motivation.html
>
> Well, "casual_spam," it must be time to change your nickname again. It
> seems that almost no one has responded to you... I was hoping no one would
> do so for a week or so. Then, I'd post. Oh, well...
>
> Maybe, you should subscribe to comp.lang.misc and post there?
> I've added it.
what people think of xyz languages, etc. Though I doubt even
comp.lang.lisp is (barely) suitable for this one.
> Well, Shen (or Qi) looks like Lisp to me... It has abundant - some would
> say excessive - parentheses.
surprise.
> Other than very minimal surface exposure, I'm
> not familiar with Lisp.
> Also, I'm not familiar with the "many of the
> advantages of ML" that Dr. Tarver wished he could bring to Lisp.
> So, should I really posit an opinion of "what [I] think of Qi (or Shen)" ... ?
> It seems Dr. Tarver is working with mostly non-mainstream languages, i.e.,
> academic. Apparently, he worked for the same University where ML was
> created, which was probably why he is familiar with it.
means anything (Standard? OCaml?) without qualifications.
BTW, it's completely useless trivia, but I feel compelled to mention
Luca Cardelli, who wrote the first ML compiler, later moved on to help
co-design Modula-3, and now works at Microsoft Research in Cambridge
messing around with F# (OCaml-based?).
And since I don't grok any ML dialect, that's pretty much all I know
about it. ;-)
> The claims that
> "'Qi' was a ground-breaking language" seem absurd given that no one, i.e.,
> everyone outside academia, was aware of this language until you posted a
> link to it...
etc.
BTW, a quick glance the other day showed that Qi seems to have been
released in 2005, so it's not very old. (And Qi II was 2009. The
website is still up, and there's quite a long page on Wikipedia about
it. The Shen page is much much smaller.)
> I did think it is interesting that Dr. Tarver _eventually_ stumbled onto a
> good idea for preserving and promoting his Qi language, i.e., make it more
> portable.
yes, sorely needed. Why more people don't do that is beyond me.
Bootstrapping and portability is a bane of HLLs, ironically, at least
in my limited experience.
> Both C and Forth were rewarded for being portable.
very good.
> His implementation of the idea of a more portable Qi apparently was comprised
> entirely of recoding Qi using a small subset of the language. He probably
> needs to add a few bootstrap-only operations to the language too. Of
> course, we don't have the myriad of computing platforms we once did.
only see IA32 or x64.
> But, today, we do have a variety of browser languages, embedded environments, and
> cloud computing, where it could be used.
> However, the fact that there are places where Shen could be used glosses
> over the fact that Shen still *looks* like Lisp. Have you ever seen anyone
> jump up and down to learn Lisp? Yeah, I didn't think so...
At least programmers often praise it (but never use it, similarly
Smalltalk, Haskell). I think one Modula-3 dude (Kalsow?) wrote his own
Lisp-y mini language (in M3). Also one FreeBASIC guy did similarly.
It's a popular pasttime, too bad most implementations leave much to be
desired. (And that's coming from a guy who doesn't grok Lisp either,
sheesh.)
> The point
> being: there are some languages programmers enjoy programming, and others
> that they don't or won't.
Doesn't look like there is much consensus for any language, honestly.
It's quite a big hodgepodge, one big melting pot. Of course, I don't
quite believe those statistics, there's no way Objective-C is more
popular than C++, not even close. I'd honestly be surprised if even
10% of programmers knew Java. (I still don't see why it's so popular.
Sure, allegedly it has some minor advantages or conveniences, but
otherwise it doesn't seem too unique. I guess it's just got lots of
corporate momentum.)
> That's mostly a function of syntax, but also of
> capability. Pascal and BASIC's syntax was acceptable, but their capability
> was limited.
but it is good. Limited? What language isn't? You can't cram
everything (although some like to try!).
As for BASIC, I've never seen a more fragmented language family. There
is very little compatibility, so it's almost not worth even lumping
together. (And ironic because some people still split off Pascal and
Delphi yet all BASICs are alike?? Not quite.)
> Fortran's capability was fine, but it's syntax was beyond
> horrible, to the point of being nightmarish.
03, 08). So there's that.
> So, even if Shen is superior
> to *all* other programming languages, not very many people are going to be
> willing to program it.
what ain't broken? But still, how can you know unless you try?
> The syntax reminds them of Lisp ... which most
> programmer's know as "Lost In Stupid Parentheses". Despite rebuttals here
> by skilled Forth programmers, Forth's lack of syntax has created much the
> same image problem for it.
much much rather learn that instead of Lisp, it looks loads easier and
more reasonable to my mind. Common Lisp and Scheme seem ultra
confusing.
> People need structure and order, i.e., syntax.
> Lisp also has the image problem that one needs an understanding of "lambda
> calculus" to effectively program in it. That perception definately doesn't
> help.
complicated field. Still fun to tinker with, I guess, but you gotta
limit yourself or you'll never get anything done. Unfortunately,
almost nobody can agree on a minimal subset of anything. Creeping
featurism, I guess.
> Should Dr. Tarver have renamed Qi to Shen afterwards? No, probably not.
> Personally, I think that was a blatant mistake.
III"?? At some point you have to admit that the language is nothing
like its predecessors. Maybe not in this particular case, but if
enough changes, it's more friendly to just change the name. (Think
"Van Halen". A lot of controversy could've been avoided if they
changed it, though obviously it would have been a bit silly since
that's the brothers' surname.)
> It's very likely that the
> original and current base of Qi users won't ever hear or learn of Shen...
Besides, apparently Qi isn't that old anyways, so there's little shift
to worry about.
> Or, if they do, they'll think it is too radical a change, e.g., like C to
> C++. In general, people don't like change. They'll accept equivalence or
> slight improvement, but major change - even if provably superior - scares
> them away. If you're designing a language for popular and widespread use,
> then average people need to be comfortable programming it. It would be wise
> if below-average people would be willing to program it too.
change. It did (sorta) "improve" things. Sometimes it's easier to
rethink things from scratch. Even Oberon changed quite a bit from
Modula-2 (though in some ways not as much). Well, we all know Pascal
did better with average programmers than those, but they still had a
lot of their own successes and are still used.
It's a weird field. New languages come out all the time, and new
features and OSes and things make things more complicated. If
anything, most languages don't really die, people just end up
preferring similar languages that have extra features (e.g. C++,
Java). Or they have to drop their favorite compiler because it won't
work on their new OS (or similar).
> As you know or should, various Forths over the years have been bootstrapped
> or implemented using a small subset of their total functionality, i.e.,
> Forth-in-Forth. Various Lisps have done so too.
things these days? Why are compilers themselves never strictly
compliant??
> In fact, I stumbled
> across three Lisps that claimed to have done so which were posted to Usenet
> archives. Two bootstrapped from eight operations and one from fourteen.
comply to anyone else is fairly useless, IMHO. Well, not really, but
you catch my drift, we don't really "need" ten bazillion incompatible
dialects. Maybe it's unrealistic to have a "full" ANSI Common Lisp or
R6RS in "strictly conformant" ANSI C89, but it seems no one even tries
anymore.
> So, Dr. Tarver was far from the first to recode Lisp-in-Lisp using a small
> subset. With "50 or less" Shen operations, the size of his subset is
> comparable to what's needed to implement a useable Forth, not just a Forth
> which is bootstrapped. So, it's entirely feasible that Shen is useable too.
Javascript.
> For those rare few who are interested in Lisp, I listed those three
> bootstrap Lisp's and their language elements here:http://groups.google.com/group/comp.lang.forth/msg/10872cb68edcb526
argue that those are too minimal, and that as such most Lisp
implementations always go well beyond that (and add a bunch of OS-
specific crud, blech, stupid Autotools).
Rod Pemberton
Jun 4, 2012, 4:35:19 PM6/4/12
to
"Rugxulo" <rug...@gmail.com> wrote in message
news:38d0a7bf-138e-401d...@i19g2000yqn.googlegroups.com...
> > [Qi and Shen or Lisp conversation snipped]
The first five comprise almost 60% ... They all appear to be C based to me.
> It's quite a big hodgepodge, one big melting pot. Of course, I don't
> quite believe those statistics, there's no way Objective-C is more
> popular than C++, not even close. I'd honestly be surprised if even
> 10% of programmers knew Java. (I still don't see why it's so popular.
> Sure, allegedly it has some minor advantages or conveniences, but
> otherwise it doesn't seem too unique. I guess it's just got lots of
> corporate momentum.)
Personally, I believe the smaller numbers are inflated or exaggerated
somewhat, and the larger ones are underestimated. You might be right
about the ones near to the top seeming overly large also. I'd guess 50%
less.
Also, you'll always see dead languages in the lists, e.g., LOGO ...
LOGO peaked in the 1980's. It was used almost exclusively for it's (now
primitive) graphics ability, by school children. But, even that usage was
almost non-existant. I don't recall anyone using LOGO as a programming
language, ever.
So, is a number like "0.839%" for LOGO realistic? I don't think so. The
Wikipedia page below claims ~460K programmers in the US. That seems really
low to me, but I'll go with it. So, that would be ~4K people programming in
Logo... That's really hard to believe, even if one considers academia.
http://en.wikipedia.org/wiki/Software_engineering_demographics
> > People need structure and order, i.e., syntax.
>
> Not really. ;-)
[OT]
Well, last night on TV, psychologists had people walking in circles around a
pole and seeing non-existant snakes in trees on Discovery Channel's Head
Games episode "Conformity". (The show should not to be confused with the
Science Channel's Head Games gameshow.)
http://dsc.discovery.com/tv/head-games/about-show.html
Over the years, there have been similar shows by others, such as "Mind
Control" by Derren Brown and "Deception" by Keith Barry.
You wouldn't believe some of the stuff psychologists, mentalists,
illusionists, hypnotists, and magicians can (supposedly) convince people to
do without them (apparently) being aware of it, and perhaps you shouldn't
believe all of it... It is TV. The stuff they refer to as NLP
(neuro-linguistic programming) is really shocking. Actual NLP seems to be
more psychology based than what they are doing, using words to cause others
to believe things untrue or to do things they wouldn't or shouldn't do.
> > As you know or should, various Forths over the years have been
> > bootstrapped or implemented using a small subset of their total
> > functionality, i.e., Forth-in-Forth. Various Lisps have done so too.
>
> So why don't more languages do this? Why is it so hard to bootstrap
> things these days? Why are compilers themselves never strictly
> compliant??
Today, they cross-compile from a working computing platform. They just have
to rework the assembler output of the compiler and have an assembler on the
new host to recompile.
Years ago, you first wrote an assembler using hand coded machine language,
since there was no assembler available. Then, you wrote a interpreter for
some minimal language. After improving the language substantially, you
wrote a compiler for another language in that interpreter language. Then,
you ported the compiler's code to the compiler's language.
AFAIK, building up a language from a small subset was not a widely used
idea. However, there are many languages and libraries that have done so
over the years. You can see that it was done with Forth and Lisp many years
ago. Although, it wasn't done entirely that way in the beginning with
Forth. It came after.
Early K&R style C also has characteristics to indicate it might've been done
that way originally. Much of the language can be built up from a small
subset of functionality that closely matches what microprocessors and
c.p.u.'s of the era supported. The C language's file robust operations can
be built upon 7 or so minimal PDP file operations. It still can be done so
to this day. Also, the declaration of the types used by procedure variables
comes after their naming in K&R C. This is easy to parse. It tells you how
many variables there are and what their names are. Then, you get those
names with their types, already knowing how many variables to expect and
what they are called. The ANSI C method of names and types together is
slightly more difficult. You don't know how many variables you'll get or
what they are called upfront.
> > In fact, I stumbled across three Lisps that claimed to have done so
> > which were posted to Usenet archives. Two bootstrapped from eight
> > operations and one from fourteen.
>
> Great, but were they "standard" in any way?
I'd assume that the operations that they chose to implement are standard.
> A random Lisp that doesn't comply to anyone else is fairly useless,
> IMHO. Well, not really, but you catch my drift, we don't really "need"
> ten bazillion incompatible dialects. Maybe it's unrealistic to have a
> "full" ANSI Common Lisp or R6RS in "strictly conformant" ANSI
> C89, but it seems no one even tries anymore.
I didn't start out to build a Forth interpreter. I also didn't intend to
make one that is ANS-94 Forth compliant. However, so far, I've only run
into a few impediments while implementing Forth from a modest set of
low-level words or primitives. I've managed to implement about 50% of
ANS-94 Forth core and core extension words. I wasn't even trying to make my
Forth words ANS compliant, but the vast majority are. The functionality is
mostly the same as the older Forth specifications. The exact number of
primitives I have changes as I work on it, but thirty to forty or so. From
what I've been doing lately, I know I'll need a few more. I doubt the
quantity will double to 60 or 80. The point is that a quite complicated
system can be built up from a minimal set of operations. That doesn't mean
that it'll be fast... It'll be working.
E.g., in the post I list two ANSI/ISO C libraries which only need 18 or 19
system calls to implement. What that means is, once you have a working C
compiler, you only need 18 or 19 OS functions to compile an existing or
implement a new C library! I know that 7 or 8 or so of those are the
original primitive PDP file I/O functions. Every OS has to have those, or
something very similar. So, implementing a C library is "do-able" even on
8-bit machine. A POSIX C library is far more complex though. But, once you
have C and a C library (mostly unneeded by a good C programmer), the entire
"world" of programming is yours... Yes, some obtuse functionality that
non-C programmers rave about won't be easy to implement, but one rarely
needs that functionality. When you do, it's likely some academic coded a
library for you. [I suspect I've stated much of this paragraph before.]
http://groups.google.com/group/comp.lang.forth/msg/10872cb68edcb526
Rod Pemberton
news:38d0a7bf-138e-401d...@i19g2000yqn.googlegroups.com...
> On May 30, 3:30 pm, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
> wrote:
...
> wrote:
> > [Qi and Shen or Lisp conversation snipped]
> >
> > The point being: there are some languages programmers
> > enjoy programming, and others that they don't or won't.
>
> http://lang-index.sourceforge.net/
>
> Doesn't look like there is much consensus for any language, honestly.
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
> > The point being: there are some languages programmers
> > enjoy programming, and others that they don't or won't.
>
> http://lang-index.sourceforge.net/
>
> Doesn't look like there is much consensus for any language, honestly.
The first five comprise almost 60% ... They all appear to be C based to me.
> It's quite a big hodgepodge, one big melting pot. Of course, I don't
> quite believe those statistics, there's no way Objective-C is more
> popular than C++, not even close. I'd honestly be surprised if even
> 10% of programmers knew Java. (I still don't see why it's so popular.
> Sure, allegedly it has some minor advantages or conveniences, but
> otherwise it doesn't seem too unique. I guess it's just got lots of
> corporate momentum.)
somewhat, and the larger ones are underestimated. You might be right
about the ones near to the top seeming overly large also. I'd guess 50%
less.
Also, you'll always see dead languages in the lists, e.g., LOGO ...
LOGO peaked in the 1980's. It was used almost exclusively for it's (now
primitive) graphics ability, by school children. But, even that usage was
almost non-existant. I don't recall anyone using LOGO as a programming
language, ever.
So, is a number like "0.839%" for LOGO realistic? I don't think so. The
Wikipedia page below claims ~460K programmers in the US. That seems really
low to me, but I'll go with it. So, that would be ~4K people programming in
Logo... That's really hard to believe, even if one considers academia.
http://en.wikipedia.org/wiki/Software_engineering_demographics
> > People need structure and order, i.e., syntax.
>
> Not really. ;-)
Well, last night on TV, psychologists had people walking in circles around a
pole and seeing non-existant snakes in trees on Discovery Channel's Head
Games episode "Conformity". (The show should not to be confused with the
Science Channel's Head Games gameshow.)
http://dsc.discovery.com/tv/head-games/about-show.html
Over the years, there have been similar shows by others, such as "Mind
Control" by Derren Brown and "Deception" by Keith Barry.
You wouldn't believe some of the stuff psychologists, mentalists,
illusionists, hypnotists, and magicians can (supposedly) convince people to
do without them (apparently) being aware of it, and perhaps you shouldn't
believe all of it... It is TV. The stuff they refer to as NLP
(neuro-linguistic programming) is really shocking. Actual NLP seems to be
more psychology based than what they are doing, using words to cause others
to believe things untrue or to do things they wouldn't or shouldn't do.
> > As you know or should, various Forths over the years have been
> > bootstrapped or implemented using a small subset of their total
> > functionality, i.e., Forth-in-Forth. Various Lisps have done so too.
>
> So why don't more languages do this? Why is it so hard to bootstrap
> things these days? Why are compilers themselves never strictly
> compliant??
to rework the assembler output of the compiler and have an assembler on the
new host to recompile.
Years ago, you first wrote an assembler using hand coded machine language,
since there was no assembler available. Then, you wrote a interpreter for
some minimal language. After improving the language substantially, you
wrote a compiler for another language in that interpreter language. Then,
you ported the compiler's code to the compiler's language.
AFAIK, building up a language from a small subset was not a widely used
idea. However, there are many languages and libraries that have done so
over the years. You can see that it was done with Forth and Lisp many years
ago. Although, it wasn't done entirely that way in the beginning with
Forth. It came after.
Early K&R style C also has characteristics to indicate it might've been done
that way originally. Much of the language can be built up from a small
subset of functionality that closely matches what microprocessors and
c.p.u.'s of the era supported. The C language's file robust operations can
be built upon 7 or so minimal PDP file operations. It still can be done so
to this day. Also, the declaration of the types used by procedure variables
comes after their naming in K&R C. This is easy to parse. It tells you how
many variables there are and what their names are. Then, you get those
names with their types, already knowing how many variables to expect and
what they are called. The ANSI C method of names and types together is
slightly more difficult. You don't know how many variables you'll get or
what they are called upfront.
> > In fact, I stumbled across three Lisps that claimed to have done so
> > which were posted to Usenet archives. Two bootstrapped from eight
> > operations and one from fourteen.
>
> Great, but were they "standard" in any way?
> A random Lisp that doesn't comply to anyone else is fairly useless,
> IMHO. Well, not really, but you catch my drift, we don't really "need"
> ten bazillion incompatible dialects. Maybe it's unrealistic to have a
> "full" ANSI Common Lisp or R6RS in "strictly conformant" ANSI
> C89, but it seems no one even tries anymore.
make one that is ANS-94 Forth compliant. However, so far, I've only run
into a few impediments while implementing Forth from a modest set of
low-level words or primitives. I've managed to implement about 50% of
ANS-94 Forth core and core extension words. I wasn't even trying to make my
Forth words ANS compliant, but the vast majority are. The functionality is
mostly the same as the older Forth specifications. The exact number of
primitives I have changes as I work on it, but thirty to forty or so. From
what I've been doing lately, I know I'll need a few more. I doubt the
quantity will double to 60 or 80. The point is that a quite complicated
system can be built up from a minimal set of operations. That doesn't mean
that it'll be fast... It'll be working.
E.g., in the post I list two ANSI/ISO C libraries which only need 18 or 19
system calls to implement. What that means is, once you have a working C
compiler, you only need 18 or 19 OS functions to compile an existing or
implement a new C library! I know that 7 or 8 or so of those are the
original primitive PDP file I/O functions. Every OS has to have those, or
something very similar. So, implementing a C library is "do-able" even on
8-bit machine. A POSIX C library is far more complex though. But, once you
have C and a C library (mostly unneeded by a good C programmer), the entire
"world" of programming is yours... Yes, some obtuse functionality that
non-C programmers rave about won't be easy to implement, but one rarely
needs that functionality. When you do, it's likely some academic coded a
library for you. [I suspect I've stated much of this paragraph before.]
http://groups.google.com/group/comp.lang.forth/msg/10872cb68edcb526
Rod Pemberton
Rugxulo
Jun 9, 2012, 3:05:06 PM6/9/12
to
Hi,
On Jun 4, 3:35 pm, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
wrote:
> "Rugxulo" <rugx...@gmail.com> wrote in message
compatible. The others (C#, Java), not so much, IMO.
Though honestly, I can't help but be cynical (?) here, so when I see
the top five, all I'm really seeing is the efforts of commercial
vendors: C# = MS, Java = Oracle, Obj-C = Apple, C/C++ = FSF/GNU, etc.
(among others of course).
HLLs often proclaim portability as a lofty (almost mandatory) goal,
but these days, it seems almost a conflict of interest. To make
something truly portable, you have to almost hate your OS or your
compiler, and many seem content to be unportable in the name of speed,
features, pride, etc. (And you could always conditionally be both, but
nobody ever does that.) I'm probably guilty of that too.
Sorry for the brooding, just something on my mind.
> > It's quite a big hodgepodge, one big melting pot. Of course, I don't
> > quite believe those statistics, there's no way Objective-C is more
> > popular than C++, not even close. I'd honestly be surprised if even
> > 10% of programmers knew Java. (I still don't see why it's so popular.
> > Sure, allegedly it has some minor advantages or conveniences, but
> > otherwise it doesn't seem too unique. I guess it's just got lots of
> > corporate momentum.)
>
> Personally, I believe the smaller numbers are inflated or exaggerated
> somewhat, and the larger ones are underestimated. You might be right
> about the ones near to the top seeming overly large also. I'd guess 50%
> less.
Well, most programming is done behind closed doors, and a lot of
people still don't share their code (even if non-commercial). It's the
traditional copyright mindset. It's very prevalent, even in this GNU
age. ;-) So everything on these kinds of lists has to be taken with
a grain of salt because we'll never truly know what goes on behind the
scenes.
> Also, you'll always see dead languages in the lists, e.g., LOGO ...
> LOGO peaked in the 1980's. It was used almost exclusively for it's (now
> primitive) graphics ability, by school children. But, even that usage was
> almost non-existant. I don't recall anyone using LOGO as a programming
> language, ever.
I would doubt it too, but who knows. Perhaps all the code these web
searches find is old stuff?? It doesn't mean it's all being worked on
and still maintained now. Who knows. Anyways, things go in cycles, and
some languages are "flavor of the week" (C#, Java). I'm sure Logo had
its 15 minutes of fame at one time (though dunno if it was ever
standardized or semi-sorta or whatever).
> So, is a number like "0.839%" for LOGO realistic? I don't think so. The
> Wikipedia page below claims ~460K programmers in the US. That seems really
> low to me, but I'll go with it.
Probably means professionals or engineers who use it on the side, not
bored hobbyist cranks like me. I guess it's easy to forget that the
IBM PC, to most people, is a consumer device (like a toaster or
microwave), not something extensible and programmable for screwing
around with.
> So, that would be ~4K people programming in
> Logo... That's really hard to believe, even if one considers academia.
>
> http://en.wikipedia.org/wiki/Software_engineering_demographics
Who knows how many Logo groups exist, maybe they meet once a week
somewhere? Dunno, but it's certainly possible.
> > > As you know or should, various Forths over the years have been
> > > bootstrapped or implemented using a small subset of their total
> > > functionality, i.e., Forth-in-Forth. Various Lisps have done so too.
>
> > So why don't more languages do this? Why is it so hard to bootstrap
> > things these days? Why are compilers themselves never strictly
> > compliant??
>
> Today, they cross-compile from a working computing platform. They just have
> to rework the assembler output of the compiler and have an assembler on the
> new host to recompile.
More likely that they just don't care or bother at all. Or at least
that seems to be the case to my weak eyes.
> Years ago, you first wrote an assembler using hand coded machine language,
> since there was no assembler available. Then, you wrote a interpreter for
> some minimal language. After improving the language substantially, you
> wrote a compiler for another language in that interpreter language. Then,
> you ported the compiler's code to the compiler's language.
But they always seem to throw out the intermediate forms. Admittedly
weak, but it would prevent others from having to start from scratch,
so to speak.
"xyz language is great, but you'll have to use abc OS + architecture
and pqr compiler." (I didn't know I was shopping for a new computer
too!)
> AFAIK, building up a language from a small subset was not a widely used
> idea. However, there are many languages and libraries that have done so
> over the years. You can see that it was done with Forth and Lisp many years
> ago. Although, it wasn't done entirely that way in the beginning with
> Forth. It came after.
I think most languages and implementations today make things too
tightly woven together, not separated enough from OS or cpu or common
features. It's very hard not to be (too much) influenced by your
surroundings. Bad assumptions are made, sometimes on purpose, but
nobody cares because (they think) "nobody else cares either".
> Early K&R style C also has characteristics to indicate it might've been done
> that way originally. Much of the language can be built up from a small
> subset of functionality that closely matches what microprocessors and
> c.p.u.'s of the era supported.
Yes, it was done in smaller stages because of RAM constraints.
Nowadays it's seemingly 1000x more complex, despite still delivering
the same functionality. I don't know why a modern implementation has
to be so complex, but it usually is. (Contrast GCC with LCC or TCC.)
Though "nobody" uses K&R syntax anymore, oddly. It's weird to me how
people can brag on and on about a language (e.g. Ada83) but still
strictly only use a newer version (Ada2005). In other words, it's
wasn't "good enough" in the first place (to them), but now that it has
xyz, it's "perfect" (until next revision!).
Disagreements over dialects can hamper getting actual work done. And
it's just silly (IMHO) to drop a platform (which only has older
compilers due to bootstrapping issues) over dialect disagreements.
It's like it's a crime to use "older" dialects on "newer" OSes. They
want to be all new, all the time, else nobody will like them (I
guess). It's like they want to pretend that the language "as
originally intended" isn't good for literally anything anymore.
Strange stuff.
> I didn't start out to build a Forth interpreter. I also didn't intend to
> make one that is ANS-94 Forth compliant. However, so far, I've only run
> into a few impediments while implementing Forth from a modest set of
> low-level words or primitives. I've managed to implement about 50% of
> ANS-94 Forth core and core extension words. I wasn't even trying to make my
> Forth words ANS compliant, but the vast majority are. The functionality is
> mostly the same as the older Forth specifications. The exact number of
> primitives I have changes as I work on it, but thirty to forty or so. From
> what I've been doing lately, I know I'll need a few more. I doubt the
> quantity will double to 60 or 80. The point is that a quite complicated
> system can be built up from a minimal set of operations. That doesn't mean
> that it'll be fast... It'll be working.
Well, that's good, of course. My point was that nobody does that
anymore, for whatever reason. You'd think they would stick to a common
denominator, but for most people these days, that means "top tier"
only, which is sad. I feel like a standard has failed if nobody sticks
to it. Hence things like pure ANSI C (C89) are probably effectively
dead in lieu of POSIX.
It's just weird. On the one hand, as a developer, you want to
accomplish a goal in a reasonable way. But who is your audience?
There's nothing wrong with targeting a tiny niche fragment, but it
seems weird to limit yourself arbitrarily. It's just a weird idea that
"if you build it, they will come". That's true, but it feels like
consumers are being forced more than invited.
(lame, obsolete, nowadays incorrect examples) "You can't use Oberon
without OberonOS." (or) "You can't use Java without Sun's JVM." (or)
"You can't use Lisp without garbage collection." (or) "You can't use
GCC without *nix."
Even across x86, it seems very hard to be portable.
> E.g., in the post I list two ANSI/ISO C libraries which only need 18 or 19
> system calls to implement. What that means is, once you have a working C
> compiler, you only need 18 or 19 OS functions to compile an existing or
> implement a new C library!
Great but (almost) useless as "nobody" cares for pure ANSI C anymore.
(Or maybe you mean POSIX, but I'd be surprised.)
> I know that 7 or 8 or so of those are the
> original primitive PDP file I/O functions. Every OS has to have those, or
> something very similar. So, implementing a C library is "do-able" even on
> 8-bit machine. A POSIX C library is far more complex though.
Indeed. Not necessarily bad, just platform zealotry prevents people
from working together very well. So even "POSIX" sometimes doesn't
"work". I guess if you only love your own platform and hate everybody
else, "portability" is a dirty word.
> But, once you
> have C and a C library (mostly unneeded by a good C programmer), the entire
> "world" of programming is yours...
It's already all yours, you just don't have total specs for
everything. ;-)
That's all anybody can complain about, really, not knowing or
understanding "how to do it". If we knew how to do everything, OS and
language wouldn't matter at all. So I could just manually translate or
implement everything, I wouldn't even need a specific compiler. But
source code isn't usually readable enough for that, and specs aren't
always forthcoming (and synapses aren't always firing ...).
> Yes, some obtuse functionality that
> non-C programmers rave about won't be easy to implement, but one rarely
> needs that functionality.
I dunno, everything is complicated except very basic I/O. Even ANSI C
is barely supported sometimes (difficulties in setjmp/longjmp or
signal), but it does seem like a good minimal "accepted" ground to
build upon (no huge runtime overhead). Then again, that's like saying,
"Any good compiler (textual translator) could be written in ISO 7185
Pascal", but no one ever does!
> When you do, it's likely some academic coded a
> library for you. [I suspect I've stated much of this paragraph before.]
>
> http://groups.google.com/group/comp.lang.forth/msg/10872cb68edcb526
Still interesting, though it leaves out a few things. ETA has 8,
Befunge-93 has 26, 68000 had? 56, 8086 had 100+, etc. I'm probably
forgetting a few others too (e.g. Oberon isn't that bloated either,
according to the EBNF).
BTW, how many libc functions are in ANSI C89? 32 keywords (not
counting preprocessor), 15 headers, probably 100 (??) functions,
blindly guessing.
P.S. I really shouldn't complain, esp. since something like FPC's
implementation solved a lot of issues. Plus ANSI C89 and ANS 94 Forth
have very many implementations (more than most!), so at least in that
regard they succeeded. I just get frustrated when something can't (or
won't) compile easily (or anymore or ...).
On Jun 4, 3:35 pm, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
wrote:
> "Rugxulo" <rugx...@gmail.com> wrote in message
>
> news:38d0a7bf-138e-401d...@i19g2000yqn.googlegroups.com...> On May 30, 3:30 pm, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
> > wrote:
>
> > > The point being: there are some languages programmers
> > > enjoy programming, and others that they don't or won't.
>
> >http://lang-index.sourceforge.net/
>
> > Doesn't look like there is much consensus for any language, honestly.
>
> http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
>
> The first five comprise almost 60% ... They all appear to be C based to me.
For three of them, you're mostly right, as they indeed are 99%
> news:38d0a7bf-138e-401d...@i19g2000yqn.googlegroups.com...> On May 30, 3:30 pm, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
> > wrote:
>
> > > The point being: there are some languages programmers
> > > enjoy programming, and others that they don't or won't.
>
> >http://lang-index.sourceforge.net/
>
> > Doesn't look like there is much consensus for any language, honestly.
>
> http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
>
> The first five comprise almost 60% ... They all appear to be C based to me.
compatible. The others (C#, Java), not so much, IMO.
Though honestly, I can't help but be cynical (?) here, so when I see
the top five, all I'm really seeing is the efforts of commercial
vendors: C# = MS, Java = Oracle, Obj-C = Apple, C/C++ = FSF/GNU, etc.
(among others of course).
HLLs often proclaim portability as a lofty (almost mandatory) goal,
but these days, it seems almost a conflict of interest. To make
something truly portable, you have to almost hate your OS or your
compiler, and many seem content to be unportable in the name of speed,
features, pride, etc. (And you could always conditionally be both, but
nobody ever does that.) I'm probably guilty of that too.
Sorry for the brooding, just something on my mind.
> > It's quite a big hodgepodge, one big melting pot. Of course, I don't
> > quite believe those statistics, there's no way Objective-C is more
> > popular than C++, not even close. I'd honestly be surprised if even
> > 10% of programmers knew Java. (I still don't see why it's so popular.
> > Sure, allegedly it has some minor advantages or conveniences, but
> > otherwise it doesn't seem too unique. I guess it's just got lots of
> > corporate momentum.)
>
> Personally, I believe the smaller numbers are inflated or exaggerated
> somewhat, and the larger ones are underestimated. You might be right
> about the ones near to the top seeming overly large also. I'd guess 50%
> less.
people still don't share their code (even if non-commercial). It's the
traditional copyright mindset. It's very prevalent, even in this GNU
age. ;-) So everything on these kinds of lists has to be taken with
a grain of salt because we'll never truly know what goes on behind the
scenes.
> Also, you'll always see dead languages in the lists, e.g., LOGO ...
> LOGO peaked in the 1980's. It was used almost exclusively for it's (now
> primitive) graphics ability, by school children. But, even that usage was
> almost non-existant. I don't recall anyone using LOGO as a programming
> language, ever.
searches find is old stuff?? It doesn't mean it's all being worked on
and still maintained now. Who knows. Anyways, things go in cycles, and
some languages are "flavor of the week" (C#, Java). I'm sure Logo had
its 15 minutes of fame at one time (though dunno if it was ever
standardized or semi-sorta or whatever).
> So, is a number like "0.839%" for LOGO realistic? I don't think so. The
> Wikipedia page below claims ~460K programmers in the US. That seems really
> low to me, but I'll go with it.
bored hobbyist cranks like me. I guess it's easy to forget that the
IBM PC, to most people, is a consumer device (like a toaster or
microwave), not something extensible and programmable for screwing
around with.
> So, that would be ~4K people programming in
> Logo... That's really hard to believe, even if one considers academia.
>
> http://en.wikipedia.org/wiki/Software_engineering_demographics
somewhere? Dunno, but it's certainly possible.
> > > As you know or should, various Forths over the years have been
> > > bootstrapped or implemented using a small subset of their total
> > > functionality, i.e., Forth-in-Forth. Various Lisps have done so too.
>
> > So why don't more languages do this? Why is it so hard to bootstrap
> > things these days? Why are compilers themselves never strictly
> > compliant??
>
> Today, they cross-compile from a working computing platform. They just have
> to rework the assembler output of the compiler and have an assembler on the
> new host to recompile.
that seems to be the case to my weak eyes.
> Years ago, you first wrote an assembler using hand coded machine language,
> since there was no assembler available. Then, you wrote a interpreter for
> some minimal language. After improving the language substantially, you
> wrote a compiler for another language in that interpreter language. Then,
> you ported the compiler's code to the compiler's language.
weak, but it would prevent others from having to start from scratch,
so to speak.
"xyz language is great, but you'll have to use abc OS + architecture
and pqr compiler." (I didn't know I was shopping for a new computer
too!)
> AFAIK, building up a language from a small subset was not a widely used
> idea. However, there are many languages and libraries that have done so
> over the years. You can see that it was done with Forth and Lisp many years
> ago. Although, it wasn't done entirely that way in the beginning with
> Forth. It came after.
tightly woven together, not separated enough from OS or cpu or common
features. It's very hard not to be (too much) influenced by your
surroundings. Bad assumptions are made, sometimes on purpose, but
nobody cares because (they think) "nobody else cares either".
> Early K&R style C also has characteristics to indicate it might've been done
> that way originally. Much of the language can be built up from a small
> subset of functionality that closely matches what microprocessors and
> c.p.u.'s of the era supported.
Nowadays it's seemingly 1000x more complex, despite still delivering
the same functionality. I don't know why a modern implementation has
to be so complex, but it usually is. (Contrast GCC with LCC or TCC.)
Though "nobody" uses K&R syntax anymore, oddly. It's weird to me how
people can brag on and on about a language (e.g. Ada83) but still
strictly only use a newer version (Ada2005). In other words, it's
wasn't "good enough" in the first place (to them), but now that it has
xyz, it's "perfect" (until next revision!).
Disagreements over dialects can hamper getting actual work done. And
it's just silly (IMHO) to drop a platform (which only has older
compilers due to bootstrapping issues) over dialect disagreements.
It's like it's a crime to use "older" dialects on "newer" OSes. They
want to be all new, all the time, else nobody will like them (I
guess). It's like they want to pretend that the language "as
originally intended" isn't good for literally anything anymore.
Strange stuff.
> I didn't start out to build a Forth interpreter. I also didn't intend to
> make one that is ANS-94 Forth compliant. However, so far, I've only run
> into a few impediments while implementing Forth from a modest set of
> low-level words or primitives. I've managed to implement about 50% of
> ANS-94 Forth core and core extension words. I wasn't even trying to make my
> Forth words ANS compliant, but the vast majority are. The functionality is
> mostly the same as the older Forth specifications. The exact number of
> primitives I have changes as I work on it, but thirty to forty or so. From
> what I've been doing lately, I know I'll need a few more. I doubt the
> quantity will double to 60 or 80. The point is that a quite complicated
> system can be built up from a minimal set of operations. That doesn't mean
> that it'll be fast... It'll be working.
anymore, for whatever reason. You'd think they would stick to a common
denominator, but for most people these days, that means "top tier"
only, which is sad. I feel like a standard has failed if nobody sticks
to it. Hence things like pure ANSI C (C89) are probably effectively
dead in lieu of POSIX.
It's just weird. On the one hand, as a developer, you want to
accomplish a goal in a reasonable way. But who is your audience?
There's nothing wrong with targeting a tiny niche fragment, but it
seems weird to limit yourself arbitrarily. It's just a weird idea that
"if you build it, they will come". That's true, but it feels like
consumers are being forced more than invited.
(lame, obsolete, nowadays incorrect examples) "You can't use Oberon
without OberonOS." (or) "You can't use Java without Sun's JVM." (or)
"You can't use Lisp without garbage collection." (or) "You can't use
GCC without *nix."
Even across x86, it seems very hard to be portable.
> E.g., in the post I list two ANSI/ISO C libraries which only need 18 or 19
> system calls to implement. What that means is, once you have a working C
> compiler, you only need 18 or 19 OS functions to compile an existing or
> implement a new C library!
(Or maybe you mean POSIX, but I'd be surprised.)
> I know that 7 or 8 or so of those are the
> original primitive PDP file I/O functions. Every OS has to have those, or
> something very similar. So, implementing a C library is "do-able" even on
> 8-bit machine. A POSIX C library is far more complex though.
from working together very well. So even "POSIX" sometimes doesn't
"work". I guess if you only love your own platform and hate everybody
else, "portability" is a dirty word.
> But, once you
> have C and a C library (mostly unneeded by a good C programmer), the entire
> "world" of programming is yours...
everything. ;-)
That's all anybody can complain about, really, not knowing or
understanding "how to do it". If we knew how to do everything, OS and
language wouldn't matter at all. So I could just manually translate or
implement everything, I wouldn't even need a specific compiler. But
source code isn't usually readable enough for that, and specs aren't
always forthcoming (and synapses aren't always firing ...).
> Yes, some obtuse functionality that
> non-C programmers rave about won't be easy to implement, but one rarely
> needs that functionality.
is barely supported sometimes (difficulties in setjmp/longjmp or
signal), but it does seem like a good minimal "accepted" ground to
build upon (no huge runtime overhead). Then again, that's like saying,
"Any good compiler (textual translator) could be written in ISO 7185
Pascal", but no one ever does!
> When you do, it's likely some academic coded a
> library for you. [I suspect I've stated much of this paragraph before.]
>
> http://groups.google.com/group/comp.lang.forth/msg/10872cb68edcb526
Befunge-93 has 26, 68000 had? 56, 8086 had 100+, etc. I'm probably
forgetting a few others too (e.g. Oberon isn't that bloated either,
according to the EBNF).
BTW, how many libc functions are in ANSI C89? 32 keywords (not
counting preprocessor), 15 headers, probably 100 (??) functions,
blindly guessing.
P.S. I really shouldn't complain, esp. since something like FPC's
implementation solved a lot of issues. Plus ANSI C89 and ANS 94 Forth
have very many implementations (more than most!), so at least in that
regard they succeeded. I just get frustrated when something can't (or
won't) compile easily (or anymore or ...).
Rod Pemberton
Jun 9, 2012, 7:49:41 PM6/9/12
to
"Rugxulo" <rug...@gmail.com> wrote in message
news:47c22852-3659-4a10...@30g2000yqi.googlegroups.com...
> On Jun 4, 3:35 pm, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
> wrote:
> > "Rugxulo" <rugx...@gmail.com> wrote in message
> >
news:38d0a7bf-138e-401d...@i19g2000yqn.googlegroups.com...
> > > On May 30, 3:30 pm, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
> > > wrote:
...
> wrote:
> > "Rugxulo" <rugx...@gmail.com> wrote in message
> >
news:38d0a7bf-138e-401d...@i19g2000yqn.googlegroups.com...
> > > On May 30, 3:30 pm, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
> > > wrote:
> > > > The point being: there are some languages programmers
> > > > enjoy programming, and others that they don't or won't.
>
>
> > > Doesn't look like there is much consensus for any language, honestly.
>
> > [link]
> > > Doesn't look like there is much consensus for any language, honestly.
>
>
> > The first five comprise almost 60% ... They all appear to be C based to
> > me.
>
> For three of them, you're mostly right, as they indeed are 99%
> compatible. The others (C#, Java), not so much, IMO.
>
> Though honestly, I can't help but be cynical (?) here, so when I see
> the top five, all I'm really seeing is the efforts of commercial
> vendors: C# = MS, Java = Oracle, Obj-C = Apple, C/C++ =
> FSF/GNU, etc. (among others of course).
You're cynical that commercial software has all the success?
> > The first five comprise almost 60% ... They all appear to be C based to
> > me.
>
> For three of them, you're mostly right, as they indeed are 99%
> compatible. The others (C#, Java), not so much, IMO.
>
> Though honestly, I can't help but be cynical (?) here, so when I see
> the top five, all I'm really seeing is the efforts of commercial
> vendors: C# = MS, Java = Oracle, Obj-C = Apple, C/C++ =
> FSF/GNU, etc. (among others of course).
The biggest market is the business market. They've got customers who pay
them money.
Who wants the problems an incompatibilities of open-source software? Even
projects which started out a commercial, with lots of money backing them,
quickly become stale, start suffering bit-rot, and begin breaking other
things when they fix a different problem. You can pick any open or free
project you want and see that happening: Linux, GNU C, OpenOffice,
OpenWatcom, VLC, Opera, Kernelex ... I've not seen any which hasn't broken
one thing while fixing something else.
E.g., let's take VLC. They just release a new, heavily rewritten, and much
improved version: "twoflower" 2.0.0 and 2.0.1. Now, I've got lots of wmv
and mpg files that won't play, or have all sorts of graphics and sound
issues ... video tearing, wrong colors, vertical/horizontal sync playing
instead of video. It's so bad, I'm actually having to use WMP. No joke.
Also, the sound is no longer "flat". By flat, I mean played at the levels
in the recording. I didn't realize it at first when listening to CDs and
MP3s. Certain songs sound exactly the same on CD players, records, cassette
tapes, and FM radio. I did realize it after listening my favorite Internet
radio station and hearing a song I'd listened to previously via that same
station. It's also a song I know well from the cassette era. A big
"WTF"... All the sound levels in VLC were *WRONG*. It seems that this
version of VLC has an internal equalization curve applied to everything it
plays that you can't disable. That's in addition to whatever you choose for
equalization or your speaker settings. From what I can tell, the hidden eq
curve boosts very low and very high frequencies alot, reduces all the other
frequencies slightly - almost flatly, with a slightly sharper reduction at
voice frequencies. It's truly horrid. If you manage to fix the non-high
and non-low frequences via eq, then those high and low frequencies are maxed
out, or they're distorted if you've lowered their settings. Whomever snuck
that in, has seriously defective hearing or was using some really bad
speakers/headphones. Of course, it could be some complication resulting
from them applying various algorithms, e.g., multiple eq curves applied for
some reason.
> My point was that nobody
> anymore, for whatever reason. You'd think they would stick to a
> common denominator, but for most people these days, that means
> "top tier" only, which is sad. I feel like a standard has failed if nobody
> sticks to it. Hence things like pure ANSI C (C89) are probably
> effectively dead in lieu of POSIX.
Well, today, most programmers, I would assume, are not engineers,
> common denominator, but for most people these days, that means
> "top tier" only, which is sad. I feel like a standard has failed if nobody
> sticks to it. Hence things like pure ANSI C (C89) are probably
> effectively dead in lieu of POSIX.
mathematicians, physicists, etc who got into programming via work, school or
academia, or home use. Today, I'd assume most programmers are chasing the
money. They're going to college and getting a degree in CS (computer
science). They're not interested in EE, ME, math or physics or chemistry,
and maybe not even capable of getting a degree in those fields. What I've
seen of CS programmers is that they usually aren't someone who is interested
in programming computers, but they're very interested programming *games*.
They want to develop some "cool" game. E.g., D&D and Tolkien revisited,
board wargames as 3D FPS, MMORPGs, MUDs, uMoria 3D, virtual LARP, i.e.,
whatever is "next big (gaming) thing". Engineers, mathematicians,
physicists, old school programmers who program aren't usually interested in
games. They like coding computer solutions in much the same way they like
solving tough problems.
> It's just weird. On the one hand, as a developer, you want to
> accomplish a goal in a reasonable way. But who is your audience?
> There's nothing wrong with targeting a tiny niche fragment, but it
> seems weird to limit yourself arbitrarily. It's just a weird idea that
> "if you build it, they will come". That's true, but it feels like
> consumers are being forced more than invited.
their hardware, video cards, and software applications to just work without
issues. For that, you need MS Windows. Hardware manufacturers write
drivers and update software for Windows. Like it or not, Linux just isn't
capable of that.
> Even across x86, it seems very hard to be portable.
instructions on x86. When I come across a piece of software that runs
slowly, like C64 1Mhz era slow, on a Ghz class x86. It's gone. I find
another program. To be portable, you have to reduce software to the
smallest set of useable and common functionality. That means slow. In a
perfect world, the hardware would implement an OS and GUI. Graphics cards
are completely capable of having a GUI in hardware or software implemented
on the card itself. PCs are fully capable of having an OS implemente in
hardware or software implemented on the motherboard. The more OS and driver
related software you need, the harder it becomes to implement an effective
OS. Linux runs into this problem. Drivers are not written for it, or are
closed source. So, Linux users use the minimal level of hardware support
for which they can get a generic driver. They're missing out on all the
hardware advances. The Linux developers don't seem to be keeping pace with
all the software and hardware changes, i.e., lack of funds, lack of skilled
programmers, lack of compatibility with Windows drivers, etc.
> > E.g., in the post I list two ANSI/ISO C libraries which only need 18 or
> > 19 system calls to implement. What that means is, once you have a
> > working C compiler, you only need 18 or 19 OS functions to compile
> > an existing or implement a new C library!
>
> Great but (almost) useless as "nobody" cares for pure ANSI C anymore.
> (Or maybe you mean POSIX, but I'd be surprised.)
language without the C libraries. There are a few, mostly trivial things
you need from the libraries which aren't part of the C language that are
needed. The real exception is file I/O. You need the C library's file I/O.
Coding non-applications, i.e., an OS or drivers etc can require alot of the
more advanced stuff, but even the majority of that is written in standard C
within the library. So, you can write it yourself. In a few cases, you'll
need some inline assembly or external assembly.
> If we knew how to do everything, OS and
> language wouldn't matter at all.
Brains ... (intellect)
Bucks ... (money)
Bouts ... (time)
> So I could just manually translate or implement everything,
> I wouldn't even need a specific compiler. But source code isn't
> usually readable enough for that, and specs aren't always
> forthcoming (and synapses aren't always firing ...).
free.
> [...] difficulties in setjmp/longjmp or signal [...]
You shouldn't need setjmp/longjmp. If you do, it indicates you didn't
follow good structured programming, or you're doing something non-C-ish:
multiple entry points to procedures, . Besides, they are custom to a
specific C implementation, i.e., non-portable. They can be difficult to use
correctly even for a specific C compiler. IIRC, one of the return values is
defined for ANSI C but not POSIX C. They usually work by dumping a bunch of
processor registers into a C array. They don't save procedure parameters or
stack frame etc. I.e., they're something you should avoid. I'd only
consider them if extreme error recovery was required. I've posted a few
posts discussing them. I fairly recently posted a reply to
alt.os.development summarizing what H&S says about them.
http://groups.google.com/group/alt.os.development/msg/cf0da548ff6e33a7
AFAIR, I not used signal much either... It seems I've used it a few times
to trap memory access violations, and disable DOS specific traps like
Ctrl-C. I know POSIX environments have more signals, so it might used more
frequently there.
> > When you do, it's likely some academic coded a
> > library for you. [I suspect I've stated much of this paragraph before.]
> >
> >
http://groups.google.com/group/comp.lang.forth/msg/10872cb68edcb526
>
> Still interesting, though it leaves out a few things. ETA has 8,
> Befunge-93 has 26, 68000 had? 56, 8086 had 100+, etc.
> I'm probably forgetting a few others too (e.g. Oberon isn't
> that bloated either, according to the EBNF).
>
Well, I wasn't doing assembly languages.
> Still interesting, though it leaves out a few things. ETA has 8,
> Befunge-93 has 26, 68000 had? 56, 8086 had 100+, etc.
> I'm probably forgetting a few others too (e.g. Oberon isn't
> that bloated either, according to the EBNF).
>
I'll add a note to check ETA and Befunge.
I've added others to my list (unpublished):
L4 microkernel (7)
Malbolge (7)
Fromage (10)
Unix v7 (46)
LCC's IR (109)
POSIX 1003.2 (130)
Mach v3 microkernel (~140)
1003.1-90 FIPS 151-2 (199)
POSIX 1003.1-1996 (390)
AES (489)
SVID3 base (582)
XPG4 base (607)
Single UNIX (1168)
Single UNIX v2 (1434)
Single UNIX v3 (1742)
> BTW, how many libc functions are in ANSI C89? 32
> keywords (not counting preprocessor), 15 headers,
> probably 100 (??) functions, blindly guessing.
I started gathering stuff for a C library some years ago. I probably have a
list somewhere...
Well, I don't seem to have a clean list of ANSI or ISO C functions!
I do have a few lists from the Internet of POSIX functions that categorize
by specification. From one of the POSIX function lists:
33 keywords in ANSI C
38 keywords in ISO C (+5)
146 ANSI C functions (*)
226 C 94 functions (+80) (*)
555 ISO C functions (+329) (*)(**)
(*) That's after _attempting_ to weed out keywords, constants, structs, C
types, defines, and macro's...
(**) There is overlap of some math functions due to tgmath.h.
I have haphazardly accumulated alot of other C info...
I have a note in a file that K&R C had 23 keywords and 2 pre-processor
directives. As for C "primitives", I've previously posted that C has about
16 "actions", 20 arithmetic operations (not including variations to support
C's many object types). One list has 21 C object types for ISO C.
That includes a few not available to ANSI C. Another list has 50 operators
for C. That includes things like paired brackets, braces, paren's, GCC &&
extension, and pseudo-C operators alignof() and typeof(). So, probably 44
or so for ISO C ... Another list has 12 keywords and procedures which are
C's flow control words. Another list has 22 pre-processor defines supported
by GCC, 13 by OpenWatcom (v1.3), and 7 by other compilers. Another file has
a list which has 55 lines of C operator's and punctuation, 123 lines of
keywords (with many non-ANSI/ISO), 167 compiler extension words. A hash
function I use as part of an in-progress C compiler, has 353 hash values for
C keyword's, operators, pre-processor directives. That included many
compiler specific variations. So, that's gives an idea of the maximum
language "words". That doesn't include C library functions. That also
doesn't include the massive amount of items in the POSIX file I grep'd
above. The other C compiler related programs and grammars I have weren't so
easy to read. Another list indicates ANSI C(89) had 15 headers, three
headers were added(95), six headers were added with ISO C(99) for a total of
24 headers. Those three were probably one of their addendum's or TC's...
1989
assert.h ctype.h errno.h float.h limits.h locale.h math.h setjmp.h signal.h
stdarg.h stddef.h stdio.h stdlib.h string.h time.h
1995
iso646.h wchar.h wctype.h
1999
complex.h fenv.h inttypes.h stdbool.h stdint.h tgmath.h
This is the big list of POSIX functions (ANSI and ISO C too) via Wayback
archive:
Pete Forman's "Portability Guide"
http://web.archive.org/web/20010802210248/http://www.crosswinds.net/~petef/c/portability.txt
Rod Pemberton
Rugxulo
Jun 11, 2012, 1:08:39 PM6/11/12
to
Hi,
On Jun 9, 6:49 pm, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
supported by the biggest commercial companies, who have a tendency to
(over)advertise and drown out everything else, intentionally or
otherwise. Moreso I wish developers weren't so trendy as to only use
the latest and greatest fads. Then again, we still have good *old*
UNIX (tm), so .... ;-)
BTW, a lot of free/libre software is commercially funded too, even
compilers, but that's moreso from freelance work and corporations than
the idea of pushing the burden on each individual user to contribute
financially, so it seems (and is) cheaper overall.
> Who wants the problems an incompatibilities of open-source software? Even
> projects which started out a commercial, with lots of money backing them,
> quickly become stale, start suffering bit-rot, and begin breaking other
> things when they fix a different problem. You can pick any open or free
> project you want and see that happening: Linux, GNU C, OpenOffice,
> OpenWatcom, VLC, Opera, Kernelex ... I've not seen any which hasn't broken
> one thing while fixing something else.
We all know that just because you pay or don't pay for something, that
has no bearing on how well it is written or how often it is updated.
Yes, a lot of open source sucks, so does a lot of commercial stuff,
but part of the idea of being a programmer is because nothing fulfills
your needs / wants. If it did, you'd just use what already existed.
(Don't use VLC, not a big multimedia buff, sorry.)
> Well, today, most programmers, I would assume, are not engineers,
> mathematicians, physicists, etc who got into programming via work, school or
> academia, or home use. Today, I'd assume most programmers are chasing the
> money.
No, but there is always a huge segment of people who do. That's not
necessarily bad, but it sometimes implodes upon itself.
> They're going to college and getting a degree in CS (computer
> science). They're not interested in EE, ME, math or physics or chemistry,
> and maybe not even capable of getting a degree in those fields. What I've
> seen of CS programmers is that they usually aren't someone who is interested
> in programming computers, but they're very interested programming *games*.
These days, a handful of guys can't make a commercial game anymore. Or
it would suck (or be very "retro"). Things just got too complicated.
But yes, traditionally, lots of people got into programming to do some
games. Look at all the DOS stuff from the '90s. But unfortunately, a
lot of that interest died out for various reasons. You don't see a lot
of DOS game programmers anymore, even among those few who do still
target DOS.
> They want to develop some "cool" game. E.g., D&D and Tolkien revisited,
> board wargames as 3D FPS, MMORPGs, MUDs, uMoria 3D, virtual LARP, i.e.,
> whatever is "next big (gaming) thing". Engineers, mathematicians,
> physicists, old school programmers who program aren't usually interested in
> games. They like coding computer solutions in much the same way they like
> solving tough problems.
Home computers are becoming more like appliances (or consoles) than
programmable calculators. It's less about work (or even leisurely fun)
vs. more about multimedia these days. And networking, too, of course.
> > It's just weird. On the one hand, as a developer, you want to
> > accomplish a goal in a reasonable way. But who is your audience?
> > There's nothing wrong with targeting a tiny niche fragment, but it
> > seems weird to limit yourself arbitrarily. It's just a weird idea that
> > "if you build it, they will come". That's true, but it feels like
> > consumers are being forced more than invited.
>
> Nobody wants MS Windows for windowing or as their GUI.
Even MS seems intent on pushing Win32 to the background with Metro
replacing it (almost).
But yes, a lot of people want GUIs, they think console stuff is
deprecated. They're obsessed with their silly menus, icons, etc. They
can't live without them. And Win32 GUI apps are far from unpopular.
(If anything, there are too many that are of questionable use or too
bloated and brittle.)
> Everybody wants
> their hardware, video cards, and software applications to just work without
> issues. For that, you need MS Windows. Hardware manufacturers write
> drivers and update software for Windows. Like it or not, Linux just isn't
> capable of that.
Linux has tons of drivers, moreso than pure kernel code. The problem
isn't lack of drivers or even developers, as Linux is quite popular.
The main issue is lacking public specs, so some hardware can't be well-
supported. ACPI and WLAN cause the biggest problems in Linux, and
sometimes gfx too (esp. 3D). Otherwise, Linux is equally good. But
yes, Windows is slightly better "in some ways" for whatever reason.
(It's hard work, so I'm not surprised that some engineers want to be
paid more than Linux companies traditionally offer.)
> > Even across x86, it seems very hard to be portable.
>
> Software needs to be fast. That means using all those specialize
> instructions on x86.
But x86 is a family, not one specific implementation. So there is no
general rule about what is fast. The only real case I can think of is
SIMD (e.g. SSE), which is what I assume you meant here.
> When I come across a piece of software that runs
> slowly, like C64 1Mhz era slow, on a Ghz class x86. It's gone. I find
> another program.
Oh, so you don't use GCC? (kidding) ;-)
> To be portable, you have to reduce software to the
> smallest set of useable and common functionality. That means slow.
Not necessarily, you can be limited and fast, as long as you aren't
too strict on yourself. But I agree that sometimes it is harder than
you'd like.
> In a perfect world, the hardware would implement an OS and GUI.
Splashtop?
> Graphics cards
> are completely capable of having a GUI in hardware or software implemented
> on the card itself.
Aero? Quartz?
> PCs are fully capable of having an OS implemente in
> hardware or software implemented on the motherboard.
ROM-DOS?
> The more OS and driver
> related software you need, the harder it becomes to implement an effective
> OS.
Not to mention bugfixes and updates.
> Linux runs into this problem. Drivers are not written for it, or are
> closed source.
They aren't all closed source, but some need proprietary firmware. The
kernel devs already whined about this forever. Some things have
improved but others still need work.
And it's not like Windows doesn't have similar issues. Vista changed
the driver model, as did Win64.
> So, Linux users use the minimal level of hardware support
> for which they can get a generic driver. They're missing out on all the
> hardware advances. The Linux developers don't seem to be keeping pace with
> all the software and hardware changes, i.e., lack of funds, lack of skilled
> programmers, lack of compatibility with Windows drivers, etc.
The only compatibility with Windows is ndis, I think, as I've not seen
others. The idea of portable drivers isn't new, but for whatever
reason, Linux and Windows and Mac don't (publicly) share between
themselves. I've seen a few other "hobby" OSes borrow from FreeBSD,
though.
http://code.google.com/p/rosetta-os/
http://udi.certek.com/
> > > E.g., in the post I list two ANSI/ISO C libraries which only need 18 or
> > > 19 system calls to implement. What that means is, once you have a
> > > working C compiler, you only need 18 or 19 OS functions to compile
> > > an existing or implement a new C library!
>
> > Great but (almost) useless as "nobody" cares for pure ANSI C anymore.
> > (Or maybe you mean POSIX, but I'd be surprised.)
>
> Well, if skilled, you can code almost every *application* with just the C
> language without the C libraries. There are a few, mostly trivial things
> you need from the libraries which aren't part of the C language that are
> needed. The real exception is file I/O. You need the C library's file I/O.
I like the idea of Forth block files, but it's impractical for average
use, hence hosted is better, IMO. But yeah, file system support can
get complicated if you aren't careful.
> Coding non-applications, i.e., an OS or drivers etc can require alot of the
> more advanced stuff, but even the majority of that is written in standard C
> within the library. So, you can write it yourself. In a few cases, you'll
> need some inline assembly or external assembly.
I just mean moreso that POSIX is preferred over ANSI C, hence a lot of
stuff needs a billion of POSIX functions instead of the minimal-ish
ANSI variety.
> > If we knew how to do everything, OS and
> > language wouldn't matter at all.
>
> Brute-force ... (trial and error)
> Brains ... (intellect)
> Bucks ... (money)
> Bouts ... (time)
Brute-force and Bouts, that's me. ;-)
> > So I could just manually translate or implement everything,
> > I wouldn't even need a specific compiler. But source code isn't
> > usually readable enough for that, and specs aren't always
> > forthcoming (and synapses aren't always firing ...).
>
> Search for a solution... Sometimes they aren't available, at least for
> free.
Google is sometimes frustratingly inadequate, but that's probably
because my interests are quite esoteric. I can't even find what used
to exist, esp. because most stuff wasn't properly archived or nobody
hosts it anymore (or trivial licensing issues, e.g. not GPL friendly
so nobody cares, etc).
> > [...] difficulties in setjmp/longjmp or signal [...]
>
> You shouldn't need setjmp/longjmp. If you do, it indicates you didn't
> follow good structured programming, or you're doing something non-C-ish:
> multiple entry points to procedures, .
I know, coroutines (e.g. Lua) or exceptions (SJLJ).
> Besides, they are custom to a
> specific C implementation, i.e., non-portable. They can be difficult to use
> correctly even for a specific C compiler. IIRC, one of the return values is
> defined for ANSI C but not POSIX C. They usually work by dumping a bunch of
> processor registers into a C array. They don't save procedure parameters or
> stack frame etc. I.e., they're something you should avoid. I'd only
> consider them if extreme error recovery was required. I've posted a few
> posts discussing them. I fairly recently posted a reply to
> alt.os.development summarizing what H&S says about them.
>
> http://groups.google.com/group/alt.os.development/msg/cf0da548ff6e33a7
It's a weird thing, but it is quite common, so I would like to one day
understand it (unlikely!). ;-)
> AFAIR, I not used signal much either... It seems I've used it a few times
> to trap memory access violations, and disable DOS specific traps like
> Ctrl-C. I know POSIX environments have more signals, so it might used more
> frequently there.
Trapping SIGILL would be nice for opcode emulation, but apparently not
a lot of people care for that. Sue me for liking compatibility.
> > > When you do, it's likely some academic coded a
> > > library for you. [I suspect I've stated much of this paragraph before.]
>
> http://groups.google.com/group/comp.lang.forth/msg/10872cb68edcb526
>
> > g4gqv4$qk...@aioe.org
Horrible language, unusable, just because a guy genetically designed a
"hello world" doesn't make it reasonable. ;-)
> POSIX 1003.2 (130)
Too old, most people ignore it and use lots of extensions.
> Single UNIX v3 (1742)
Yikes, that's a bloated pig. Scary stuff.
> > BTW, how many libc functions are in ANSI C89? 32
> > keywords (not counting preprocessor), 15 headers,
> > probably 100 (??) functions, blindly guessing.
>
> I guess I should add ANSI C ...
>
> I started gathering stuff for a C library some years ago. I probably have a
> list somewhere...
>
> Well, I don't seem to have a clean list of ANSI or ISO C functions!
>
> I do have a few lists from the Internet of POSIX functions that categorize
> by specification. From one of the POSIX function lists:
>
> 33 keywords in ANSI C
From the list (mentioned below, which is a nice find BTW), it lists
"main" as a keyword. I'm not sure I'd count that.
> 38 keywords in ISO C (+5)
Presumably that means C94's NA1 additions.
> 146 ANSI C functions (*)
A little quirky but nice core functionality.
> 226 C 94 functions (+80) (*)
Ugh, wchar_t (puke).
> 555 ISO C functions (+329) (*)(**)
>
> (*) That's after _attempting_ to weed out keywords, constants, structs, C
> types, defines, and macro's...
> (**) There is overlap of some math functions due to tgmath.h.
Yeah, I think C99 went too far in some ways.
> I have haphazardly accumulated alot of other C info...
>
> I have a note in a file that K&R C had 23 keywords and 2 pre-processor
> directives.
Most people seem to have switched to at least ANSI C89 since many
years. A few have moved to C99, but overall it's not 100% popular yet
(though getting there!), e.g. MSVC still lacks it. Anyways, I don't
see a lot of K&R stuff still around, but I'm sure some probably still
exists somewhere.
> So, probably 44
> or so for ISO C ... Another list has 12 keywords and procedures which are
> C's flow control words. Another list has 22 pre-processor defines supported
> by GCC, 13 by OpenWatcom (v1.3), and 7 by other compilers. Another file has
> a list which has 55 lines of C operator's and punctuation, 123 lines of
> keywords (with many non-ANSI/ISO), 167 compiler extension words. A hash
> function I use as part of an in-progress C compiler, has 353 hash values for
> C keyword's, operators, pre-processor directives. That included many
> compiler specific variations. So, that's gives an idea of the maximum
> language "words".
Sounds worse than it is.
> This is the big list of POSIX functions (ANSI and ISO C too) via Wayback
> archive:
>
> Pete Forman's "Portability Guide"http://web.archive.org/web/20010802210248/http://www.crosswinds.net/~...
Yeah, good find, thanks. But POSIX is so unwieldy. :-(
On Jun 9, 6:49 pm, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
wrote:
> "Rugxulo" <rugx...@gmail.com> wrote in message
>
> news:47c22852-3659-4a10...@30g2000yqi.googlegroups.com...> On Jun 4, 3:35 pm, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
> > wrote:
> > > "Rugxulo" <rugx...@gmail.com> wrote in message
>
> news:38d0a7bf-138e-401d...@i19g2000yqn.googlegroups.com...> > > On May 30, 3:30 pm, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
> > > > wrote:
>
> > > > > The point being: there are some languages programmers
> > > > > enjoy programming, and others that they don't or won't.
>
> "Rugxulo" <rugx...@gmail.com> wrote in message
>
> news:47c22852-3659-4a10...@30g2000yqi.googlegroups.com...> On Jun 4, 3:35 pm, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
> > wrote:
> > > "Rugxulo" <rugx...@gmail.com> wrote in message
>
> news:38d0a7bf-138e-401d...@i19g2000yqn.googlegroups.com...> > > On May 30, 3:30 pm, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
> > > > wrote:
>
> > > > > The point being: there are some languages programmers
> > > > > enjoy programming, and others that they don't or won't.
>
> > > > Doesn't look like there is much consensus for any language, honestly.
>
>
> > > The first five comprise almost 60% ... They all appear to be C based to
> > > me.
>
> > For three of them, you're mostly right, as they indeed are 99%
> > compatible. The others (C#, Java), not so much, IMO.
>
> > Though honestly, I can't help but be cynical (?) here, so when I see
> > the top five, all I'm really seeing is the efforts of commercial
> > vendors: C# = MS, Java = Oracle, Obj-C = Apple, C/C++ =
> > FSF/GNU, etc. (among others of course).
>
> You're cynical that commercial software has all the success?
>
> The biggest market is the business market. They've got customers who pay
> them money.
No, I meant that it's kinda "convenient" that the "most popular" is
> > > me.
>
> > For three of them, you're mostly right, as they indeed are 99%
> > compatible. The others (C#, Java), not so much, IMO.
>
> > Though honestly, I can't help but be cynical (?) here, so when I see
> > the top five, all I'm really seeing is the efforts of commercial
> > vendors: C# = MS, Java = Oracle, Obj-C = Apple, C/C++ =
> > FSF/GNU, etc. (among others of course).
>
> You're cynical that commercial software has all the success?
>
> The biggest market is the business market. They've got customers who pay
> them money.
supported by the biggest commercial companies, who have a tendency to
(over)advertise and drown out everything else, intentionally or
otherwise. Moreso I wish developers weren't so trendy as to only use
the latest and greatest fads. Then again, we still have good *old*
UNIX (tm), so .... ;-)
BTW, a lot of free/libre software is commercially funded too, even
compilers, but that's moreso from freelance work and corporations than
the idea of pushing the burden on each individual user to contribute
financially, so it seems (and is) cheaper overall.
> Who wants the problems an incompatibilities of open-source software? Even
> projects which started out a commercial, with lots of money backing them,
> quickly become stale, start suffering bit-rot, and begin breaking other
> things when they fix a different problem. You can pick any open or free
> project you want and see that happening: Linux, GNU C, OpenOffice,
> OpenWatcom, VLC, Opera, Kernelex ... I've not seen any which hasn't broken
> one thing while fixing something else.
has no bearing on how well it is written or how often it is updated.
Yes, a lot of open source sucks, so does a lot of commercial stuff,
but part of the idea of being a programmer is because nothing fulfills
your needs / wants. If it did, you'd just use what already existed.
(Don't use VLC, not a big multimedia buff, sorry.)
> Well, today, most programmers, I would assume, are not engineers,
> mathematicians, physicists, etc who got into programming via work, school or
> academia, or home use. Today, I'd assume most programmers are chasing the
> money.
necessarily bad, but it sometimes implodes upon itself.
> They're going to college and getting a degree in CS (computer
> science). They're not interested in EE, ME, math or physics or chemistry,
> and maybe not even capable of getting a degree in those fields. What I've
> seen of CS programmers is that they usually aren't someone who is interested
> in programming computers, but they're very interested programming *games*.
it would suck (or be very "retro"). Things just got too complicated.
But yes, traditionally, lots of people got into programming to do some
games. Look at all the DOS stuff from the '90s. But unfortunately, a
lot of that interest died out for various reasons. You don't see a lot
of DOS game programmers anymore, even among those few who do still
target DOS.
> They want to develop some "cool" game. E.g., D&D and Tolkien revisited,
> board wargames as 3D FPS, MMORPGs, MUDs, uMoria 3D, virtual LARP, i.e.,
> whatever is "next big (gaming) thing". Engineers, mathematicians,
> physicists, old school programmers who program aren't usually interested in
> games. They like coding computer solutions in much the same way they like
> solving tough problems.
programmable calculators. It's less about work (or even leisurely fun)
vs. more about multimedia these days. And networking, too, of course.
> > It's just weird. On the one hand, as a developer, you want to
> > accomplish a goal in a reasonable way. But who is your audience?
> > There's nothing wrong with targeting a tiny niche fragment, but it
> > seems weird to limit yourself arbitrarily. It's just a weird idea that
> > "if you build it, they will come". That's true, but it feels like
> > consumers are being forced more than invited.
>
> Nobody wants MS Windows for windowing or as their GUI.
replacing it (almost).
But yes, a lot of people want GUIs, they think console stuff is
deprecated. They're obsessed with their silly menus, icons, etc. They
can't live without them. And Win32 GUI apps are far from unpopular.
(If anything, there are too many that are of questionable use or too
bloated and brittle.)
> Everybody wants
> their hardware, video cards, and software applications to just work without
> issues. For that, you need MS Windows. Hardware manufacturers write
> drivers and update software for Windows. Like it or not, Linux just isn't
> capable of that.
isn't lack of drivers or even developers, as Linux is quite popular.
The main issue is lacking public specs, so some hardware can't be well-
supported. ACPI and WLAN cause the biggest problems in Linux, and
sometimes gfx too (esp. 3D). Otherwise, Linux is equally good. But
yes, Windows is slightly better "in some ways" for whatever reason.
(It's hard work, so I'm not surprised that some engineers want to be
paid more than Linux companies traditionally offer.)
> > Even across x86, it seems very hard to be portable.
>
> Software needs to be fast. That means using all those specialize
> instructions on x86.
general rule about what is fast. The only real case I can think of is
SIMD (e.g. SSE), which is what I assume you meant here.
> When I come across a piece of software that runs
> slowly, like C64 1Mhz era slow, on a Ghz class x86. It's gone. I find
> another program.
> To be portable, you have to reduce software to the
> smallest set of useable and common functionality. That means slow.
too strict on yourself. But I agree that sometimes it is harder than
you'd like.
> In a perfect world, the hardware would implement an OS and GUI.
> Graphics cards
> are completely capable of having a GUI in hardware or software implemented
> on the card itself.
> PCs are fully capable of having an OS implemente in
> hardware or software implemented on the motherboard.
> The more OS and driver
> related software you need, the harder it becomes to implement an effective
> OS.
> Linux runs into this problem. Drivers are not written for it, or are
> closed source.
kernel devs already whined about this forever. Some things have
improved but others still need work.
And it's not like Windows doesn't have similar issues. Vista changed
the driver model, as did Win64.
> So, Linux users use the minimal level of hardware support
> for which they can get a generic driver. They're missing out on all the
> hardware advances. The Linux developers don't seem to be keeping pace with
> all the software and hardware changes, i.e., lack of funds, lack of skilled
> programmers, lack of compatibility with Windows drivers, etc.
others. The idea of portable drivers isn't new, but for whatever
reason, Linux and Windows and Mac don't (publicly) share between
themselves. I've seen a few other "hobby" OSes borrow from FreeBSD,
though.
http://code.google.com/p/rosetta-os/
http://udi.certek.com/
> > > E.g., in the post I list two ANSI/ISO C libraries which only need 18 or
> > > 19 system calls to implement. What that means is, once you have a
> > > working C compiler, you only need 18 or 19 OS functions to compile
> > > an existing or implement a new C library!
>
> > Great but (almost) useless as "nobody" cares for pure ANSI C anymore.
> > (Or maybe you mean POSIX, but I'd be surprised.)
>
> Well, if skilled, you can code almost every *application* with just the C
> language without the C libraries. There are a few, mostly trivial things
> you need from the libraries which aren't part of the C language that are
> needed. The real exception is file I/O. You need the C library's file I/O.
use, hence hosted is better, IMO. But yeah, file system support can
get complicated if you aren't careful.
> Coding non-applications, i.e., an OS or drivers etc can require alot of the
> more advanced stuff, but even the majority of that is written in standard C
> within the library. So, you can write it yourself. In a few cases, you'll
> need some inline assembly or external assembly.
stuff needs a billion of POSIX functions instead of the minimal-ish
ANSI variety.
> > If we knew how to do everything, OS and
> > language wouldn't matter at all.
>
> Brute-force ... (trial and error)
> Brains ... (intellect)
> Bucks ... (money)
> Bouts ... (time)
> > So I could just manually translate or implement everything,
> > I wouldn't even need a specific compiler. But source code isn't
> > usually readable enough for that, and specs aren't always
> > forthcoming (and synapses aren't always firing ...).
>
> Search for a solution... Sometimes they aren't available, at least for
> free.
because my interests are quite esoteric. I can't even find what used
to exist, esp. because most stuff wasn't properly archived or nobody
hosts it anymore (or trivial licensing issues, e.g. not GPL friendly
so nobody cares, etc).
> > [...] difficulties in setjmp/longjmp or signal [...]
>
> You shouldn't need setjmp/longjmp. If you do, it indicates you didn't
> follow good structured programming, or you're doing something non-C-ish:
> multiple entry points to procedures, .
> Besides, they are custom to a
> specific C implementation, i.e., non-portable. They can be difficult to use
> correctly even for a specific C compiler. IIRC, one of the return values is
> defined for ANSI C but not POSIX C. They usually work by dumping a bunch of
> processor registers into a C array. They don't save procedure parameters or
> stack frame etc. I.e., they're something you should avoid. I'd only
> consider them if extreme error recovery was required. I've posted a few
> posts discussing them. I fairly recently posted a reply to
> alt.os.development summarizing what H&S says about them.
>
> http://groups.google.com/group/alt.os.development/msg/cf0da548ff6e33a7
understand it (unlikely!). ;-)
> AFAIR, I not used signal much either... It seems I've used it a few times
> to trap memory access violations, and disable DOS specific traps like
> Ctrl-C. I know POSIX environments have more signals, so it might used more
> frequently there.
a lot of people care for that. Sue me for liking compatibility.
> > > When you do, it's likely some academic coded a
> > > library for you. [I suspect I've stated much of this paragraph before.]
>
> http://groups.google.com/group/comp.lang.forth/msg/10872cb68edcb526
>
>
> > Still interesting, though it leaves out a few things. ETA has 8,
> > Befunge-93 has 26, 68000 had? 56, 8086 had 100+, etc.
> > I'm probably forgetting a few others too (e.g. Oberon isn't
> > that bloated either, according to the EBNF).
>
> > Still interesting, though it leaves out a few things. ETA has 8,
> > Befunge-93 has 26, 68000 had? 56, 8086 had 100+, etc.
> > I'm probably forgetting a few others too (e.g. Oberon isn't
> > that bloated either, according to the EBNF).
>
> I've added others to my list (unpublished):
>
> Malbolge (7)
>
Horrible language, unusable, just because a guy genetically designed a
"hello world" doesn't make it reasonable. ;-)
> POSIX 1003.2 (130)
Too old, most people ignore it and use lots of extensions.
> Single UNIX v3 (1742)
Yikes, that's a bloated pig. Scary stuff.
> > BTW, how many libc functions are in ANSI C89? 32
> > keywords (not counting preprocessor), 15 headers,
> > probably 100 (??) functions, blindly guessing.
>
> I guess I should add ANSI C ...
>
> I started gathering stuff for a C library some years ago. I probably have a
> list somewhere...
>
> Well, I don't seem to have a clean list of ANSI or ISO C functions!
>
> I do have a few lists from the Internet of POSIX functions that categorize
> by specification. From one of the POSIX function lists:
>
> 33 keywords in ANSI C
"main" as a keyword. I'm not sure I'd count that.
> 38 keywords in ISO C (+5)
> 146 ANSI C functions (*)
> 226 C 94 functions (+80) (*)
> 555 ISO C functions (+329) (*)(**)
>
> (*) That's after _attempting_ to weed out keywords, constants, structs, C
> types, defines, and macro's...
> (**) There is overlap of some math functions due to tgmath.h.
> I have haphazardly accumulated alot of other C info...
>
> I have a note in a file that K&R C had 23 keywords and 2 pre-processor
> directives.
years. A few have moved to C99, but overall it's not 100% popular yet
(though getting there!), e.g. MSVC still lacks it. Anyways, I don't
see a lot of K&R stuff still around, but I'm sure some probably still
exists somewhere.
> So, probably 44
> or so for ISO C ... Another list has 12 keywords and procedures which are
> C's flow control words. Another list has 22 pre-processor defines supported
> by GCC, 13 by OpenWatcom (v1.3), and 7 by other compilers. Another file has
> a list which has 55 lines of C operator's and punctuation, 123 lines of
> keywords (with many non-ANSI/ISO), 167 compiler extension words. A hash
> function I use as part of an in-progress C compiler, has 353 hash values for
> C keyword's, operators, pre-processor directives. That included many
> compiler specific variations. So, that's gives an idea of the maximum
> language "words".
> This is the big list of POSIX functions (ANSI and ISO C too) via Wayback
> archive:
>
Yeah, good find, thanks. But POSIX is so unwieldy. :-(
Rod Pemberton
Jun 11, 2012, 8:00:00 PM6/11/12
to
"Rugxulo" <rug...@gmail.com> wrote in message
news:5122a5ce-d38e-40d2...@3g2000vbx.googlegroups.com...
> On Jun 9, 6:49 pm, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
> wrote:
[SNIP]
> wrote:
> > setjmp/longjmp
>
> It's a weird thing, but it is quite common, so I
> would like to one day understand it (unlikely!). ;-)
>
> It's a weird thing, but it is quite common, so I
> would like to one day understand it (unlikely!). ;-)
>
> > They usually work by dumping a bunch of
> > processor registers into a C array.
A block of code { ... } in C or most looping constructs have a single entry
> > processor registers into a C array.
point and exit point. If some code has a single entry point and single exit
point, it's called structured code as in it uses structured programming
concepts. The opposited of structured programming was unstructured code
called "spaghetti code". It used unmatched loop constructs, multiple entry
points, etc. It was the result of using GOTO or jumps. E.g., BASIC used
GOTO, but many also had GOSUB and RETURN. GOTOs can be used in place of
GOSUB and RETURN. However, you could use multiple GOTOs to enter exit the
code block. That'd be unstructured. The problem was people couldn't keep
track of where the jumps went. So, looping constructs, switches,
procedures, etc were designed with the single entry and single exit concept
using syntax to hide the jumps and GOTOs.
Co-routines allow you to "ping-pong" back and forth to different points
within a couple code blocks. It's unstructured code.
A procedure (or function) in various languages are structured too (single
entry point, single exit point). C is partially structured when it comes to
procedures. There is a single entry point. You can only enter a procedure
by calling it. But, C allows multiple exit points, i.e., you can use
return() or exit() numerous times. You can usually code a C procedure to
have a single exit point by using a local variable as a status flag or
return value.
Setjmp saves the register context and longjmp restores it. If used
properly, this allows an entry point *anywhere* and exit points *anywhere*.
If you think of a C procedure which is structured, i.e., it has one entry
point and is only using one exit point, then "split" the procedure so that
the entry point and exit point are located in different places, that's what
setjmp/longjmp allow. I.e., you've "called" a virtual procedure with setjmp
and you've returned from that virtual procedure with longjmp. That's just a
way to think about it.
PUSHA is an x86 that saves all registers to the x86 stack. POPA restores
all registers from the stack. setjmp and longjmp is the C version. It
works a little bit differently. Usually, there is some inline assembly which
saves or restores, perhaps half the processors registers. The other half of
the registers either don't need saving, or can be corrupted, or aren't in
use. C's setjmp saves into an array, i.e., some addressable memory, instead
of to a stack. C's longjmp restores those registers. I know there is
return some value, but I don't recall exactly how that's used.
> Most people seem to have switched to at least ANSI C89 since
> many years.
conflicts with botched typedef syntax). I like the procedure declarations
better but only if I have to parse them with my code... I like the use of
char* as generic pointers and equivalence of small int's with char, but it
is a defect in the type system.
For the most part, I like ANSI C. I like typedef's, but they forgot a usage
keyword for typedef types. Although pointers that don't point to an object
type were missing in C, i.e., an address, I don't like they way they
implemented void* in C. There are some trivial things in ANSI C that I
think were "mis-located" ... I.e., they should've been in a certain include
file but are in a different one, or should've been part of the C language
proper but is in some include file. E.g., exit() should be part of the
language, like return() and malloc() too. Unfortunately, I like ANSI C
because of the way it's implemented on standard microprocessor architecture
(8-bit bytes, contiguous memory, pointer and max integer sizes the same,
two's complement arithmetic). The ANSI C specifications abstract too much
or declare needed functionality as undefined or implementation specific.
So, syntax wise it's good, but semantic wise, it's not so great. Your code
can mean something very different if on a non-standard or old platform.
Fortunately, implementors usually implement C "correctly" where possible.
> A few have moved to C99, but overall it's not 100% popular yet
> (though getting there!), e.g. MSVC still lacks it.
the stuff I'm aware that it adds is wierd. Like, solutions looking for
problems ... That probably means some of it difficult to implement too.
IIRC, there was even some type of nameless objects ... ??? Names are how C
assigns addresses to things. Second, IMO, ANSI C with it's libraries is
"complete" or even "fat" in terms of available functionality. How much more
stuff could've been added that was of serious value? It's clear from the
counts, they added a bunch of stuff. But, how much is _really_ useful? The
most useful stuff was identified early on, IMO. It's nice to code
"uint32_t" but you can do that with a #define in C89/90 too. It won't
officially mean the same thing (semantics). But, it'll compile to the same
thing on modern platforms. I'm sure some programmers find that more
functions for mathematics, graphics, audio, video are useful. But, that's
all specialized programming.
> > [my counts]
>
> Sounds worse than it is.
Yeah, I know I sampled a variety of C compiler documentation found online.
> Sounds worse than it is.
But, I don't know which. I recall seeing platforms I'd never heard of.
I.e., there's some strange stuff in there...
> > Pete Forman's "Portability Guide" [link]
>
> Yeah, good find, thanks. But POSIX is so unwieldy.
I've found others on the Internet. Let me find them amongst my numerous
> Yeah, good find, thanks. But POSIX is so unwieldy.
files and see if I can track down a few. (w/Usenet message-ids)
ISO C Names and corresponding headers
http://www.schweikhardt.net/identifiers.html
C Library functions categorized by headers
http://groups.google.com/group/comp.unix/msg/f03d8a88502ce944
msgid 20...@mcdchg.UUCP
Minimal C headers
http://groups.google.com/group/alt.sources/msg/f0586477d682fc71
msgid 13...@fig.bbn.com
POSIX #include file tester
http://groups.google.com/group/comp.sources.unix/msg/2607a5fbe5bef588
msgid 19...@prune.bbn.com
Public Domain Standard C Libraries (limited)
http://groups.google.com/group/comp.sys.atari.st/msg/950102895c44e63f
http://groups.google.com/group/comp.sys.atari.st/msg/627097b65386f75d
msgid 1...@stag.UUCP
msgid 1...@stag.UUCP
Rod Pemberton
rug...@gmail.com
Jun 12, 2012, 12:00:31 PM6/12/12
to
Hi,
On Monday, June 11, 2012 7:00:00 PM UTC-5, Rod Pemberton wrote:
> "Rugxulo" <rug...@gmail.com> wrote in message
> news:5122a5ce-d38e-40d2...@3g2000vbx.googlegroups.com...
> > On Jun 9, 6:49 pm, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
> > wrote:
>
> > > setjmp/longjmp
> >
> > It's a weird thing, but it is quite common, so I
> > would like to one day understand it (unlikely!). ;-)
> >
> > > They usually work by dumping a bunch of
> > > processor registers into a C array.
>
> A block of code { ... } in C or most looping constructs have a single entry
> point and exit point. If some code has a single entry point and single exit
> point, it's called structured code as in it uses structured programming
> concepts. The opposited of structured programming was unstructured code
> called "spaghetti code".
But I don't think C is "pure" structured anyways due to various things (break, continue), including this. Anyways, I'm also not sure I'd consider C as "bad" as original BASIC (line numbers and goto with no proper structured looping), which is usually the scapegoat for all things unstructured.
BTW, in contrast to "classic" (Wirth, ISO) Pascal goto, C is local only, hence the need for setjmp/longjmp. Though of course in Pascal you're only allowed to jump out, not into a context. (And Modula-2/Oberon don't have goto at all.)
> It used unmatched loop constructs, multiple entry
> points, etc. It was the result of using GOTO or jumps. E.g., BASIC used
> GOTO, but many also had GOSUB and RETURN. GOTOs can be used in place of
> GOSUB and RETURN. However, you could use multiple GOTOs to enter exit the
> code block. That'd be unstructured.
Well, raw assembly is kinda unstructured, but you don't really have a choice. We do have LOOP, but all the jumps are basically GOTOs. (I know you know this, just saying ....)
> The problem was people couldn't keep
> track of where the jumps went. So, looping constructs, switches,
> procedures, etc were designed with the single entry and single exit concept
> using syntax to hide the jumps and GOTOs.
From what I've seen, most people don't try to be too strict about it. So a lot of C and asm code doesn't care too much if there are multiple exits, jumps/gotos, etc.
> Co-routines allow you to "ping-pong" back and forth to different points
> within a couple code blocks. It's unstructured code.
Honestly, I don't know, as I'm no expert. I get the impression that coroutines are almost a primitive form of multi-threading, meant to pause execution and switch to another function mid-execution (and back again, etc). Not sure what that is ultra useful for, pipes??
I assume you've read Simon Tatham's article about coroutines in C. I remember it was ultra confusing to me (and still is!):
http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
> A procedure (or function) in various languages are structured too (single
> entry point, single exit point). C is partially structured when it comes to
> procedures. There is a single entry point. You can only enter a procedure
> by calling it. But, C allows multiple exit points, i.e., you can use
> return() or exit() numerous times.
Yes, and people routinely do it. I try to avoid it but am not 100% strict. In pure assembly, it's a bit odd to have multiple "ret"s in one proc, but it's also odd to constantly "jmp .ret" just to keep at one exit. (At one point, I wrote a .BAT / sed script that would convert all those latter into former to save a few bytes, heh. Silly and useless but still funny to me.)
> You can usually code a C procedure to
> have a single exit point by using a local variable as a status flag or
> return value.
Right, but most people don't.
> Setjmp saves the register context and longjmp restores it. If used
> properly, this allows an entry point *anywhere* and exit points *anywhere*.
> If you think of a C procedure which is structured, i.e., it has one entry
> point and is only using one exit point, then "split" the procedure so that
> the entry point and exit point are located in different places, that's what
> setjmp/longjmp allow.
It's still confusing, though, mainly because I don't understand the very very low-level details (or don't have them memorized, at least). And don't have any real-world examples, at least nothing easy to understand (stupid complicated algorithms, heh).
> I.e., you've "called" a virtual procedure with setjmp
> and you've returned from that virtual procedure with longjmp. That's just a
> way to think about it.
>
> PUSHA is an x86 that saves all registers to the x86 stack. POPA restores
> all registers from the stack. setjmp and longjmp is the C version. It
> works a little bit differently. Usually, there is some inline assembly which
> saves or restores, perhaps half the processors registers. The other half of
> the registers either don't need saving, or can be corrupted, or aren't in
> use. C's setjmp saves into an array, i.e., some addressable memory, instead
> of to a stack. C's longjmp restores those registers. I know there is
> return some value, but I don't recall exactly how that's used.
Well, I get that part, it's just the real-world part that is a bit odd to me.
> > Most people seem to have switched to at least ANSI C89 since
> > many years.
>
> I like typedef's, but they forgot a usage
> keyword for typedef types. Although pointers that don't point to an object
> type were missing in C, i.e., an address, I don't like they way they
> implemented void* in C. There are some trivial things in ANSI C that I
> think were "mis-located" ... I.e., they should've been in a certain include
> file but are in a different one, or should've been part of the C language
> proper but is in some include file.
I can't help but think (and don't get me wrong, I'm not saying any language is perfect or better) that Modula-2/Oberon did a bit better in these regards (no need for symbol table, types, module namespaces).
Also, and I hate to say it (as compatibility is important to me), but the whole six-letter-identifier-linker-limit for C89 is annoying. It made all the function names really goofy and weird, so it looks bad (or at least hard to remember). I guess a few custom #defines could "fix" that if I really cared. (The irony is that none of the compilers I tested ever had such a limit, and only two even had the identifier limit of 32.) I'm not even sure of a proper way to test to make sure identifiers are unique in first six chars. I guess things like that only truly matter if you can test on such a limited platform anyways. Still ....
> E.g., exit() should be part of the
> language, like return() and malloc() too.
Dunno, wouldn't it be a bit more like Pascal with built-in I/O? People always hated that. Doesn't matter much to me, but I guess it could?? complicated cross-compiling a tiny bit.
> Unfortunately, I like ANSI C
> because of the way it's implemented on standard microprocessor architecture
> (8-bit bytes, contiguous memory, pointer and max integer sizes the same,
Well, intptr_t and intmax_t aren't always the same, as you know. Gotta love tons of types! Anyways, doesn't matter, as you say, all the world's a VAX (or, really, Linux) these days.
> two's complement arithmetic). The ANSI C specifications abstract too much
> or declare needed functionality as undefined or implementation specific.
They (wisely) tried to be compatible to a billion computer architectures. I think that was a good thing, but indeed things have become more limited these days.
> So, syntax wise it's good, but semantic wise, it's not so great.
It's merely average, as nobody has gotten it perfect, by far. Some flaws, some odd cases, but it mostly works well, sorta. ;-)
> Your code
> can mean something very different if on a non-standard or old platform.
> Fortunately, implementors usually implement C "correctly" where possible.
I'm surprised too, esp. since I don't know of any popular C test suite. Ada has ACATS, but AFAIK, C never had one. I think the C Rationale gave up on the idea for time and licensing reasons. I mean, I'm sure some ad hoc versions (or maybe professional) exist, but I'm (naively) not aware of any popular test suite for C compilers. Maybe GCC has one (probably), never bothered to check.
So yeah, lucky that C compilers usually "just work".
> > A few have moved to C99, but overall it's not 100% popular yet
> > (though getting there!), e.g. MSVC still lacks it.
>
> I don't think it'll ever be that "popular" per se for a few reasons. First,
> the stuff I'm aware that it adds is wierd. Like, solutions looking for
> problems ... That probably means some of it difficult to implement too.
I agree, esp. all the math stuff (e.g. complex). I don't know why that has to be in the main language. Optional, yes, but mandatory? Not so much.
> IIRC, there was even some type of nameless objects ... ??? Names are how C
> assigns addresses to things. Second, IMO, ANSI C with it's libraries is
> "complete" or even "fat" in terms of available functionality. How much more
> stuff could've been added that was of serious value?
Dunno. It's true that some of it is a bit redundant, but I guess their idea is "don't use it if you don't need or want it". Better to have and not need than otherwise.
Still, I can't help but lament the fact that POSIX adds so much arcane junk, and people mostly seem to prefer the most obscure POSIX function instead of rolling their own (or making it optional). That always bugs me (which is probably more my fault than theirs). I realize POSIX was needed, hence unavoidable, but sometimes it's just overkill and confusing.
> It's clear from the
> counts, they added a bunch of stuff. But, how much is _really_ useful? The
> most useful stuff was identified early on, IMO. It's nice to code
> "uint32_t" but you can do that with a #define in C89/90 too. It won't
> officially mean the same thing (semantics). But, it'll compile to the same
> thing on modern platforms.
Standards seem to almost always overcomplicate everything. Sometimes it's necessary, but when it makes even simple things hard, it's not so wonderful. So yeah, things like int_least_t and int_fast_t and whatever seem to be unnecessary, but hey, I guess somebody thought it was a good idea.
> I'm sure some programmers find that more
> functions for mathematics, graphics, audio, video are useful. But, that's
> all specialized programming.
That's the thing, I wonder how some stuff ever gets standardized since nobody targets the same subject anyways. Esp. all the high-level math computation junk, which average programs don't need, I wonder how all that gets forced in when it's (seemingly) such heavy ballast.
> > > [my counts]
> >
> > Sounds worse than it is.
>
> Yeah, I know I sampled a variety of C compiler documentation found online.
> But, I don't know which. I recall seeing platforms I'd never heard of.
> I.e., there's some strange stuff in there...
Well, 1989 was far different landscape compared to 1999 or 2009. A lot of companies disappeared or were bought out since then. A lot of architectures have (effectively) died, too. You still see lots of Linux or FreeBSD ports to weird architectures, but these days it's only seemingly "x86 and x64" as top tier (probably just cheaper and easier to find). I don't mind that so much, but ignoring portability out of laziness seems to be counterproductive to me. That's something I wouldn't personally want to do (intentionally). So, in that regard, C is almost perfect (in potential, though a bit hard to realize).
> > > Pete Forman's "Portability Guide" [link]
> >
> > Yeah, good find, thanks. But POSIX is so unwieldy.
>
> I've found others on the Internet. Let me find them amongst my numerous
> files and see if I can track down a few. (w/Usenet message-ids)
All good links, thanks. My own interest was trying to learn "backwards" what "pure ANSI C" was, esp. since everyone uses so many extensions these days. You never hardly see a C compiler anymore with "only" ANSI headers, for instance. There are dozens more, which is always confusing (esp. since they never agree on what they have and often obsolete even themselves). Kinda annoying and frustrating. It's actually almost sad and funny how Linux ("portable") tends to be messier than DOS (which only has one architecture: x86). If I wanted to be unportable, I could do that in DOS asm, I don't need Linux C doing it too. ;-)
On Monday, June 11, 2012 7:00:00 PM UTC-5, Rod Pemberton wrote:
> "Rugxulo" <rug...@gmail.com> wrote in message
> news:5122a5ce-d38e-40d2...@3g2000vbx.googlegroups.com...
> > On Jun 9, 6:49 pm, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
> > wrote:
>
> > > setjmp/longjmp
> >
> > It's a weird thing, but it is quite common, so I
> > would like to one day understand it (unlikely!). ;-)
> >
> > > They usually work by dumping a bunch of
> > > processor registers into a C array.
>
> A block of code { ... } in C or most looping constructs have a single entry
> point and exit point. If some code has a single entry point and single exit
> point, it's called structured code as in it uses structured programming
> concepts. The opposited of structured programming was unstructured code
> called "spaghetti code".
BTW, in contrast to "classic" (Wirth, ISO) Pascal goto, C is local only, hence the need for setjmp/longjmp. Though of course in Pascal you're only allowed to jump out, not into a context. (And Modula-2/Oberon don't have goto at all.)
> It used unmatched loop constructs, multiple entry
> points, etc. It was the result of using GOTO or jumps. E.g., BASIC used
> GOTO, but many also had GOSUB and RETURN. GOTOs can be used in place of
> GOSUB and RETURN. However, you could use multiple GOTOs to enter exit the
> code block. That'd be unstructured.
> The problem was people couldn't keep
> track of where the jumps went. So, looping constructs, switches,
> procedures, etc were designed with the single entry and single exit concept
> using syntax to hide the jumps and GOTOs.
> Co-routines allow you to "ping-pong" back and forth to different points
> within a couple code blocks. It's unstructured code.
I assume you've read Simon Tatham's article about coroutines in C. I remember it was ultra confusing to me (and still is!):
http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
> A procedure (or function) in various languages are structured too (single
> entry point, single exit point). C is partially structured when it comes to
> procedures. There is a single entry point. You can only enter a procedure
> by calling it. But, C allows multiple exit points, i.e., you can use
> return() or exit() numerous times.
> You can usually code a C procedure to
> have a single exit point by using a local variable as a status flag or
> return value.
> Setjmp saves the register context and longjmp restores it. If used
> properly, this allows an entry point *anywhere* and exit points *anywhere*.
> If you think of a C procedure which is structured, i.e., it has one entry
> point and is only using one exit point, then "split" the procedure so that
> the entry point and exit point are located in different places, that's what
> setjmp/longjmp allow.
> I.e., you've "called" a virtual procedure with setjmp
> and you've returned from that virtual procedure with longjmp. That's just a
> way to think about it.
>
> PUSHA is an x86 that saves all registers to the x86 stack. POPA restores
> all registers from the stack. setjmp and longjmp is the C version. It
> works a little bit differently. Usually, there is some inline assembly which
> saves or restores, perhaps half the processors registers. The other half of
> the registers either don't need saving, or can be corrupted, or aren't in
> use. C's setjmp saves into an array, i.e., some addressable memory, instead
> of to a stack. C's longjmp restores those registers. I know there is
> return some value, but I don't recall exactly how that's used.
> > Most people seem to have switched to at least ANSI C89 since
> > many years.
>
> For the most part, I like ANSI C.
Ditto, though you like it a bit more than I do. But it's far from worst ever (though it does have a lot of confusing corner cases and code tends to be easily obfuscated or similarly hard to read).
> I like typedef's, but they forgot a usage
> keyword for typedef types. Although pointers that don't point to an object
> type were missing in C, i.e., an address, I don't like they way they
> implemented void* in C. There are some trivial things in ANSI C that I
> think were "mis-located" ... I.e., they should've been in a certain include
> file but are in a different one, or should've been part of the C language
> proper but is in some include file.
Also, and I hate to say it (as compatibility is important to me), but the whole six-letter-identifier-linker-limit for C89 is annoying. It made all the function names really goofy and weird, so it looks bad (or at least hard to remember). I guess a few custom #defines could "fix" that if I really cared. (The irony is that none of the compilers I tested ever had such a limit, and only two even had the identifier limit of 32.) I'm not even sure of a proper way to test to make sure identifiers are unique in first six chars. I guess things like that only truly matter if you can test on such a limited platform anyways. Still ....
> E.g., exit() should be part of the
> language, like return() and malloc() too.
> Unfortunately, I like ANSI C
> because of the way it's implemented on standard microprocessor architecture
> (8-bit bytes, contiguous memory, pointer and max integer sizes the same,
> two's complement arithmetic). The ANSI C specifications abstract too much
> or declare needed functionality as undefined or implementation specific.
> So, syntax wise it's good, but semantic wise, it's not so great.
> Your code
> can mean something very different if on a non-standard or old platform.
> Fortunately, implementors usually implement C "correctly" where possible.
So yeah, lucky that C compilers usually "just work".
> > A few have moved to C99, but overall it's not 100% popular yet
> > (though getting there!), e.g. MSVC still lacks it.
>
> I don't think it'll ever be that "popular" per se for a few reasons. First,
> the stuff I'm aware that it adds is wierd. Like, solutions looking for
> problems ... That probably means some of it difficult to implement too.
> IIRC, there was even some type of nameless objects ... ??? Names are how C
> assigns addresses to things. Second, IMO, ANSI C with it's libraries is
> "complete" or even "fat" in terms of available functionality. How much more
> stuff could've been added that was of serious value?
Still, I can't help but lament the fact that POSIX adds so much arcane junk, and people mostly seem to prefer the most obscure POSIX function instead of rolling their own (or making it optional). That always bugs me (which is probably more my fault than theirs). I realize POSIX was needed, hence unavoidable, but sometimes it's just overkill and confusing.
> It's clear from the
> counts, they added a bunch of stuff. But, how much is _really_ useful? The
> most useful stuff was identified early on, IMO. It's nice to code
> "uint32_t" but you can do that with a #define in C89/90 too. It won't
> officially mean the same thing (semantics). But, it'll compile to the same
> thing on modern platforms.
> I'm sure some programmers find that more
> functions for mathematics, graphics, audio, video are useful. But, that's
> all specialized programming.
> > > [my counts]
> >
> > Sounds worse than it is.
>
> Yeah, I know I sampled a variety of C compiler documentation found online.
> But, I don't know which. I recall seeing platforms I'd never heard of.
> I.e., there's some strange stuff in there...
> > > Pete Forman's "Portability Guide" [link]
> >
> > Yeah, good find, thanks. But POSIX is so unwieldy.
>
> I've found others on the Internet. Let me find them amongst my numerous
> files and see if I can track down a few. (w/Usenet message-ids)
Rod Pemberton
Jun 12, 2012, 11:28:55 PM6/12/12
to
<rug...@gmail.com> wrote in message
news:f3c6c6f1-645b-4977...@googlegroups.com...
> > Co-routines allow you to "ping-pong" back and forth to
> > different points within a couple code blocks. It's unstructured code.
>
> Honestly, I don't know, as I'm no expert. I get the impression that
> coroutines are almost a primitive form of multi- threading, meant
implemented in C. C is a language which doesn't formally have coroutines.
So, they are implemented in C using unstructured code, i.e., "artificially
created" multiple entry points, which C doesn't officially have...
Coroutines probably use the same or similar method in other languages, but
at the assembly level.
> Not sure what that is ultra useful for, pipes??
Well, I'm not too familiar either.
With minimal exposure and from what I've read, perhaps pipes, merging of
code, yielding, co-routines, ... But, please don't quote me.
I used a yielding mechanism once in a "mainframe" like environment. It was
used with networking code. You could "ping-pong" back and forth between
different code blocks. I don't know if I'd call that "threading" per se.
It was all a single program. I don't know if that qualifies as being
coroutines either.
Back then, my manager sent me to two classes so he could justify a raise.
Both were _way_ beneath my skill level. It was truly painful to experience
psychologically, i.e., bored to death, forced to maintain focus, not
learning anything, and required to perform well or risk losing the raise...
But, I took it seriously, and performed well. The yielding mechanism was
the only thing that was new to me. So, I had maybe five or six minutes of
exposure to it ... ? Unfortunately, there was zero use of it in my job. I
could've seen it being used there, since they ran numerous processes,
including a few networking processes.
> I assume you've read Simon Tatham's article about coroutines in
> C. I remember it was ultra confusing to me (and still is!):
Yes, a few times, some years back...
> In pure assembly, it's a bit odd to have multiple "ret"s in one proc,
> but it's also odd to constantly "jmp .ret" just to keep at one exit.
I've not noticed anyone use structured programming for assembly. However,
I've not noticed much use for multiple exits either ... I.e., my assembly,
from recollection, is mostly structured, either by happenstance or
instruction design.
> (though [ANSI C] does have a lot of confusing corner cases
understands it. People use a subset of what is legal C code to have
"readable" and "maintainable" and "understandable" code. That's why IOCCC
exists. Style guides and MISRA C etc have developed to keep people from
programming those "corner cases" since they lead to problems. Personally, I
do so too. Early on, I learned that floating point in C was problematic,
and that programming using unsigned integers was very effective in C.
I use structured code. I prefer unsigned types. I never use floating
point, if I can implement it using integers. In some cases, you need
floating point. But, they are exceptionally rare, unless you're plotting or
graphing equations. I use typedef's and avoid structs which allocate space,
unless I only need a single struct and I won't be changing the struct data
frequently. I avoid malloc(), if I can allocate the data in a declaration,
sometimes you can't. I don't have a problem casting, if needed or if it
allows me to use unsigned types. I avoid "int", although I did like
implicit int's... You can never be sure what size you're going to get with
"int". I don't use sizeof() - unless there is *absolutely* no other way.
It's very, very rare that it's actually needed. I avoid "void", but do use
it for declarations of "void xxx(void)", since some compilers eliminate much
of the function overhead with that form. I don't like "void *" either.
They botched it's implementation. I use pointers. They make programming
more effective. I avoid use of unions, since some C compilers botched it.
I avoid integers that don't specify a size, e.g., "signed" or "unsigned"
without "long" or "short". Sometimes, you end up with an "int"... In
general, I don't use "auto" or "static" or "const" or "restrict" keywords,
although everything is "auto" by default. "volatile" is the only qualifier
required every now and then. I don't use xxxx_t types in the C libraries,
including size_t and ptrdiff_t, except I do sometimes use the new uintXX_t.
(Yeah, don't mention that on comp.lang.c. They'll go nuts. I predict
suicides...)
So, if I had a grammar editor, and removed all the stuff from the C language
I don't use, it'd be a much smaller and simpler language.
> Also, and I hate to say it (as compatibility is important to me), but
> the whole six-letter-identifier-linker-limit for C89 is annoying.
???
> Well, intptr_t and intmax_t aren't always the same, as you know.
No, I don't. I don't use xxx_t types except in rare situations. There is
no need for them.
> > The ANSI C specifications abstract too much or declare needed
> > functionality as undefined or implementation specific.
>
> They (wisely) tried to be compatible to a billion computer architectures.
> I think that was a good thing, but indeed things have become more limited
> these days.
The problem, AISI, was that there were two groups of computers for which
they were attempting to make C work: standardized architectures like I
mentioned (snipped), and an eclectic variety of mainframes which weren't
standardized. That second group is now obsolete, or "dead", but their
effect on C remains. Their effect, IMO, was bad. They caused much of the
language to become "undefined" or "illegal behavior" of "implementation
defined" for compatibility or portability. If C had been standardized just
half a decade later, we'd have a very different and more useful and powerful
language. It wouldn't be as portable...
> I'm surprised too, esp. since I don't know of any popular C test suite.
> Ada has ACATS, but AFAIK, C never had one.
> [... ] but I'm (naively) not aware of any popular test suite for C
> compilers.
I think the defacto test suite for commercial C compilers is the Plum Hall
Validation Suite. Dinkumware Quick Proofer is another. I think both may be
by P.J. Plauger, author of "The Standard C Library".
The US government has it's own C compliance test suite by NIST (National
Institute of Standards and Technology) and their own C standards too (FIPS
151). There is a NIST testsuite for PCTS (Posix Conformance Test Suite
and/or FIPS 160).
Popular ... ?
The most well known free one is either enquire.c or maybe paranoia.c.
I've got a collection of free C test files from various sources, 2MB, and 33
directories. Some are from larger packages, e.g., GCC tests or LSB (Linux
standard base) or CIL (Necula, not MS) or Astr�e. Some are small test
programs for just one thing, e.g., malloc(). Others are test programs or
benchmarks in their own right, e.g.,:
cfeatures
ctorture
enquire
paranoia
hdrchk
heirloom
ieee754
posixtestsuite
Tydeman FPCE
Stanford benchmarks
Plum Hall benchmark
STL test
Test ANSI
There are also various testsuites for MISRA, POSIX, NIST PCTS/FIPS...
> I think the C Rationale gave up on the idea for time and licensing
> reasons.
I'd have to refresh on what's in there.
> Maybe GCC has one (probably), never bothered to check.
Yes, GCC has it's own test suite.
Rod Pemberton
news:f3c6c6f1-645b-4977...@googlegroups.com...
> On Monday, June 11, 2012 7:00:00 PM UTC-5, Rod Pemberton wrote:
...
> > Co-routines allow you to "ping-pong" back and forth to
> > different points within a couple code blocks. It's unstructured code.
>
> Honestly, I don't know, as I'm no expert. I get the impression that
> to pause execution and switch to another function mid-execution
> (and back again, etc).
Ok, you're talking about formal coroutines. I was referring to how they're
> (and back again, etc).
implemented in C. C is a language which doesn't formally have coroutines.
So, they are implemented in C using unstructured code, i.e., "artificially
created" multiple entry points, which C doesn't officially have...
Coroutines probably use the same or similar method in other languages, but
at the assembly level.
> Not sure what that is ultra useful for, pipes??
With minimal exposure and from what I've read, perhaps pipes, merging of
code, yielding, co-routines, ... But, please don't quote me.
I used a yielding mechanism once in a "mainframe" like environment. It was
used with networking code. You could "ping-pong" back and forth between
different code blocks. I don't know if I'd call that "threading" per se.
It was all a single program. I don't know if that qualifies as being
coroutines either.
Back then, my manager sent me to two classes so he could justify a raise.
Both were _way_ beneath my skill level. It was truly painful to experience
psychologically, i.e., bored to death, forced to maintain focus, not
learning anything, and required to perform well or risk losing the raise...
But, I took it seriously, and performed well. The yielding mechanism was
the only thing that was new to me. So, I had maybe five or six minutes of
exposure to it ... ? Unfortunately, there was zero use of it in my job. I
could've seen it being used there, since they ran numerous processes,
including a few networking processes.
> I assume you've read Simon Tatham's article about coroutines in
> C. I remember it was ultra confusing to me (and still is!):
> In pure assembly, it's a bit odd to have multiple "ret"s in one proc,
> but it's also odd to constantly "jmp .ret" just to keep at one exit.
I've not noticed much use for multiple exits either ... I.e., my assembly,
from recollection, is mostly structured, either by happenstance or
instruction design.
> (though [ANSI C] does have a lot of confusing corner cases
> and code tends to be easily obfuscated or similarly hard to read).
C, as people understand it, is different from what C is as the compiler
understands it. People use a subset of what is legal C code to have
"readable" and "maintainable" and "understandable" code. That's why IOCCC
exists. Style guides and MISRA C etc have developed to keep people from
programming those "corner cases" since they lead to problems. Personally, I
do so too. Early on, I learned that floating point in C was problematic,
and that programming using unsigned integers was very effective in C.
I use structured code. I prefer unsigned types. I never use floating
point, if I can implement it using integers. In some cases, you need
floating point. But, they are exceptionally rare, unless you're plotting or
graphing equations. I use typedef's and avoid structs which allocate space,
unless I only need a single struct and I won't be changing the struct data
frequently. I avoid malloc(), if I can allocate the data in a declaration,
sometimes you can't. I don't have a problem casting, if needed or if it
allows me to use unsigned types. I avoid "int", although I did like
implicit int's... You can never be sure what size you're going to get with
"int". I don't use sizeof() - unless there is *absolutely* no other way.
It's very, very rare that it's actually needed. I avoid "void", but do use
it for declarations of "void xxx(void)", since some compilers eliminate much
of the function overhead with that form. I don't like "void *" either.
They botched it's implementation. I use pointers. They make programming
more effective. I avoid use of unions, since some C compilers botched it.
I avoid integers that don't specify a size, e.g., "signed" or "unsigned"
without "long" or "short". Sometimes, you end up with an "int"... In
general, I don't use "auto" or "static" or "const" or "restrict" keywords,
although everything is "auto" by default. "volatile" is the only qualifier
required every now and then. I don't use xxxx_t types in the C libraries,
including size_t and ptrdiff_t, except I do sometimes use the new uintXX_t.
(Yeah, don't mention that on comp.lang.c. They'll go nuts. I predict
suicides...)
So, if I had a grammar editor, and removed all the stuff from the C language
I don't use, it'd be a much smaller and simpler language.
> Also, and I hate to say it (as compatibility is important to me), but
> the whole six-letter-identifier-linker-limit for C89 is annoying.
> Well, intptr_t and intmax_t aren't always the same, as you know.
no need for them.
> > The ANSI C specifications abstract too much or declare needed
> > functionality as undefined or implementation specific.
>
> They (wisely) tried to be compatible to a billion computer architectures.
> I think that was a good thing, but indeed things have become more limited
> these days.
they were attempting to make C work: standardized architectures like I
mentioned (snipped), and an eclectic variety of mainframes which weren't
standardized. That second group is now obsolete, or "dead", but their
effect on C remains. Their effect, IMO, was bad. They caused much of the
language to become "undefined" or "illegal behavior" of "implementation
defined" for compatibility or portability. If C had been standardized just
half a decade later, we'd have a very different and more useful and powerful
language. It wouldn't be as portable...
> I'm surprised too, esp. since I don't know of any popular C test suite.
> Ada has ACATS, but AFAIK, C never had one.
> compilers.
I think the defacto test suite for commercial C compilers is the Plum Hall
Validation Suite. Dinkumware Quick Proofer is another. I think both may be
by P.J. Plauger, author of "The Standard C Library".
The US government has it's own C compliance test suite by NIST (National
Institute of Standards and Technology) and their own C standards too (FIPS
151). There is a NIST testsuite for PCTS (Posix Conformance Test Suite
and/or FIPS 160).
Popular ... ?
The most well known free one is either enquire.c or maybe paranoia.c.
I've got a collection of free C test files from various sources, 2MB, and 33
directories. Some are from larger packages, e.g., GCC tests or LSB (Linux
standard base) or CIL (Necula, not MS) or Astr�e. Some are small test
programs for just one thing, e.g., malloc(). Others are test programs or
benchmarks in their own right, e.g.,:
cfeatures
ctorture
enquire
paranoia
hdrchk
heirloom
ieee754
posixtestsuite
Tydeman FPCE
Stanford benchmarks
Plum Hall benchmark
STL test
Test ANSI
There are also various testsuites for MISRA, POSIX, NIST PCTS/FIPS...
> I think the C Rationale gave up on the idea for time and licensing
> reasons.
> Maybe GCC has one (probably), never bothered to check.
Rod Pemberton
0 new messages