Chosing a programming language for today and the next 10 years

[Kevin Fries]

On 03/23/2011 10:03 AM, Taylor, Kaia wrote:
> I read that you want a win desktop application, as opposed to a device 
> driver, for instance.  I am guessing that code efficiency is lower 
> down on the list than coding time.  So I see it as a matter of 
> balancing how quickly you want that desktop app written, versus how 
> much ooh and aah you want for jumping right into C/C++.
> What if you:
> 1. write your desktop app in visual basic.
> This may take you >5 times less time to write, based on my own VB vs. 
> C++ learning experiences. I know it's something like "minus 2,322 geek 
> cred points" for admitting you wrote something in visual basic.  But 
> in exchange, you get your app out and tested and improved and the end 
> product will be better 6 months from now.
> 2. start learning C/C++ on the side, by working on porting that 
> app.  First port the parts of the app which could use optimization.
> 3. along with learning coding in the next 10 years, keep up on 
> improvements automated code optimizers, emulators, and porting 
> tools.  To me, using these tools means that I can get the job done 
> more quickly without necessarily going through the programming 
> learning curve that I'd have needed 10 years ago.
>

I have used this approach on several occasions, but it really depends on 
what you are trying to accomplish.  Different languages have different 
strengths and weaknesses.  I will give you my list of languages, and 
where I see each being the better choice.

C/C++ -

This one is the big kahuna ain't it.  Its fast, secure, and produces 
real applications.  But its also not portable nor scalable.  You write 
programs in C/C++ for a platform, to do a job.  You want a Windows 
driver, C is your man.  You want a Windows desktop application that is 
more than a trival front end, C++ is your friend.  You want these things 
to still be around in 10 years, yep, C/C++ can't be beat.  So what's the 
cost?  Subjective to platform changes (Window/Linux/Mac all generally 
require code changes unless your program is pretty trivial, and don't 
even think about taking those programs mobile)

HTML/Perl/PHP/DJango/Rails/JSP

My favorites in this list are plain old HTML, PHP and Rails.  Not every 
page needs to be dynamic, sometimes it more important to just get the 
information out.  Simplicity can be quite elegant.  When you do need 
more dynamic information (a blog site for example, or a site that 
customizes its content by the user), PHP can't be beat.  But PHP can 
also be a security nightmare.  Also, the level of complexity and 
features do not scale well in PHP.  Yes some people have written some 
really big stuff in PHP, but they really shouldn't have.  To up the ante 
yet another step, I like (Ruby on) Rails.  This has moved out of the 
fancy webpage and into the application that uses HTTP as its I/O.  PHP 
is still a webpage, Rails is a program.  Until Rails 3.0 proves itself, 
I am still weary of its ability to scale though.  For truly enterprise 
class web sites applications, you can't beat JSP (i.e. Java).

Python/Ruby/Perl/VB/Mono/Java/Flex

C and C++ is some pretty heavy lifting, and the second category produces 
great cloud and intranet applications, but where do you go if you need 
something in between.  Something that runs locally not via the web, but 
is more flexible than C/C++.  Every item (except for actual Visual 
Basic, but is fixed by using Mono) is cross platform.  Again, I take a 
tiered approach to which I like.  Python is a procedural language that 
is masquerading as a object oriented one (for all you python fanboys out 
there, I am right, and if you don't understand why, maybe you need to 
have a better understanding of security mechanisms in object 
orientation).  I have some real security concerns about python, due to 
this trickery.  However, it is very handy, and useful language for 
writing some killer scripts and command line utilities.  In this area, 
Python does a brilliant job at replacing Perl.  When I am looking for 
something that adheres better to object oriented concepts, and has 
better encapsulation, I move up to Ruby.  Python and Ruby also allow you 
to produce an application that contains multiple faces, such as web and 
desktop, on Windows, Mac and Linux.  Both languages also have decent 
interactive consoles that allow for realistic RAD development (as 
opposed to the Waterfall used in Java and C/C++).  However, Ruby's 
better encapsulation allows for much better and more flexible features 
to be extended later.  Plus, nobody does ActiveRecord like Ruby, and 
everyone should.  Databases, x500 directories, file systems, all use a 
simple and uniform interface, Ruby is really a step up.  Both Python 
(via DJango) and Ruby (via Rails) allows you to reuse your desktop 
objects in creating web based services.  So, a modern day equivalent to 
the old Client/Server model would have a web server providing a part of 
your functionality and a independent desktop application.  Ruby is the 
best in the business in this model.  Flex can also be looked at here, 
but Adobe just does not seem to be getting the kind of traction, and 
really does not do as well as Ruby/Python on the cross platform front 
(anyone else give up on running the Air version of Pandora Radio... I 
rest my point)

Middleware

Databases are old fashion, but a necessity.  If you really want to add 
to your bag of tricks, look into some of the many no-sql databases.  I 
have looked at CouchDB, and liked it, and know many people that swear by 
it.  I personally like MongoDB.  Python, C/C++, Ruby, Java, all have 
object class library that allows MongoDB to blend into your application 
far more seamlessly than I thin CouchDB does.  At work, I deal with 
another big, big nosql database call MarkLogic.  The key to ML is 
learning xquery and xpath, as well as xml and xslt.

Front Ends

Lots have tried, none has become dominant.  If you are writing for 
Windows, and are OK with limiting your market that way, the Windows API 
is well documented and fairly simple to use.  Windows and Mac are both 
able to use the GTK (i.e. Gnome) or QT (i.e. Kde) windowing kits.  But 
both are difficult to deploy on Windows for the average user.  Java has 
its own windowing kit, and nobody, not even Oracle really likes the damn 
thing.  You may want to look into one of the independent 3rd party 
windowing kits.  Most of them are simply a library that needs 
installed.  In the Windows environment, this library can be included 
with your install.  A simple search and you can look at hundreds of 
these, but I would start with wxWindows, Fox, SDL, and FLTK.

I hope that my rundown was not too confusing.  I am sure many on this 
list will agree and disagree with much of what I said.  Other will have 
their opinions, some may rank the products in a different way.  So, your 
mileage may vary.

Good Luck
Kevin Fries
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.PLUG.phoenix.az.us/pipermail/plug-discuss/attachments/20110323/0cd3744f/attachment.html>