bluetech

find is essentially the command line tool for traversing the file system hierarchy recursively. It's got a million options, e.g. whether to follow symlinks, depth, file/directory/device/.., user, group, change time and many more. When you use grep -r, it only does the most common thing which is to just go over all the files. If you want something more "fancy", you can use find, e.g.:

  $ find -name '*.c' -type f -exec grep printf '{}' +

Well, just below the Plan 9 sections comes this: http://catb.org/~esr/writings/taoup/html/ch20s03.html#id3016... And he's right, ioctl's can be quite tricky to operate sometimes.

I think linux users, if they would go for such a thing, will be better served by systemd. See for example

http://0pointer.de/blog/projects/instances.html http://lists.freedesktop.org/archives/systemd-devel/2011-Sep...

Yes, and you can also have multiple parents with a reference-count semantics.

  void * talloc_steal(const void * new_ctx, const void * ptr);

  The talloc_steal() function changes the parent context of a talloc
  pointer. It is typically used when the context that the pointer is
  currently a child of is going to be freed and you wish to keep the
  memory for a longer time.

  NOTE: It is possible to produce loops in the parent/child relationship
  if you are not careful with talloc_steal(). No guarantees are provided
  as to your sanity or the safety of your data if you do this.

There's also talloc_reparent where you explicitly choose the parent to change.

I have used talloc for a medium-sized project, and it was quite refreshing. Of course, it all depends on your program's structure. An hierarchical allocator naturally fits hierarchical data structures and containers, so parsers for example can benefit immensely in my experience.

You are correct in that you can just write constructors and destructors, but then you still need to worry about error handling, double-frees and whatnot. With an allocator like talloc, you just state the relationships during the allocation, and afterwards only worry about the high-level structure.

One thing which can be somewhat cumbersome is the need to pass around those "contexts"; for example, if you allocate an array of some struct, and you need to allocate additional memory inside that struct, your context will presumably be the array, and so you need to have access to it. One solution I have found which is helpful in most, but not all, situations is to use the wonderful container_of[1] macro, which enables you to do upcasting using some pointer trickery. And of course, it does cost some performance as they say on their homepage.

[1] http://www.kroah.com/log/linux/container_of.html

C# (by .NET 4) now has real expando objects, if you really need them. It uses what they call the Dynamic Language Runtime: http://msdn.microsoft.com/en-us/library/system.dynamic.expan...

It seems like half the papers ever written about Haskell contain a solution to this problem... This includes most papers about monads and monad transformers.

And of course, the LINQ version returns an IEnumerable<TResult>, while the List version return List<TResult>. You could chain a .ToList() there to make them equivalent (if needed).

It is not necessarily bureaucracy or "state-heaviness"; Israel is a small country, the army may be using these frequencies, and they need to cleared out before being used by the public. It was the same with bluetooth and other wireless technologies.

I learned C as my first language, and there was nothing "confusing" about it. I find C to be quite direct - here's a variable, there's a loop, a function, a struct. Even pointers are straightforward one you know about memory and addresses, and you will need to understand them (conceptually) sooner or later anyway.

In fact, the abstractions you mention are what might be confusing for the beginner: Classes, objects, inheritance, polymorphism, iterators, high-order functions, closures, monads, generators, etc. all require as much book- and code-staring as either void or function pointers do for the first time.

I do however agree with you that C is harder and much less useful to learn than a "batteries-included", modern language like Python or Ruby as a first language.

Python 3.1 changes the way floats are converted to strings. See http://docs.python.org/dev/py3k/whatsnew/3.1.html#other-lang...

What about this: http://docs.python.org/dev/py3k/whatsnew/3.1.html#other-lang... (the fifth bullet)

It seems to make things more reasonable. After all, Python has showed that saying "that just how it works" can be avoided, as in the case of / defaulting to floating-point division.