2009/9/1 Malcolm Reynolds malcolm.reynolds@gmail.com:
On Tue, Sep 1, 2009 at 6:21 PM, Drew Crampsiedrewc@tech.coop wrote:
2009/9/1 Gustavo gugamilare@gmail.com:
Hello,
I also like to keep things simple. Here are a few suggestions, though.
In paragraph 4, you didn't mention "sockets" explicitly in the list. I don't know if that is intended to be included in "Networking", because Unix sockets are local to the computer.
To be quite honest, i don't know if CLtL3 actually needs sockets or networking. If we have FFI and extensible streams, we can build sockets and networking as library code.. right? I'm interested in hearing dissent on this one.
I've only been working with CL for 6 months so take all my opinions with that in mind.. but I think not having native sockets / networking is a big minus for a language in this day and age.
Section 2 of the charter mentions a 'standard library', which will include sockets and networking code. It is a lot easier, as a community, to ship a library than it is implementation-specific code. You, as a user, would use the 'standard library' and not care.
To a relative beginner like me, having to use FFI (I know what this is but have never touched it myself) and extensible streams (I don't really have a concrete idea of what these entail, is it in any way similar to Java *OutputStream classes?) just to write to the network seems like quite a lot of hoops to jump through as opposed to just using some standardised functions.
As a user, you would not need to write your own networking library just to use the network.. library implementors would do this for you, as they do now. The fact is that current implementations build their networking code on the equivalent of FFI and extensible streams, so that's all that really needs describing (read 'standardised') in order to build a portable sockets/networking library.
And I understand the situation now is that there are a plethora of networking libraries, which no doubt causes confusion when coming to the language for the first time...
The goal of the CLtL3 project is not to make the language easier for those using it the first time, it's to provide a solid foundation for library authors and promote portability among implementations. Many things in CL are confusing to newcomers, and it is not our expressed goal to change this.
Rather, the goals of CLtL3 are to provide enough of a "Common Lisp" base language so that things like networking libraries and the like may be implemented using portable constructs rather than implementation-specific ones. As a newcomer, this may not seem as important to you has using the same network library as everyone else, but from those trying to provide that networking library, it's extremely important... vital even.
I think forcing implementations to include network code which you can rely on to be maintained and debugged is a big win.
"forcing implementations" is not something we want or plan to do. We rather hope to keep things simple enough that the cost of adoption for implementations is a minimal as possible. If we have to force implementors to do anything, we'll have lost the battle before it's even begun.
For a new user like yourself, it's not going to matter if networking is in CLtL3 or the 'standard library' whatsoever. For an implementor, not having to support all that extra code in the library is a big plus and lowers the barriers to adoption... they can just ship CLtL3 compatibility, and let us worry about the 'standard library'.
Which do you think is better, many implementations of the same protocol scattered among lisps, or a single-sourced library built on portable constructs that have been provided by each implementation? My opinion is that the latter is likely to provide a better user experience with less effort to implementors than the former, and hence more likely to see wide adoption.
I'm playing devil's advocate to a certain extent, so please don't take my arguments as a brushing off of your needs. I'm interested in hearing rebuttals and more dissent, but the goals expressed in the charter must be kept in mind... keeping CLtL3 small and simple is the only way it's going to work, and if we can remove the need to describe something large and complex like networking and sockets, we'll have a better chance of actually achieving something rather than just arguing about it :).
Cheers, drewc
Cheers,
Malcolm