Re: Designing a Language for Library Developers
Posted: Oct 11, 2005 9:48 AM
> I am not developing Heron so much for application
> developers as I am for library developers.
> When writing libraries you tend to think about code quite
> a bit differently than when you are writing an
> application. You end up being more concerned with
> efficiency, flexibility, facility and extensibility.
I'm not sure there's a real difference, unless you believe that application developers don't care about efficiency, flexibility, facility, and extensibility. What is fundamentally harder or different about writing libraries? Is the idea that Heron will be a library-building language, and that application developers will use some other language (HeronScript?) and call into your libraries? Similar to how the low-level and high-performance parts of the Python, Ruby, and PHP libraries are all written in C?
I'm curious to know why you believe the programming problems faced by library developers are fundamentally different than the problems faced by application developers. I find that a lot of my application development time goes into writing libraries; application projects involving more than a couple of programmers are often centered around agreeing on and implementing shared code and idioms -- in other words, libraries. Libraries (at least as I think of them) are the verbs of the domain-specific languages that develop in the course of application development. Really good libraries are used in multiple applications or problem domains.
> when I tried to develop better libraries in C++ or Delphi
> or Scala is when I started to run into very hard
> limitations of the language (for instance writing
> efficient numerical programming libraries, constrained
> value primitives, SI types, AOP designs, reference counted
> pointers, optimized dictionary classes, policy based
> designs, meta-programming, etc.).
With all due respect you are still dodging the question. "Certain problems." "Hard limitations." Can you give any examples of a real programming problem you've had trouble implementing in a modern language, and explain what the problems are? I could understand, for example, that developing efficient matrix handling libraries in Ruby might be a problem, but why not fall back to C for the parts that demand high-performance? Maybe I'm missing something -- a couple of examples of real problems would help me "get it." Don't be afraid you will talk over my head -- I've written plenty of libraries and applications that use them.
> I believe that
> the success of a language for the most part is decided by
> the quality and variety of libraries which come with it,
That is certainly true -- it's hard to imagine Java, C#, Python, Ruby, et al. taking off if all you got was a compiler or interpreter. Libraries allow programmers to start solving real problems without making them write everything from the ground-up. Well-written libraries also serve as example code for people learning a new language. In its day even C's standard libraries were a big time-saver. C++ succeeded without any strong libraries (at least at first), probably because the stable, efficient, and familiar (if not exactly O-O) C libraries were available.
I believe one of the hardest parts of writing libraries is designing the API. As I wrote earlier I don't think most "average" programmers look inside libraries much -- they write to the API. Beyond the signature of a single library function there's the overall gestalt of the library -- the shared types and idioms that make it all hang together. The C standard library (with a few ugly exceptions) has a feel to it, a very Unixy feel of small blocks that can be put together to make something. What do you think about designing library APIs, and how will Heron enable better library APIs, and not just faster library internals?
> I recently
> had a personal revelation that I take suggestions and
> criticisms far too personally, and interpret them as
> direct attacks on my character. I am now making a sincere
> effort to be much more open-minded.
So the reference to The Psychology of Computer Programming I read in the comments to one of your postings hit perhaps close to home? In my experience -- to say nothing of the experiences documented by Weinberg, Yourdon, Brooks, etc. -- programmer ego has a lot more to do with programming project success or failure than languages or libraries.