Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #16632 > unrolled thread
| Started by | visualforth@rocketmail.com |
|---|---|
| First post | 2012-10-23 16:09 -0700 |
| Last post | 2012-10-25 10:17 -0400 |
| Articles | 20 on this page of 74 — 16 participants |
Back to article view | Back to comp.lang.forth
I Don’t Make Mistakes. I Use C visualforth@rocketmail.com - 2012-10-23 16:09 -0700
Re: I Don’t Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-23 16:43 -0700
Re: I Don’t Make Mistakes. I Use C jacko <jackokring@gmail.com> - 2012-10-23 16:50 -0700
Re: I Don’t Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-23 18:58 -0700
Re: I Don’t Make Mistakes. I Use C jacko <jackokring@gmail.com> - 2012-10-24 15:12 -0700
Re: I Don’t Make Mistakes. I Use C "Elizabeth D. Rather" <erather@forth.com> - 2012-10-23 14:02 -1000
Re: I Don’t Make Mistakes. I Use C Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-24 02:51 +0200
Re: I Don’t Make Mistakes. I Use C Mark Wills <forthfreak@gmail.com> - 2012-10-24 04:23 -0700
Re: I Don’t Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-23 19:20 -0700
Re: I Don?t Make Mistakes. I Use C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-24 05:04 -0500
Re: I Don?t Make Mistakes. I Use C "Elizabeth D. Rather" <erather@forth.com> - 2012-10-24 08:04 -1000
Re: I Don?t Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-24 13:11 -0700
Re: I Don?t Make Mistakes. I Use C Pavel Klinkovsky <pavel.klinkovsky@gmail.com> - 2012-10-24 13:21 -0700
Re: I Don?t Make Mistakes. I Use C Fritz Wuehler <fritz@spamexpire-201210.rodent.frell.theremailer.net> - 2012-10-25 20:00 +0200
Re: I Don?t Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-25 11:30 -0700
Re: I Don?t Make Mistakes. I Use C Anonymous <nobody@remailer.paranoici.org> - 2012-10-26 09:00 +0000
Re: I Don?t Make Mistakes. I Use C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-26 05:01 -0500
Re: I Don?t Make Mistakes. I Use C Brad Eckert <hwfwguy@gmail.com> - 2012-10-26 08:46 -0700
Re: I Don?t Make Mistakes. I Use C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-25 23:05 -0500
Re: I Don?t Make Mistakes. I Use C Anonymous <nobody@remailer.paranoici.org> - 2012-10-28 15:35 +0000
Re: I Don?t Make Mistakes. I Use C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-28 12:06 -0500
Re: I Don?t Make Mistakes. I Use C Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-28 21:38 +0100
Re: I Don?t Make Mistakes. I Use C jacko <jackokring@gmail.com> - 2012-10-28 16:34 -0700
Re: I Don?t Make Mistakes. I Use C Anonymous <nobody@remailer.paranoici.org> - 2012-10-29 10:56 +0000
Re: I Don?t Make Mistakes. I Use C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-29 06:11 -0500
Re: I Don?t Make Mistakes. I Use C rickman <gnuarm@gmail.com> - 2012-10-29 13:51 -0400
Re: I Don?t Make Mistakes. I Use C Anonymous <nobody@remailer.paranoici.org> - 2012-10-29 20:45 +0000
Re: I Don?t Make Mistakes. I Use C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-30 04:20 -0500
Re: I Don?t Make Mistakes. I Use C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-30 04:16 -0500
Re: I Don’t Make Mistakes. I Use C rickman <gnuarm@gmail.com> - 2012-10-25 10:04 -0400
Re: I Don’t Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-25 14:16 -0700
Re: I Don’t Make Mistakes. I Use C "Elizabeth D. Rather" <erather@forth.com> - 2012-10-25 15:51 -1000
Re: I Don’t Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-25 20:14 -0700
Re: I Don?t Make Mistakes. I Use C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-25 23:11 -0500
Re: I Don?t Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-25 21:53 -0700
Re: I Don?t Make Mistakes. I Use C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-26 01:27 -0500
Re: I Don?t Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-26 07:06 -0700
Re: I Don?t Make Mistakes. I Use C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-26 11:34 -0500
Re: I Don?t Make Mistakes. I Use C Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-26 19:13 +0200
Re: I Don?t Make Mistakes. I Use C Alex McDonald <blog@rivadpm.com> - 2012-10-27 04:49 -0700
Re: I Don?t Make Mistakes. I Use C "Elizabeth D. Rather" <erather@forth.com> - 2012-10-25 21:20 -1000
Re: I Don’t Make Mistakes. I Use C "Elizabeth D. Rather" <erather@forth.com> - 2012-10-25 21:23 -1000
Re: I Don’t Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-26 00:53 -0700
Re: I Don’t Make Mistakes. I Use C "Stanley Daniel de Liver" <notagoodone@invalid.org.invalid> - 2012-11-21 16:21 +0000
Re: I Don't Make Mistakes. I Use C "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-24 06:55 -0400
Re: I Don't Make Mistakes. I Use C "Elizabeth D. Rather" <erather@forth.com> - 2012-10-24 08:17 -1000
Re: I Don't Make Mistakes. I Use C "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-25 00:23 -0400
Re: I Don't Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-24 22:18 -0700
Re: I Don't Make Mistakes. I Use C "Elizabeth D. Rather" <erather@forth.com> - 2012-10-24 21:47 -1000
Re: I Don't Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-25 11:21 -0700
Re: I Don't Make Mistakes. I Use C "Elizabeth D. Rather" <erather@forth.com> - 2012-10-25 08:43 -1000
Re: I Don't Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-25 12:18 -0700
Re: I Don't Make Mistakes. I Use C "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-26 19:55 -0400
Re: I Don't Make Mistakes. I Use C "Elizabeth D. Rather" <erather@forth.com> - 2012-10-26 17:38 -1000
Re: I Don't Make Mistakes. I Use C Brad Eckert <hwfwguy@gmail.com> - 2012-10-26 09:07 -0700
Re: I Don't Make Mistakes. I Use C "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-26 19:56 -0400
Re: I Don't Make Mistakes. I Use C "Elizabeth D. Rather" <erather@forth.com> - 2012-10-26 17:47 -1000
Re: I Don't Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-26 22:04 -0700
Re: I Don't Make Mistakes. I Use C visualforth@rocketmail.com - 2012-10-27 07:27 -0700
Re: I Don't Make Mistakes. I Use C Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-27 19:14 +0200
Re: I Don't Make Mistakes. I Use C Brad Eckert <hwfwguy@gmail.com> - 2012-10-24 11:48 -0700
Re: I Don't Make Mistakes. I Use C rickman <gnuarm@gmail.com> - 2012-10-25 19:14 -0400
Re: I Don’t Make Mistakes. I Use C Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-24 10:41 -0700
Re: I Don’t Make Mistakes. I Use C Pavel Klinkovsky <pavel.klinkovsky@gmail.com> - 2012-10-24 13:10 -0700
Re: I Don’t Make Mistakes. I Use C "Elizabeth D. Rather" <erather@forth.com> - 2012-10-24 14:00 -1000
Re: I Don’t Make Mistakes. I Use C Pavel Klinkovsky <pavel.klinkovsky@gmail.com> - 2012-10-24 23:54 -0700
Re: I Don't Make Mistakes. I Use C "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-25 00:29 -0400
Re: I Don't Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-24 22:25 -0700
Re: I Don't Make Mistakes. I Use C Pavel Klinkovsky <pavel.klinkovsky@gmail.com> - 2012-10-24 23:57 -0700
Re: I Don't Make Mistakes. I Use C Pavel Klinkovsky <pavel.klinkovsky@gmail.com> - 2012-10-25 00:11 -0700
Re: I Don’t Make Mistakes. I Use C visualforth@rocketmail.com - 2012-10-24 16:14 -0700
Re: I Don’t Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-24 17:16 -0700
Re: I Don’t Make Mistakes. I Use C visualforth@rocketmail.com - 2012-10-24 17:47 -0700
Re: I Don’t Make Mistakes. I Use C rickman <gnuarm@gmail.com> - 2012-10-25 10:17 -0400
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-10-28 12:06 -0500 |
| Subject | Re: I Don?t Make Mistakes. I Use C |
| Message-ID | <0-idncfvF4W2-xDNnZ2dnUVZ8kmdnZ2d@supernews.com> |
| In reply to | #16807 |
Anonymous <nobody@remailer.paranoici.org> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > >> Fritz Wuehler <fritz@spamexpire-201210.rodent.frell.theremailer.net> wrote: >> > Paul Rubin <no.email@nospam.invalid> wrote: >> > >> > And, Ada is much better than almost any system at separate compilation and >> > making sure things like arguments are consistent and correct across the >> > whole application. >> > >> >> That leaves the expense of the development environments, which apparently >> >> really was >> > >> > /is/ >> > >> >> a serious problem, but not one intrinsic to the language. Today there's >> >> at least one good free implementation (GNAT), so Ada is more accessible >> >> now than it was. >> > >> > It isn't, since you can't use the free implementation (U.S. taxpayer >> > funded, btw) for anything having to do with work (because there >> > isn't any support) and not anything closed source (it's GPL). >> >> Well, hold on: if you want paid support GNAT is supported by AdaCore > > The statement I responded to was quoted above, "Today there's at least one > good free implementation (GNAT)". > > That's incorrect. It's partially correct, it's good but it's not free. > > GNAT comes in two flavours, GPL, with no support option and with GPL > libraries, two things that make it untenable for business. The > Adacore version you mention is USD 20,000 minimum for support, but > you can't get the code unless you pay for support. I don't believe that's possible for the compiler: the compiler is GPL code, therefore anyone can give the compiler to anyone else. I understand that the runtime has some other licence. It's quite clear at adacore.com: What is the license of GNAT Pro? The GNAT Pro tools are licensed under the GNU General Public License (GPL), while the GNAT Pro runtime and libraries are licensed under the GNAT Modified GPL (GMGPL). The GMGPL guarantees that *executables* generated by GNAT Pro can be distributed under customer-specific terms and conditions. Specifically, the GMGPL ensures that customers can generate proprietary, classified, or otherwise restricted executables. >> and there is a version of the GNAT runtime library that isn't pure >> GPL if you need to write proprietary software. > > But it's not supported and no company is going to bet their business > on core tools with no accountability or support, so no enterprise is > going to use it. Absolutely, I understand that. I've been in the GCC support business for 15 years. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-10-28 21:38 +0100 |
| Subject | Re: I Don?t Make Mistakes. I Use C |
| Message-ID | <2424357.RxXSL74dWZ@sunwukong.fritz.box> |
| In reply to | #16809 |
Andrew Haley wrote: >>> and there is a version of the GNAT runtime library that isn't pure >>> GPL if you need to write proprietary software. >> >> But it's not supported and no company is going to bet their business >> on core tools with no accountability or support, so no enterprise is >> going to use it. > > Absolutely, I understand that. I've been in the GCC support business > for 15 years. I understand the support part, but I don't understand the "accountability part". Yes, I know that the GPL has a paragraph written in all caps, shouting that there is NO WARRANTY. But so does any commercial EULA I've ever read and clicked "accept". If you compile your Ariane 5 code with GNATS, and the rocket blows up, the GNATS team will *not* pay for another rocket. Regardless if you have used the free version or the one with the $20k pricetag. If you bet your company on the new revolutionary "sell low, buy high" algorithm for high-speed trading, and don't manage to shut down the machine for 45 minutes, the people who sold you the compiler will never ever pay for the $400M you lost in the meantime. Even if it *was* their fault, and they got some comparison flag wrong. You usually do get support with free software for free, too. The quality of the support depends on how nicely you ask and how stupid your question is; free software is supported by the authors. In general, as it's free software, you could (in theory) fix your problem yourself. In practise, it is usually easier to file a bug report to the maintainer (as Brook's law tells you: if you fix the bug yourself, it's "adding another person to the project"). If the project is mainly a cash cow for a company who sells support, the free-software side of the support may be poor and the code may be difficult to maintain, because that way the company can sell more support contracts. On the other hand, when we filed a bug report about 20 years ago for the "long long" bug in GCC (which was specified to be "twice as long as long int", but on a 64 bit machine with a 64 bit int, it was just 64 bits, too), the non-commercial, non-cygnus maintainers back then responded with "we changed the spec instead, it's now twice as long as int". I don't think a support contract would have given us what we wanted and needed. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | jacko <jackokring@gmail.com> |
|---|---|
| Date | 2012-10-28 16:34 -0700 |
| Subject | Re: I Don?t Make Mistakes. I Use C |
| Message-ID | <e2692916-11fb-4802-b819-cb73dfeb15b5@googlegroups.com> |
| In reply to | #16818 |
> On the other hand, when we filed a bug report about 20 years ago for the > "long long" bug in GCC (which was specified to be "twice as long as long > int", but on a 64 bit machine with a 64 bit int, it was just 64 bits, > too), the non-commercial, non-cygnus maintainers back then responded > with "we changed the spec instead, it's now twice as long as int". I > don't think a support contract would have given us what we wanted and > needed. Type modifiers in C were always a silly idea. Just like C++ and the syntactic sugar to avoid seeing function pointers. And all this register, volatile, and static stuff is not needed. A static local can be inferred by read before write. I agree with extern though, although debate exists as to all .h names being extern. If libansforth.so existed, how many symbols would it have, need, ...?
[toc] | [prev] | [next] | [standalone]
| From | Anonymous <nobody@remailer.paranoici.org> |
|---|---|
| Date | 2012-10-29 10:56 +0000 |
| Subject | Re: I Don?t Make Mistakes. I Use C |
| Message-ID | <8fd57e8f0367d49362fda6384e2670fd@remailer.paranoici.org> |
| In reply to | #16809 |
Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > Anonymous <nobody@remailer.paranoici.org> wrote: > > Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > > > >> Fritz Wuehler <fritz@spamexpire-201210.rodent.frell.theremailer.net> wrote: > >> > Paul Rubin <no.email@nospam.invalid> wrote: > >> > > >> > And, Ada is much better than almost any system at separate compilation and > >> > making sure things like arguments are consistent and correct across the > >> > whole application. > >> > > >> >> That leaves the expense of the development environments, which apparently > >> >> really was > >> > > >> > /is/ > >> > > >> >> a serious problem, but not one intrinsic to the language. Today there's > >> >> at least one good free implementation (GNAT), so Ada is more accessible > >> >> now than it was. > >> > > >> > It isn't, since you can't use the free implementation (U.S. taxpayer > >> > funded, btw) for anything having to do with work (because there > >> > isn't any support) and not anything closed source (it's GPL). > >> > >> Well, hold on: if you want paid support GNAT is supported by AdaCore > > > > The statement I responded to was quoted above, "Today there's at least one > > good free implementation (GNAT)". > > > > That's incorrect. It's partially correct, it's good but it's not free. > > > > GNAT comes in two flavours, GPL, with no support option and with GPL > > libraries, two things that make it untenable for business. The > > Adacore version you mention is USD 20,000 minimum for support, but > > you can't get the code unless you pay for support. > > I don't believe that's possible for the compiler: the compiler is GPL > code, therefore anyone can give the compiler to anyone else. I > understand that the runtime has some other licence. No, the compiler is hair-splittingly dual licensed, this is what makes Adacore viable. If not for that, they have no business. GNAT is GPL for those who don't pay, and GMGPL for those who do, so they don't have to open their source. Adacore owns the copyrights, so they can do whatever they want. And that's how they made a business out of the 100% U.S. taxpayer funded development of GNAT. > It's quite clear at adacore.com: Apparently NOT! ;-) > > What is the license of GNAT Pro? > > The GNAT Pro tools are licensed under the GNU General Public License > (GPL), while the GNAT Pro runtime and libraries are licensed under the > GNAT Modified GPL (GMGPL). The GMGPL guarantees that *executables* > generated by GNAT Pro can be distributed under customer-specific terms > and conditions. Specifically, the GMGPL ensures that customers can > generate proprietary, classified, or otherwise restricted executables. Right, as long as they pay the USD 20,000. Notice the words above like "customer-specific" and "customers". Those words mean you have to pay money. All others get GPL and no certications and no fixes and no support. Rather than continuing to argue about it based on a five second website read, try this: call up Adacore or send them an email and ask for a copy of the safety-certified GMGPL toolchain, since according to you the code is GPL and has to be made available for no more than distribution costs. According to your IANALBIPOOTV misinterpretation this should be no problem! Well?! We're waiting! > > >> and there is a version of the GNAT runtime library that isn't pure > >> GPL if you need to write proprietary software. That's right, as long as you pay the 20,000 bucks you get the GMGPL runtime. You're making wild-ass guesses about how this works, but I have been telling you how customers explained it to me. I think you should either show us your free copy of GMGPL GNAT or just admit you're blowing smoke out of your ass! And I am aware, and have already mentioned that gcc-Ada is or was LGPL, and that is the 3rd flavor, but we are talking about GNAT, which comes in only two versions, paid GMGPL or unpaid, unsupported pure GPL.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-10-29 06:11 -0500 |
| Subject | Re: I Don?t Make Mistakes. I Use C |
| Message-ID | <J_ydnTJPxu7_-RPNnZ2dnUVZ8i-dnZ2d@supernews.com> |
| In reply to | #16821 |
Anonymous <nobody@remailer.paranoici.org> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > >> Anonymous <nobody@remailer.paranoici.org> wrote: >> > Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >> > >> >> Fritz Wuehler <fritz@spamexpire-201210.rodent.frell.theremailer.net> wrote: >> >> > Paul Rubin <no.email@nospam.invalid> wrote: >> >> > >> >> > And, Ada is much better than almost any system at separate compilation and >> >> > making sure things like arguments are consistent and correct across the >> >> > whole application. >> >> > >> >> >> That leaves the expense of the development environments, which apparently >> >> >> really was >> >> > >> >> > /is/ >> >> > >> >> >> a serious problem, but not one intrinsic to the language. Today there's >> >> >> at least one good free implementation (GNAT), so Ada is more accessible >> >> >> now than it was. >> >> > >> >> > It isn't, since you can't use the free implementation (U.S. taxpayer >> >> > funded, btw) for anything having to do with work (because there >> >> > isn't any support) and not anything closed source (it's GPL). >> >> >> >> Well, hold on: if you want paid support GNAT is supported by AdaCore >> > >> > The statement I responded to was quoted above, "Today there's at least one >> > good free implementation (GNAT)". >> > >> > That's incorrect. It's partially correct, it's good but it's not free. >> > >> > GNAT comes in two flavours, GPL, with no support option and with GPL >> > libraries, two things that make it untenable for business. The >> > Adacore version you mention is USD 20,000 minimum for support, but >> > you can't get the code unless you pay for support. >> >> I don't believe that's possible for the compiler: the compiler is GPL >> code, therefore anyone can give the compiler to anyone else. I >> understand that the runtime has some other licence. > > No, the compiler is hair-splittingly dual licensed, this is what > makes Adacore viable. If not for that, they have no business. GNAT > is GPL for those who don't pay, and GMGPL for those who do, so they > don't have to open their source. But that simply isn't true. As the page at adacore.com makes clear, the tools are GPL. > Adacore owns the copyrights, so they can do whatever they want. And > that's how they made a business out of the 100% U.S. taxpayer funded > development of GNAT. I don't believe you. >> It's quite clear at adacore.com: > > Apparently NOT! ;-) > >> >> What is the license of GNAT Pro? >> >> The GNAT Pro tools are licensed under the GNU General Public License >> (GPL), while the GNAT Pro runtime and libraries are licensed under the >> GNAT Modified GPL (GMGPL). The GMGPL guarantees that *executables* >> generated by GNAT Pro can be distributed under customer-specific terms >> and conditions. Specifically, the GMGPL ensures that customers can >> generate proprietary, classified, or otherwise restricted executables. > > Right, as long as they pay the USD 20,000. Notice the words above > like "customer-specific" and "customers". Those words mean you have > to pay money. All others get GPL and no certications and no fixes > and no support. That's fair enough. > Rather than continuing to argue about it based on a five second > website read, try this: call up Adacore or send them an email and > ask for a copy of the safety-certified GMGPL toolchain, since > according to you the code is GPL and has to be made available for no > more than distribution costs. No, that's not what the GPL says. It does not say that you have to make software available to anyone who asks, for no more than distribution costs, and it never has. It says that anyone who receives the binaries must also receive the source code if they ask for it, and they then have the right to supply that code to anyone else. You're perfectly entitled to sell GPL code and to refuse to deal with people who aren't your customers. > According to your IANALBIPOOTV misinterpretation this should be no problem! > > Well?! We're waiting! > >> >> >> and there is a version of the GNAT runtime library that isn't pure >> >> GPL if you need to write proprietary software. > > That's right, as long as you pay the 20,000 bucks you get the GMGPL runtime. > > You're making wild-ass guesses about how this works, but I have been > telling you how customers explained it to me. I think you should > either show us your free copy of GMGPL GNAT or just admit you're > blowing smoke out of your ass! And I am aware, and have already > mentioned that gcc-Ada is or was LGPL, and that is the 3rd flavor, > but we are talking about GNAT, which comes in only two versions, > paid GMGPL or unpaid, unsupported pure GPL. You apparently don't understand the GPL. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2012-10-29 13:51 -0400 |
| Subject | Re: I Don?t Make Mistakes. I Use C |
| Message-ID | <k6mfma$5dl$1@dont-email.me> |
| In reply to | #16822 |
On 10/29/2012 7:11 AM, Andrew Haley wrote: > > You apparently don't understand the GPL. > > Andrew. Maybe the issue is around who *wrote* the code in question. If Adacore wrote the code and released one version of it as GPL, could they not sell a different version of the code? On the other hand, if Adacore took GPL code written by someone else and modified it, I think the GPL would make *all* derivatives of that code GPL and so freely distributable. So who actually wrote the code? Rick
[toc] | [prev] | [next] | [standalone]
| From | Anonymous <nobody@remailer.paranoici.org> |
|---|---|
| Date | 2012-10-29 20:45 +0000 |
| Subject | Re: I Don?t Make Mistakes. I Use C |
| Message-ID | <6f075eac386a4c1bb7d455e420456bc2@remailer.paranoici.org> |
| In reply to | #16829 |
rickman <gnuarm@gmail.com> wrote: > On 10/29/2012 7:11 AM, Andrew Haley wrote: > > > > You apparently don't understand the GPL. I think I do, but it really doesn't matter here. All of your assumptions about the parameters of this whole discussion are baseless. Your misunderstandings and arguing from ignorance are epic! Congrats.. > > > > Andrew. > > Maybe the issue is around who *wrote* the code in question. If Adacore > wrote the code and released one version of it as GPL, could they not > sell a different version of the code? Ding! > On the other hand, if Adacore took GPL code written by someone else and > modified it, I think the GPL would make *all* derivatives of that code > GPL and so freely distributable. > > So who actually wrote the code? A guy who works for Adacore, now. But, I don't know how he got control of the copyright since he was working for New York University under public funding when GNAT was first written. I guess if you're smart enough to write a bunch of compilers (this was far from his first) you're smart enough to wrangle the copyrights..even on the taxpayer's dollar. And curioser still is GNAT would /seem/ to be a GPL-derivative work since it's a front-end to gcc and doesn't stand alone. I'm not sure how they can dual license it, but they do. That's what lawyers and customers to pay for them are all about.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-10-30 04:20 -0500 |
| Subject | Re: I Don?t Make Mistakes. I Use C |
| Message-ID | <zq2dnSWoyfdvBhLNnZ2dnUVZ8lydnZ2d@supernews.com> |
| In reply to | #16830 |
Anonymous <nobody@remailer.paranoici.org> wrote: > And curioser still is GNAT would /seem/ to be a GPL-derivative work > since it's a front-end to gcc and doesn't stand alone. I'm not sure > how they can dual license it, but they do. No they don't, as their web page makes clear: the compiler is licensed under the GPL. Hey, I even quoted it. > That's what lawyers and customers to pay for them are all about. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-10-30 04:16 -0500 |
| Subject | Re: I Don?t Make Mistakes. I Use C |
| Message-ID | <zq2dnSqoyfeXBhLNnZ2dnUVZ8lydnZ2d@supernews.com> |
| In reply to | #16829 |
rickman <gnuarm@gmail.com> wrote: > On 10/29/2012 7:11 AM, Andrew Haley wrote: >> >> You apparently don't understand the GPL. > > Maybe the issue is around who *wrote* the code in question. If > Adacore wrote the code and released one version of it as GPL, could > they not sell a different version of the code? They could, but a. The compiler is derived from GCC. b. AdaCore make it plain that the GNAT Pro compiler is licensed under the GPL. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2012-10-25 10:04 -0400 |
| Message-ID | <k6c64b$rvf$1@dont-email.me> |
| In reply to | #16635 |
On 10/23/2012 8:02 PM, Elizabeth D. Rather wrote: > On 10/23/12 1:09 PM, visualforth@rocketmail.com wrote: > .... >> -.- >> Excerpt from "I Don’t Make Mistakes. I Use C" >> Source: >> http://electronicdesign.com/blog/altembedded-6/embedded/dont-mistakes-74459 >> >> >> What about Forth ? >> > > Folks who design languages have a target programmer/user in mind. I > remember when Ada was being designed and various prototypes were being > published and reviewed. The target programmer for Ada was a very > low-level coder, working from a rigid spec in a "waterfall" development > process in a very large project. Because this was a very junior person, > it was assumed that the compiler had to second-guess everything. This is what you get if you want to assemble a large group of programmers. You can't always hire the best and the brightest unless perhaps you are NASA and I expect they only get those when they are recruiting astronauts. I've been working with computers for over 40 years and it seems to me that this is always the problem, getting enough good people to do the work. The skill level/quality of candidates for any job description fit the bell curve and there are not enough beyond one sigma much less beyond three sigma (in both directions fortunately). > Once Ada was released for use, the military (which had asked for it, and > initially required its use) found that their software costs went through > the roof. Very soon they modified the rule to require Ada only for > projects budgeted >$1m, and some years later dropped it altogether. > > There is still a dedicated corps of Ada advocates, about the size of the > Forth community according to some estimates. > > Forth also had a target programmer in mind: Chuck designed it for > himself. He included all the features that he felt made him more > productive and his programs more reliable: interactivity, modularity, > maximum programmer control. This works for people who are very smart, > very knowledgeable about their application domain, and willing to assume > responsibility for their work. In other words, the opposite of the > target Ada programmer. One place where Ada is alive and well is in VHDL. It may not be the same language, but it is similar and based on the same principles. Oddly enough the two languages I like are Forth and VHDL. > As for size of projects: Forth tends to shrink projects (that is, > projects originally expected to require 30 or 40 programmers were done > in a shorter time with 10-15). I've worked on or managed several fairly > large projects (10+ programmers), and found Forth works well in that > environment providing you insist on getting the smartest and most > professional folks you can find. If you can get the "smartest and most professional" programmers, I think nearly any language will do the job. But I suppose I get your point. What happens if you get the same sort of crew for a large Forth project that everyone else gets for their C projects? I think programmers and managers see the world differently. Programmers tend to think of work in terms of what is optimal, superior and interesting. Managers tend to think of work in terms of what is consistent, reliable and predictable. The two are seldom the same and managers make important decisions, even if they aren't right. I've been lucky and most of the bad decisions on projects I have done were my manager's, not mine. Now however, we are the same person... so I get to make *all* the bad decisions. ;-o Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-10-25 14:16 -0700 |
| Message-ID | <7xa9vadzg8.fsf@ruckus.brouhaha.com> |
| In reply to | #16707 |
rickman <gnuarm@gmail.com> writes: > If you can get the "smartest and most professional" programmers, I > think nearly any language will do the job. "Smartest and most professional programmers" is a platitude anyway, because of the bell curve. They are out there but they are choosing their own projects, running their own companies, etc. And beyond that layer, they're in academia, gathering up Fields medals, Nobel prizes, and beyond even that routine Nobel Prize level, there's a guy at IAS whose intellect has been compared in print to Isaac Newton's. > But I suppose I get your point. What happens if you get the same sort > of crew for a large Forth project that everyone else gets for their C > projects? Or look at it from the other direction: A project with 10-15 super-strong programmers is going to generate quite a lot of code, which implies a fairly powerful computer (not a tiny embedded thing), and most of the code probably doesn't directly poke the hardware. So you've got both a codebase size that's outside Forth's comfort zone and doesn't use Forth's advantages, and machine resources that can withstand the admittedly higher demands of most other languages. So if you've got programmers who were good enough to get your project done despite the low-level nature of Forth, it's possible they could have accomplished even more with more powerful tools.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2012-10-25 15:51 -1000 |
| Message-ID | <7oGdnZ_ZQto6cRTNnZ2dnUVZ_sudnZ2d@supernews.com> |
| In reply to | #16711 |
On 10/25/12 11:16 AM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> If you can get the "smartest and most professional" programmers, I >> think nearly any language will do the job. > > "Smartest and most professional programmers" is a platitude anyway, > because of the bell curve. They are out there but they are choosing > their own projects, running their own companies, etc. And beyond that > layer, they're in academia, gathering up Fields medals, Nobel prizes, > and beyond even that routine Nobel Prize level, there's a guy at IAS > whose intellect has been compared in print to Isaac Newton's. Well, I did say "the smartest and most professional folks *you can find*" :-) But I've been on projects staffed with the first <n> warm bodies available at a low salary, as well as projects staffed with hand-picked people, and I know for a fact that the 2nd kind gets the project done both quicker and cheaper, even though their salaries may be much higher. >> But I suppose I get your point. What happens if you get the same sort >> of crew for a large Forth project that everyone else gets for their C >> projects? > > Or look at it from the other direction: A project with 10-15 > super-strong programmers is going to generate quite a lot of code, which > implies a fairly powerful computer (not a tiny embedded thing), and most > of the code probably doesn't directly poke the hardware. So you've got > both a codebase size that's outside Forth's comfort zone and doesn't use > Forth's advantages, and machine resources that can withstand the > admittedly higher demands of most other languages. > > So if you've got programmers who were good enough to get your project > done despite the low-level nature of Forth, it's possible they could > have accomplished even more with more powerful tools. I have been on projects with 10-15 programmers, most of whom were super-strong. But they typically involved multiple computers of various sizes, and a large overall project that could be factored into discrete chunks. Factoring works as well in project management as it does in programming. In one example, Such projects work extremely well with Forth, providing management is sufficiently nimble to keep up with the fast pace of Forth projects. In one such project, the now-famous Saudi airport, the Forth team completed in 18 months (27 man-years) a huge project on which 30 programmers had previously labored for 3 years (90 man-years), using the most powerful programming tools available at the time, and completed about 1/4 of the project with unacceptable timing performance. Obviously I know nothing of the skill level of the unsuccessful programming team, but they all were employees of a major aerospace firm. The airport is currently advertising for Forth programmers, btw. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-10-25 20:14 -0700 |
| Message-ID | <7xpq452aci.fsf@ruckus.brouhaha.com> |
| In reply to | #16722 |
"Elizabeth D. Rather" <erather@forth.com> writes: > In one such project, the now-famous Saudi airport, the Forth team > completed in 18 months (27 man-years) a huge project on which 30 > programmers had previously labored for 3 years (90 man-years), using > the most powerful programming tools available at the time, and > completed about 1/4 of the project with unacceptable timing > performance. Right, that was what, the 1980's? The other stuff available at that time was terrible compared to what's around now, as were large organizations' development processes. Of course Forth has gotten better too, but by as large a factor? If Forth is 3x better than before and the other stuff is 50x better than before, the advantage has moved to the other side. > the unsuccessful programming team... all were employees of a major > aerospace firm. That does sound like a recipe for bureaucracy and bloat. > The airport is currently advertising for Forth programmers, btw. Now THAT is interesting, and may be worth making a separate post about, in case some clf'er wants to apply. (Assuming Forth Inc. doesn't already have the situation under control).
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-10-25 23:11 -0500 |
| Subject | Re: I Don?t Make Mistakes. I Use C |
| Message-ID | <g42dneH18KIakBfNnZ2dnUVZ8lSdnZ2d@supernews.com> |
| In reply to | #16723 |
Paul Rubin <no.email@nospam.invalid> wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> In one such project, the now-famous Saudi airport, the Forth team >> completed in 18 months (27 man-years) a huge project on which 30 >> programmers had previously labored for 3 years (90 man-years), using >> the most powerful programming tools available at the time, and >> completed about 1/4 of the project with unacceptable timing >> performance. > > Right, that was what, the 1980's? The other stuff available at that > time was terrible compared to what's around now, as were large > organizations' development processes. Of course Forth has gotten > better too, but by as large a factor? If Forth is 3x better than > before and the other stuff is 50x better than before, the advantage > has moved to the other side. Well, if pigs could fly ... I don't believe for a moment that programmers are anything like N x more productive than we were. It helps to have faster computer so we aren't waiting for things to happen, but the complexity of the systems we use has increased which soaks up a fair bit of that performance improvement. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-10-25 21:53 -0700 |
| Subject | Re: I Don?t Make Mistakes. I Use C |
| Message-ID | <7xvcdx7s1z.fsf@ruckus.brouhaha.com> |
| In reply to | #16725 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > Well, if pigs could fly ... I don't believe for a moment that > programmers are anything like N x more productive than we were. It > helps to have faster computer so we aren't waiting for things to > happen, but the complexity of the systems we use has increased which > soaks up a fair bit of that performance improvement. The faster and much more capacious computers doesn't just mean you're not waiting for things, it means you can use pre-existing tools that are overkill for the problem at hand just because it's convenient and you finish faster. E.g. instead of spending N months implementing a database as part of the system, you'd spend an afternoon setting up an SQL server. Instead of implementing custom message formats and communications layers you'd use AMQP or web services or whatever. Instead of intricately coded character-oriented screen UI's (I worked on those and it was painful) you'd serve some simple web pages and access them with browsers. That doesn't even get to using languages that can juggle strings, nested structures, etc. natively, like anything reasonable today can. The programs wouldn't fit in PDP-11's any more, but that's not relevant. I put up a url recently (definitely not scientific, but plausible) claiming software productivity doubles every 6 years: http://people.cs.umass.edu/~yannis/law.html Look at some SPOJ problems ( http://www.spoj.pl/problems/classical/ ) and think of how long it would take to do them in Forth compared to other possibilities. This is more of the same.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-10-26 01:27 -0500 |
| Subject | Re: I Don?t Make Mistakes. I Use C |
| Message-ID | <XJ-dnQSi4uX7sBfNnZ2dnUVZ8kKdnZ2d@supernews.com> |
| In reply to | #16727 |
Paul Rubin <no.email@nospam.invalid> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> Well, if pigs could fly ... I don't believe for a moment that >> programmers are anything like N x more productive than we were. It >> helps to have faster computer so we aren't waiting for things to >> happen, but the complexity of the systems we use has increased which >> soaks up a fair bit of that performance improvement. > > The faster and much more capacious computers doesn't just mean you're > not waiting for things, it means you can use pre-existing tools that are > overkill for the problem at hand just because it's convenient and you > finish faster. E.g. instead of spending N months implementing a > database as part of the system, you'd spend an afternoon setting up an > SQL server. Instead of implementing custom message formats and > communications layers you'd use AMQP or web services or whatever. Sure, but that's like saying you can program much faster if you use a program that's already been written instead of writing a new one! I'm talking about the actual productivity of programmers writing programs. > Instead of intricately coded character-oriented screen UI's (I worked on > those and it was painful) you'd serve some simple web pages and access > them with browsers. That doesn't even get to using languages that can > juggle strings, nested structures, etc. natively, like anything > reasonable today can. The programs wouldn't fit in PDP-11's any more, > but that's not relevant. > > I put up a url recently (definitely not scientific, but plausible) > claiming software productivity doubles every 6 years: > > http://people.cs.umass.edu/~yannis/law.html That is maybe plausible, just about, for some things. The KWIC problem described is an interesting case because if you ignore efficiency issues you can solve it quickly. Does this mean that today's programmers are more productive than yesterday's? No! Yestderday's programmers would have been able to solve the KWIC problem quickly too if they could have got away with ignoring efficiency, although without a fast interactive development environment it would have taken them somewhat longer. > Look at some SPOJ problems ( http://www.spoj.pl/problems/classical/ ) > and think of how long it would take to do them in Forth compared to > other possibilities. This is more of the same. Well, maybe, but I think it's a bogus comparison. AFAICS that's a bunch of toy problems in pure maths; of course you want a programming language and environment suited to that. Real programming, and real programmer productivity, isn't dominated by that kind of thing, IME. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-10-26 07:06 -0700 |
| Subject | Re: I Don?t Make Mistakes. I Use C |
| Message-ID | <7x625xe39v.fsf@ruckus.brouhaha.com> |
| In reply to | #16728 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > Sure, but that's like saying you can program much faster if you use a > program that's already been written instead of writing a new one! I'm > talking about the actual productivity of programmers writing programs. Well, partway agreed. Programming is putting existing building blocks together, which in the early days meant individual machine instructions plus maybe some subroutines that computed (say) square roots. These days we get bigger blocks, and if they are general purpose and re-usable then building applications from them still counts as programming. As a maybe-better example, if we were writing a compiler today, we'd use a parser generator instead of writing a hand-coded parser like a 1970's implementer would have done. > That is maybe plausible, just about, for some things. The KWIC > problem described is an interesting case because if you ignore > efficiency issues you can solve it quickly. Does this mean that > today's programmers are more productive than yesterday's? No! > Yestderday's programmers would have been able to solve the KWIC > problem quickly too if they could have got away with ignoring > efficiency, although without a fast interactive development > environment it would have taken them somewhat longer. I think Parnas's 1972 description probably was based on assembly language, and I could imagine implementing KWIC in assembler taking a week. If done in Snobol or Lisp, the part about generating the rotated lines could probably be done almost as easily as in Python today, but in all cases I'm not sure how the sorting phase would have been done. In the (plausible) case of a book-sized input, sorting in memory on a 1972 minicomputer wouldn't have been feasible, and an external sort utility might not have been presumptively available (I don't know). Today we'd just sort in memory, or we could call the unix "sort" command for an external sort. In a really enormous case, we could use MrJob, which is a Python wrapper for Hadoop, and (optimistically) still complete the coding task in an hour, if the Hadoop cluster was already set up. That would have just been outlandish in the 1970's. >> SPOJ problems ( http://www.spoj.pl/problems/classical/ ) > Well, maybe, but I think it's a bogus comparison. AFAICS that's a > bunch of toy problems in pure maths; of course you want a programming > language and environment suited to that. Real programming, and real > programmer productivity, isn't dominated by that kind of thing, IME. Maybe this is better then: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.117.1208&rep=rep1&type=pdf
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-10-26 11:34 -0500 |
| Subject | Re: I Don?t Make Mistakes. I Use C |
| Message-ID | <cPWdnbkpTYgHJhfNnZ2dnUVZ8nmdnZ2d@supernews.com> |
| In reply to | #16735 |
Paul Rubin <no.email@nospam.invalid> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> Sure, but that's like saying you can program much faster if you use a >> program that's already been written instead of writing a new one! I'm >> talking about the actual productivity of programmers writing programs. > > Well, partway agreed. Programming is putting existing building blocks > together, which in the early days meant individual machine instructions > plus maybe some subroutines that computed (say) square roots. These > days we get bigger blocks, and if they are general purpose and re-usable > then building applications from them still counts as programming. As a > maybe-better example, if we were writing a compiler today, we'd use a > parser generator instead of writing a hand-coded parser like a 1970's > implementer would have done. Right, yes. If a programmer back then had had a bunch of subroutines to do the difficult algorithms then it'd be just a job of tying them together. This makes the programmer more productive in the sense that they're solving problems faster, but I believe that to say they're more productive is bogus -- they're producing less. It depends on what you mean by productivity. And I don't really want to start counting lines of code -- as Dijkstra said, we should count the lines of code *used* to solve a problem, not the lines of code *produced*. It is worth counting lines of code, but they must appear on the debit side of the ledger! >> That is maybe plausible, just about, for some things. The KWIC >> problem described is an interesting case because if you ignore >> efficiency issues you can solve it quickly. Does this mean that >> today's programmers are more productive than yesterday's? No! >> Yestderday's programmers would have been able to solve the KWIC >> problem quickly too if they could have got away with ignoring >> efficiency, although without a fast interactive development >> environment it would have taken them somewhat longer. > > I think Parnas's 1972 description probably was based on assembly > language, and I could imagine implementing KWIC in assembler taking > a week. If done in Snobol or Lisp, the part about generating the > rotated lines could probably be done almost as easily as in Python > today, but in all cases I'm not sure how the sorting phase would > have been done. loop s arb $ pre len(1) $ c len(1) $ d *lgt(c,d) rem $ post = pre d c post :s(loop) :-) (From http://www.j-paine.org/dobbs/snobol_one_liner.html) > In the (plausible) case of a book-sized input, sorting in memory on > a 1972 minicomputer wouldn't have been feasible, and an external > sort utility might not have been presumptively available (I don't > know). Minicomputer? Why a minicomputer? Larger computers all had a library of external sorting commands > Today we'd just sort in memory, or we could call the unix "sort" > command for an external sort. In a really enormous case, we could > use MrJob, which is a Python wrapper for Hadoop, and > (optimistically) still complete the coding task in an hour, if the > Hadoop cluster was already set up. That would have just been > outlandish in the 1970's. I guess so! But as I said, this just means that the programmers are solving a different problem. >>> SPOJ problems ( http://www.spoj.pl/problems/classical/ ) >> Well, maybe, but I think it's a bogus comparison. AFAICS that's a >> bunch of toy problems in pure maths; of course you want a programming >> language and environment suited to that. Real programming, and real >> programmer productivity, isn't dominated by that kind of thing, IME. > > Maybe this is better then: > > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.117.1208&rep=rep1&type=pdf Yes, that's an interesting one. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-10-26 19:13 +0200 |
| Subject | Re: I Don?t Make Mistakes. I Use C |
| Message-ID | <19873993.C5Gze9Gjdy@sunwukong.fritz.box> |
| In reply to | #16735 |
Paul Rubin wrote: > As a > maybe-better example, if we were writing a compiler today, we'd use a > parser generator instead of writing a hand-coded parser like a 1970's > implementer would have done. Yes, we would. But then, we have parser generators in Forth like Gray (comes with Gforth) for more than 20 years now. Another thing is that on a desktop Forth, you can access all these nice and complicated C libraries, too. With a tool like Swig, the bindings are even created automatically (thouhg the Forth module for Swig still has a few rough edges, and therefore isn't released yet). Using Forth doesn't exclude you from using available pieces of software written in other languages. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <blog@rivadpm.com> |
|---|---|
| Date | 2012-10-27 04:49 -0700 |
| Subject | Re: I Don?t Make Mistakes. I Use C |
| Message-ID | <8d2e96d2-e37b-400d-8402-be0e50538ebc@g18g2000vbf.googlegroups.com> |
| In reply to | #16743 |
On Oct 26, 6:13 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote: > Paul Rubin wrote: > > As a > > maybe-better example, if we were writing a compiler today, we'd use a > > parser generator instead of writing a hand-coded parser like a 1970's > > implementer would have done. > > Yes, we would. But then, we have parser generators in Forth like Gray > (comes with Gforth) for more than 20 years now. > > Another thing is that on a desktop Forth, you can access all these nice > and complicated C libraries, too. With a tool like Swig, the bindings > are even created automatically (thouhg the Forth module for Swig still > has a few rough edges, and therefore isn't released yet). Using Forth > doesn't exclude you from using available pieces of software written in > other languages. > > -- > Bernd Paysan > "If you want it done right, you have to do it yourself"http://bernd-paysan.de/ Is somebody working on a Forth SWIG plugin? I've been using the XML output and XSLT to modify it into Forth. I'd be interested to see this.
[toc] | [prev] | [next] | [standalone]
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
Back to top | Article view | comp.lang.forth
csiph-web