41–50 of 110 posts
Earlier quoted context omitted.
You're probably joking, but sloccount says: ansic: 82714 (99.68%) perl: 124 (0.15%) sh: 78 (0.09%) asm: 48 (0.06%) cpp: 17 (0.02%) (for nginx-0.8.53)
Why have I gotten 13 upvotes for this? Serious question.
If you think about it for a second, you realize that TrueType rasterization can't be that hard because printers were doing it long ago on crappy little embedded processors, but the default is just to fall back on the big ugly library, and then wrap it and pretend it's not there. How about instead, just write some good code? This is why 'modern' software can still manage to bring a 3GHz quad-core to it's knees, IMHO
This is also why we have many more softwares available now. The improvement in hardware specs are so useful not only because it is faster, but also because we can do much more without having to care about the details. Writing tiny, efficient libraries is cool, but it takes a lot of time, everything else being equal, so if you can afford not doing it, you don't.
Assuming English isn't your first language, that would be phrased "much more software"; software is always singular.
Earlier quoted context omitted.
Why have I gotten 13 upvotes for this? Serious question.
Umm..13 people found it insightful/interesting? I don't know..
The core of my protobuf-decoding library upb ( https://github.com/haberman/upb/wiki ) is 3k SLOC of C. That includes * a hash table implementation * a reference-counted string type * a generic interface for doing tree traversals of protobuf data * the protobuf decoder itself (which implements the previous interface) * all the code to load proto descriptors (including bootstrapping the first one, which is necessary to…
It really says something about C that so many useful-but-small systems have a good chunk of code devoted to hash table implementations, atoms ("a reference-counted string type"), etc. When working with C, it sometimes makes sense to have bespoke data structures, but it always makes me think of Hanson's _C Interfaces and Implementations_, Greenspun's tenth rule, etc. My 1500loc C project also has a hash table implemen…
Minimal hashtable implementation: an array declaration, a memset call, and a template search loop which either uses pointers or locations (pointers to 'next' pointers), depending on whether you need to look up the item, or potentially remove it. Roughly 2+n lines for n hash operations.
Earlier quoted context omitted.
I did once write a 2k-line bytecode interpreter and runtime for R4RS Scheme -- the compiler, library, and debugger were another 2-3kloc of Scheme. I even used it as my main hacking platform for years. But I didn't post it here because: * It depends on the Boehm garbage collector. * (This is embarrassing.) It stopped working after some version bump of GCC, and the cause is not at all obvious to me. Since I don't Schem…
No blame, but I'm curious "why you don't Scheme much anymore". Was it due to Python, Common Lisp, etc? I switched from (Chicken) Scheme to Common Lisp (and, in parallel, from Python to Lua), and, having read a lot of old code of yours, I'm curious about your choices - you seem consistently sensible and pragmatic. (Sorry to put you on the spot.)
Very impressed with LuaJIT2, btw -- I'd like to do more with it.
Shocked that silentbicycle hasn't mentioned it already, but Arthur Whitney whipped up the first prototype/inspiration for the J language in a short bit of macro heavy C over the course of an afternoon. 42 lines? http://pastebin.com/s2usuqDq If this interests you at all, absolutely worth reading Roger Hui's retrospective on the subject (more about J + Ken Iverson, but definitely fascinating) http://keiapl.org/rhui/
I'm going to save this for the next time someone asks why there aren't more females in CS/programming. I just tell them that this kind of code is held in high esteem, instead of being ridiculed for the stupidity that it is.
Earlier quoted context omitted.
You're probably joking, but sloccount says: ansic: 82714 (99.68%) perl: 124 (0.15%) sh: 78 (0.09%) asm: 48 (0.06%) cpp: 17 (0.02%) (for nginx-0.8.53)
Why have I gotten 13 upvotes for this? Serious question.
Getting a standards-compliant XML parser into 2K lines is going to be a challenge, if you're not going to cheat on what a "line" is. You must be able to deal with both UTF-8 and UTF-16 [1] (and remember UTF-16 can be in either endian order), you have several tables of things like what chars are valid where, you've got data structures to declare, and there's a lot of edge cases that may not leap to mind but if you don…
This is a pretty good argument against XML.
How much memory does the code the blog poster described leak? How does it respond to edge cases and invalid input? Finally, is it portable beyond one specific OS? Beyond POSIX or Windows-based systems? Those questions are especially pertinent in C.
As for twok, I believe the error handling to be decent and I don't believe it leaks. I'd be happy to hear of any errors you find. It's only portable to Windows, OS X, and Linux because that's all I have access to. It may work on BSD also.