Weblogs Forum - Designing a Language for Library Developers

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Designing a Language for Library Developers

47 replies on 4 pages. Most recent reply: Oct 17, 2005 1:28 PM by Max Lybbert

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 47 replies on 4 pages [ 1 2 3 4 | » ]

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Designing a Language for Library Developers (View in Weblogs)

Posted: Oct 10, 2005 4:01 PM

Summary
The design of Heron is more inspired by the problems faced by library developers than software developers.

Greg Jorgensen asked me recently:

I'm curious to know what kinds of programming problems you have that would prompt you to design and implement your own language. I get the impression from your postings that none of the available languages are sufficiently powerful to do what you want to do with them. I understand getting frustrated with the shortcomings of specific languages, but when I'm able to choose among even the small number of languages I am proficient with I can usually pick one that makes me happy and gets the job done.
I am genuinely curious to know if you decided to create your own language because you can't solve your development problems with an existing language, or if Heron is more of an intellectual exercise. What is it about modern programming languages that you find "eternally frustrating?" Is the frustration from real development projects you can't implement? Can you give an example of a real application that will be enabled by Heron, but not by C++, Java, Smalltalk, Scheme, Ruby, take your pick?

I couldn't answer the question satisfactorily and I got a bit defensive (sorry about that Greg). I just realized that question was discordant with my way of thinking because I am not developing Heron so much for application developers as I am for library developers. I have had a successful career developing applications in Delphi and C++. In general I have no problems writing software in these languages and many others (my current favourite language incidentally is Scala). However 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.).

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. One of my primary goals with Heron is to create a language which will make it much easier for myself and others to develop interesting and useful libraries. 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, and if Heron makes it easier for me to develop high-quality libraries then I think it has a fighting chance.

PS : My apologies to everyone to whom I have been defensive or flippant over the last year. I am trying to work these kinks out of my operating system. 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.

Kondwani Mkandawire

Posts: 530
Nickname: spike
Registered: Aug, 2004

Re: Designing a Language for Library Developers

Posted: Oct 11, 2005 12:42 AM

It would also be safe to assume that you are hoping to at some point
have Heron filter into Main stream application development, am I right?
This is said considering your blog: "Heron Needs or Killer App" (I think
it was called).

In any case, best of luck again.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Designing a Language for Library Developers

Posted: Oct 11, 2005 7:21 AM

> It would also be safe to assume that you are hoping to at
> some point
> have Heron filter into Main stream application
> development, am I right?

Yes definitely. Part of what will decide which application area Heron will become best suited for will be determined by the capabilities of the neccessary libraries available. At the beginning I plan on focusing on mathematics, science, graphics, and learning.

> In any case, best of luck again.

Thank you very much for the encouragement.

Greg Jorgensen

Posts: 65
Nickname: gregjor
Registered: Feb, 2004

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.

> However
> 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.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Designing a Language for Library Developers

Posted: Oct 11, 2005 11:05 AM

> I'm not sure there's a real difference, unless you believe
> that application developers don't care about efficiency,
> flexibility, facility, and extensibility.

I respecfully disagree: a library intended to be used outside of a handful of applications has more stringent requirements for these things than code only used in a single application.

> What is
> fundamentally harder or different about writing libraries?

Libraries generally have different requirements than software.

> 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?

Currently this is the way things are developing. Eventually though it will be possible to develop applications entirely in Heron as well.

> With all due respect you are still dodging the question.
> 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."

I don't think I can help you here if you don't already see any problem with using C or cross language development in general.

In the end this discussion comes down to the fact that if you are happy using existing languages, then I am not going to sway your decision about a new language (and I consider it futile to try), especially an immature and incomplete one like Heron.

> how will Heron enable better
> library APIs, and not just faster library internals?

I don't believe it will, but I don't see any significant differences between API's for most modern Object Oriented languages.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: Library Development vs. Application Development

Posted: Oct 11, 2005 1:11 PM

/* What is fundamentally harder or different about writing libraries?
*/

Let me wade in here. Something tells me it's a trap, but I've been snagged so often, there's no reason to try avoiding them now.

Imagine for a moment that as an inexperienced programmer I come to you and let you know I'm in the middle of developing a distributed application. Should I use UDP, FLIP (http://64.233.161.104/search?q=cache:mJfu3W90wtEJ:pdos.csail.mit.edu/~kaashoek/papers/flip.ps), tcp/ip, HTTP, XML-RPC, SOAP, REST(http://webservices.xml.com/pub/a/ws/2003/09/30/soa.html), ...? Or, what if I can get a 10% speed boost in my application, but I need to use twice as much memory? Should I do it?

Something tells me you'd say "that depends, what [are you doing | is your environment like | will the application's usage pattern be | ...]?" An application developer knows the answer to your second question, but a library developer may not. Yes, when you develop libraries alongside applications you'll know the answer, but when you develop general-purpose, stand-alone libraries, you're going to be flying blind sometimes.

And that difference is what cdiggins was referring to.

Greg Jorgensen

Posts: 65
Nickname: gregjor
Registered: Feb, 2004

Re: Designing a Language for Library Developers

Posted: Oct 11, 2005 1:53 PM

> I respecfully disagree: a library intended to be used
> outside of a handful of applications has more stringent
> requirements for these things than code only used in a
> single application.

Yes of course. But those are things you address with design, programming rigor, testing, etc. I'm not persuaded that software libraries differ so fundamentally that they need a different language than application code. At least that hasn't generally been the case, except where interpreted languages need certain high-performance library routines written in a compiled language. The question is, how does Heron (or any language) make it possible to write better libraries?

Suppose I grant that writing libraries is so different from writing applications that library writers need specialized languages to do a good job. How will Heron address that need? If I were a library writer what would sell me on Heron?

> Libraries generally have different requirements than
> software.

Well, yes, but what I'm trying to get from you is what (in your opinion) those different requirements are, and what plans you have to address those with Heron. Accounting systems have different requirements than web sites but many programmers have found Java or C# up to both of those tasks.

> Currently this is the way things are developing.
> Eventually though it will be possible to develop
> applications entirely in Heron as well.

I'm trying to imagine what a language would look like if it was explicitly designed to be good for writing libraries, but not good for writing applications. And I guess I'm trying to reconcile this (to me) new twist on the Heron pitch with what you've written before. I was under the impression just last week that Heron was going to be a multi-paradigm language that fixed the performance issues and other limitations of C++. I don't remember any mention until this thread that you thought of Heron as something other than a general-purpose programming language, so I'm a little off-balance.

> I don't think I can help you here if you don't already see
> any problem with using C or cross language development in
> general.

I don't see that writing some parts of the Python or Ruby libraries in C is any different from what you're proposing. If Heron is only for libraries, and the applications are written in something else, isn't that cross-language development? I personally don't see any problem using C when it's the best fit for the job, and I've been using C since it was released by Bell Labs, but I am aware of the many bad things people say about it.

> In the end this discussion comes down to the fact that if
> you are happy using existing languages, then I am not
> going to sway your decision about a new language (and I
> consider it futile to try), especially an immature and
> incomplete one like Heron.

I am not asking you to sway me to use Heron. I am just asking you to give more details on the thought process and design decisions. Like I wrote in my original comment on one of your articles, I am interested in the language design process and what new ideas you have. You are the one posting articles about your new language, so if you don't intend to attract interest and potential users, what is the purpose? I understand Heron is immature and incomplete, but that shouldn't (and hasn't) stopped you from writing about your ideas, so where's the harm in me asking you more about it? If that isn't what you want from these articles and blog entries, what kind of feedback and participation are you looking for?

> I don't believe it will, but I don't see any significant
> differences between API's for most modern Object Oriented
> languages.

Maybe that's because you've been out of application development for too long, designing libraries and languages. ;-) As an application developer I can tell you that when I have my pick of languages and tools, the libraries -- and most especially the library APIs -- are one of the most important things I look at. Maybe we're talking about different APIs -- I am guessing that you mean that how languages call library functions doesn't vary much. But since you're also talking about writing "better" libraries I'm saying that the APIs from the application point of view are almost always going to be a bigger selling point than the details of the internal implementations.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: Designing a Language for Library Developers

Posted: Oct 11, 2005 3:45 PM

/* [a library intended to be used outside of a handful of applications has more stringent requirements for these things than code only used in a single application.]

... But those are things you address with design, programming rigor, testing, etc.
*/

If I'm understanding this correctly, the point is that Heron will make design, programming rigor, testing, etc. easier, and thus a good fit for writing libraries.

For instance, Heron uses duck typing, so there are no virtual function calls, and performance is improved. Heron will have AOP, and that will be used to permit design with contracts, making testing easier. The multi-paradigm, resource management, and macro features will help with design rigor. And so on.

I think the main thrust is that Heron will likely not ship with application development wizards. You won't be able to click on the "make an internet browser" button, like you do in Visual Studio. But the feature list for Heron should make creating correct, high performance code easier. And while that is a welcome addition to an application developer's toolkit, it's especially welcome news to a library developer.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Designing a Language for Library Developers

Posted: Oct 11, 2005 3:48 PM

> If I'm understanding this correctly, the point is that
> Heron will make design, programming rigor, testing, etc.
> easier, and thus a good fit for writing libraries.

Yes that sums it up very well Max.

Greg Jorgensen

Posts: 65
Nickname: gregjor
Registered: Feb, 2004

Re: Designing a Language for Library Developers

Posted: Oct 11, 2005 4:09 PM

Max Lybbert wrote:
> If I'm understanding this correctly, the point is that
> Heron will make design, programming rigor, testing, etc.
> easier, and thus a good fit for writing libraries.

That's what I understand, too, at least in this thread, where Heron is presented as a language for library developers. But what I keep asking is, how will Heron make design, programming rigor, testing, etc. easier? What specific features does Heron have that make it better than any other language, for library writing or anything else? I've looked through the Heron postings with interest and honestly can't find an answer or an example.

> For instance, Heron uses duck typing, so there are no
> virtual function calls, and performance is improved.

Come on -- duck typing just pushes the "do you have this method?" question off and makes it a run-time problem. As Bruce Eckels and others have described, duck typing is really better described as latent typing. If Mr. Diggins has figured out how to implement duck typing more efficiently than static typing that would be interesting and worthy of discussion. Would a library that supports duck typing require some kind of virtual machine, like a JVM or .NET? Or does Mr. Diggins have a way to efficiently implement duck typing in a compiled language?

> Heron will have AOP, and that will be used to permit
> t design with contracts, making testing easier. The
> multi-paradigm, resource management, and macro features
> will help with design rigor. And so on.

I'm not asking what features Heron might have -- that's been all over the map. I'm asking: How specifically will Heron enable me to write better code (libraries or otherwise) than the other languages available to me? If that isn't a legitimate question to ask about a new language, or proposed new language, then what kinds of questions should I be asking? Go back and read the other threads on Heron. Mr. Diggins has made claims about Heron being better, faster, easier, more expressive, etc. many times but without any explanation or example. He has also criticized C++ and hinted that Heron will be better. I'm not just pulling these questions out of thin air.

> I think the main thrust is that Heron will likely not ship
> with application development wizards. You won't be able
> to click on the "make an internet browser" button, like
> you do in Visual Studio.

Mr. Diggins didn't say or imply that, and neither did I. It's possible to write application code without starting with a wizard in Visual Studio. Let's assume we all know how to write a program from a blank editor screen.

> But the feature list for Heron
> should make creating correct, high performance code
> easier. And while that is a welcome addition to an
> application developer's toolkit, it's especially welcome
> news to a library developer.

I would like to believe that he's on to something, because if he does have some ideas that will help anyone write more correct and faster code we will all welcome those into our toolkit, whether we're writing libraries or applications or filling in the blanks in a wizard-generated source file. I just want to know what those ideas are described in some way other than vague generalities.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Designing a Language for Library Developers

Posted: Oct 11, 2005 4:27 PM

> > For instance, Heron uses duck typing, so there are no
> > virtual function calls, and performance is improved.
>
> Come on -- duck typing just pushes the "do you have this
> method?" question off and makes it a run-time problem.

Not neccessarily, duck-typing can be done at compile-time. Take a look at the BIL ( http://www.kangaroologic.com/interfaces/ ) which is a C++ library using macros for compile-time duck-typing.

> As
> Bruce Eckels and others have described, duck typing is
> really better described as latent typing.

Those are incorrect characterizations.

> If Mr. Diggins
> has figured out how to implement duck typing more
> efficiently than static typing that would be interesting
> and worthy of discussion.

See my article at CUJ: http://www.cuj.com/documents/s=8188/cuj0409f/ or my articles at CodeProject.com http://www.codeproject.com/script/articles/list_articles.asp?userid=1295110

> Would a library that supports
> duck typing require some kind of virtual machine, like a
> JVM or .NET?

No.

> Or does Mr. Diggins have a way to efficiently
> implement duck typing in a compiled language?

Yes.

Greg Jorgensen

Posts: 65
Nickname: gregjor
Registered: Feb, 2004

Re: Designing a Language for Library Developers

Posted: Oct 11, 2005 5:34 PM

> Not neccessarily, duck-typing can be done at compile-time.
> Take a look at the BIL (
> http://www.kangaroologic.com/interfaces/ ) which is a C++
> library using macros for compile-time duck-typing.

Rather a clever simulation of duck typing. Odd that you are so critical of C++ and then endorse preprocessor tricks like this. And you told me just a few days ago to look at the "nightmarish" source code in Boost! I can live with unreadable code tucked away in a library file but I don't think I want this all over my code:


BOOST_IDL_BEGIN(IObject)
    BOOST_IDL_FN0(GetObjectSize, int)
    BOOST_IDL_FN0(GetClassId, int)
    BOOST_IDL_FN0(GetClassName, char const*)
    BOOST_IDL_FN0(GetObjectId, ObjectId)
BOOST_IDL_END(IObject)

> > As
> > Bruce Eckels and others have described, duck typing is
> > really better described as latent typing.
>
> Those are incorrect characterizations.

I'd ask you to explain why Mr. Eckels (and others) are incorrect, but I have by now learned that asking you to explain your statements is futile.

> > Or does Mr. Diggins have a way to efficiently
> > implement duck typing in a compiled language?
>
> Yes.

These lopsided conversations have a weird Popular Science letters page flavor to them.

The faster-than light rocket I'm working on will enable people to travel to the stars faster, safer, and more efficiently than current technologies, which I have mastered but found wanting.

Q: What's wrong with current space flight technology? Can you tell us more about your technology? Have you figured out how to overcome the laws of physics without killing the people inside? Can you tell me more -- I'm really interested.

It sucks. Not now. Yes. Read my article about goldfish farming for more details.

Sarcasm aside, your responses to sincere questions in almost all of your threads on Artima share the same quality: You make general and vague claims and statements, then someone tries to drill down for more information, then you get defensive, flip, or answer in some non-responsive way. I guess that's why the Heron community consists of you, the Heron Google group is your postings, with one exception, and the Wikipedia moderators described your entry on Heron as a "vanity project" but couldn't bring themselves to delete it because of procedural lenience. I have to give you credit for spreading the word about a mostly non-existent language -- the opening line in the CUJ article you pointed me to is a great example: "While interface constructs are a commonplace feature in many newer languages (Java, Delphi, C#, Heron, and D, for instance), they're not in C++." Which one of those doesn't belong?

In July of this year you posted on the O'Reilly network: I realized that my big problem was that I lacked focus and I was trying to stuff every cool technology I could find into the language. ... At this point, I am preparing the first version of the standard library, and I am wondering what I should emphasize. So my question to you is this: what would it take for a programming language to get you excited?

A programming language designer who could describe what he's doing without offending everyone who expressed interest would be a start. If you think floating a different set of feature mixes every week ("C++ meets Eiffel", "Generative, generic, dynamic/reflective, functional, object-oriented", "classes, contracts, interfaces, and crosscutting concerns") will get programmers excited, I don't know what to say.

Good luck to you... I'll be happy to look at Heron when I see the O'Reilly book.

Greg Jorgensen

Posts: 65
Nickname: gregjor
Registered: Feb, 2004

Re: Designing a Language for Library Developers

Posted: Oct 11, 2005 5:35 PM

> > If I'm understanding this correctly, the point is that
> > Heron will make design, programming rigor, testing,
> etc.
> > easier, and thus a good fit for writing libraries.
>
> Yes that sums it up very well Max.

I get it now, thanks for clearing that up and explaining the advantages of Heron to me.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: Designing a Language for Library Developers

Posted: Oct 11, 2005 5:47 PM

/* [I think the main thrust is that Heron will likely not ship with application development wizards. You won't be able to click on the "make an internet browser" button, like you do in Visual Studio.]

Mr. Diggins didn't say or imply that, and neither did I. It's possible to write application code without starting with a wizard in Visual Studio. Let's assume we all know how to write a program from a blank editor screen.
*/

I didn't mean that in a flippant way. I know there honestly is a "web browser" button in Visual Studio (or at least there was one in Visual Basic a few years back), because an old friend of mine used to use it as an example of how much more productive he believed Visual Basic made him. That he had no grasp of grammar issues completely escaped him.

I originally wanted to write "no GUI interface," but that's not entirely accurate since Mr. Diggins is working on some primitive graphics library. I couldn't think of any good wording to explain that I was referring to wizard code without the characterization I used.

Now, from a blank editor screen, what are your most likely causes for confusion? In C++ one of the biggest is the fact that the steering committe is gun shy when it comes to adding new keywords to the language (virtual base classes are very different from virtual functions) (in Perl, it's that the designers have been adding keywords and almost keywords as fast as they can think of 'em). This has made for a terse language that often shoots programmers in the foot (or blows off their leg, as Stroustrup once said).

Heron has a syntax based on Pascal or similar langauges. That "feature" is meant to make comprehension of existing code easier, which leads to more correct code. Ada programmers will tell you the same thing.

Another common cause for bad code is failure to test, or to document testing. Heron adresses this through design by contract (or will, in any case). That "feature" permits, and even encourages constant run-time and compile-time tests, which leads to more correct code and better programming rigor. The Eiffel folks even point to the fact that having the test in front of the programmer (instead of in a separate file as in Boost.Test or JUnit) can help remind him of what, exactly, the function promises to do and can avoid expensive errors (http://archive.eiffel.com/doc/manuals/technology/contract/ariane/page.html).

Heron will use delegation. Yes, that's available in other langauges. And it's popular because it leads to more correct code than function pointers. I have no experience with true delegation, but I understand it is also useful in other contexts.

Heron will require use of smart pointers to eliminate both resource leaks and garbage collection overhead so that software that must be efficient (such as libraries) will be.

Is that helpful?

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Designing a Language for Library Developers

Posted: Oct 11, 2005 7:10 PM

> > > As
> > > Bruce Eckels and others have described, duck typing
> is
> > > really better described as latent typing.
> >
> > Those are incorrect characterizations.
>
> I'd ask you to explain why Mr. Eckels (and others) are
> incorrect,

I understand latent typing to be synonymous with Dynamic typing, but I see that sometimes it means implicit typing.

http://c2.com/cgi/wiki?LatentTyping

So I stand corrected.

> but I have by now learned that asking you to
> explain your statements is futile.

Well you can forget about me responding to your questions any further. Despite how "well-intentioned" you claim to be, this post simply reveals that you are being simply combative and argumentative.

Flat View: This topic has 47 replies on 4 pages [ 1 2 3 4 | » ]

Previous Topic

Next Topic