Scot P. Floess wrote:

I've not used C# - but as I understand it has similar constructs as Java (and C++)...

What about Java didn't you understand? Trying to understand what you didn't understand to make a suggestion...

I know, back in the day, I was all about Pascal :)

Well, that's why you like Pascal w/ P-Code, er, Java (writeln) and it's VM

mark "just *how* deep is that tomcat stack trace?"

On 13/12/10 17:32, Lamar Owen wrote:

On Monday, December 13, 2010 11:14:24 am Sven Aluoor wrote:

...

What programming language should I learn?

Python. You can find useful examples of python code throughout CentOS, beginning the yum itself. Get yourself a copy of 'Dive into Python' (can be had as a free download, legalling) and, well, dive into python!

I completely agree! Python is really worth looking at. And a lot of the tools on RHEL/CentOS are written in Python.

http://diveintopython.org/

I see quite some people suggest Perl. I've been in that camp as well, but I personally find Python much more intuitive than Perl, and also a lot more consistent. Perl is truly like paint, you can splash the colours around just like you want. The learning curve for Perl is quite higher than Python in my experience.

"Dive into Python" helped me to really get started, and it went fast with this book.

Python enforces you to be more consistent, which is not a bad thing if you want to understand better what you are doing in the very beginning. Later on Perl, Ruby, C#, Java, C/C++ might be a good alternatives, as they probably are much stronger in a lot of fields for more complex tasks.

But remember each tool has its own use case. You don't need a hammer when you have screws. It's the same with programming languages. And Python and Perl are often used as the "Swiss Army Knife". Useful for a lot of ad-hoc and not too heavy routine tasks, but you won't rely on it when going hunting in the wilderness.

kind regards,

David Sommerseth

On 12/14/2010 4:43 AM, Natxo Asenjo wrote:

...

Python enforces you to be more consistent, which is not a bad thing if you want to understand better what you are doing in the very beginning. Later on Perl, Ruby, C#, Java, C/C++ might be a good alternatives, as they probably are much stronger in a lot of fields for more complex tasks.

use strict; use warnings;

if you write Perl and do not use that, you will have problems, yes.

...

But remember each tool has its own use case. You don't need a hammer when you have screws. It's the same with programming languages. And Python and Perl are often used as the "Swiss Army Knife". Useful for a lot of ad-hoc and not too heavy routine tasks, but you won't rely on it when going hunting in the wilderness.

well, Perl helps me daily on the wilderness of my job. I do not understand the analogy, but it probably is my fault ;-)

Perl is easy to write, starts up relatively quickly, and has a lot of available modules for specific operations. Since it interpreted as plain text, you can include a file with the full syntax available for configuration instead of having to writing your own parser with yet-another-syntax for config files. But, it is somewhat hard to scale and maintain because people write in different styles and things that start small tend to have a lot of global variables that are hard to remember as the code grows. And perl is not great for GUI programs. I'd consider backuppc (which contains a nearly complete rsync implementation) and RT (a trouble-ticket system) to be ambitious projects for perl.

For larger scale things, look at java. Examples might be OpenNMS, Hudson, OpenGrok, or Alfresco. These are long-running servers where the startup time is not a problem and in Hudson's case the cross-platform compatibility is a big plus because a master program can schedule and distribute jobs across many different types of machines.

On 12/14/2010 10:46 AM, m.roth@5-cent.us wrote:

Yup.

<snip> > yet-another-syntax for config files. But, it is somewhat hard to scale > and maintain because people write in different styles and things that > start small tend to have a lot of global variables that are hard to > remember as the code grows. And perl is not great for GUI programs.

*snarl* There is *no* excuse for lots of globals. Pass your stuff. The most complicated programs I've ever written in perl (I guess that was the billing system for a very small telecom, 600-700 lines or more) had less than 10 globals, and maybe less than five (it's been 6 years since I was there, so I don't remember). Using globals is *lousy*, *lazy* programming, and I wouldn't trust folks that write anything more than a 20 or 30 line script to program *anything* until they'd gone back and internalized modular coding. And then I'd review their code for the next six months....

<snip>

Keep in mind that you can do some amazing things with a 30 line perl script that uses an assortment of modules to to the real work (try something like breaking email attachments out into files with some other approach to appreciate it).

But, there is a line of thought that says programming (perhaps not including text munging...) is really all about designing data structures and after that the code is obvious. I don't have a problem with the concept of globals in general. Perl's namespaces aren't really private after all, but for practical reasons you would usually want to put things in an array of hashes or some similar arrangement that you can loop over instead of having a bazillion variable names.

On 12/14/2010 1:16 PM, Adam Tauno Williams wrote:

Personally I've banned Perl from the network primarily because of the maintenance disaster that is CPAN.

And your perfectly maintained public source of equivalent functionality is in what language?

But, you should rarely if ever use CPAN code directly in Centos for the same reasons you wouldn't drop a stock upstream kernel every few days. Most of what you are likely to need are packaged - and maintained - in EPEL or rpmforge.

-- Les Mikesell lesmikesell@gmail.com

Kwan Lowe wrote:

On Tue, Dec 14, 2010 at 2:41 PM, Les Mikesell lesmikesell@gmail.com wrote:

...

On 12/14/2010 1:16 PM, Adam Tauno Williams wrote:

...

Personally I've banned Perl from the network primarily because of the maintenance disaster that is CPAN.

And your perfectly maintained public source of equivalent functionality is in what language?

But, you should rarely if ever use CPAN code directly in Centos for the same reasons you wouldn't drop a stock upstream kernel every few days. Most of what you are likely to need are packaged - and maintained - in EPEL or rpmforge.

:) Thank goodness for CPAN2RPM. I use it quite often for the occasional package that is not in the default repos.

As to Perl.. though it still is my preferred language for getting things done (mainly because I understand it that I first think out problems in Perl then convert to other languages), I have seen some bad, really bad Perl code..

And your point is? I consider the fact that *every* *single* *time* tomcat crashes ("you cannot have null pointer exceptions in java", the books all said), the stack trace is 150 or 200 calls deep. Show me something written in C, or C++, or perl, or php, or... that's that bad.

And then there was the guy I worked with in the late eighties, who converted a 3000-line RPGIII program to a 600 line RPGII program, while I went from a 2200-line COBOL program to 600+ lines....

mark

On Tue, 2010-12-14 at 15:33 -0600, Les Mikesell wrote:

On 12/14/2010 3:01 PM, m.roth@5-cent.us wrote:

...

...

As to Perl.. though it still is my preferred language for getting things done (mainly because I understand it that I first think out problems in Perl then convert to other languages), I have seen some bad, really bad Perl code..

And your point is? I consider the fact that *every* *single* *time* tomcat crashes ("you cannot have null pointer exceptions in java", the books all said), the stack trace is 150 or 200 calls deep. Show me something written in C, or C++, or perl, or php, or... that's that bad.

That's not really a language problem - that's a programmer assuming that exceptions won't happen and not bothering to catch them in appropriate places. But when does tomcat crash anyway?

...

And then there was the guy I worked with in the late eighties, who converted a 3000-line RPGIII program to a 600 line RPGII program, while I went from a 2200-line COBOL program to 600+ lines....

If you don't like java's verbosity, you might like groovy. You can, for example, print items from a database in about 3 lines. http://docs.codehaus.org/display/GROOVY/Tutorial+6+-+Groovy+SQL (and from any database type that has a jdbc driver, and from any platform that runs java).

Yes, but reference the preceding paragraph "programmer assuming that exceptions won't happen". The i-can-do-it-in-three-lines [a real favorite of Pythonistas] claim should always make one shiver - because it means the code doesn't manage errors (and is thus bad code).

Les Mikesell wrote:

On 12/14/2010 3:01 PM, m.roth@5-cent.us wrote:

...

...

As to Perl.. though it still is my preferred language for getting things done (mainly because I understand it that I first think out problems in Perl then convert to other languages), I have seen some bad, really bad Perl code..

And your point is? I consider the fact that *every* *single* *time* tomcat crashes ("you cannot have null pointer exceptions in java", the

books

...

all said), the stack trace is 150 or 200 calls deep. Show me something written in C, or C++, or perl, or php, or... that's that bad.

That's not really a language problem - that's a programmer assuming that exceptions won't happen and not bothering to catch them in appropriate places. But when does tomcat crash anyway?

<chuckle> But it *is* a language problem, because any pretty much any other language, you don't have function calls (oh, sorry, "methods") hundreds of calls deep.

...

And then there was the guy I worked with in the late eighties, who converted a 3000-line RPGIII program to a 600 line RPGII program, while I went from a 2200-line COBOL program to 600+ lines....

If you don't like java's verbosity, you might like groovy. You can, for

OO in general, and java in particular, IMO, is trying to enforce good coding standards by compiler... except, of course, that it doesn't work.

example, print items from a database in about 3 lines.

Really? I can do that in one: sqlplus (or mysql, or whatever) select * from mytable;

Or from C, using, say, Pro*C: Exec SQL select .... End-Exec

mark, being difficult

Les Mikesell wrote:

On 12/14/2010 3:38 PM, m.roth@5-cent.us wrote:

...

...

If you don't like java's verbosity, you might like groovy. You can, for

OO in general, and java in particular, IMO, is trying to enforce good coding standards by compiler... except, of course, that it doesn't work.

...

example, print items from a database in about 3 lines.

Really? I can do that in one: sqlplus (or mysql, or whatever) select * from mytable;

Or from C, using, say, Pro*C: Exec SQL select .... End-Exec

     mark, being difficult

I think besides being difficult you are missing the point - you can't do anything else with those values from a sql server's own monitor tool - and the way you do even that will vary with the sql server flavor. With groovy you can use any jdbc interface the same way and hand off the values to any other java jars or code you have around - maybe use jfreereport to graph them with a few more lines, etc. I suppose you could do that in C if you wanted to spend the rest of your life writing it.

Sure I can, but then, I know a good bit of sql as a language (bleah!). Why "the rest of my life"? Through the nineties, a *lot* of folks wrote a *lot* of C with embedded SQL as it's called.

But I think the real point of this thread is that perl isn't bad, bad programmers (sorry, "developers") will write bad code in any language.

mark

On 14/12/10 23:22, Les Mikesell wrote:

On 12/14/2010 4:01 PM, m.roth@5-cent.us wrote:

...

Les Mikesell wrote:

...

On 12/14/2010 3:38 PM, m.roth@5-cent.us wrote:

...

...

If you don't like java's verbosity, you might like groovy. You can, for

OO in general, and java in particular, IMO, is trying to enforce good coding standards by compiler... except, of course, that it doesn't work.

...

example, print items from a database in about 3 lines.

Really? I can do that in one: sqlplus (or mysql, or whatever) select * from mytable;

Or from C, using, say, Pro*C: Exec SQL select .... End-Exec

      mark, being difficult

I think besides being difficult you are missing the point - you can't do anything else with those values from a sql server's own monitor tool - and the way you do even that will vary with the sql server flavor. With groovy you can use any jdbc interface the same way and hand off the values to any other java jars or code you have around - maybe use jfreereport to graph them with a few more lines, etc. I suppose you could do that in C if you wanted to spend the rest of your life writing it.

Sure I can, but then, I know a good bit of sql as a language (bleah!). Why "the rest of my life"? Through the nineties, a *lot* of folks wrote a *lot* of C with embedded SQL as it's called.

The sql side is easy enough - the point you are missing is that you have access to any number of jdbc connections/versions at once (say you want to copy among different database types) and also to anything else already available as a java jar or source. Writing the code to display a graph on most platforms is the part I thought would take you a substantial amount of time, where with groovy you can include swing and jfreereport and hand it some values.

I planned to stay out of this discussion. But when I see claims that jdbc connections and doing copy between/among different database types, I must raise my voice.

Most databases to indeed follow SQL standards. But there are several SQL standards (SQL92, SQL98), and then you have different interpretations of them. So a INSERT statement which works flawlessly against a MySQL database might not work against PostgreSQL, SQLite or Oracle - due to that the MySQL syntax might not follow a defined SQL standard.

Then you can have a SQL query working flawlessly against PostgreSQL, but it uses features only available to PostgreSQL, like SEQUENCE. So Oracle, SQLite or MySQL won't understand NEXTVAL() .

And the list can go on and on and on and on ...

As long as the database API don't "stupidify" the API so remove the need of writing SQL statements yourself, you need to really do a lot of careful research and testing among all database types you want to support - and only use features which works identical for all types. Or else you need to add a wrapper layer adopting queries depending on the backend database.

SQLalchemy [1] does such "stupidifying" work. But it makes a lot of simple SQL commands more complicated if you know SQL very well. Hence my term "stupidifying". But it's probably the safest path. However, I don't know if SQLalchemy or similar modules are available to other languages than Python.

[1] http://www.sqlalchemy.org/

...

But I think the real point of this thread is that perl isn't bad, bad programmers (sorry, "developers") will write bad code in any language.

That may be someone's point. Mine is that a lot of good code has already been written and is easily available. Use it instead of writing your own bad code. And this is especially true for perl and java with a little bit of overlap in the places you might use them. Groovy sort of increases that overlap.

To reuse other libraries/modules/extensions is *almost* always a good idea, no matter which language you use. At least if that library/module/extension is used by many and have a good development trend and few annoying bugs. But sometimes, such an approach makes life much more difficult than it needs to be to solve a single task.

F.ex ... What if I have a C program and need a /very simple/ XML output, which is rather static. One simple solution is:

printf("<?xml version=\"1.0\"?>\n" "<mydata><sender>%s</sender><msg>%s</msg></mydata>\n", sender, message);

How many of you would use, say libxml2 to do the same job?

xmlDoc *doc; xmlNode *root;

doc = xmlNewDoc((xmlChar *)"1.0"); root = xmlNewNode(NULL, (xmlChar *)"mydata"); xmlDocSetRootElement(doc, root);

xmlNewTextChild(root, NULL, (xmlChar *) "sender", (xmlChar *) sender); xmlNewTextChild(root, NULL, (xmlChar *) "msg", (xmlChar *) message); xmlSaveFile("-", doc); xmlFreeDoc(doc);

(I avoided using scripting languages in this example on purpose, to avoid another Python/Perl/PHP/my-favourite-language discussion)

Both are valid solutions and produce exactly the same result. But using the external library in this case is actually more error prone. If you forget xmlFreeDoc(), this little application leaks memory. There are no checks for NULL pointers, causing a segmentation fault. While the single printf() line would just print "(null)" instead and not crash. Sometimes the latter is preferred and acceptable, but a segfault is almost never acceptable.

But the printf() solution also have a few other nasty gotchas which libxml2 will handle gracefully. Imagine if the message string contains HTML data, or just a single ampersand. However, sometimes your program will just dump out numbers, and then suddenly printf() is just as good as the libxml2.

So there are times when using external libraries/modules/extensions are completely overkill. And there are times when doing it yourself is task too big. Most good and skilled developers usually see where this border line goes. The rest of the developers just hack something together and provides something which usually works very fine and that you don't need to read the code afterwards.

Bottom line is: It doesn't matter which language you use or which modules that language supports. What matters is: a) Is the language suitable for the task, b) Can the developer use the language and needed modules efficiently, c) Does the developer know how to solve the complete task wisely ... the rest is just a matter of personal taste.

kind regards,

David Sommerseth

On 12/15/2010 7:07 AM, David Sommerseth wrote:

...

The sql side is easy enough - the point you are missing is that you have access to any number of jdbc connections/versions at once (say you want to copy among different database types) and also to anything else already available as a java jar or source. Writing the code to display a graph on most platforms is the part I thought would take you a substantial amount of time, where with groovy you can include swing and jfreereport and hand it some values.

I planned to stay out of this discussion. But when I see claims that jdbc connections and doing copy between/among different database types, I must raise my voice.

Most databases to indeed follow SQL standards. But there are several SQL standards (SQL92, SQL98), and then you have different interpretations of them. So a INSERT statement which works flawlessly against a MySQL database might not work against PostgreSQL, SQLite or Oracle - due to that the MySQL syntax might not follow a defined SQL standard.

Then you can have a SQL query working flawlessly against PostgreSQL, but it uses features only available to PostgreSQL, like SEQUENCE. So Oracle, SQLite or MySQL won't understand NEXTVAL() .

I don't think I claimed that java/groovy/jdbc would make standard sql work with non-standard sql server types, but it can give you a connection to nearly every type of server with the ability to write your own queries and handle the results. Perl would have the equivalent with DBI/DBD. If you are just doing data copies/conversions, you might be able to do the whole thing with something like Pentaho's ETL tool that used to be kettle but is now PDI: http://kettle.pentaho.com/

To reuse other libraries/modules/extensions is *almost* always a good idea, no matter which language you use. At least if that library/module/extension is used by many and have a good development trend and few annoying bugs. But sometimes, such an approach makes life much more difficult than it needs to be to solve a single task.

F.ex ... What if I have a C program and need a /very simple/ XML output, which is rather static. One simple solution is:

 printf("<?xml version=\"1.0\"?>\n"
        "<mydata><sender>%s</sender><msg>%s</msg></mydata>\n",
  sender, message);

How many of you would use, say libxml2 to do the same job?

 xmlDoc *doc;
 xmlNode *root;

 doc = xmlNewDoc((xmlChar *)"1.0");
 root = xmlNewNode(NULL, (xmlChar *)"mydata");
 xmlDocSetRootElement(doc, root);

 xmlNewTextChild(root, NULL,
                 (xmlChar *) "sender", (xmlChar *) sender);
 xmlNewTextChild(root, NULL,
                 (xmlChar *) "msg", (xmlChar *) message);
 xmlSaveFile("-", doc);
 xmlFreeDoc(doc);

(I avoided using scripting languages in this example on purpose, to avoid another Python/Perl/PHP/my-favourite-language discussion)

Both are valid solutions and produce exactly the same result. But using the external library in this case is actually more error prone. If you forget xmlFreeDoc(), this little application leaks memory. There are no checks for NULL pointers, causing a segmentation fault. While the single printf() line would just print "(null)" instead and not crash. Sometimes the latter is preferred and acceptable, but a segfault is almost never acceptable.

But the printf() solution also have a few other nasty gotchas which libxml2 will handle gracefully. Imagine if the message string contains HTML data, or just a single ampersand. However, sometimes your program will just dump out numbers, and then suddenly printf() is just as good as the libxml2.

So there are times when using external libraries/modules/extensions are completely overkill. And there are times when doing it yourself is task too big. Most good and skilled developers usually see where this border line goes. The rest of the developers just hack something together and provides something which usually works very fine and that you don't need to read the code afterwards.

I usually either start with the simplest possible way or the most complete abstraction I can find, depending on the need for performance and the time it takes to digest the API for the high level tool. There's a 50/50 chance that this first choice will be wrong, but anything in between has generally been worse. XML::Twig would probably be my perl-ish choice for anything involving xml, particularly parsing it.

Bottom line is: It doesn't matter which language you use or which modules that language supports. What matters is: a) Is the language suitable for the task, b) Can the developer use the language and needed modules efficiently, c) Does the developer know how to solve the complete task wisely ... the rest is just a matter of personal taste.

Just tracking the available libraries and the bugs that are likely to affect your use of them is about a full time job though, so there probably aren't a lot of people that are equally capable of doing something quickly in more than a few languages. Consultants, of course, are always ready to say that they can as long as you are paying for the time it takes...

On 12/14/2010 2:55 PM, Kwan Lowe wrote:

On Tue, Dec 14, 2010 at 2:41 PM, Les Mikeselllesmikesell@gmail.com wrote:

...

...

Personally I've banned Perl from the network primarily because of the maintenance disaster that is CPAN.

And your perfectly maintained public source of equivalent functionality is in what language?

But, you should rarely if ever use CPAN code directly in Centos for the same reasons you wouldn't drop a stock upstream kernel every few days. Most of what you are likely to need are packaged - and maintained - in EPEL or rpmforge.

:) Thank goodness for CPAN2RPM. I use it quite often for the occasional package that is not in the default repos.

That keeps sanity in your RPM database, but doesn't help much with the situation where functionality in the modules is refactored and you need to update (or not) certain versions of different modules together. If you are pulling from someone else's repo, they will hopefully have tested the versions they've packaged already.

As to Perl.. though it still is my preferred language for getting things done (mainly because I understand it that I first think out problems in Perl then convert to other languages), I have seen some bad, really bad Perl code..

Yes, perl doesn't stop you from doing bad things. If it did, it would likely stop you from doing good things that no one considered before. But, how likely do you think it is that someone who writes bad perl code would do better (or maybe even anything...) in a language with more annoying syntax rules?

On Tue, Dec 14, 2010 at 4:20 PM, Natxo Asenjo natxo.asenjo@gmail.com wrote:

It kind of gets boring to see Perl attacked for no reason. The problem is: if you do not counter the claims, they show up in Google and then people will think Perl is bad. So this is why one has to set it straight.

It is quite funny that when pythonistas come accross 'bad python', they say: oh, they *clearly* do not understand the language, that is why this code is bad. So: why would it be different in any other language?

...

As to Perl.. though it still is my preferred language for getting things done (mainly because I understand it that I first think out problems in Perl then convert to other languages), I have seen some bad, really bad Perl code..

of course. Have you seen really bad (C|Python|Visual Basic|shell|.*)? I guess so too. Will that have to do with the coder of with the language?

It's a balance, certainly...

My experience is that the quicker you can get things done in a language, the more likely that you will find bad code examples. I've seen Perl code that does a system 'ls' then counts characters in the string to extract the size information.

Some years ago I saw a piece of code that generated code... The generated code would individually load every element of an array with a zipcode for lookups. Yes... Rather than load the array directly, the code generated a perl script that, on each line, loaded a number into a new element of the array. The generated code was thousands of lines long, took an hour to start up, and needed a E250 to run. At the time my first thought was that the developer got paid based on the number of lines of code... Still can't imagine why he would take such an approach.

Greetings,

On Wed, Dec 15, 2010 at 3:20 AM, m.roth@5-cent.us wrote:

Kwan Lowe wrote:

Um, that COBOL code I fixed?

That reminds me of a structural analysis fortran program into pascal in dos using expanded/extended memory with disk as virtual memory without a single goto etc.

Gosh I didn't keep track of the lines of code I shaved off it I guess at least one line per goto/branch.

Sigh... missing the fun of cursing heartily the original programmer/developer... Gone are those days.

Regards,

Rajagopal

On 12/14/2010 3:45 PM, Kwan Lowe wrote:

My experience is that the quicker you can get things done in a language, the more likely that you will find bad code examples. I've seen Perl code that does a system 'ls' then counts characters in the string to extract the size information.

But that's probably someone who learned to code in C. If you started with perl you'd almost never do character by character operations.

Some years ago I saw a piece of code that generated code... The generated code would individually load every element of an array with a zipcode for lookups. Yes... Rather than load the array directly, the code generated a perl script that, on each line, loaded a number into a new element of the array. The generated code was thousands of lines long, took an hour to start up, and needed a E250 to run. At the time my first thought was that the developer got paid based on the number of lines of code... Still can't imagine why he would take such an approach.

I don't think there is any explanation for that one.

On 12/13/2010 11:37 AM, Les Mikesell wrote:

On 12/13/2010 10:14 AM, Sven Aluoor wrote:

...

Hi folks

I have more than 12 years experience with UNIX system administration, but I am too stupid for programming. My only programming experience is shell scripting. I tried to learn Java, but don't understand it because it is too complicated for my limited brainpower.

What programming language should I learn?

A friend said that C-Sharp (Mono) is very simple. Is this true?

Perl is probably the easiest next step for someone who has shell scripting experience. The language can as complicated as you want to make it, but you can keep it simple if you like. The big win with perl is that pretty much anything you are likely to need to do has already been done with code available on CPAN.

On the other hand, if you had some reason to want to use Java (like a need to use existing code in binary jars), you might like groovy which is mostly compatible with standard java but can also act like an interpreter with much of the verbose requirements removed so it is much easier to see the logic of a program.

Perl++

It's like paint. You have a fairly basic set of tools, but they can be combined to make anything you can imagine. Like paint though, if you don't care about your work, you can end up with a bleeping mess. If you care about your art though, you can make powerful masterpieces.

Perl is strictly object oriented, though it can be used as such. It has very few enforced rules, so it's up to you to develop a clean coding style.

There is a line in the docs with regard to variables in module that, I think, applies to everything in perl.

Perl doesn't have an infatuation with enforced privacy. It would prefer that you stayed out of its living room because you weren't invited, not because it has a shotgun -- Larry Wall

Some people love the freedom of this ideaology while others hate it. Whether perl is right for you will depend largely on your take on this. If you prefer structure, then Python is an excellent alternative.

On Mon, 2010-12-13 at 14:49 -0700, Warren Young wrote:

On 12/13/2010 9:37 AM, Les Mikesell wrote:

...

On 12/13/2010 10:14 AM, Sven Aluoor wrote:

...

A friend said that C-Sharp (Mono) is very simple. Is this true?

I doubt you'll find it any less complex than Java. The two are very similar, conceptually. C# exists more for political and business reasons than technical ones; it fills the same space Java could fill, in a platform-agnostic world.

False. C# has significant technical advantages over Java - good Generics and LINQ just being two.

Another advantage over Java is the namespaces were not created by a addled drug addict. Seriously "Xalan", "Xerces", and "Struts"? (just to name three). Yea, that is clear. I'll take C# "System.Xml" and "System.ComponentModel" everyday.

Another poster mentioned a documentation advantage, but I imagine a lot of that advantage is eroded by being Windows and Microsoft centric.

No, not really. The portability is extremely good. Good code is strict code.

any case, I don't think the documentation advantage is enough to solve the core problem you likely had with Java, which C# shares, that being its relative verbosity and strictness.

Strictness is a *feature*. Especially for someone who wants to initially learn programming.

...

Perl is probably the easiest next step for someone who has shell scripting experience.

Seconded.

-1 Perl is a withering dinosaur.

Don't be distracted by the Perl 6 noise. Perl 6 has been "coming" for a decade now,

+1

I expect by the time P6 arrives very few people will care; Perl has been fading for a long time.

On 12/13/2010 4:32 PM, m.roth@5-cent.us wrote:

Adam Tauno Williams wrote:

<snip> > -1 Perl is a withering dinosaur. <snip> > I expect by the time P6 arrives very few people will care; Perl has > been fading for a long time.

ROTFLMAO! It'll wither some time after the last COBOL program is retired... and definitely after java dies with a stake through its heart.

Yeah - that is kind of funny, especially for sysadmin type work. And by the way, there is a usable Perl 6 implimentation released, for some definitions of usable: http://rakudo.org/. But, I'm not sure there's a good reason to move away from perl 5.

On 12/13/2010 5:20 PM, Warren Young wrote:

...

Strictness is a *feature*. Especially for someone who wants to initially learn programming.

The OP already tried that, with Java, and didn't like it.

The argument's bogus anyway. Many experienced programmers want to teach strictness from the start, apparently without considering how many of their peers started with a non-strict language. BASIC, shell, JavaScript, PHP...classic beginner languages each, and probably all with bigger installed bases than any other interpreted language mentioned in this thread. Dijkstra's assertion that such languages "...mentally mutilate [programmers] beyond hope of regeneration..." is disproven by decades of experience.

But more to the point, real world values don't fit theoretical static typing concepts. If you are interacting with humans or things humans read and type, you might as well let a language with dynamic typing deal with it for you (but dynamic vs. static isn't really the same as strict vs. weak anyway).

I'm assuming you don't wish to argue that the vast majority of programmers working today are mental cripples.

I doubt if there are a lot that can simultaneously think in procedural and object concepts, though. Someone who learns that code and data are different things and that data is not to be trusted will have a hard time dealing with objects where the only way to access data is to execute code associated with it.

On 12/13/2010 6:08 PM, Benjamin Franz wrote:

...

I doubt if there are a lot that can simultaneously think in procedural and object concepts, though. Someone who learns that code and data are different things and that data is not to be trusted will have a hard time dealing with objects where the only way to access data is to execute code associated with it.

I don't know about that. I started on Apple Integer BASIC back in 1980, dropped to assembly on multiple platforms, and eventually ended up doing OO style design in Perl in the 90s *before* it officially had OO. I remember my sister commenting something to the effect that I seemed to design code mentally in OO styles regardless of the actual implementation language a decade or so ago.

It's one thing to build complex data structures (like making your basic C data type "array of struct ...") so you can iterate nicely, but something else to think the code belongs to it.

Jerry Franz wrote:

Thinking the code belongs to the data just a mental model. One of many that may be used or not used at need for the exact same code. But never make the mistake of thinking any of them are "The Truth". A good programmer switches mental models as needed and is not wedded to any of them as "The Truth" - merely as *convenient to the task*.

+10

...and I started programming in binary, then moved up to assembler. When I finally got to FORTRAN IV I thought I'd reached nirvana.

As teaching languages go I still like Pascal and it's not bad as a general purpose language. For practical work I lean towards PERL and PHP, but then I do sys admin for work and websites for fun.

Define your task then -

Use the tool that fits the task... not the other way around!

-- Steve Lindemann, MSIS __ Network Administrator //\ ASCII Ribbon Campaign Marmot Library Network \// against HTML/RTF email, +1.970.242.3331 x116 //\ vCards & M$ attachments http://www.marmot.org

On 14/12/10 00:20, Warren Young wrote:

On 12/13/2010 3:02 PM, Adam Tauno Williams wrote:

...

On Mon, 2010-12-13 at 14:49 -0700, Warren Young wrote:

...

C# exists more for political and business reasons than technical ones; it fills the same space Java could fill, in a platform-agnostic world.

False. C# has significant technical advantages over Java - good Generics and LINQ just being two.

I meant to say it was *created* more for political and business reasons than technical ones. Yes, the two have diverged since that time.

...

Another advantage over Java is the namespaces were not created by a addled drug addict.

I don't think naming arguments hold much water. Memorization is a key part of learning any programming language. Nothing is truly intuitive in computing. ("The only intuitive interface is the nipple.") You may like your set of names more than another, but they all have to be memorized if you want to use them.

To the OP's complaint, I think both languages have a similar problem, that being the depth and scope of each platform's namespaces. They're both elephantine. With Perl, at least, you can start by ignoring CPAN and everything they added in Perl 5. The Perl 4 core is a powerful but readily grasped step up from shell scripting.

Besides, you shouldn't be throwing stones. There's another "mono" that is currently more common, according to Google.

...

...

Another poster mentioned a documentation advantage, but I imagine a lot of that advantage is eroded by being Windows and Microsoft centric.

...The portability is extremely good....

"Extremely?" http://www.mono-project.com/Compatibility

Mono is an impressive project, but you can't tell me someone wouldn't get into trouble by developing using Microsoft's documentation only.

Besides, CentOS doesn't come with a CLR, so I suspect it's not portable enough for the OP.

Mono is a Intellectual Property and licence minefield. http://www.linuxplanet.com/linuxplanet/reports/6801/1/ http://en.wikipedia.org/wiki/Mono_%28software%29#Mono_and_Microsoft.E2.80.99s_patents

And considering what's happening with Novell these days as well, I would be concerned relying on Mono until things gets clearer. The Microsoft agreement and Novell had is about to expire soon as well, iirc.

kind regards,

David Sommerseth

Warren Young wrote:

On 12/13/2010 9:37 AM, Les Mikesell wrote:

...

On 12/13/2010 10:14 AM, Sven Aluoor wrote:

<snip>

Your next step should be to something simpler, and with less of a difference to your existing experience.

...

Perl is probably the easiest next step for someone who has shell scripting experience.

Seconded.

Thirded. And if you eventually want to program, perl uses C syntax (mostly... but then, almost everything does these days, with exceptions like python), and it's not a big stretch to move. The advantage of going to perl is a) it's a scripting language, and so you get faster debugging, and b) all versions of *Nix have it installed, and, speaking of being platform-agnostic, it runs on all versions of WinDoze. <snip>

I say this as someone who has written substantial programs in a dozen different programming languages, and sampled probably a dozen more. Perl is your best next step.

Same here. Six heavily, a couple not much, and all shells. And M$ batchfiles, long ago. <snip> Try perl, you'll like it. We'll ignore the fact that, back in the nineties, at the end of the 104 or so page man page, the secret was that it stood for P(athologically) E(clectic) R(ubbish) L(ister)....

mark

Adam Tauno Williams wrote:

On Mon, 2010-12-13 at 17:14 +0100, Sven Aluoor wrote:

...

Hi folks I have more than 12 years experience with UNIX system administration, but I am too stupid for programming. My only programming experience is shell scripting. I tried to learn Java, but don't understand it because it is too complicated for my limited brainpower. What programming language should I learn? A friend said that C-Sharp (Mono) is very simple. Is this true?

<snip>

Another one to look at is Python. You can probably get off-the-ground

<snip> And python's the only language to use whitespace as a syntax element....

mark, shaking his head

On Monday, December 13, 2010 12:54:35 pm Benjamin Franz wrote:

But seriously, there are a fair number of (mostly older) languages that are fairly picky about whitespace. I still remember writing FORTRAN.

We still have one application running on a VAXStation 4000 being maintained in FORTRAN (controlls a 7,000 pound astronomical photographic plate 'scanner' (aka a microdensitometer) using an IEEE488 connected laser position interferometer servo system and a SCSI-connected CAMAC crate for general purpose I/O and the A to D pixel photometer readout). The FCC even did web cgi programs in FORTRAN. And there are a number of scientific packages still using FORTRAN that are still being developed and maintained. It is far from a dead language, and is still being taught as a major scientific language. FORTRAN and LABview are rather common in academia, as is Matlab.

We're looking at porting the VS4000's FORTRAN code to C on CentOS, but getting the CAMAC Linux drivers (uses the SCSI generic interface) to work has been a challenge.

Adam Tauno Williams wrote: <snip>

My only real usability gripe is the craptastic type management, static typing would be a big improvement. [But pythonista's heads would explode at having to eat their own dog-food about writing 'self documenting code'].

Hey, the dogs' food is USDA approved, I believe. That stuff, um, shouldn't there have been a recall.... <g>

mark

http://24.5-cent.us/egoless_documentation.doc, published in the late, lamented SysAdmin

On 12/13/2010 12:08 PM, R P Herrold wrote:

As the thread was for a newbie recommendation, I'd really consider Ruby before any of the others,

Yes, Ruby can work for much the same reasons I gave for Perl in my previous post in this thread. I'd say it has a bigger mismatch w.r.t. shell script than Perl does, but it shares the same sensibility and level of complexity.

In some effort to keep the thread on topic, some of the languages mentioned so far don't ship with CentOS: C#, Lua, and Pascal, that I saw. The OP didn't say, but I'm assuming part of the goal here is to be able to write programs that will run on any CentOS box without adding third-party software.

Here are the languages I found in the main CentOS 5 package repository:

- all the other shell dialects: the OP is trying to move past these

- Ada: not yet advocated for

- assembly: if the OP thought Java too tough, he ain't seen nothin' yet

- Awk: not yet advocated for

- C and C++: see assembly :) (No flames, please. I write C++ most every day, and have written substantial amounts of pure C.)

- Java: DQ'd by the OP

- Objective C and Objective C++: not yet advocated for

- Perl, Python and Ruby: already well advocated

- Tcl: not yet advocated for

I'm ignoring special-purpose yet Turing-complete languages like Postscript and bc, as well as those too tightly coupled to a particular platform to be considered general-purpose, like elisp and PHP.

On Mon, 13 Dec 2010, cornel panceac wrote:

my first language was pascal. if i'd had the opportunity, i'd start with c. herbert schildt's teach yourself c was great for me.

Ahh Schildt. Yes, I learnt from that book too. A tad dry, and it tends to teach you syntax more than real program design, but it's an excellent starting point, and if you work through it properly doing all the examples you do get a good base level of understanding. I'd definitely recommend it.

jh

2010/12/15 cpolish@surewest.net

cornel panceac wrote:

...

my first language was pascal. if i'd had the opportunity, i'd start with

c.

...

herbert schildt's teach yourself c was great for me.

I think C is an excellent place to begin. But try K & R (ISBN-10 0131103628) which is the classic introduction.

Schildt is reviled in the church of C. See http://accu.org/index.php?module=bookreviews&func=search&rid=608 where he is roundly rebuked. He doesn't do well in any of the numerous reviews of his books on the ACCU site.

He's even got an entry in the comp.lang.c FAQ: Q: I need a random number generator. A: Count errors in Herbert Schildt's C books. No one has detected any consistent pattern.

-- Charles Polisher

thank you very much, but i was talking about another book :)

LOL...great analogy..I think the details will be lost on many non firearm types...but I found it to be a great analogy...:)

On Mon, Dec 13, 2010 at 3:03 PM, Lamar Owen lowen@pari.edu wrote:

On Monday, December 13, 2010 03:15:48 pm Nick wrote:

...

This is a bit like saying "I have 12 years experience of hunting but I

too

...

myopic to aim a pistol," then asking "which firearm should I carry?"

To an extent; I read it more along the lines of 'I have 12 years experience hunting with a scoped rifle but am too nearsighted to aim a regular pistol with iron sights, what sort of handgun would you recommend' to which I would answer 'Remington XP-100 in .223 Remington, .308 Winchester, or .35 Remington, depending on the size game hunted, or Thompson-Center Contender, which should be chambered in something like .223 Remington for small game, .30-30 or .243 Winchester for medium game, and .45-70 for larger game. Recoil in the larger calibers will be significant. Scopes for these handguns are pretty much required, and range is comparable to a short carbine in the same caliber.'

In other words, the choice of a new programming language has something to do with what you're going to do with it. And much like trying to use a T/C Contender in .45-70 Government as a first hunting handgun, there are some languages that aren't really suitable for a first language. You need to start with something a little easier to handle, like a Ruger Blackhawk or an S&W L- or N-frame in .357 Maximum; you can load it with .38 S&W Special for a fairly easy to shoot handgun, and graduate up through .357 S&W Magnum and the hard-hitting .357 Remington Maximum; you could even get something in .357 SuperMag..... And scopes are available for that frame.....

If you've done shell scripting, pick something that can build from that; I mentioned Python, but Perl or Ruby would be just a good, really. The key point is to build on something with some familiarity, and while strongly-typed languages have their uses and strengths, 'scripting' languages are possibly going to be an easier learn. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

Patrick Lists wrote:

On 12/13/2010 05:14 PM, Sven Aluoor wrote:

...

I have more than 12 years experience with UNIX system administration, but I am too stupid for programming. My only programming experience is shell scripting. I tried to learn Java, but don't understand it because it is too complicated for my limited brainpower.

What programming language should I learn?

A friend said that C-Sharp (Mono) is very simple. Is this true?

Have a look at Lua (www.lua.org). Imo it's quite readable and less

<snip> Don't. I have literally never heard of it before, and I at least have heard of everything else folks have mentioned. Learn something that there's a *large* base of folks who know enough to help you.

mark "gee, no one's suggested lisp..."

On 12/13/2010 3:30 PM, m.roth@5-cent.us wrote:

...

Have a look at Lua (www.lua.org). Imo it's quite readable and less

<snip> Don't. I have literally never heard of it before,

It's quite popular in some areas, particularly as an embedded scripting engine in games.

Having written one substantial program in Lua, I can say it's not a great next step, particularly if shell scripting is a good solution to the OP's current problems. Lua is clean and simple, but as a replacement for shell...no. Just, no.

Besides, it isn't in the main CentOS repo.

On Monday, December 13, 2010 07:11:40 pm R P Herrold wrote:

One could do ** much worse ** than Lua (the rantings of the MSFT fanboi here for the patent encumbered kit, not shipped on CentOS, such as C# come to mind)

Or Intercal, although it's not in the repos.

Which reminds me of my favorite funny line in an RPM description, on Fedora now: [root@localhost ~]# rpm -qi moserial Name : moserial Relocations: (not relocatable) [snip]

Description : Moserial is a clean, friendly gtk-based serial terminal for the gnome desktop. It is written in Vala for extra goodness.

:-O (!!??!?!?!?) And while moserial (and cutecom) have their definite uses (I have used both), to have the language it's written in as part of the description beggars the imagination....

On 14/12/10 05:46, Nico Kadel-Garcia wrote:

On Mon, Dec 13, 2010 at 11:14 AM, Sven Aluoor aluoor@gmail.com wrote:

...

Hi folks

I have more than 12 years experience with UNIX system administration, but I am too stupid for programming. My only programming experience is shell scripting. I tried to learn Java, but don't understand it because it is too complicated for my limited brainpower.

What programming language should I learn?

A friend said that C-Sharp (Mono) is very simple. Is this true?

Learn Perl.

That's not so hard

Learn it well

This is a lot harder

: it's far more flexible and more scalable than shell, but doesn't ignore your hardwon lessons completely.

Most scripting languages are more scalable than shell, despite shell being quite comprehensive. But most other scripting languages (than shell) can do the same advanced tasks quite simpler.

A competent Perl programmer who has learned to *check their error conditions* is worth their weight oyster-crafted gemstones.

Quite so true.

kind regards,

David Sommerseth