"Simple" Languages in FreeBSD

[Priyadarshan]

On Fri, 1 Jul 2016, at 07:57, Dimitri Minaev wrote:
> On 07/01/2016 01:52 AM, Allen wrote:
> 
> > Literally anyone who responds with an opinion, I'm interested. Being
> > easy to learn for someone who isn't great with Math but does understand
> > Unix is a plus but not a requirement. I was starting to teach myself
> > Ruby on a Linux box I was using for a while and Ruby did seem to be
> > going OK, but a lot of the FreeBSD Books I've bought recommend Perl,
> > and I've also had just as many reasons from people saying to try
> > Python, so basically any Language and what reasons would be great.
> 
> A huge part of my job is automation in UNIX and 99% of it is done in 
> Bash. IMHO, shell is a must for anyone working with UNIX, even though 
> it's not really a programming language in the common sense. About 15 
> years ago I used Perl often and I remember it as a very natural language 
> very similar to shell, but better. The syntax may sometimes look 
> strange, but most of the time Perl by default does exactly what you want 
> it to do.
> 
> The Python is in fashion these days. They say it's easy to learn and has 
> a clean syntax. Perhaps, I'm getting too old to learn new languages, but 
> I found Python verbose and awkward. The trend introduced by the 
> object-oriented languages of the last decades makes the programmer use 
> various helpers, wrappers, proxy objects, singletons and other 
> doubtlessly useful but clumsy contraptions. For example, let's write a 
> simple script that runs a program, reads its output and feeds it to the 
> stdin of another program. In Perl, it's as straightforward as this:
> 
> open(P1, "ls -la |");
> open(P2, "|grep ^d");
> while (my $l = <P1>) {
> 	print P2 $l;
> }
> 
> Quite natural, eh? Now, Python:
> 
> import subprocess
> a = subprocess.Popen(["ls", "-la"], stdout=subprocess.PIPE)
> b = subprocess.Popen(["grep", "^d"], stdin=subprocess.PIPE, 
> stdout=subprocess.PIPE)
> ls = a.communicate()[0]
> r = b.communicate(input=ls)[0]
> print(r.decode())
> 
> I'm sure there are other ways to do the same in a more concise way using 
> external Python modules like 'sh', but the idiomatic way, AFAIK, is the 
> one used above.
> 
> Besides, Python, however logical it is, may be unpredictable. For
> example:
> 
> In [1]: a=99
> In [2]: b=999
> In [3]: a is 99
> Out[3]: True
> In [4]: b is 999
> Out[4]: False
> 
> I found Ruby to be more like Perl. Even though it is an object-oriented 
> language, it has many shortcuts that make things simpler, like using $_ 
> variable to store the last read string. But I never liked OOP and put 
> Ruby away.
> 
> So, from the practical point of view I would vote for Perl. Some would 
> say it's too old, but hey, it's still more popular than Ruby, according 
> to TIOBE index: http://www.tiobe.com/tiobe_index
> 
> But the popularity shouldn't be crucial in the language choice. If 
> you're going to learn programming languages for fun, have a look at some 
> less popular alternatives. One of them is my favorite Tcl. It's a 
> language with very simple syntax, underestimated but powerful. Many 
> utilities used in other languages, were born in Tcl: Sqlite, Expect and 
> Tk GUI, to name a few. It's still very popular as a built-in language in 
> network hardware. It may lack some libraries supporting modern protocols 
> (AMQP, for example), but programming in Tcl just feels great.
> 
> Another interesting language is Scheme. There are many dialects of this 
> uncommon but beautiful language. Racket has one of the largest 
> libraries, but it's rather a language for students and teachers than for 
> the real world applications. Chicken Scheme and Guile are way more 
> practical and just as rich.
> 
> Other options include Erlang and Haskell. Go language is also 
> interesting, but it is IMHO a language for real programmers.


Thanks for this.

Python, Ruby, Haskell, Julia, even PHP, they have all something
to offer.

One should really try to feel what is closer to one’s way of
thinking about problems, since the language can really help, or
really be a hindrance.

Our company uses mainly Common Lisp, but we are also a Perl shop.

It is interesting to see new employees using so-called «new»
languages, slowly but surely getting interested in the «old»
Perl 5 (aka Perl Raptor), and ultimately adopting it as main
language to «think» about problems.