   Can you help me pick a programming language without starting a flame war?
  I have designed a fairly basic CLI perl script to telnet to a selection of roughly 400 different routers between 3 different vendors, retrieve information, and then format it in the same basic style regardless of vendor. I was looking to expand this and automate further commands when I came to the revelation that this would be much more user friendly if it were designed to be an  actual GUI window with super shiny buttons to click on and such.That's where you come in. I'm thinking of making the switch to Java, C++, Python, or perhaps even sticking with Perl for creating this application. I was hoping I could get some of gamedev.net's esteemed opinion on which language they would use and maybe a little bit of the why (hopefully without starting a flame war). Some relevant factors may be...-I have experience with Java, C/C++/C#, and now Perl all to varying degrees but am far from mastering any of them which is why I've come to you to help me decide which to focus on for this project. -My overall programming experience is somewhere between newb and moderate programmer for these languages. -This is going to be run on a Unix box running Solaris 10/GDE.-Web based application is out of the question for a multitude of reasons. Although after I make this I think I might be able to get management to sign off on a web server for me. And just a brief summary for those of you skimming, I'd like to settle on a language I can use to: -Telnet to a multitude of routers-Do a large amount of string parsing and comparison -Have a visually appealing GUI window with buttons to click on and what not-Do all of the above with the least amount of coding/complication Thanks in advance for your opinions and time <3   
Quote:Original post by n00bornAnd just a brief summary for those of you skimming, I'd like to settle on a language I can use to: -Telnet to a multitude of routersAny language these days will allow you to use TCP sockets.Quote:-Do a large amount of string parsing and comparisonPerl.Quote:-Have a visually appealing GUI window with buttons to click on and what notThis depends more on the GUI library than on the language.Quote:-Do all of the above with the least amount of coding/complicationThis is very tricky. Perl will require little coding/complication now, but in my experience long-term maintenance is harder than with other languages.Overall, I think you could be happy with gtk2-perl.   ;  Alvaro, thanks for the response. I'm on my way out the door now but I'll look into  GTK2.   ;  I'd suggest C++. It's very fast even if you write horribly inefficient code, since it's quite smart in fixing your efficiency mistakes and optimizing the code. And using the STL library (it comes with every C++ compiler), string operations are quite easy too.You can also make your own special string functions very easily, for example a LowerCase() function using the STL algorithm functions.And then you can use the STL vector and map containers to sort and stores the strings. The vector class actually sorts faster than QuickSort because it uses multiple sorting algorithms based on the data structure to sort.   ;Quote:Original post by LumoojaI'd suggest C++. It's very fast even if you write horribly inefficient code, since it's quite smart in fixing your efficiency mistakes and optimizing the code.That's not even remotely true.I say stick with Perl and pick a nice GUI binding. Gtk2 or Qt would be my recommendations. (I prefer Qt, personally.)   ;  If you aren't worried about portability (to say linux or max) I'd say C# granted it isn't as *fast* as c++ (with equally well written code). The gui design and implementation is fairly easy and straight forward.   ;  To the OP: I'm going to throw in my support for sticking with Perl and finding a GUI binding library you like for it.Quote:Original post by LumoojaI'd suggest C++. It's very fast even if you write horribly inefficient code...Uh, no. Where do you get this idea from? Badly written code is badly written code, in C++ or Lisp or Malbolge.Quote:since it's quite smart in fixing your efficiency mistakes and optimizing the code.This is utterly false. When I work on optimization, I spend most of my time studying the assembly code generated by the compiler, and looking for ways to hint the compiler to generate better code by tweaking the C++ implementation. Even the best optimizing compilers out there can be brought to their knees in short order by sufficiently bad code.Quote:And using the STL library (it comes with every C++ compiler), string operations are quite easy too.The C++ standard library has pathetic string support. Actually, by comparison to Perl, pretty much every standard library has pathetic string support, but that's verging on the holy war we're not supposed to have [grin]Quote:You can also make your own special string functions very easily, for example a LowerCase() function using the STL algorithm functions.Or you could use a language whose standard library already supports things like that. Why roll your own?Quote:And then you can use the STL vector and map containers to sort and stores the strings.Other languages have associative containers, too, you know. In fact, most of them do associative maps better than std::map for various reasons. Also, std::vector is unsorted, so using it for sorted data is kind of... nonsensical.Quote:The vector class actually sorts faster than QuickSort because it uses multiple sorting algorithms based on the data structure to sort.Not quite.Yes, some C++ standard library implementations use hybrid sort algorithms to try and optimize performance based on some very, very simple heuristics. (The implementation shipping with Visual C++ uses the container's size as its rule for deciding how to sort, if I remember correctly.) Either way, there are plenty of times when a hand-rolled, data-aware sort can perform better than a std::sort.And in any case, nothing is ever "always" faster or better. Profile, profile, profile.Or, if you're like the OP and a tenth of a millisecond difference between sorting in language X versus language Y is totally irrelevant, just pick the language that makes the most sense and go get the job done.   ;Quote:Original post by n00born-Telnet to a multitude of routers-Do a large amount of string parsing and comparison -Have a visually appealing GUI window with buttons to click on and what not-Do all of the above with the least amount of coding/complication Perl, Python, C#, and Java will all be adequate for this purpose. Python's my favorite of those (Fine networking libraries; decent for string parsing; PyQt is great for GUI; coding is a breeze) but you won't go far wrong with any of those. If you feel like picking up a cool new language that'll make you forget about Perl for non-stream-processing tasks, go for Python. If you don't, write "Perl", "C#", and "Java" on pieces of paper, put them in a hat, and pick one out.   ;  Thank you all for your input. Before I was leaning towards Java but nobody really vouched for that here. I think I'm going to roll with Perl being I already have a portion of what I'll need completed, seems like that's got the most votes here so far, and glancing over GTK2-Perl and PerlQt I'm excited to give them a try. I'll drop back in after a couple weeks and reply to this post letting you all know how it goes. Until then <3   ;  Just adding my own point of view.Personally I would go down a php/web route because I have experience in that area and it provides all the necessary functionallity to get the job done. Nobody mentioned that possibility.I think other scripting languages like perl/python are quite good, and C is a little over the top for the task but it would be able to do it very well too.Likewise Java does indeed provide the requirements and would be very good for somebody who knew the ins and outs of Java.   