Interesting Libraries

I've recently come across a few very interesting libraries online. While not as complex as some of the traditional "all-inclusive" monsters such as JQuery, Boost, GLib, and friends, these libraries all exhibit a number of very exciting and interesting characteristics while remaining quite simple overall (by cleverly exploiting basic capabilities of the technologies they are implemented in).

These are:
1. Bret Victor's "Tangle"
http://worrydream.com/Tangle/

2. Cello - High Level Programming in C
http://libcello.org/



Tangle
If you've been following Bret Victor's work, you'll be familiar with his ideas about developing tools which make it easier for people to simply "directly-manipulate" (or, to put it more crudely, "play with") data to dynamically explore the effects of various parameters on the relationship between them. As they say, "seeing is believing", or in this case, seeing brings you much closer to true understanding.

Tangle is a library for embedding such interactive elements + relationships into HTML pages. From what I understand, it is basically a 2-part system:
 1) In the page's HTML markup, you annotate elements within the page to act as placeholders which are either parameters (that users can interact with) or results (where the dynamically computed results are displayed).
 2) In scripts you link to the page, you can define little program snippets for controlling how these interactive elements work together. All you have to do is to code up the relevant logic, wire it up to some built-in  contexts provided by the library (with new contexts/types easily created as needed), and these contexts automagically perform DOM-rewriting to replace the placeholders with live content.

Lib-Cello
To what extent can you modify a language by providing clever wrappers on top of the basic types it provides that you're still programming in that language... That is an interesting question, and one that is brought to the fore by Lib Cello.

Firstly, a few little disclaimers:
1) I've been trying to do similar sorts of things for ages (in fact, some parts of the implementation details are quite similar to things I've been tinkering with for our depsgraph architecture internals - more on this soon, once I flesh these ideas out a bit further)
2) IMO this is awesome!!! (by and large - there are one or two little things which I'm a bit doubtful on, but still, overall I'm quite impressed, otherwise I wouldn't be writing about it!)

The gist of what this library does (and why it's quite awesome IMO) is that it tries to bring "modern" programming language abstractions to good-ol' C, while staying within the confines of the basic tools offered to us by the standard language without resorting to building heavyweight manual machinery (*ahem* GLib), or special preprocessors (*ahem* OOC - thanks jesterking IIRC for the link several years ago).

Of course there are the natural debates about the "worthiness" of such efforts:
- C++ exponents will no-doubt just be jumping up and down saying that C++ started out as a set of macro-preprocessor extensions for C which eventually morphed into the current ugly beast that is modern C++, and that if you really want OO and/or other modern techniques with basic C-like syntax and without a virtual machine, you should be moving to C++.   (Objective-C exponents will also claim something similar, though will probably claim a slight moral highground by saying that their language is less nasty/complex than C++... that, and the fact that they language only runs on glossy iLike's from the Cult of Mac.)

- Dynamic Language/Managed Code fanatics (predominantly the Java/Ruby/Javascript/C#/.NET/Go/whatever-is-most-trendy-today crowd) will claim that C (and also C++) are antiquated low-level horrors that should be avoided at all costs. True, for a large proportion of the computing/programming community, that is very very true (it only takes a short time teaching people to code to realise this). It's also true that there are some benefits that managed environments provide (e.g. JIT optimisation benefits, and greater opportunities for "sandboxing" that works).


However, the claims that you "can't" do such-and-such in C is rubbish. So too are the claims that "all" code written in C is by simple virtue of being written in a language whose spec has barely changed in 3 decades is "dangerous" and "error prone". As "The Hard Way to Learn C" discusses (in Chapter ?), it *is* possible to write OO-style code in C.

In fact, I'm going to argue that despite the core of Blender being written in C, it is very much Object-Orientated (though perhaps not using the full spectrum of inheritance shenanigans, though it's still there if you know where to look - Hint: ID/ScrArea structs as as basetypes/serialisation headers for the appropriate datatypes) as opposed to being a purely "classical textbook procedural approach".

Also, as an aside, you'll notice that "real" production C-code is usually nowhere near as ghastly as the one-slide examples usually shown in introductory texts/lectures on C that are typically taught these days, which typically show some function where there are n (where n > 2) degrees of pointer indirection with a bunch of bitshifts + octal bitmasks layered on top for good measure.

"Real" C-code though (at least that which is used for proper application programming, as opposed to that which was the result of some disassembled/obfuscated driver code) typically never looks like that - "good" software engineering principles basically say and end up meaning that as disciplined software engineerers using such languages, you have style guides which dictate that confusing/error-prone/etc. constructs are simply avoided in pratical usage.

Thus, I argue that with real production C-code, many of the modern concepts that you deal with are possible to easily implement within the confines of the language (well, maybe with the exception of co-routines, at least in a portable way, which is a real pity), as long as you understand deep down the concepts and thought patterns you're trying to express (and do so in a structured way). Indeed, there are times when it would be "nice" to have syntax which helps to make it clear to everyone that that is what you're doing, but special syntax is not a requirement to you being able to do something!

Anyways, there are still many positive benefits of being able to to still develop code "in C" (that can be compiled by any standard C compiler out there), as opposed to having to go to other frameworks/language stacks. Chief among those is that if things go to custard, you can always just revert to creating your own techniques to solve your specific need using the same basic building blocks (or just toss in the hat and use "raw C", if it all truly becomes too much!). Integration with other existing C-code is another major benefit.

Finally, simply being able to create a credible modern-looking language (which almost crosses the line into being a fully-fledged Domain Specific Language for making your current work easier) is just simply an awesome (and very fun) technical challenge. I've been known to tinker with such things before (there's heaps of evidence of this if you want to check ;), and strongly believe that "style" guidelines should never stand in the way of you wrapping up slightly nasty hacks within sanitised interfaces which vasty simplify the end results in the long run (i.e. iterator macros, which take the bite out of iterating over complex collections).

It is this final point which impresses me most with Lib Cello. With this library, they've almost completely transcended the shackles of "traditional C", and created a language which almost looks like just another modern dynamic language, save for the fact that it still compiles on the standard C-compiler toolchains and doesn't need any special runtime base libs either!

In particular, there are aspects here which I'd contemplated at various early stages of the despgraph design/prototyping work of trying to setup in the depsgraph core to make certain things easier. Although ultimately I didn't go quite that far this time, it's still interesting peeking under the covers and seeing just exactly how this feat was pulled off (and IMO, it is quite an impressive feat indeed).