On Wednesday 09 February 2011 15:07:07 Martin Vidner wrote:
> Amaranth: Why Ruby
> ==================
> 
> Robert suggested a survey to choose the language, but that would
> omit the reasoning, the criteria. The implied criterion is:
> 
> - popularity among current and potential contributors
> where Ruby wins the SUSE WebYaST people and other SUSE web/Rails
> developers
> 
> Let me add other ones I could think of:
> 
> - existing code base
> We have YaPI and User in Perl
> We want to interface with WebYaST in Ruby
> 
> - the above two combined: libraries and contributors of other distros'
> yast-like tools Fedora, Ubuntu, Pardus use Python
> 
> - runtime efficiency
> it matters for installation RAM requirements
> I don't have the data. Anyone?
> So far I found http://eigenclass.org/R2/writings/object-size-ruby-ocaml
> which basically says that rb 1.8 has bloated @members so use 1.9 or
> structs.
> 
> In the end I think that barring a veto by another criterion, the
> most important one is the availability of developers to make the
> transition. That results in Ruby, but I may be wrong and maybe there
> are five of you who will say "Yes! As long as it's Intercal!"
> 
> Please reply with insights into the criteria already mentioned, your
> preferences, or other criteria.

Actually, we should use upstream stuff where appropriate, and here I see 
Python more common. As long as we want to use e.g. PackageKit as back-end, we 
need to have Python installed (and occupying memory) anyway.

I think that we should look into libraries which will most likely be used and 
consider whether it is worth it aligning on a single language.

Jiri


-- 
Regards,

Jiri Srain
YaST Team Leader
---------------------------------------------------------------------
SUSE LINUX, s.r.o.                             e-mail: [email protected]
Lihovarska 1060/12                             tel: +420 284 084 659
190 00 Praha 9                                 fax: +420 284 084 001
Czech Republic                                 http://www.suse.cz
-- 
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to