Slashdot Mirror

← Back to Domains

Domain: compuphase.com

Stories and comments across the archive that link to compuphase.com.

Comments · 6

  1. What about Small by mu22le · · Score: 3, Interesting · on What are the Next Programming Models?

    I have heard marvels of Embryo Enlightenment version of SMALL

  2. Fixing the buffer overflow problem for good. by Ninja+Programmer · · Score: 1 · on The Lessons of Software Monoculture
    • If it were that simple, than there should be no buffer overflows in modern C/C++ programs. But it apparently isn't that simple, for several reasons. Using container libraries costs extra time and effort, and it is less efficient than error checking that is built into the compiler, for example. Also, using container libraries is not something that the C/C++ compilers help enforce; that is, if some module doesn't use it, nobody ever gets warned about it.
    False on ALL counts! Allow me to introduce you to the Better String Library for C and C++. This library handles strings and growable block buffers in general.
    • Because of its superior API (closer to higher level languages, and a superset of what C/C++ has to offer) it is Easier to use than the C/C++ alternatives. (The functions do more and do things that other languages have done with strings for a long time.)
    • Because of its superior architecture (length delimited) and implementation (uses the fastest corners of the state of the art in C/C++ compiler technology) it is Faster than the C/C++ alternatives. (I've got the benchmark numbers to prove it)
    • It comes with the optional bsafe module that creates link overrides to the standard C library functions where buffer overflows occurr most often and which are redundant to functionality in the Better String Library. I.e., deprecation of bad C library routines can be Enforced.
    • And, of course, the API is completely buffer overflow safe.
    This library has been thoroughly tested, its portable, its open source , and is currently used in projects such as Myriad and the Small Language. I assert that moving away from C/C++ in an attempt to escape buffer overflows is not only misguided, but unnecessary if you use the the Better String Library. The whole "using C/C++ inevitably leads to buffer overflows" idea gets thrown out the window if you are using it. I would encourage any C/C++ programmer to try it out before concluding that you need to move away from C/C++.
  3. Re:Nobody ever looks at Io or REXX... by Daath · · Score: 2, Informative · on Searching for the Best Scripting Language

    Also Small.
    Lisp.
    Scheme.
    Actually just pick one ;)

  4. Small, the C scripting language. by YakumoFuji · · Score: 3 · on C Styled Script - C-like Scripting Language
    I've been using 'Small' for a fair while now, here

    from the site;

    Small is a simple, typeless, 32-bit extension language with a C-like syntax. A Small "source" program is compiled to a binary file for optimal execution speed. The Small compiler outputs P-code (or bytecode) that subsequently runs on an abstract machine. Execution speed, stability, simplicity and a small footprint were essential design criteria for both the language and the abstract machine.

    • Small is a simple, C-like, language.
    • Small is a robust language with a robust compiler.
    • Small comes with an implementation of an abstract machine in portable C. The abstract machine is a set of C functions that you can easily link to an application or function library. By compiling the source code to P-code for an abstract machine (or "virtual machine"), Small is much faster than pure interpreters.
    • Small has a good interface to native functions (in C/C++); your application calls functions from -Small programs, Small programs call functions from your application.
    • Small is a 32-bit language, even when compiled with 16-bit DOS tools.
    • For porting purposes, Small is written in ANSI C as much as possible; Big Endian versus Little Endian is handled. -Small is quick (especially with Marc Peter's assembler implementation and/or his "just-in-time" compiler) -Small is, er..., small.
    • Small is free and it has a liberal license (you may use it for commercial applications, and you may also freely distribute modified sources or binaries ---though you take responsibility for those modifications).


    Write your Own Operating System [FAQ]!
  5. Re:Grad Student? by K8Fan · · Score: 2 · on Genetic Stone Soup

    Replying to my own posting, it appears that in a previous incarnation, Jim Kent was the author of the FLC/FLI animation format. That must be why the named was so familiar.

  6. No surprise by Zach+Baker · · Score: 2 · on Tim Sweeney On Programming Languages
    I was casting around for a scripting language to use in a game I was working on about a year ago. I took a look at Python, but it didn't seem embeddable enough at the time (I suppose the situation has improved). The number one candidate was actually JavaScript... seriously! The only real problem was that it was a little too slow, but not horribly so. Otherwise it had some great features:
    • First and most important of all, it has a good mechanism for exposing C functions to scripts. This is crucial.
    • You can strip out just about EVERYTHING, even text functions if you want. Great if you have to target a PSX or N64.
    • Similarly, you can save memory since you're able to compile script text, then throw the text away and keep the bytecodes.
    • A flexible syntax that could be used like C or as a line-based language, in scripts, on a command line, or in a config file.
    • Garbage collection and a fixed heap size.
    • Debugging support, which is often forgotten but important.
    However, the script <--> C++ interface, though simple and mostly effective, was still fairly primitive and certainly not on the level of UnrealScript (which BTW just totally rocks the party, I hope we can see more of it soon). I would really like to see more scripting languages which bind as tightly with a C++ framework like UnrealScript does, for instance parsing C++ header files instead of depending on an interface to be defined elsewhere. I think just about every program should take advantage of a glue language, and the better the interface, the better the gluing. =^)

    I also checked out ICI (cool), saw whether Perl could be cut down to size (not easily, but it would be worthwhile), TinyScheme (sure is!), and Small (very cool!). Now that there's more attention to large-scale, reusable game scripting (take a look at a new project, GODL) I think we should expect that good games will have a good scripting language behind them.