Clipper 5.2e 32-Bit Edition
Saulo
directions to a new Clipper version release targeting 32-Bit based OS?
For me I would ask very ''basic'' things:
>> Standard DLL generation under Windows
>> Only Console apps
>> ADS RDD
My intention is to keep it as simple as possible just to get an exit
from the trap that CA imposed to us when it stopped Clipper`s
development.
What do you think?
Saulo
Lawrence
COM objects, would suite me
Stephen Quinn
> A 32 Bit Version of Clipper, which can access and call window DLL and
> COM objects, would suite me
You have that already with VO.
If you mean 32bit DOS/Console apps then use XBase++ and/or Harbour.
The person to ask is Brian Feldman, he's the only one that knows if he'll
put resources towards a Clipper update, whether it's a patch or a 32bit
version
HTH
Steve Quinn
Roger Harris
it could produce 32 bit console applications
Cheers
Roger
"Stephen Quinn" <squ...@brutecom.com.au> wrote in message
news:aaiksc$b1a8j$1...@ID-88745.news.dfncis.de...
Stephen Quinn
You can, but XBase++ does it better.
HTH
Steve Quinn
Roger Harris
"Stephen Quinn" <squ...@brutecom.com.au> wrote in message
news:aaips9$b5hbr$1...@ID-88745.news.dfncis.de...
Mike Evans
"Roger Harris" <ro...@HarrisSoftware.com> wrote in message news:IE8z8.3272$lA2.2...@news.xtra.co.nz...
Saulo
My intention is to send to GrafX (Brian Feldman) a Wish List from the
Clipper Community about CLIPPER!
GrafX is now the owner of Clipper and what I hope is that finaly we
can speak to someone that can do something to improve it.
We are talking about CLIPPER!
I already bought both Xbase++ and CA-VO!
I already was there, saw them and was frustrated!
I don`t want to change the focus of my message to discuss others
languages/Vendors!
Saulo
"Stephen Quinn" <squ...@brutecom.com.au> wrote in message news:<aaiksc$b1a8j$1...@ID-88745.news.dfncis.de>...
Saulo
> A 32 Bit Version of Clipper, which can access and call window DLL and
> COM objects, would suite me
>
>
>
Ok... DLL calling!
About ActiveX I would avoid asking that for the first release because
I believe that this may lead to a big amount of development effort to
be applied.
DLL generation/calling will generate an instantaneous migration path.
Your Clipper code will be able to be called by Delphi, C++, etc...
For me, by now, just this would be nice :)
Saulo
TG
I made the mistake of buying V1.3 and never received anything that even
resembled a patch!
$1000 bucks down the drain... Never again!
At least with VO you got a patch or three. Alaska's support attitude sucks!
TG
"Stephen Quinn" <squ...@brutecom.com.au> wrote in message
news:aaips9$b5hbr$1...@ID-88745.news.dfncis.de...
Stephan St-Denis
I already asked Brian and he told me that Clipper already has a 32 bits
version... named VO.
I know what you want and I wanted the same thing. But unfortunately, Brian
and his team will put all their efforts on VO and probably nothing on
Clipper.
Anyway, since you already own VO, why don't you use it for your future
projects ?
I currently use Xbase++ and I can tell you that it's a lot of pain to port
our current Hybrid program to full GUI. The GUI classes aren't well designed
(compared to Delphi's one) and after reading the VO documentation, I can
tell you that VO's GUI classes seems better than Xbase++'s ones.
Just my 2 cents,
Stephan St-Denis
"Saulo" <sa...@password.info> a écrit dans le message de news:
69456e0b.02042...@posting.google.com...
Mike Evans
1. By far the best gui it's Delphi Gui (Classes - IDE )
2. The second one for me is the VB
3. The third one is DB2k
3. The third one is VO ( by far worst than Delphi )
4. Alaska Xbase++ is the worst from the above languages on the Gui level until know.
On the language level i prefer Xbase++ then VO and then Delphi ( I don't like Pascal anyway). Vo have a lot more ready Classes
than Xbase and it's more powerfull but Xbase++ have a future (The same for VO from now on). I like very much from Xbase the easy way
to create Threads (Thread safe even for Gui Classes etc) and the easiness to create classes or CB on the fly and distribute them
over the net using tcpip sockets etc. I like also from VO the way that you can create Toolbars - browses -Servers - OCX etc. The bad
think about Xbase Dialect is that tere are a lot of clones ( VO, Xbase++,DB2k,FW,CL4W,Harbour,Xharbour, Flagship, MAX, clip2c
etc.... )in contrast with Object Pascal that there are only one ( maybee too). If there was only one Xbase dialect then i think that
thinks will be different.
P.S. I haven't test C#
"Stephan St-Denis" <step...@progicielsconcept.com> wrote in message news:aajgu9$1jid$1...@cti15.citenet.net...
Marcos Nogueira
I think that, besides minor technical improvements, Clipper deserves a market
re-positioning. IMHO, throwing away "depreciatory" terms like "legacy", "dbase",
"DOS", etc., and enhancing its superb qualities for non-graphical requirements,
can give Clipper a longer and brighter future (at least would help us in
convincing our customers <g>).
Best regards,
Marcos Nogueira
S. Paulo - Brazil
Mike Evans
from Xbase++ The WAA (optimized cgi using DLL's) - HRF (Html reflection Framework)-WIS- Profiler - XML support (Until know only for
reading). Even if VO have OCX capabilities it's not very well designed so they missed some thinks.
"Mike Evans" <soft...@ipirotiki.gr> wrote in message news:aajk8m$hkv$1...@usenet.otenet.gr...
Stephen Quinn
I think you'll find the VO is Brians main focus and not Clipper.
XBase++ is better at NON GUI (Console) stuff by far, you can actually still
do @x,y SAY,@x,yGET with XBase++, whereas they took that functionality out
of the Terminal library in VO2.5 (all Terminals good for as a quick & dirty
debug window, even then it isn't great<g>).
Eg
? 'Tell me what's wrong with this routine'
So if you want 32bit Console go XBase++.
If you want GUI go VO, Delphi, something else (I don't recommend XBase++ for
GUI - but others have had good usage using it for GUI) - your choice.
Personally I'm doing VO and Delphi and probably learn C# and the NET
framewok
- when the current project is out the door.
HTH
Steve Quinn
Jules Alberts
<aren...@zaz.com.br> wrote:
<snip>
>I think that, besides minor technical improvements, Clipper deserves
>a market re-positioning. IMHO, throwing away "depreciatory" terms
>like "legacy", "dbase", "DOS", etc., and enhancing its superb
>qualities for non-graphical requirements, can give Clipper a longer
>and brighter future (at least would help us in convincing our
>customers <g>).
just throwing away words wouldn't really help, but i'm sure you know
that :)
what would help? clipper is IMHO a 3gl with some OO extensions
(tbrowse, class(y)). there are some 4gl-lish commands, a SET FILTER
can do something like a SELECT statement, but it's so slow i never
bother. i just go through the lot sequential or use an index SCOPE. so
real OO and real 4GL would be a good thing.
also, a real database with triggers, referential integrity built-in
etc. would be good. i know clipper isn't limited to dbf, but it has an
xBase heritage. so couple it with advantage (which i don't know, but a
lot of people seem to like it), or some open source DB.
third, the OS level commands are all DOS based, no long filenames, no
UNC, no URI (URL).
also, make it (the db, programmaing language, interface) platform
independant, don't tie your users to dos, NT, linux, mac, make it easy
to port.
i'm afraid all this won't happen too soon, and even if it would, it
would be a new product, with it's own new bugs...
so i'm putting my money somewhere else. i'm porting our 500.000 line
main clipper app to a postgresql database with a PHP frontend. if i
run into stuff that's too difficult for PHP, i have lots of serverside
languages too choose from, like c. postgresql gives me everything i
could want from a database, PHP will allow me to quickly create
scripts which will generate my HTML, and c will do... well, anything
:)
we have thought about delphi, VB, VO, but IMHO the open source
products have so many advantages i wouldn't consider going closed
source again.
clipper has done a great job for me (and my company), but it's time to
move on...
--
Jules Alberts
Brian
Here at GrafXsoft it's a very busy and exciting time. I've received quite a
bit of interest and ideas for Clipper's future. Our intention has never
been to kill the product. We intend to continue to sell and market the 5.3
version and may even bundle some third party libs with it. If there are
enough people that are interested in a 32 bit release of Clipper I see no
reason why we would not do it. IMHO, Clipper is a viable product as it
exists in 16 bit. Bring Clipper to 32 bit would only seem like a logical
thing to do.
IMO, Clipper has never had a better home.
Regards
Pre Orders for VO 2.6
http://www.grafxsoft.com/vo26.htm
Uri V. Hnykin
Hi, Jules Alberts && All !
u> so i'm putting my money somewhere else. i'm porting our 500.000 line
u> main clipper app to a postgresql database with a PHP frontend. if i
u> run into stuff that's too difficult for PHP, i have lots of serverside
u> languages too choose from, like c. postgresql gives me everything i
u> could want from a database, PHP will allow me to quickly create
u> scripts which will generate my HTML, and c will do... well, anything
u> :)
u>
u> we have thought about delphi, VB, VO, but IMHO the open source
u> products have so many advantages i wouldn't consider going closed
u> source again.
We think you are wrong in at least two things:
1. Why can't be clipper in open source? There is at least two
clipper compatible tools in the open source already:
harbour/xharbour - is Windows oriented,
CLIP - is Unix oriented.
2. Postgres :) is not bad thing, but CLIP is much faster in
terminal/server model, comparing with PHP+Postgres's client/server.
Why rewrite 500000 lines of sources? There is less lines in clipper
itself. Would not be better to waste your time for testing
and developing above tools (harbour/xharbour/CLIP)?
u> clipper has done a great job for me (and my company), but it's time to
u> move on...
Not all of old clipper-heads are thinking like you. Long live to Clipper!
u> --
u> Jules Alberts
CLIP team.
Frank van Nuffel
>What do you think?
>Saulo
Hi believers,
Here's the wish list's addition of just some other believer:
1 open up Clipper's OOP subsystem
enable subclassing, but while doing, fix a little in the existing
classes;
1.a following Anton's model, also allow casting of subclass'
scope operations; allow multiple inheritance, allow the
creation of static classes (ie. classes only enumerating
class members and methods (static elements in C++
terms)), allow classing of the built-in types, rebuild Clipper
in such a way that it can be used entirely in an OOP way,
as well as downward compatibly supporting the old ways
(Clipper then could do better than FlagShip in such)
1.b provide the source code for the existing classes
1.c systematically provide Hungarian notation for all members
of the existing classes (simply using VAR ... IS ... and
METHOD ... IS .. additions to the existing class declarations);
for downward compatibility reasons with existing code which
relies on many non-Hungarian notated VAR names, the existing
names can continue to appear parallel with the new names; one could
even consider an experiment in which Hungarian notation
becomes applied to all functions/methods too, parallel with the
standard names (for instance provide a #pragma Map ... directive
ala xBase++)
2 provide the event model integrated in the core functionality
3 enhance the performance of the graphical interface
4 support for a real DBMS platform ala objectDB (including transactioning)
5 client/server RDD delivered standard (from one of the players currently
available)
6 support for hypertext
7 last but not least: Brian, please provide a pre-Orders page for Clipper
(i would jump to it immediately)
Sail safe home, you Clipper!
Frank
Frank van Nuffel
break the preprocessor's limit of using only base memory,
making it using up available extended mem
this is definitely a wish list on the long run; maybe, i'm too
enthusiastic; sorry for that;-)
F.
Stephan St-Denis
Don't forget unlimited number of array elements... unlimited string
length... long file names... and so on...
Stephan St-Denis
"Frank van Nuffel" <f_...@pi.be> a écrit dans le message de news:
aak2am$prm$1...@reader10.wxs.nl...
Frank van Nuffel
John
The need to update an old application make me study and learn Clipper in the
last 6 months.
My feeling about it was something "nostalgic" that a so powerfull language was
left on the side by it's own developper. The presence of a few group that
where working to offer xBase a real futur was altough reconforting.
But now that GraphXsoft is taking Clipper and VO for a trip is a REAL JOY !!!
: )
I feel like i will be "up to date" soon.
Clipper can now grow to a new level, and i will participate actively.
It's very good news for everybody in the field.
(QUESTION)
Can it be a good idea to merge Clipper and VO in a new package that will get
as much of the power of both with the least of their weakness?
(We will soon be in a 64bits world)
I think that most of the programmer are ready to learn a few new "tricks" if
the results worth the efforts.
John
Patrick Mast
> Can I use Apollo with Xbase++ do you know
I don't know, but I started a Apollo connection to harbour. See
http://www.Harbour-Project.org. The source code for the Apollo connection is
in the Contrib dir.
--
Regards,
Patrick Mast
http://www.PatrickMast.com
http://www.FiveWin.info
http://www.Harbour-Project.org
Patrick Mast
> Don't forget unlimited number of array elements... unlimited string
> length... long file names... and so on...
Hey guys, all that's on your wishlist is already in Harbour!! Not? ;-))
Ray Marron
news:Snhz8.46219$Ze....@afrodite.telenet-ops.be...
> Frank,
>
> > Don't forget unlimited number of array elements... unlimited string
> > length... long file names... and so on...
> Hey guys, all that's on your wishlist is already in Harbour!! Not? ;-))
Everything except all the RDD choices that Clipper is famous for. How many
RDDs does Harbour fully support now?
--
Ray Marron
Massimo Belgrano
Massimo Belgrano
Why double the effor for made the clipper future?
I love clipper and i am using Xbase and either products are great.
With Cooperation you and alaska can made a more better product.
With Xbase++ & VO & Clipper (& Flagship) Fusion you can made a very good
product
You sell it in America and Alaska in Europe and africa
One Bussines is More bussines.
Sorry for my very bad enghish?
Do you know eXPress++ from Donnay? it is a gold product!
"Brian" <sa...@grafxsoft.com> ha scritto nel messaggio
news:9Cez8.67897$EK.44...@e3500-atl1.usenetserver.com...
Marcos Nogueira
>
> IMO, Clipper has never had a better home.
More good news. Do you plan to open a "Clipper suggestion" email like you've
done for VO?
Clifford Wiernik
patches to each version with the next version comes basically every 5 months or
so. That is no different than Microsoft and most others. Try accounting
software, pay 15% support each year and don't get any patches without a support
contract for the most part. Some are only fixed on the next release. Many
xbase++ users have major software in use with the package. I remember the same
problems with Clipper. I can't remember which version, winter 85 or so that
had major, unusable problems with indexes that took several months to fix.
Clipper 5.0 and 5.01 were basically useless for applications with a larger
number of private variables. Did not get really fixed until the 5.2e version.
(random overwriting of internal memory holding the file table area).
Cliff Wiernik.
Al Acker
>>Do you plan a partnership with xbase++?
I think Brian is laughing too hard to even attempt to answer that question.
Al
--
Al Acker, President, Editor
Acker Consulting Inc.
http://www.ackerconsulting.com
The Xbasefiles e-zine
http://www.thexbasefiles.com
Al Acker
>>
After a lot of testings and different language's that i have test these is
mine conclusion.
1. By far the best gui it's Delphi Gui (Classes - IDE )
2. The second one for me is the VB
3. The third one is DB2k
3. The third one is VO ( by far worst than Delphi )
4. Alaska Xbase++ is the worst from the above languages on the Gui level
until know.
>>
I agree with the above...but if you like Delphi's IDE and don't like the
language, you should try C++ Builder... same IDE, same Classes but much
better language. ( IMO C is much more "Clipper like" than Pascal ).
Pritpal Bedi
> Here at GrafXsoft it's a very busy and exciting time. I've received quite a
> bit of interest and ideas for Clipper's future. Our intention has never
> been to kill the product. We intend to continue to sell and market the 5.3
> version and may even bundle some third party libs with it. If there are
> enough people that are interested in a 32 bit release of Clipper I see no
> reason why we would not do it. IMHO, Clipper is a viable product as it
> exists in 16 bit. Bring Clipper to 32 bit would only seem like a logical
> thing to do.
>
> IMO, Clipper has never had a better home.
I am thrilled to here it!
Now I hope I will be able to execute all my ActiveX stuff from within
Clipper than via different route.
Pritpal Bedi, India
A Student of Software Analysis & Design
.
Vouch, the software that grows with you
.
http://www.vouchcac.com
mailto:vouc...@hotmail.com
Rene Pilon
that Clipper would have to be completely rewritten in order to make it
32bits - I suddenly wondered - isn't the core of VO (without the gui
framework) really 32bit Clipper???
Heck - they still have the Error 5333 with VO - this leads me to believe
that the core to VO is obviously Clipper re-written in 32bits.
This leads me to believe that if a lot of the VO front end was removed from
VO - you would probably be left with a 32bit Clipper - and this includes the
RDD functionality.
Correct me if I'm wrong in my line of thinking - maybe I'm missing something
here....
Stephen Quinn
VO doesn't have a GET system, it doesn't have a TBrowse (The current browser
requires a GUI).
> Heck - they still have the Error 5333 with VO
Used to be a Error 4660 before that.
> - this leads me to believe
> that the core to VO is obviously Clipper re-written in 32bits.
Well that's what it was 'supposed' to be<g>
> This leads me to believe that if a lot of the VO front end was removed
from
> VO - you would probably be left with a 32bit Clipper - and this includes
the
> RDD functionality.
What would you expect to see on screen if you took away the front end.
Do you want to hand code windows, I did that with XBase and didn't like
it<g>
The VO Terminal/Console window has very little (none IMO) going for it if
you want to develop Windows apps, if you want console apps then XBase++ is
better.
HTH
Steve Quinn
Klas Engwall
>With Xbase++ & VO & Clipper (& Flagship) Fusion you can made a very good
>product
>You sell it in America and Alaska in Europe and africa
>One Bussines is More bussines.
Competition is the mother of innovation and progress, monopoly is the
mother of stagnation and decline. To create one big monopoly on each
side of the Atlantic is a very strange idea indeed, Massimo.
Klas
-------
klas dot engwall at engwall dot com
Spammers, please use this address :-) mailto:postmaster@[127.0.0.1]
Klas Engwall
>Here at GrafXsoft it's a very busy and exciting time. I've received quite a
>bit of interest and ideas for Clipper's future.
This is IMO the happiest moment in many years for the Clipper
community. Congratulations and best wishes to you and your team.
>If there are
>enough people that are interested in a 32 bit release of Clipper I see no
>reason why we would not do it. IMHO, Clipper is a viable product as it
>exists in 16 bit. Bring Clipper to 32 bit would only seem like a logical
>thing to do.
Other people have been building castles elsewhere in this thread. My
wishes are quite modest. Being able to let my old Clipper applications
access the Win32 API is really all I want. As a first step, anyway ...
And a 32 bit Clipper version would also give us a chance to test the
hypothesis that has been flying around the Xbase++ community for
years: "Going to 32 bits is the reason for things being so slow". <G>
> IMO, Clipper has never had a better home.
Well, that's kind of obvious, isn't it? <G>
Ted Koby
1. Long file names
2. 4 GB file sizes (can I get that with 32 bit OS, or is it a 2 GB DOS
limit?)
3. More columns in a tbrowse.
4. Be able to use Visual FoxPro dbfs.
5. COPY TO or APPEND FROM tab delimited files (or better yet, specify
the delimiter). Along those lines, also be able to specify the field
text delimiter and to specify the end of record delimter (chr(13)
and/or chr(10)).
6. For COPY TO and APPEND FROM, an EVAL and EVERY similar to INDEX ON.
7. Larger array limit.
8. An ISALPHA and ISDIGIT like the AT/RAT function.
Thanks for the thread Saulo and TIA Brian.
Al Acker
The VO Terminal/Console window has very little (none IMO) going for it if
you want to develop Windows apps, if you want console apps then XBase++ is
better
>>
As long as you don't have to access data! <G>. VO's data access speed is
much much better than Xbase++.
Jules Alberts
<snip>
> We think you are wrong in at least two things: 1. Why can't be
> clipper in open source? There is at least two clipper compatible
> tools in the open source already: harbour/xharbour - is Windows
> oriented, CLIP - is Unix oriented.
true, but opens source isn't the only reason i'm migrating
> 2. Postgres :) is not bad thing, but CLIP is much faster in
> terminal/server model, comparing with PHP+Postgres's client/server.
>
> Why rewrite 500000 lines of sources? There is less lines in clipper
> itself. Would not be better to waste your time for testing and
> developing above tools (harbour/xharbour/CLIP)?
well, i expect the new app to be a lot smaller while having the same
functionality or more. things like network programming, referential
integrity, triggers & constraints, sending email, making agenda's,
converting to PDF are all available for the postgresql / PHP platform.
also the postgresql and the PHP community are pretty big, there's
loads of documentation, loads of informal support (usenet etc.) and i
don't have to worry about not having a certain functionality when i
should need it.
in clipper i had to do a lot myself, i started this app in 1995, there
wasn't so much communication (like this group) or publicly available
libs as there are now. correct me if i'm wrong, but AFAIK there wasn't
very much...
> u> clipper has done a great job for me (and my company), but it's
> time to u> move on...
>
> Not all of old clipper-heads are thinking like you. Long live to
> Clipper!
well, count me in as a clipper-head, and please don't get me wrong, i
like clipper a lot. but IMHO it's not the best choice for the core
system of a whole company. not for my company anyway.
--
Jules Alberts
Stephen Quinn
> 2. 4 GB file sizes (can I get that with 32 bit OS, or is it a 2 GB DOS
limit?)
2G - 16 bit DOS limit
4G - 32 bit OS limit
--------------------------------
> 3. More columns in a tbrowse.
How many are you talking about??
There's code on the OASIS that'll allow you to have lots of columns.
If it doesn't fit on the screen what's the use of it<g>, I use a hot key to
swap columns showing similar data
eg
CostPrice
ListPrice
TradePrice
F8 - cycles the above 3 columns
--------------------------------
> 5. COPY TO or APPEND FROM tab delimited files (or better yet, specify
> the delimiter). Along those lines, also be able to specify the field
> text delimiter and to specify the end of record delimter (chr(13)
> and/or chr(10)).
> 6. For COPY TO and APPEND FROM, an EVAL and EVERY similar to INDEX ON.
> 8. An ISALPHA and ISDIGIT like the AT/RAT function.
You can write these now yourself - no need to wait for any update.
HTH
Steve Quinn
siowin1
It is time to tell my Clients Clipper never died, not even 2000 (Y2K) Year
2002 may be year 4000 ha,ha,ha
32.Bit Clipper should be able upgrade to 64.Bit in the future simple....
At the moment, can some one point out basic requirements of 32.Bit based...¿
e.Commence...?
Anthony Chua
"Saulo" <sa...@password.info> wrote in message
news:69456e0b.02042...@posting.google.com...
Karl Nitschke
And you'll also rewrite Comix? And convince the Blinker people to
rework their linker? And convince ADS? And what about all the
dead-third party products we need? E.g., Clip4Win & FiveWin, etc?
Doesn't even seem remotely plausible to me.
I hate VO. Always have.
But why duplicate effort?
If a VO 3.0 came out and it had greater Clipper compatibility, e.g.,
could run from the command-line like Clipper or Harbour, had a feature
that used the original Clipper PP, etc., that could kill several birds
with one stone. Would even get a lot of VO haters, like me, to take
the product seriously again.
At least the third-party stuff we need would be available to some
degree in VO equivalents.
Karl
Ted Koby
Thanks for info/comments.
On the tbrowse, I'm being lazy. I get master files (they are all
different structures, non-dbf sources, and one time jobs) with
hundreds of fields per record and I do analysis and data verification.
Your comments have inspired me to use the stuff between my ears.
I forgot to mention that speed is very important. Clipper has been a
perfect balance between language robustness and speed. I tried
Xbase++ and it was too slow on large files. I was hoping the items on
the wish list would be implemented in assembly (assembler?) language,
for speed.
Where can I find the solutions to item 5:
>> 5. COPY TO or APPEND FROM tab delimited files (or better yet, specify
>> the delimiter). Along those lines, also be able to specify the field
>> text delimiter and to specify the end of record delimter (chr(13)
>> and/or chr(10)).
TIA,
Ted
Goran Stojanov
Karl Nitschke wrote:
> Brian,
>
> If a VO 3.0 came out and it had greater Clipper compatibility, e.g.,
> could run from the command-line like Clipper or Harbour, had a feature
> that used the original Clipper PP, etc., that could kill several birds
> with one stone. Would even get a lot of VO haters, like me, to take
> the product seriously again.
This is an excelent idea. I strongly support this and I think that it
shouldn't be too dificult. You already have cavocomp.dll (the compiler),
cavopp.dll (the preprocessor). Just make small exe files that will call
them cavocomp.exe and cavopp.exe. Then we are not bound to use the
repository, while we can still use the classes. Not everyone prefers using
resources. Dynamic creation of objects gives you much bigger flexibility.
And if you open up the compiler and pre-processor, you'll have them both.
Think about this twice.
Goran
Eduardo Horbino
Cheers
"Ted Koby" <sigm...@yahoo.com> wrote in message
news:3ccf470a...@news.la.sbcglobal.net...
Stephen Quinn
> Where can I find the solutions to item 5:
>
> >> 5. COPY TO or APPEND FROM tab delimited files (or better yet, specify
> >> the delimiter). Along those lines, also be able to specify the field
> >> text delimiter and to specify the end of record delimter (chr(13)
> >> and/or chr(10)).
FOpen()/FWrite()/FClose()
// Create new constants that call your functions
#COMMAND COPY etc....
#COMMAND APPEND etc....
HTH
Steve Quinn
Victor K
Would be nice to have in 32-Bit edition or VO (I purchased VO 2.0 from CA
long time ago, tried to use, you know what happened) way to convert program
to 100% web use. ASP or PHP, etc. Browse in Clipper so powerful, even
Microsoft tried to make something look like in ASP.NET. Everybody agree that
browse is hearth of clipper. So if any way to make conversion between VO
code and web code would be nice. One of good ideas has company Luxent some
time ago with eBizweb software. I have even my special ec-designer written
in pure clipper generating asp code, but some features still missing. No
time. So in my opinion - two things very important today - browse & web. If
new owners will look somehow in this, they got my support.
15 years with clipper, still heavy developer.
Regards, Victor
Phil Barnett
> in clipper i had to do a lot myself, i started this app in 1995, there
> wasn't so much communication (like this group) or publicly available
> libs as there are now. correct me if i'm wrong, but AFAIK there wasn't
> very much...
Actually, this group was really ramping up around then, much larger than
now, and FIDO was trailing down.
Compuserve always had big action then.
--
Phil Barnett mailto:midnight @ the-oasis.net
Oasis WWW http://www.the-oasis.net
FTP Site ftp://ftp.the-oasis.net
Clipper FAQ http://www.the-oasis.net/clipper.html
Harbour Project http://www.Harbour-Project.org
Phil Barnett
http://www.the-oasis.net/files/utils/flatconv.zip
and
http://www.the-oasis.net/files/utils/data_doc.zip
Data_doc reads the .DBF and creates an import template, flatconv runs it.
You can create input and output templates, and you can customize the
template after it's created.
flatconv will automatically detect eol markers of crlf and lf and strip
them properly.
Karl Nitschke
> you should try C++ Builder...
Ah, I remember you pushing FiveWin really hard in the old days. Then
suddenly you hated it.
Then you pushed XBase++ really hard. And then suddenly you hated that
too.
Now you're recommending "C" for business software developers?
Dear oh dear!
Next you'll be recommending that we all smoke crack before starting
our programming sessions! <G>
Karl
Al Acker
Back in the 80's FiveWin was the best way to move Clipper apps to Windows.
Then Antonio's support went down hill... at the same time that happened...
the guys from Germany started working on Xbase++.... it started out looking
like the best thing since sliced bread... well after a time, it was obvious
that they couldn't fix the performance bugs and their attitude left lots to
be desired. I left a good paying job because I didn't agree with the way
the company was being run and I lost confidence in their technical and
business abilities ( and I wasn't afraid to tell Alaska exactly what I
thought <GGG> ).
You forgot to mention dB2K which I spent a few years with doing some very
large applications.. we made them work and they worked well...but IMO, it
took way more effort than they were worth. ( We still do some dBASE apps
and help developers with it.. it's an ok platform but it does have a few
walls you have to work around ).
Well after all the work, all the headaches, I've gone to C++ cause I'm too
tired and too old to be running into walls with small companies that lack
the horsepower to keep up in this day of age where MS pops out a new OS or
major patch every other month <G>.
I guess I differ from some other programmers.... if a product doesn't do
exactly what I need or has bugs that stay around for ever without getting
fixed... I'm not afraid to change directions and go to something better.
So far, I'm very happy with C++ Builder. And my clients don't have to put
up with some of the problems and performance limitations of other products.
Back in the old Clipper / FiveWin days, I would never have thought of going
to C because of the added time involved in producing apps. But now with OOP
and the new Delphi / C++ Builder class IDEs, coding in C++ is just as fast
as anything else out there and the performance is a quantum amount better.
Bottom line, I'm willing and able to change directions... some people lack
the confidence, ability and guts to make a change..
I'm not one of them.
Dave Pearson
> Back in the 80's FiveWin was the best way to move Clipper apps to Windows.
FiveWin existed in the 80s?
--
Dave Pearson | OSLib - Timeslice release functions.
http://www.davep.org/ | eg - Norton Guide reader for Linux.
http://www.davep.org/clipper/ | weg - Norton Guide reader for Windows.
http://www.davep.org/norton-guides/ | dgscan - DGROUP scanner for Clipper.
Al Acker
I could be wrong but yes I have a 5 1/4 disk of a very early version...
I'm thinking it was around '89 ???... but like I said I could be wrong....
at least it _feels_ that it was that long ago < G >.
Ted Koby
I'll do some homework.
Ted
Lorenzo Fiorini
> I'll do some homework.
In Harbour dbdelim and dbsdf are written in Harbour itself. The same
is for debugger, report, label, memo* and many other parts.
You could join the Harbour crew and your "homework" could become the
Harbour command 'COPY TO/APPEND FROM ... DELIMITED WITH "'" SEPARATED
WITH ";" ENDED BY chr(10)' or whatever you want. At the same time
other Clipper developers could contribute their "homeworks" in other
areas.
OpenSource is not different from what we have always done. The only
difference it that the "building tools" part of our work can be shared
with others. Even more they will help you to debug and test your tools
saving your time and your customers to some bugs.
Clipper 32bit is already here is free is multiplatform is called
Harbour and is waiting for you. Look at www.harbour-project.org.
Regards.
Lorenzo Fiorini
Dave Pearson
> I could be wrong but yes I have a 5 1/4 disk of a very early version...
> I'm thinking it was around '89 ???... but like I said I could be wrong....
That would have it pre-dating Windows 3.0 and Clipper 5.0. I didn't think it
started out on S87 with Windows 2.0 as a target.
Al Acker
name now..) I think that worked with Windows 2. But I do know the first
version of FiveWin was very early and not well known. I had been using FW
for a long time when to my surprise I found a very old disk packed away that
I had picked up at a conference and had never looked at <G>.
Dave Pearson
> Could be I'm thinking of the product Greg Yellick did ( can't remember the
> name now..) I think that worked with Windows 2.
Greg Yellick? Perhaps you mean Craig Yellick? In that case perhaps you're
thinking of Dolce Vita? I hadn't realised that it had a Windows 2/S87
incarnation.
> But I do know the first
> version of FiveWin was very early and not well known. I had been using FW
> for a long time when to my surprise I found a very old disk packed away
> that I had picked up at a conference and had never looked at <G>.
I've got a vague recollection that FiveWin first turned up some time around
1992 or 1993. I do remember it turning up, in a demo form, on various BBS
systems in the UK.
Al Acker
>>
Perhaps you mean Craig Yellick? In that case perhaps you're
thinking of Dolce Vita? I hadn't realised that it had a Windows 2/S87
incarnation
>>
Not sure exactly when but it was pre-FiveWin <G>.
Ted Koby
Massimo Belgrano
120.000.000/100.000
"Klas Engwall" <klas.e...@nospam.please> ha scritto nel messaggio
news:3ccf4aa3...@nntpserver.swip.net...
> >With Cooperation you and alaska can made a more better product.
> >With Xbase++ & VO & Clipper (& Flagship) Fusion you can made a very good
> >product
> >You sell it in America and Alaska in Europe and africa
> >One Bussines is More bussines.
>
> Competition is the mother of innovation and progress, monopoly is the
> mother of stagnation and decline. To create one big monopoly on each
> side of the Atlantic is a very strange idea indeed, Massimo.
Klas Engwall
>120.000.000/100.000
And the point is ...?
Al Acker
VO is to VB like Xbase++ is to VO <GGG>.
siowin1
Suppose to be 31.Mar.2002 ....
Diana
Care about Xbase since 1998 (water, sleep, sun, music, air...)
"Saulo" <sa...@password.info> wrote in message
news:69456e0b.02042...@posting.google.com...
valusoft
wrote:
>Is the delay of Xbase++1.80 relate to this subject ?
>
>Suppose to be 31.Mar.2002 ....
>
>Diana
>
>Care about Xbase since 1998 (water, sleep, sun, music, air...)
>
>
Diana,
Your question would be best answered by the people at Alaska...who
almost never come to this newsgroup.
Regards,
Ross McKenzie
ValuSoft
Melbourne Australia
Karl Nitschke
> Back in the 80's FiveWin was the best way to move Clipper apps to Windows.
Yep, and back in the 60's "C" was the best way to move versus
assembler or Fortran. Syntax is still just as clunky, though, and none
of its main problems have been fixed in the 30+ years it's been
around. (OK, unless you want to argue that C# == C+++ ?)
> Bottom line, I'm willing and able to change directions... some people lack
> the confidence, ability and guts to make a change..
I changed directions from C 20 years ago and still wouldn't go back.
All the major development environments have the good things you
mention, without having to deal with the C language.
But I agree with you totally. You need an over abundance of
confidence, incredible ability and tremendous guts to do business
application development work in C. Good luck to you. ;-)
Karl
Karl Nitschke
> I strongly support this and I think that it
> shouldn't be too dificult. You already have cavocomp.dll (the compiler),
> cavopp.dll (the preprocessor). Just make small exe files that will call
> them cavocomp.exe and cavopp.exe. Then we are not bound to use the
> repository, while we can still use the classes. Not everyone prefers using
> resources. Dynamic creation of objects gives you much bigger flexibility.
> And if you open up the compiler and pre-processor, you'll have them both.
> Think about this twice.
Nothing in programming is easy, but it strikes me as remotely viable,
versus the utterly ludicrous notion that a Clipper-32 would be a
viable project.
Who (in their right mind) would spend money on a closed source version
of Clipper when Harbour and XHarbour are available for FREE and DO
MORE ?
Who would want to spend months or years waiting for bug fixes, when
they can be addressed more quickly by open source editions?
The only thing going for a Clipper-32 would be the fact that it would
"supposedly" be more stable than Harbour. But that's a myth. You'd
have to not only recompile the source code but rewrite all the memory
management functionality, etc. All kinds of low level stuff would have
to be recreated. A Clipper-32 would not automatically be as stable as
the existing Clipper.
Much better to offer a more "Clipperish" way of doing things under VO.
One development team. One development project. Less risk. More chance
of something coming out on the market before 2010.
Karl
Al Acker
If that's what you think about C you haven't looked at it for 20 years
<G>. The C++ Builder classes make C a snap... if you're half the programmer
I think you are... you'd be surprised.
John
Have a look at www.ClipX.net, about HTML and CGI in pure Clipper...
I will soon try it, it's looking very interesting.
John
Massimo Belgrano
cooperation must Be important for all Xbase languages
"Al Acker" <a...@thexbasefiles.com> ha scritto nel messaggio
news:t6EA8.52193$ao1.9718@rwcrnsc54...
Karl Nitschke
> If that's what you think about C you haven't looked at it for 20 years
> <G>. The C++ Builder classes make C a snap...
There are good classes around for most languages these days. And
plug-in ActiveX controls, etc., that do a lot of the grunt work. But
how does that make any particular programming language easy? After
you've done all that you've still got to sit down and cut code. Why
the hell do I want to spend 2 days hunting down an obscure GPF caused
by doing something stupid like using an INT instead of a LONG or a
LONG instead of a FLOAT? Or mess around with allocating and
deallocating memory and all that other nonsense. You're moving
*against* where the entire industry is moving. C is sometimes the best
(or only) language to do certain tasks, but I think if you asked 100
programmers, all but the C bigots/fanatics would agree that it's a
lousy language for high level work. Always has been, always will be.
It's even silly to be debating this topic in the 21st century.
Karl
Neil
devel...@capitaloffice.com.au says...
> C is sometimes the best
> (or only) language to do certain tasks, but I think if you asked 100
> programmers, all but the C bigots/fanatics would agree that it's a
> lousy language for high level work. Always has been, always will be.
> It's even silly to be debating this topic in the 21st century.
You're writing as though there's no difference between C and C++.
Are you saying that anyone using Borland C++ Builder for application
development has made the wrong choice? Have you ever actually USED C++
Builder? I'm asking because it's not really much different from working
with Delphi, and I wonder if now you're also willing to tar Delphi with
that same brush?
Richard Bos
> In article <a7bb84b0.02050...@posting.google.com>,
> devel...@capitaloffice.com.au says...
>
> > C is sometimes the best
> > (or only) language to do certain tasks, but I think if you asked 100
> > programmers, all but the C bigots/fanatics would agree that it's a
> > lousy language for high level work. Always has been, always will be.
> > It's even silly to be debating this topic in the 21st century.
>
> You're writing as though there's no difference between C and C++.
No, he's writing that as if he knows bugger-all about proper C
programming. C can easily be used for high level work, provided you know
how to program.
Richard
Al Acker
Now I _know_ you haven't used a C product in 20 years < G >.
Al Acker
>>Have you ever actually USED C++ Builder?
It's pretty obvious he's never used C++ Builder or he wouldn't be saying
what he's saying <GGG>.
You're 100 percent correct, I find C++ Builder as easy ( easier for me <g>)
to use as Delphi. It's people like Karl that scare people away from trying
something new.
Klas Engwall
Better than what? Better than Clipper? Better than VO? Better than
everyone else?
>cooperation must Be important for all Xbase languages
Why would that be important? What are you hoping to gain? Market
strength by elimininating the competition? A technological "advantage"
by creating a patchwork of diverging technologies from all the
different xBase flavors melted down in one big pot? There is no way a
mess like that would be beneficial to anyone.
When you create that Super-Clipper of your dreams, all but one in your
so called "cooperation" would have to go the same way Wordtech went
years ago - some bits and pieces saved and the rest flushed down the
toilet. Since you say that Xbase++ is better I can only assume that
you want Alaska to take over the others (and that is also what you
suggested last year, at least regarding Clipper and VO).
That, in turn, leads to the question why you would want to kill
Clipper. And kill VO. And kill Flagship (which was on your
"cooperation" list last week). And kill all the other xBase flavors
too (since they are now also on your list).
It is pretty clear who would be the losers if your dream were to come
true. But who would be the winner? Probably Microsoft.
Karl Nitschke
> You're 100 percent correct, I find C++ Builder as easy ( easier for me <g>)
> to use as Delphi. It's people like Karl that scare people away from trying
> something new.
Nonesense, I've always advocated the best tool for the job. If I had
to glue Excel, Access and Word together, I'd use Visual Basic. If I
had to write a fax server application I'd probably use Delphi. If I
had to write something net specific Java would be the best choice. If
I had to write programming libraries, compilers or other lower level
stuff, than C++ is obviously a good choice. For business applications,
Xbase style languages are still excellent tools. But there are also
exceptions to every rule. If you were doing something in SQL Server
and the site was very Microsoft application & tool orientated, then
maybe Access would be a better choice than Xbase, and so on...
That's the "ideal" scenario, anyway. What happens in reality is
developers tend to try to force their existing tools to do all kinds
of things they were not intended for or are only superficially good
at. If I wanted someone to write me a reasonably complex business app
and the developer recommended C++ I'd consider the guy to be an
irresponsible cowboy.
Now, take something like the harbour project. They are virtually all C
programmers working on that. Why *bother* if C is so wonderful?
Clearly, a lot of C programmers don't think so, and I'm sure those
guys aren't idiots.
Karl
Al Acker
I think I'm typically lazy when it comes to programming.... IE I use the
best fit I can to get the job done. I can write in a lot of languages and
I'm not afraid of learning something new when it has it's advantages. Do
you honestly think I'd be using a tool that takes longer if I could use
another tool that was faster to code and performed up to my needs?
What you describe is C code of about 10 to 15 years ago. C++ with all the
classes available and the modern IDEs are just as fast to code in as _any_
xbase language and with the Borland Delphi/CBuilder IDEs makes putting
business apps together quicker than any Xbase product out there.
If you haven't used Delphi or CBuilder to put together an entire app, then
you're not qualified to make any statements about them. ( And by your
statements here.... it's pretty obvious you haven't ).
Karl Nitschke
> development has made the wrong choice? Have you ever actually USED C++
> Builder? I'm asking because it's not really much different from working
> with Delphi, and I wonder if now you're also willing to tar Delphi with
> that same brush?
For various reasons we've had to use Delphi in our own project work.
Some of the third-party developers who have written "plug-ins" for our
software also use Delphi. In a lot of respects Delphi sucks too, but
horses for courses. For lots of jobs it's probably the best tool
available at present. Unfortunately, it is still way too easy for
Delphi to GPF, and often it is not the fault of the Delphi programmer
that it happens. (Let's not even worry about C.) And those problems
are for most practical purposes impossible to diagnose cost
effectively when you are off site. Again, I'm not saying anything that
isn't obvious or self-evident.
Yes, there are lots "I am a great programmer" types who are convinced
they can write C/C++/assembler, etc., apps that are just as cost
effective or as safe, as high level languages. Well, the bottom line
is that's hogwash. And of course, when you tell these "great
programmers" the obvious, you're stepping on their toes and they are
going to be rather sensitive about that.
I was watching a TV show a few weeks ago about stuntmen and one of the
guys there made a point that serves as a brilliant metaphor for
creating reliable software. He pointed out that the stuff stuntmen do
has got to look as dangerous as possible, but really be as safe as
possible. If there is only a 1% risk of death, well that would mean
that after 100 jobs (on average) every stuntman would be dead. So
obviously, the stunts have got to be a *lot* safer than that. Everyone
should apply that principle to programming. No matter how good you
*think* you are, I've never seen a programmer not make mistakes. (And
not cost my company time and money.) Big, complex C or C++ apps with
obscure bugs can destroy your reputation and your business. Why take
those risks when, in this day and age, there is no need to.
Karl
Al Acker
Well, I'll tell you what.... I'll just have to take my chances with C++
Builder and run the risk of killing my reputation and business. And you
stay with your rock solid xbase program. < G >
Karl Nitschke
The C language hasn't changed in nearly 40 years Al. And C++ is a bit
of a gludge as well.
I see you swept over all the points I've raised and simply decided the
easiest solution was to attack my ability as a programmer. That's
fine. None of this is very important in the grand scheme of things.
My father had postrate cancer recently, and some of the absolutely
stupid, terrible and conflicting advice he got from another bunch of
experts ("doctors") was far more scary (and potentially serious) than
arguing about whether C is or isn't the right tool for building
business apps. (It was funny how all these "experts" were convinced
that the procedures they were trained in were better than everyone
else's, but how could they all be right?)
The most harm you could do is cost a business some time and money (one
hopes). And the bottom line is I'd rather use a program written by a
brilliant C programmer than a program written by an xbase dummy!
Karl
Dave Pearson
> > Now I _know_ you haven't used a C product in 20 years < G >.
>
> The C language hasn't changed in nearly 40 years Al. [SNIP]
I think you'll find that it has, more than once.
Richard Bos
> Big, complex C or C++ apps with
> obscure bugs can destroy your reputation and your business. Why take
> those risks when, in this day and age, there is no need to.
I shouldn't even be trying to debunk this kind of obvious outhouse
stuffing, but just one question: WTF do you think your great, safe,
reliable languages are implemented in? I'll tell you: 90% of the time,
it's C or maybe C++. SO most of the time, your "reliable" languages are
no more reliable than these "dangerous" C implementations, and often
less so.
Richard
Richard Bos
> > Now I _know_ you haven't used a C product in 20 years < G >.
>
> The C language hasn't changed in nearly 40 years Al.
*Splutter* And when, pray, do you think C was designed?
And when do you think the 1989 ISO C Standard was written?
And when, ditto, for the 1999 ISO C Standard?
Richard
Dave Pearson
> Who (in their right mind) would spend money on a closed source version of
> Clipper when Harbour and XHarbour are available for FREE and DO MORE ?
One possibility: People who want someone to blame if/when it all goes wrong.
Dave Pearson
> [SNIP] No matter how good you
> *think* you are, I've never seen a programmer not make mistakes. (And
> not cost my company time and money.) Big, complex C or C++ apps with
> obscure bugs can destroy your reputation and your business. Why take
> those risks when, in this day and age, there is no need to.
Hmm.
,----[ <a7bb84b0.02050...@posting.google.com> ]
| Now, take something like the harbour project. They are virtually all C
| programmers working on that. Why *bother* if C is so wonderful? Clearly, a
| lot of C programmers don't think so, and I'm sure those guys aren't
| idiots.
`----
I think it's fair to say that harbour is a "complex C or C++ app". Indeed,
it's probably a lot more complex than most "business applications" because
it is designed and intended to be used in ways that most of the developers
can't imagine, such is the nature of a "higher level language".
It's a rare language implementation that doesn't have bugs. Clipper
programmers, for example, know that better than most.
But, that aside, I don't buy the idea that, because programmers are
fallible, they should use "higher level languages". There are terrible
programmers out there, that's a given. Arguably, "higher level languages"
let terrible programmers program for a lot longer before they're found out.
By your reasoning we should all take the "macho approach" to programming so
that we can weed out all the really terrible programmers who destroy the
reputation of the industry.
So, I think that's sorted, the next time someone suggests a solution that
*isn't* developed in C or C++ you should wonder what sort of cowboy he is
and what he's got to hide, he could be out to destroy the reputation of your
business.
. o O ( If your neighbour hasn't typed malloc() or `new' today, ask )
( yourself, what's he hiding? Report him now before he destroys our )
( industry. )
--
Harbour is a free | Harbour Web Site: http://www.harbour-project.org/
software, cross | Harbour FAQ.....: http://www.harbour-project.org/faq/
platform, Clipper | My Harbour Pages: http://www.davep.org/harbour/
compatible compiler | My Harbour News.: http://www.davep.org/harbour/news/
Dave Pearson
> That's the "ideal" scenario, anyway. What happens in reality is developers
> tend to try to force their existing tools to do all kinds of things they
> were not intended for or are only superficially good at.
Even "ideal" programmers are pragmatists at times.
> If I wanted
> someone to write me a reasonably complex business app and the developer
> recommended C++ I'd consider the guy to be an irresponsible cowboy.
That would seem to make you as big a cowboy as you'd think he is. Hopefully,
in reality, you'd actually find out *why* he recommended C++ and evaluate
his abilities and the suitability of his proposal based on the reasons.
Hint: there might be a startlingly good reason why he wants to develop your
"reasonably complex business app" in (some specific implementation of?) C++.
Wouldn't it be a good idea to find out?
> Now, take something like the harbour project. They are virtually all C
> programmers working on that. Why *bother* if C is so wonderful? Clearly, a
> lot of C programmers don't think so, and I'm sure those guys aren't
> idiots.
You seem to be saying: "Some C programmers use C to implement other
languages, therefore a lot of C programmers don't think that C is
wonderful". I don't think that's a very sound argument given that the number
of C programmers who implement other languages in C are very probably in the
minority.
Moishe Mordkovych
> ::enough people that are interested in a 32 bit release of Clipper I see no
> ::reason why we would not do it.
I am interested.
MM
Edward J Barr
<a...@thexbasefiles.com> writes
Appropriate language for appropriate jobs. I started out in C (learend on a
networkink course), then tought myself Clipper because the money looked good at
the time. When I realised that we definitly had to go to Windows for some things
I looked at Delphi, Visual Basic and Powerbuilder. VB was a joke, unstable and
with lousy database access, Delphi seemed a fantasic general purpose windows
language but in those days its database access seemed slow, Powerbuilder seemed
a nightmare in some ways but the datawindow sold me on it and the datbase access
was the best of the lot. So I chose Powerbuilder. The strange thing is that I
still use Clipper a lot witin the office and simply would not consider useing
anything but Clipper for our point of sale system as the idea of Windows outside
the office is to me a recipie for trouble.
Horses for courses.
-
Edward J Barr
Antonio Linares
Have a look at Harbour (www.harbour-project.org) and
FWH (www.fivetech.com)
They are all you need,
Check them for yourself,
Antonio
Edward J Barr
<sa...@grafxsoft.com> writes
>Saulo,
>
>Here at GrafXsoft it's a very busy and exciting time. I've received quite a
>bit of interest and ideas for Clipper's future. Our intention has never
>been to kill the product. We intend to continue to sell and market the 5.3
>version and may even bundle some third party libs with it. If there are
>enough people that are interested in a 32 bit release of Clipper I see no
>exists in 16 bit. Bring Clipper to 32 bit would only seem like a logical
>thing to do.
>
> IMO, Clipper has never had a better home.
>
>Regards
>
>Brian
>http://www.grafxsoft.com
>
>Pre Orders for VO 2.6
>http://www.grafxsoft.com/vo26.htm
>
I don't know why some people in this thread go on about a 32 bit version of
clipper. Surly its great strength is that we can write DOS bas database
applications either stand alone or if we want a network version with a dtatbase
engine we just add advanteage.
--
Edward J Barr
Lawrence
Karl Nitschke
> stuffing, but just one question: WTF do you think your great, safe,
> reliable languages are implemented in? I'll tell you: 90% of the time,
> it's C or maybe C++. SO most of the time, your "reliable" languages are
> no more reliable than these "dangerous" C implementations, and often
> less so.
How ludicrous. Have you developed a programming language in C++
lately? Do you know many years that takes and what it costs to get the
bugs out of it?
Karl
Karl Nitschke
Don't you know?
> And when do you think the 1989 ISO C Standard was written?
>
> And when, ditto, for the 1999 ISO C Standard?
The phrase, "sticking lipstick on a pig" springs to mind.
It baffles me that so many computer programmers working in this field,
don't actually read anything about the art, and more so now, the
science of computer programming. (Beyond their reference manuals,
anyway.)
"Oh no, I don't read those medical journals on how to do stuff. I use
leeches and get good results. This is based on my direct experience,
so I ain't gonna listen to nobody who wants to argue that fact."
Here are a couple of references so you can check your facts on C
productivity versus high level languages:
Casper Jones, "Software Productivity Research Programming Languages
Table", 7th Ed., Software Productivity Research.
Steve McConnell, "Rapid Development"
Karl
Edward J Barr
What windows API on a pure DOS box ? There are places that I don't want to
deploy windos, point of sale for example.
--
Edward J Barr
Dave Pearson
> > *Splutter* And when, pray, do you think C was designed?
>
> Don't you know?
I think he's checking if you do. According to you it was 1962, right?
> > And when do you think the 1989 ISO C Standard was written?
> >
> > And when, ditto, for the 1999 ISO C Standard?
>
> The phrase, "sticking lipstick on a pig" springs to mind.
The fact that you don't seem to like the changes doesn't mean that there
have been no changes since C first appeared.
Richard Bos
> > *Splutter* And when, pray, do you think C was designed?
>
> Don't you know?
Oh, I rather think I do. Do you? Yes? Are you sure? Are you _quite_ sure
the C language hasn't changed in 40 years? I know C is a guru-ish
language, but the implications of that statement of yours are a bit too
satori-ish even for C.
> > And when do you think the 1989 ISO C Standard was written?
> >
> > And when, ditto, for the 1999 ISO C Standard?
>
> The phrase, "sticking lipstick on a pig" springs to mind.
Goodness me, you have weird fetishes.
> It baffles me that so many computer programmers working in this field,
> don't actually read anything about the art, and more so now, the
> science of computer programming. (Beyond their reference manuals,
> anyway.)
So it does me. However, I'm not one of those. I prefer to base my
opinions on a solid basis of facts, unlike some.
> Steve McConnell, "Rapid Development"
Rapid Development is a guaranteed way go get rapid bugs, IME. I prefer
thinking _before_ I start to code.
Richard