[PC-BSD Dev] PC-BSD scripting langiage... again

Torsten Eichstädt torsten.eichstaedt at web.de
Sat Mar 30 07:25:42 PDT 2013

I'm glad to see that this subject(s) triggers interest of more than two 

Would it make sense we start collecting requirements and arguments in the PC-
BSD wiki?

To avoid repeating them over and over (I do so, at least...) and bring them in 
a better shape, e.g. a table for easy comparison.  That would also make it 
easier to see where our opinions are personal likings, prejudices, and where 
more "objective".

It would also be possible to create very small "spike solutions" in different 
candidate languages to get a feeling and compare them.  Very important, too: 
ask users and collect feedback.

> [...JavaScript...]
> Contra:
> * No official standalone interpreter
Not official, but there is one in KDE (locate kjs).  Besides that, JS is 
standardized, and embedded in many software systems.  If kjs does not satisfy 
you, you can "plug&play" your own standalone interpeter within a day or two.

> * 'Strange' OOP methodology. I'm not JS professional but I can't see how to
> make more or less complex object oriented design using JS
Honestly, I feel you're biased.

We're talking about configuration handling.  That's the domain.  Obviously, 
OOP will help to do that job, but hopefully it should be possible with a 
_fairly simple_ design!  Please, let us praise the KISS principle every day!

'Strange methodology': Where?  What?  The 'strangest' language on the list of 
candidates is, indeed: Python!  Perl holds the 2nd place ;)

My nightmare is to envision that s/o (e.g. customer/user) who wants to change 
or add some simple things, needs to have a master degree in computer science 
and 5+ years experience in Python's specialties to get the job done...

> * JS is not traditional scripting language for Unix system scripting. So it
> has not some libraries and features. Also most of developers that makes
> deal with Unix scripting knows sh/bash/perl/python but not JS.

My father and grandpa worked at the "German Post", my grand-grandpa and his 
father worked at the "Reichspost" --> I work for the Post, too. ;)

On missing libs:  Yes, this might be a point.  But this will change when more 
apps are written in QML.  You may want to have a look in Wikipedia or similar.  
JS is embedded in many software systems as a lean, but powerful scripting 
engine.  Most in the domain of web/internet, but there are others as well.

What do we need?
- Proper string handling, exception handling, module system: built-in.
- Test & Doc framework: available
- OS interface?  A basic one is built-in. If we need specials (i.e. call a lib 
directly to avoid parsing output from stdin), we would probably have to write 
glue for any other scripting language as well.

> IMHO JS was designed for UI scripting (does not metter html based UI or
JavaScript is ECMAScript.  It was not genuinely designed solely for UI, but as 
a simple, general purpose, multi-paradigma, scripting language.  JS was not 
designed as clean and scientifically like Python.  It evolved.  On the other 
hand: The more scientific way Python was designed did not lead to a less 
error-prone language... ;)

> not). I think that no reason to use it in places where more suitable
> solutions is.
That's the point.  Let's find the most suitable solution.

> IMHO Python whould be best choise
Yes I like Python, too.  But let's keep in mind that eventually there _will_ 
be people involved who are not fully educated in CS and programming.  They 
need a language that is less error-prone, and less complicated.

Another pro: JSON is a subset of JS's literal syntax.  Thus a newbie would not 
have to learn a data format _and_ a programming language; only the language is 
enough.  And if (s)he already knows JS (every web designer does) --> doesn't 
have to learn the syntax of config data files.  YAML is a superset of JSON, so 
the difference will not be large.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pcbsd.org/pipermail/dev/attachments/20130330/9a6c0d5e/attachment.html>

More information about the Dev mailing list