Paul Graham On 'Great Hackers'
dcgrigsby writes "Always interesting, if not unbiased, Paul Graham has published a new article on 'Great Hackers', discussing why Perl and Python are apparently better than Java, on why Microsoft developers get offices, and a host of other sure-to-be-controversial stuff."
Interesting insights.
I wonder, how does one become a great hacker? How do you make yourself a great hacker? I'm not sure it's possible...I mean, I know you can do a lot of things to make yourself dumb, but what can you do to make yourself smart?
I guess a good part of it comes from working on what inspires you, and what makes you happy. In general, I find that it's very difficult to make very smart people do things they don't want to do.
I suppose that in order to accomplish something important, it has to be important to you. It could be that you love it. Obviously, if you can keep alive the zest for programming you had when you were young, then you're bound to do well. If your current profession is making you senile, then you're probably not going to keep that hacker spark going.
I think the real issue must be inquisitiveness. I find that good hackers are very curious about the world around them. Ultimately, that must be the answer. To be a good hacker, you must have a genuine thirst for knowledge, and a desire to improve things for those around you. Sounds good to me.
Anyone who spends their time improving software is doing us all a favor... that's why my screensaver at work has always said: 'Hackers are great'.
It took some explaining to convince my boss that "hackers" wasn't a negative term, but since then I've received nothing but compliments from other geeks in the office.
Hackers are great!
+ Donald Gunth
+ Email: dgunth@quicktek.net
"Caffeine is the greatest lubricant ever created." -ESR
Second, and I'll probably be modded as troll for this, but all the programmers I know who like perl are sysadmin types who don't know better. Popularity isn't a much better measure of "goodness" in the open-source world than it is anywhere else.
Graham may make some good points but he's SO far out in left field on others that his credibility is shot as far as I'm concerned.
Is suited to people who simply want to write large bodies of maintainable code. It's not intended for small hacks, nor is it intended for being close-to-the-metal.
The idea that one must automatically be a crap programmer because one likes Java is an egotistical and obnoxious point of view. I happen to like Python and C and C++ as well as Java, and I use all of those on occassion, but Java is no less a suitable and appropriate language to use for some tasks as any of those other languages.
I'm sorry, but Graham's dismissive attitude towards Java is evidence of extreme arrogance.
Did he mention that these Great Hackers have quote possibly some of the greatest creative minds in the world. Sure you have to know what your doing, but the ability to think outside yourself, see the bigger picture, is what makes these guys great. When you come across a problem that may seem impossible to get a work around for, these guys think and think, and they get their solution because they are able to see a myriad of different perspecvtives as a possible solution to a really tough problem. these guys are paid the big bucks because they do have that extra quality as well as being good hackers. i think thats what separates the good, from the great.
Now I would classify myself as a hacker, but cant play a musical instrument (CD player isn't a musical instrument right?) and sci-fi gives me a softie. Dig guns though.
IMHO a good/great hacker must be prepared to go where he wants to with confidence. Don't just take on everyone else's mindset (if you do what the other 6 billion people are doing you're not going to do anything worthwhile). In short, scratch your own itch.
Engineering is the art of compromise.
Spend some time somewhere like Perl Monks and you'll find out that there are a lot of competent Perl programmers who aren't sysadmin types. Or go and look at CPAN to see the variety of different kinds of software that are available in the Perl world.
Furthermore I'd like to point out that Graham made a claim about the behaviour of hackers, not open source programmers. Most of the people who contribute to Sourceforge would not, in Graham's opinion, deserve the compliment of being called hackers. Therefore their aggregate choices are irrelevant.
Disclaimer: I'm a fairly well-known Perl programmer.
Not all jobs are that way - sometimes overhearing what the other people around you are talking about is more useful to overall productivity. And some people can concentrate even with lots of background noise. But for a lot of people, offices would have been more productive than cubicles.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
He's right. You guys are so personally offended you can't see the forest for the trees.
/. crowd. In your opinion, who's the most likely hacker?
He's talking about hackers here, kids. Not 90% of the
a. sysadmin
b. java developer
c. janitor
Personally, I'm voting for (a). (A) because most sysadmins deal with perl, lots of unix systems, they know *nix inside and out.
Java guys are out of the question, they're too wrapped up in their baby blankets sucking their thumbs to realize they are not _in_ the group we're speaking of.
Janitors, well, it's possible, but probably not common.
I'm a sysadmin, and I user perl all day long. Sometimes at night, when a brute force ssh attack comes along. I need to know which exploits are out there, I'm constantly trying to break my system. I'm constantly learning about the newest buffer overflows in solaris. I am intimately aware of memory space in the kernel. I don't live in a Java Dream World (tm). I don't have all day long to dream of how, if java were tangible matter, it'd be able to cure world hunger. I'm too busy living in the Real World(tm).
In conclusion, while it's uncommon to have good hackers know they're good, it's a lot more common to have a bunch of wanna-bes think they are "the hackers".
Graham essentially spouts a lot of geek cred virtues that suit the stereotype of hackers that we all, in some way, want to be. So we all read the article, see a little bit of ourselves in it ("yeah, I'm pretty politically incorrect, too."), and feel good about how special we are. Just like astrology profiles based on your sign contain a lot of qualified compliments ("you speak your mind, sometimes offending other people without meaning to."), Graham's articles have a constant thread of "geeks are special, and you're a geek, too."
Taken literally, the people Graham is talking about are perhaps 2-3% of the coding population. In other words, they're the equivalent of supermodels, rock stars, and brilliant twentysomething CEOs, and just as accessible to you or me. In practical terms, you'll almost never, ever work with, hire, or be the kind of person he's discussing, so put down the geek wank material.
Every time I read a Graham article, I feel dirty at the amount of false modesty and self-congratulation involved. He's like a digital Stuart Smalley.
Anyone who loves or hates any language, platform, or manufacturer, doesn't know what they're talking about.
If you look at what a good joiner uses, you'll note that he has a large set of tools, and picks the right one. There is no advantage in trying to turn wood on a lathe with a screwdriver - that's the job of a chisel.
A similar thing applies with computational work. If you truely know what you are doing, you'll use the right tool for the job. If your wanting to accumulate a large set of facts, and then do some comparisons across that set of facts, that's a job for Prolog. No matter that C, or Java, or Perl, or whatever, is more popular. They are just a poor fit to the task, which would mean you'd need to write a predicate logic packeage in them, to get them to work.
Look at tools like FFTW. It's written in OCaml, and C. Two different languages, each used seperatly, to play to thier strengths. OCaml does tree parsing, and optimising of an abstract syntax tree. C code does the numerical heavy lifing. That's choosing the right (rather, a good, there is a pluraity of good tools for that) tool for the job. Trying to do the abstract syntax tree parsing in C, or the numerical heavy lifting in OCaml is just stupid - you'll end up with something that's nowhere near as good.
Try writing an OS kernel in Perl.
'Favourite language' is something that's not a good metric. I've solved problems (and that's what it's all about) using 50 lines of C feeding 100 lines of Fortran feeding 50 lines of Perl producing Postscript that compiled to the desired diagrams, because that's what suited the problem domains best.
Claiming that 'good hackers like language X' misses the whole point. Good hackers will use the best tool for the job.
Also, Graham seems to be conviently ignoring the 'can this be understood three years down the line' aspect. There is no point in having code that you can't maintain. That's where Java comes in - it's got a blend of power and syntactic salt help keep things maintainable. Asserting that maintainabilty isn't relevant just strikes me as something that's, well, immature.
I believe that he mentioned this because the guys at the startup viewed 'hacker' to refer to themselves, not to the crackers that they knew the marketers intended, and that they probably did in fact hate working on the AS/400 -- thus making the truth of the headline (for them) ironic.
:) Since, as you point out, the AS/400 is a secure box, the humor comes from the headline being true in both a literal AND an ironic sense simultaneously.
I thought it was pretty funny, actually.
NT was way ahead of anything else at the time, say, circa 1997. UNIX and graphics were not yet playing well together at that point. The Mac was still stuck with an unprotected single-thread OS underneath. Sure, you could run Apache on a Linux server, but realistically, that's all you wanted to run on Linux at the time.
Software maintenance is the single largest portion of the software life cycle. (IMHO)
So, why would I as chief programmer or system architect on a software project (that has a budget) allow pieces of the of software system to be built with languages that the 'common' programmer doesn't know? Sure, you could spend money training all the 'lesser' programmers in Python and/or PERL but, why waste the money? There are perfectly good languages that are defacto standard, provide loads of functionality, development tools, and are known by the 'so-called common' programmer. Every language has its pros and cons. So, if Java's weakness is uber-hackers don't like to use it than PERL's and Python's is maintainability. :) )
(However, I think author might be poking the tiger with comments like: "Of all the great programmers I can think of, I know of only one who would voluntarily program in Java." And we all feel right into that trap... I know I did.
Also, the single most important resource on a software project is people (again IMHO). Typical development scenario: New contract has been acquired. So, you as the "boss" hired 10 developers for the new project. One of which falls in the author's super-elite hacker class. The project's initial system delivery goes as smooth as glass cause the 'brains' of the operation (or the 1% as the author calls it) did majority of the work. Well, shortly after the initial delivery the hacker decides the project is now boring, the system was delivered and he or she is now looking for a new challenge. He or she now leaves the program and/or company. Now, there is a serious issue. Since the hacker did 90% of the work, now 90% of the core knowledge of how to maintain the system has left as well. (And I don't care who you are. Jesus himself couldn't write software that is perfect the first time. Bugs are always present and requirements can and do change. And Jesus also can microwave a burrito so hot he himself couldn't eat it!)
Given the author's profile of the hacker- Quiet, anti-social and loves his/her corner office with the door locked (which is a BS stereo-type)probably also didn't bother to pass any knowledge on to anyone else on the project. So, tell me again why this person was 'the most valuable thing' to us and the delivered system?
I personally love working with people are technically sharp but, also like working with other people and sharing info. I have caught myself being sort of elitist when I was the technical authority on something. But what does that gain you? Nothing in my experience. You want to be respected by your peers and co-workers? Share with them your knowledge not just lines of code (be it byte-code or interpreted scripts).
We are blind to the Worlds within us
waiting to be born...
He's not talking about the superiority of any language or implying that some languages have no use.
Think of it in these terms, if you're a salesman selling yachts, looking at the type of watch a potential buyer is wearing can quickly help you identify persons of extreme interest who you should take every possible care to treat right. This doesn't say anything at all about the ability of a cheap Casio to tell the time or perform reliably. It's just saying that people who wear Rolexes are the type of people you're looking for if you are selling yachts.
Similarly, Graham's suggesting that in his experience, great hackers he knows almost invariably enjoy using Python.
I know it's easy to get defensive when someone looks dismissively at the Casio on your wrist, but to say that they shouldn't do so because you can tell time just as well as someone with a Rolex is missing the point.
i read in the jargon file once that you cannot "become" a hacker -- rather, others must bestow it upon you. you have to earn it. you can't buy it. you can't decide you are. Yeah, you have to do stuff, but you should be doing it just because. Then others will decide you are a "hacker"
The More Laws, the less Justice --Marcus Tullius Cicero
"It was really interesting until he pointed out that great hackers work differently than I do, at which point it became clear that he is a moron."
Just like /. is unbiased.
I know there have been flame wars about using the word "hacker" for years, and I certainly don't want to start another one. I don't care if people use the term as a pejorative or a badge of honor. I don't care if it means a computer criminal or software developer. I don't care if it means white hat or black hat. That's a debate best left back in 1985.
;) But I don't think this view represents the majority of developers; it may not even represent the majority of open source developers. The hacker/craftsman camp is a small minority.
But having said that, I think it's time we retire the word "hacker". The reason I think this is because the use of this word, which is supposed to be so positive: the curious, problem-solving tinkerer, isn't really that positive anymore. I'm talking about hackers as craftsmen (another word the author uses in the article). Defining software development as a craft harkens back to a an age when the industry was young and still defining itself. An age when the industry was hidden behind equipment in a backoffice or university machine room populated by bright-but-eccentric pioneers. A time when the industry, and its pioneers, didn't know what its Best Practices were. Those days are over.
Today, the industry has matured in many ways. Today, projects, and the organizations that manage them, don't want a tinkerer who will sit in the backoffice and figure stuff out. They want well-rounded individuals who can gather and interpret requirements, communicate with their team, and develop elegant, well-designed solutions using best practices. They want Software Engineers and Software Architects.
There is still a camp out there that is resisting this change. They still believe in the craftsman lifestyle, and they still code with emacs (oops, another flame war!
The author makes the point that some developers are so much more productive than their peers because of how they use technology, but does he realize that those productive developers are not hackers/craftsmen pecking out PHP or perl in their emacs session? They are Software Engineers using latest-generation tools and languages, design patterns and best practices, object-oriented techniques and integration technologies like message queues, not to mention web services and remoting. And incidently, they're still employable.
----
"Oh, bother," said Pooh, as he hid Piglet's mangled corpse.
I have *never* met a true hacker who programmed in java
Pleased to meet you.
A true hacker would know that there is no "one language". I've "hacked" together scripts in shell script, batch, EMCAScript, VBScript, and yes.. Perl! I've also written applications in BASIC, C, C++, Java. Many of these applications started life as quick 'n' dirty scripts. As I needed better maintainability, I've rebuilt them in the latter languages because they become easier to extend and maintain.
I recall the day when Perl was the "Practical Extraction and Report Language". Now you can build entire geek community websites out of it. What happened? Perl grew up. It gained namespaces, OO-capabilities, became more consistent, etc. Not all scripting languages have this (i.e. batch files, yuck!). Some develop them overtime (look at the great strides that PHP has made since itself was a bunch of scripts written in another language). So even the best hacker tools mature. Does that make them less of a hacker tool, or more of a hacker and non-hacker tool?
Oh, and as for why anyone would program in Java? Well, personally, I have a wife and kids to feed. It just so happens that my bosses pay me to write applications that deploy to WebSphere servers. While I could use Jython, or probably some strange Java-Perl bindings that no doubt exist, I would be quickly fired leaving my family in an unreliable state of upkeep.
So, I "hack" in the evenings and on weekends. I "hack" at work to help get my job done. And you know what, sometimes I even do it in Java.
BTW, Paul Graham just went down several notches on my respectibility meter. What an idiot.
The problem is that the line between arrogant and asshole is pretty fine. If you have a great hacker who is arrogant and hard to get along with then replace him with a mediocre programmer who can work inside a team without dusrupting it.
Sometimes the arrogant assholes spend all their time telling everybody else how much they suck with brings the productivity of the whole team down.
evil is as evil does
The author of this piece seems to me to be right, within the context he's talking about. He does seem to miss another element, which I will denote with the phrase Hackers vs. Engineers.
A great deal of the work of software development is done by guys like me. We style ourselves Professional Engineers. I don't mind working in a cubicle, because I'm a pro, and most of the slobs working in the trenches get cubes. I don't mind working on dumb projects, or bad code, because I'm a pro, and that's work that needs to get done.
I do share a lot with the guys he's talking about. I take naps at work, because as he says, that's more efficient than zoning out at my desk. I like interesting problems. I enjoy writing code.
But I style myself a professional, which means that much of what he says is not (I insist) true about me (because such would be unprofessional, I insist).
This is just my opinion, and I apologize in advance for anything above that came out like me stating a "fact."
Actually, the fact that good hackers prefer Python to Java only really tells you something about the relative unsuitability of Java to hacking. That a language is not easy to hack with is not a reflection of the strength of the language, it a reflection of how "safe" the language is.
File under 'M' for 'Manic ranting'
In 1997? I had been using X11 on *solid* DEC workstations since 1992 or so, and Unix was more than capable of playing well with graphics. Hell, I was using X11 on relatively solid Linux workstations in 1993, and getting decent performance out of it!
NT 3.51 was a decent operating system, designed as it was by one of the experts on VMS. NT 4 (which was released somewhere around 1997) was an enormous step backwards, putting the graphics code into the kernel -- a step that it took until Windows 2000 to recover from.
A computer is a machine for getting wrong answers quickly.
Perl can help with that.
Or maybe they tried it and found it lacking?
And what is this fascination with OOP? The only task I can think of (please name some more if can think of any) that lends itself naturally towards OOP is GUI/Widget handling. Everything else is much better expressed using so-called "sum types" (read about ML to find out what they are) and pattern matching.
Forcing everything into the OOP way of thinking without even considering that e.g. the functional/declarative way of doing things might be better suited to some tasks is certainly not clever. So much for Ruby (and Java, but the Java people probably didn't know any better at the time).
HAND.
I think, by any definition I am familiar with, we can safely rule out that particular claim. Besides, maybe the best hackers in the world never shower, shave once a week, wear 10 year old T-shirts with stains, and (as a consequence maybe) haven't had sex in 5 years, or never at all.
Should we still follow their livestyle blindly ? I don't think so. So it doesn't matter which language the Uberhackers use, who cares if they use Perl, Python or Ruby. I use what I am most familiar and productive in myself.
how about something more important, like integrated OOP. nothing's worse than claiming to be heavily object oriented, that has a bolted on OOP model.
OMG, not the Ruby cliche again.
Python is not by any stretch less OO than Ruby. Having first class functions is not a liability, it's a strength. Object model is not bolted on Python - everything in Python is an object.
python reminds me so much of windows. everyone uses it, because it's all they know exists.
Ruby people go to great lengths to attack Python at every opportunity. For the most part this appears to be because modern Python renders Ruby pretty much irrelevant. Ruby is not really better than Python as a language, period. Ruby is better than Perl, and pretty much equivalent to Python on all linguistic accounts, but loses royally on maturity, community and industrial popularity.
Offset that with the fact that most Rubyistas that talk crap about Pythonistas don't really have experience with Python, but merely reiterate the misunderstandings of other Rubyistas. Repeating a lie often enough doesn't make it true - it makes for mediocre advocacy that might catch a few clueless perl refugees, but isn't going to work for "great hackers" which is the topic of today.
Save your wrists today - switch to Dvorak
At my last job, the guy who emptied out the garbage cans (so I guess that makes him the janitor) was a real computer enthusiast. He knew all about firewire, bluetooth, USB2.
He was a janitor in a State Government building, and he was about 40, so I'm guessing he got the job when he was a kid (maybe he bailed out of high school because it was boring) and got this job as a janitor. If I was 10 years or so from a full-ride pension, I'd empty garbage cans all day and hack all night, u'betchum.
My father is a blogger.
Perl OO is actually very elegant. Let's check the three primary characteristics of OO, against Perl:
Inheritance - How much "overhead" is there in creating a new class in perl? Almost nothing; simply set your package name and then start writing methods. Perl takes care of inheritance, even multiple inheritance on every method call. Since objects are usually created as hashrefs, there's no ambiguity about the contents of an object which inherits from multiple parent classes.
There's no need for separating declarations and definitions - just "use" the package names which you need - typically only when instantiating new members of those classes.
Encapsulation - probably perl's biggest advantage is that the hashref (associative array) is a first-class datatype in the language. There is no need for container classes, because you can store anything you like in a hashref. Hashrefs handle easily many real-world problem domains: categorisation of source data (e.g. sum by month), easy creation of data structures of arbitrary complexity, dynamic modification of said data structures. Programmers spend less time thinking up elegant designs for linked lists or btree structures to hold data. A hashref neatly encapsulates an object's instance data and it permits inspection. Sure it's possible to change a value inside a hashref without going through a class's setting method - but then, it's not perl's job to set the rules of object access. You set the rules yourself and you're solely responsible to follow them. Getting back to the hashrefs though, most importantly the use of hashrefs means that there is no need to to declare every single item of instance data which a class has - each class can add to and take from its instance data at will.
Polymorphism - a perl object is a reference to something, blessed into a class. Any perl code can call an object's methods without having to know anything about the class of the object. In C++ for comparison, a reference needs to be declared as some class, and only the methods defined for that class can be used on it. What if you want to pass in references to any of several classes? Well, all those classes have to have a common parent class, and only the parent class methods can be used by the code which is using the reference. What if they don't have a common parent class? Well that's tough, but there are a lot of kludges which C++ coders can use to get around the language restrictions, like casting references and templates. Perl OO has none of these design flaws - you have a reference, doesn't matter what it is, you can call its methods.
Memory management - unlike C for example, perl has automatic memory management. Storage is returned to the heap when it goes out of scope or when the last reference to it is deleted. Sure C++ has "new", but you have to know when to call "delete".
First class string support - most programs use strings a lot, and it's very convenient to have first-class string support within the language (and automatic memory management so strings can be extended without overflowing a buffer).
First class regex support - again, very convenient, very flexible, very quick to write
Certainly perl can be used to write hideously ugly and unmaintainable code - but then it can also be used to write neat and well-structured code.
I came from a C / C++ background. I found coding OO perl to result in much more natural OO design than was possible in C++. I could focus on designing a system of independent classes which provided functionality, and a set of interoperable classes which solved the application problem, rather than trying to fit my needs into what C++ could do, or even worse spending time trying to get around the limitations of C++. There's a reason that C++ is so devoid of public class
Different languages apply different degrees of rigidity at compile time. One drawback to scripting languages is that mistakes that could have resulted in compile-time errors become run-time errors instead. Grandparent was making a very specific point, and anyone experienced in C and Perl should have understood that point.
He isn't advocating that you switch to O'Caml - he's not even ready to switch himself, in professional life. He is describing the mindset that comes to someone who has used the conventional languages heavily for many years. You may arrive at that mindset yourself one day.
First off, I'd like to see those benchmarks. I'm not sure I believe them. Oh I'm sure such results could be achieved, but likely they were programmed in ways that do not take advantage of the best features of Python. Probably things like Fibonacci tests and the like. Pfff.
Second, I've got a secret to share with you about writing software. The secret is that in most applications not more than 5% to 20% of the code actually requires the speed that an optimized C/C++/Java implementation would give it. GUIs, text processing, database queries, networking (and just about any I/O bound) will be very close in speed in Python or similar languages to natively compiled code. In the cases of GUIs especially most of the time the CPU is simply waiting on the user anyways.
Now what about that remaining 5% to 20% you may ask? If you need the speed then implement that in optimized C or C++. Python is designed to interface such code easily. But do us all a favor and leave the baggage of you high performance languages out of the main application logic.
The ultimate plays for Madden 2006
Two words: static typechecking. This single property has very far reaching consequences. Most importantly, it allows to detect many programming errors at compile time that would go unnoticed in most other languages. Oh, and don't tell me C++ has a strong type system. It hasn't. For instance, I can do all kinds of nasty things with pointers that are never checked.
Other features:
- higher order functions, partial evaluation
- garbage collection (really efficient, not the time and memory consuming stuff from Java)
- close to the mathematical description of problems
- ...
The point is, I can still program the functional way with all its advantages, but revert to imperative style for the small amount of code that really needs to be fast. Personally, I still prefer Haskell, though (lazy evaluation is fun!).Sebastian
Any program can be written on a Turing machine. Or in Brainfuck for that matter.
And C++ can do functional programming. It *is* a functional language, in some respect.
No, it fails on most properties that make up functional languages: functions are not "first class", there is no static type checking, there is no partial evaluation, variables represent memory cells instead of values, ...
Sebastian
Now, see, you almost had a point when you referred to function objects. They can indeed serve many of the same purposes as closures. But really, such support as C++ does have for treating functions as first class entities is hacky and unreadable template garbage at best. I'm quite a fan of C++ for some things, but that sort of claim is just unrealistic.
Let's take a specific example. Compare the standard "fold" function in something like ML or Haskell with the hackery required to achieve anything close to the same effect in c++. In the functional languages, it's trivial. In C++, it's... well, if you think it's at all elegant, please feel free to post your implementation here so everyone else can learn from it.
Huh? Even people like Andrei, who have written feature articles on this subject, can't provide C++ with anything close to the elegance of a typical functional programming language's "match" construction.
Um, no. There is a world of difference. Most of that world is full of side effects, things which a purely declarative style makes rather difficult, no?
Of course. So can assembly language. Whether they can do it well enough to be of any real use is a different question entirely.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I'm a painter as well and I love oil paints. I think your idealised Engineer is just that - an ideal. In practice, I don't think people who make software are like engineers, or like scientists, I think many software creators are like painters. And like painters, I think software creators have affection for their tools.
Show me someone who has just created their first language with flex and bison and doesn't get a bit of a buzz out of it. Show me someone that has architected something beautiful but cannot see the beauty in it.
No, I think you have an unrealistic view about software. And if I'm no longer an 'engineer' I'm not sure that's something I really care about, never having claimed to be building bridges in the first place.
I'm uncertain what you mean when you suggest that "the current state of O'Caml is that interfacing to these kinds of 3rd party libraries (using standard DLL or share library interfaces) is almost unworkable."
Are you referring to the ability to construct bindings for shared libraries written in C? Are you referring to being able to generate bindings to shared libraries written in C? Are you referring to being able to write short annotations for introducing symbols from shared libraries written in C in OCaml code?
I suppose one of the problems with being vague is that people have no idea what you're asking.
You can write bindings to C libraries by hand using the FFI, like you can with Python, Perl, or Java.
There are ways of generating wrapper code for interfacing to shared libraries, like CamlIDL and SWIG. You could also generate interfaces for use with the Dl module.
The Caml Humps site is a good place to start looking for some of the presently available libraries.
I think a far more annoying aspect of Objective Caml is that it is not currently possible to have natively-compiled dynamic shared libraries written in Objective Caml; all programs will be statically linked to Objective Caml libraries. You can load dynamic bytecode, but that's really just not the same.
There once was a program for wrapping Objective Caml code into a DLL but I don't think it has been kept up to date, it's a dirty approach, and as far as I recall it only worked on Windows.
There's the SCaml effort, but it seems to be falling behind, is incomplete, and only works on a few platforms.