Toolkit

Hey guys, I'm putting together a toolkit of commonly used things that I can plug into programs rather than writing them from scratch every time and I want to know what I should put in it.

So far I've got a stack, doubly-linked list, double-ended queue, and binary search/sort algorithms.

What else does /prog/ think I should put in there?

A Lisp interpreter.
Or Glib.

I think you should switch to a real language.

>>3
I haven't even mentioned what I'm using.

>>4
It can't be that good if such common data structures and algorithms aren't provided by a standard library.  AFAIK C++ already provides everything you've done, whereas something like Prolog makes it and unnecessary and irrelevant.

>>4
Yeah, if your language doesn't have even such basic features, it sucks. If it is C (I hope so), consider it as a necessary evil and use it only when absolutely necessary, and use FFI to take care of the rest. If it's not C, scrap it.

I see no reason to use C for anything except OS kernels, microkernels or device drivers.  For applications, higher-level languages like Haskell or Prolog seem better.  If you need  speed, you can write ***the parts that profiling indicates are slow*** in C++ that runs just as fast as C (check out the performance TR).

I have also seen it argued that C is a good teaching language because it's smaller than C++, Java, etc.  But following this line of reasoning, Scheme is better again.

EVRY BUDY LUVS GOOD OLD BIFF CUZ HES A KEWL DOOD AN HE RITES REEL AWESUM THINGZ IN CAPITULL LETTRS LIKE THIS!!!

>>1
your application to McDonalds

>>9
I lol'd.

IT'S A WHEEL

>>11
Wheel 2.0 is more .NET.

>>12
Wheel 3.0 is as .NET as possible.

>>7
Along this line of thought x86 Assembler is the best teaching language, but just maybe I'd start with a scripting language or basic. BTW, you can't write an OS-kernel in C alone, both NT and Linux kernels are optimized in assembler or straight-forward machine code(you can't write firmware even on assembler).

OP: you include things in your libraries as they become relevant that way they don't have a lot of cool sounding functions, which will you never need.

>>1
Put Lisp

>>14
7 here. I meant "smaller" in a very vague sense, to do with what psychologists call cognitive load. While individual assembly languages _are_ simple, programs written in them are not. As you identified, scripting languages would also be a good choice for teaching, perhaps not BASIC though :-)

I've no idea about the NT kernel (and you don't either, or else you wouldn't be allowed to say so in public). I am familiar with some Unix-like OSs though (Plan 9, Inferno). They use a tiny amount of assembler (I count about 1KLOC in Inferno) but it isn't for optimisation it's because C can't express some operations on modern processors. Using assembler for speed no longer makes sense because scheduling of separate execution units, delay slots, etc. ensure that compiler output will usually outperform hand-coded assembler.

Oh, and modern firmware (by which I presume you mean BIOS on a PC) is often written in assembler. It has been written in Forth in the past (OpenFirmware on SPARCStations and Macs), but no more AFAIK. LinuxBIOS is written in mostly C, with a little assembler.

>>16

NT kernel source code was leaked a couple of years back. It's mostly C. Lurk moar.

>>16
Heh. I learned assembler by reading the BIOS source listing IBM gave you when you bought the original IBM PC.
I'm old.

everything worth doing requires monads

24 Name: Sgt.Kabu᪅雳kiman䭕ﺩ 2012-05-29 2:32

Bringing /prog/ back to its people
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy