Looking for some advice:
I have limited free time, but am very interested in simulating gaming situations on my own. I know Lisp a little bit, but am woefully ignorant of other computer languages. What is the most efficient choice of programming languages for me to learn? I don't need to produce anything for anyone else (besides perhaps results.) I just want quick answers.
Well, you couldn't find a worse language than LISP(OK perhaps InterLISP.) I swear by VB6. But, it costs money and has a steep learing curve if all you want is quick and dirty answers. I also think that you will find simulation will consume all the free time you can muster. It isn't the coding that takes time. It's making certain your answers are correct. PASCAL or plain C might be the route to take. Afraid I can't help you with current compiler sources.
Also take a look at RealBasic:
http://www.realbasic.com/
You can download it and try it for free for 30-days. Heck, you might finish your project that fast.
I'm seen some pretty complicated stuff done in RB. Your results may vary.
Good Cards,
V
Everyone's got a preference. I think we all agree that you should try to lose your LISP. In my youth I had to write a LISP interpreter in C.
I would cast a vote for C. You never know what you might want to do in the future, and if you know C, you could "upgrade" to C++, or "downgrade" to Pascal (which is quite similar to C). C isn't that complicated if you just want to learn enough to get up and running and solve some straightforward things.
Also, if you program in C, you'll be immune to programming snobs like me who might scoff at any programs written in Basic! It's true that the hip generation is now using C++, but with C you'll still be in that "hardcore, old-school" category.
This is a factor in favor of Pascal. At some point it is probably worth it to upgrade, and Delphi is, in my opinion, quit a bit more convenient, especially for non-professionals.
Karel
An application written in compiled BASIC can never be as fast as one accomplishing the same work written in "C". But I know (or knew) BASIC so very well that I'd like to save the what, 300 or 500 hours that being marginal in "C" would take me.
If I were considering writing something for which I believed there would be a commercial market, making a 500 hour learning commitment and springing for a $500 price tag would seem reasonable.
But for satisfying my own infantile curiosities, is there not a documented, compilable BASIC that doesn't cost half a thousand dollars?
An application written in compiled BASIC can never be as fast as one accomplishing the same work written in "C".
CVData and CVCX were developed in compiled BASIC and are the fastest BJ simulators available.
This is a real question. Can a lanuage written to be intrepeted and that ignores efficiencies valuable in compilation be comparable in speed as a compiled language to one which was written to be compiled?
see http://compilers.iecc.com/comparch/article/92-08-042
The reason for my interest in the reason of the slowness of basic is that
basic is the best program language that there is today, from the
programmers point of view. But I simply cant see the reason for the
slowness of compiled basic!
and also from this site, from another writer:
A few years ago there was some discussion about producing a compiler for
it [a business-oriented BASIC-style language called BBx]. We found several reasons why a compiler would not be a great idea. The main reason is that the runtime dynamics of BASIC don't translate well to a compiled environment. The most important aspects are dynamic string/array management and dynamic flow control involving error/exception handling.
I just don't think interpreted languages compile well. If they do then
they really aren't exploiting the special strengths of interpretation.
You end up with the worst of both worlds.
see also http://www.dmst.aueb.gr/dds/news/104.html
BASIC has many features that are inherently slow. Comparable programs written in C do not rely on such features, and therefore, generate faster code. The most important features of BASIC that result to slow code are:
1. All numeric computations are done in floating point by default. One must explicitly name a variable with a special integer suffix code, to declare it as an integer.
2. String operations rely on the dynamic memory allocation and garbage collection. Both are slower than the staticaly allocated string memory / programer controlled allocation and disposal schemes that C programmers use.
Furthermore, in PC environments, C programs often directly control the hardware of the output devices (e.g. screen) by using pointers to the memory associated with them (e.g. screen buffer). The same operation can be expressed in BASIC only in a more roundabout way (usualy through a POKE operation) and will therefore be slower.
There seems now doubt to these writters that a program compiled from "C" is significantly faster than one compiled from a version of BASIC. I truly wish that this not be so, but am confined by my ignorance.
see http://www.truebasic.com/editions.html
Their cheapest version of True BASIC is a mere $40. Can anyone tell me if this would worthwhile?
I'm really feeling out of my league.
CVData would seem be prove these people wrong. Two million rounds per second simming complex cover play seems quite acceptable to me. Some comments:
> The most
> important features of BASIC that result to
> slow code are:
> 1. All numeric computations are done in
> floating point by default. One must
> explicitly name a variable with a special
> integer suffix code, to declare it as an
> integer.
Not for over a decade. In Visual basic any variable name can be used for any data type. Even user data types. You can also change the default.
> 2. String operations rely on the dynamic
> memory allocation and garbage collection.
> Both are slower than the staticaly allocated
> string memory / programer controlled
> allocation and disposal schemes that C
> programmers use.
VB supports both variable length and fixed length strings. But, there isn't any string manipulation in a simulator anyway.
> Furthermore, in PC environments, C programs
> often directly control the hardware of the
> output devices (e.g. screen) by using
> pointers to the memory associated with them
> (e.g. screen buffer). The same operation can
> be expressed in BASIC only in a more
> roundabout way (usualy through a POKE
> operation) and will therefore be slower.
> There seems now doubt to these writters that
> a program compiled from "C" is
> significantly faster than one compiled from
> a version of BASIC. I truly wish that this
> not be so, but am confined by my ignorance.
CVBJ goes beyond that. It directly accesses the memory on the video card and sends basic video card hardware ops to AND, OR and INVERT bitmaps. This is certainly an unusual technique for a BASIC program, but can be done.
It should also be noted that Visual Basic uses the Visual C++ compiler.
Thanks for you input. I think I'm going to take a dive into C for now, but if that effort crashes and burns I know where to look.
> It's true
> that the hip generation is now using C++,
> but with C you'll still be in that
> "hardcore, old-school" category.
as in San Dimas? Station!
(Sorry, couldn't resist.)
Glad to get your comments. Most of the criticisms of BASIC I found were somewhat dated: they all seemed to be from when everyone got interpreted QBASIC with their DOS.
I suspect I know the answer to this. In your opinion, would choosing one of the lesser lights, REALBASIC or TrueBASIC instead of MS VB be a mistake?
And I really do value your opinion.
Posting Permissions
-*-
Bookmarks