[ruby-talk:22570] Re: OSSL opinion

Frykholm, Niklas wrote:

>>please, avoid the pitfall, common in Java APIs, of obscuring the starting
....
> I agree, it is horrible, but in all fairness you probably end up with
> something like this if you try to define a completely general crypto
> interface that:

Yeah, I know... I had to use an explicit factory in REXML.  What I really 
wanted was a way for a base class to return an instance of a subclass; this 
would have been the ideal solution:

        x = Source.new(someobject)   # -> StringSource, IOSource, ...

I'm sure there's an obvious Ruby solution, but I haven't had time to look 
into it too much.

> Java is enterprise-level "programming in the large" taken to its extreme.
> All cases are covered: "OK, so you want a checkbox label which mixes
> cyrillic, arabic (running in the opposite direction), kanji and braille
> with a different font for each character --- we can do that." This
> over-generality makes it awkward for simpler projects (and 98 % of the
> projects are simpler). And since everything is provided in one big honking
> runtime environment instead of in small loadable modules, it is impossible
> to escape it.

Hm.  I don't know if it is *impossible*.  Ruby stresses PoLS, but I believe 
an equally important motto is: "Make the common case easy, and the uncommon 
case possible."  Ruby supports this extremely well, but it is up to the API 
developers to make sure this happens.

<rant mode="on">
The problem with Java is that often the uncommon case is possible, but the 
common case is not easy, and any deviation from the common case requires 
you to dive fully into a difficult API that allows you to do the uncommon.  
A really nice API will provide for a sort of scaled approach, shielding the 
programmer from the stuff they don't need to worry about.

I suppose it is a little late, but I'd like to provide the caveat here that 
I'm only down on Java in comparison to Ruby.  I am a Java developer by 
trade, and have been doing it professionally since it was pre-1.0 alpha 
software.  I'm a bit soured by having to watch the API grow from something 
small, easy, and useful to something bloated and with a steep learning 
curve.  I don't know about you folks, but I just *can't* remember all of 
the Java core API... and I used to be able to.  This hasn't all been bad; 
Swing was, in general, an vast improvement over AWT.  Take the SQL API, 
though.  Originally, you could implement a subclass of ResultSet with a 
little effort.  They doubled the number of method calls in 2.0(?), which 
makes the interface a bit unweildy, IMHO.  

I just don't want to have to watch that kind of bloat happen to Ruby (or 
common Ruby libraries), and I like to stress KISS in my own applications.  
Electric XML (the Java library) is a perfect example.  XML APIs got bloated 
and obtuse with DOM and SAX compliance; I use XML in almost every project, 
and I've *yet* to see a case where I need, or where my job is made easier 
rather than harder, by a DOM or SAX compliant toolkit.  In fact, I've gone 
so far as to retrofit most of my applications with Electric XML which has 
uniformly made my own code more readable.  This isn't to say that DOM and 
SAX aren't a good idea; it is simply my opinion that they over-generalized 
it.  You can't just make a new Element with "new Element()"... you have to 
use factories for *everything*, which is tedious.
</rant>

> In Ruby we can provide both a simple Blowfish.(rb|so) which is as simple
> as
> 
> cipher_text = Blowfish.encrypt(plain_text, key)
> 
> for those who want that and a huge over-generalized CSP, if there ever is
> a need for that. The only thing we need to fear are namespace collisions.

This is good.

--- SER


-----=  Posted via Newsfeeds.Com, Uncensored Usenet News  =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
 Check out our new Unlimited Server. No Download or Time Limits!
-----==  Over 80,000 Newsgroups - 19 Different Servers!  ==-----