View Single Post
Old 3rd February 2012
ocicat ocicat is offline
Administrator
 
Join Date: Apr 2008
Posts: 3,297
Default

Quote:
Originally Posted by thirdm View Post
Here's a fuller answer about the decision to use Perl:

http://marc.info/?l=openbsd-misc&m=121155084515533&w=2
Very thoughtful answer, thirdm! Thanks for taking the time to contribute deeper reflection.

Why Perl is in base has been discussed on misc@ periodically for a number of years. My recollection centered around project developer comments such as the following:

http://marc.info/?l=openbsd-misc&m=123044348520838&w=2

However, your resurrection of Espie's take (as done above...) is more apropos(1).
Quote:
...I'm always unclear just how big an issue GPL in base is for OpenBSD and whether that issue isn't overstated by some people)
I suspect it is an unofficial dream to be rid of all GNU dependencies making at least one *BSD thoroughly self-sufficient from relying on any GNU tool in the base installation. As an example, several releases ago there was considerable discussion about moving OpenBSD to pcc:

http://undeadly.org/cgi?action=artic...20091228231142

As I recall, the motivation came from wanting to move away from GCC3.2 which was getting old in the tooth. pcc was considered, but many of the developers had concerns over whether pcc was mature enough & whether it could handle all of OpenBSD's supported platforms. The window for making a decision was short, so retrofitting GCC4 was the alternative chosen.

I suspect that there will be continued piecemeal moves away from GNU. If mandoc(1) (for replacing textproc/groff...) & tmux(1) (for replacing misc/screen...) are indications, there are collateral advantages. Increased stability is one. Clarity coming from reviewing the problems of old & seeing where usage is likely to go in the future is another. The original tools being replaced had been long used in enough situations for their deficiencies to become clear. Plus, there have been developers motivated enough to come up with working alternatives. Clarity didn't come from using newer shinier tools & languages; clarity came from understanding the fundamental problem space.
Quote:
I also like what ocicat said in suggesting shell script (though, personally, I go out of my way to avoid shell script beyond a two liner...
While I understand why you made this statement, I will nevertheless push back. Some of the most useful pieces of code I have written which I come back to time & again are shell scripts to backup & restore, plus build bootable USB flash drive configurations. They are not elaborate, but the bootable USB configuration script is over 250 lines. Shell scripting isn't sexy, but gluing together common Unix tools is a useful & practical skill. Could these be rewritten in Perl and/or Python? Given how I use these tools, keeping them compatible to OpenBSD's base configuration is a useful feature, so that excludes Python. Could they be rewritten in Perl? Sure (& I considered this at the time...), but there isn't much to gain. The scripts work quite fine as they are now, so until I have reason to revisit the decision, they will continue to be maintained & tweaked as shell scripts.

FWIW.
Quote:
...since you said your goal was to perhaps contribute to OpenBSD someday. I'm guessing you would start with making ports, in which case you'd need to know shell script, perhaps some Perl, Makefiles, and some C at a minimum. If you learned Python instead of Perl, maybe you could start by maintaining Python module ports.
This is a useful suggestion! However, depending upon the application chosen for porting, the list of tools one needs familiarity gets long (as seen here in your example...). When the question gets focused on what should be a person's first language, I still come back to scripting in some form. Scripting is practical, & nominal mastery can be attained in a few months. Not everyone needs to be fluent in C/C++, & as you know, good C/C++ programmers take years to mature.
Quote:
...but there are other worlds, and OpenBSD supports programming in them quite well too, despite the preferences of many of its kernel and user land developers.
I want to underscore your point here too. As I continue to be employed as a developer, I, too, keep coming back to the value of functional programming originally advocated by Lisp (& Haskell...). As time allows, I hope to explore these further.

But for those who dismiss the notion, functional programming idioms can be found in Perl & Javascript too(as examples...).

Again, thanks thirdm for your insight! You have made some compelling arguments.
Reply With Quote