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

Torsten Eichstädt torsten.eichstaedt at web.de
Mon Apr 1 07:41:37 PDT 2013

> But what about server? IMHO kdelibs on server is not the best solution.
> Making (and supporting) own interpreter is out of scope.
Compiling kjs static breaks it out of kdelibs.  The resulting binary will be 
still fairly small, I guess.

> Not only configuration handling but also (maybe complex) tools. OOP is not
Contra.  I'm only talking about (more or less simple) config handling.  For 
more complex tools, whoever writes that is free to use any programming 
language, libs and frameworks (best) suitable to solve the problem.

> silver bullet, I know. Often OOP design let keep code simply and easy to
> extend (and support).
D'accord.  OO-design *done right* is a big help.  This often means: better 
restrict yourself and do not use specials just to save some lines of code.

> > 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. ;)
> Not exactly. People who have experience in Unix scripting in common case
> uses Perl/Python. JS people in common case have experience in the other
> things.
> So if you understand what (and how) to do something with Unix you (in
> common case) use shell/python/perl.
And IMHO the common case: Shell Script is dangerous and error-prone.
Python is not suitable for simple tasks *where users* shall be able to change 
s/th, because for newbies Python is too error-prone.
The same hold true for Perl, plus it's "uglier" than Python, harder to read.

> Many developers of open source projects making open source related tasks
> simular to work experience (and in parallel with primary job). That
> developers uses primary job skills to do something and don't have time (or
> wish) to make something exotic.
Yes.  But honestly, JavaScript is not exotic!  It's a widely used, 
standardized scripting language.  Any experienced programmer will be able to 
learn it within short time.

> We speak not only about desktop. Yes mixing scripting with QML/Qt apps may
> be reasonable. But PC-BSD is not only kde/Qt based desktop. It also CLI
> based TrueOS.
See above.  Build a static JS-interpreter and everything's fine.  Then a CLI 
and GUI (QML?) tool can easily share code to do the work, and differ only in 
UI.  PC-BSD's GUI-fied config tools are (all?) Qt-based (for good reason).

> We can also use PHP, why not? And all of GUI utils will be based on single
> QWebView. And we will got remote Web administration out of box.
Nice idea! :) Answer of Radio Erivan: In principle, YES, BUT ...

> In my view  any choosen scripting language should not replace shell
> scripts. It should be used for tasks too complex for shell scripting.
Yes!  But IMHO this is true for most tasks of config handling!  Look in the 
bug reports, if you did not already stumble over many bugs resulting from the 
inherent weaknesses of Shell Script.

Furthermore, many (most?) bugs could have been catched during development if 
tests had been used.  But that would mean, to catch error cases, you need 
better modularization, and exception handling.  Shell Script does not provide 
either... (there is exception handling, but it's only suitable for very simple 

> Personally,
> I'm not interested in the revolution. (Don't fix it while it's no broken)
See above.  Much of PC-BSD's config handling *is* inherently broken.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pcbsd.org/pipermail/dev/attachments/20130401/3248fc7c/attachment.html>

More information about the Dev mailing list