On 03/23/2011 11:06 AM, Stephen wrote:
This is a great bit of information, One thing he does not mention is
the similarities in all of these languages, you learn one the others
get somewhat easier... (not all but many)

Good point...  And you are right in a way, but not completely.

You basically have four (actually three) different programming methodologies:

1) Scripting - This will be languages like Bash but advanced scripting can be accomplished with Perl, Python, and Ruby Scripting languages are all about accomplishing a single task and ending. Programs should never be persistantly running with one (IMHO) and only one exception, services. These are designed to generally use a series of utilities, and accomplish a "task" then end. Sometimes that task is to get a service running, in which case it may stay running to wait for the service to end, then clean up. But that is the only time a script should really stay running. A perfect place for scripts are command line programs, and cron jobs. Many people would combine Procedural and Scripting as the same thing. To me they are different due to how they are used, and the techniques you use would therefore change.

2) Procedural - C/Perl/PHP
Procedural programming you teach the system what needs done. It is like writing a how to manual. Do this, then this, then that. Common steps are often placed into separate packages called function or procedures depending on the language (some often say functions return values, procedures do not, and as a general rule, this is true, but some languages don't follow that convention). Learning to program in any procedural language will help you to transfer your skills to almost any other procedural language. The steps will be the same, only they syntax will change.

3) Object Oriented - Python/Ruby/C++/Java/Mono
OO languages are not that much different from procedural ones, and yet, nothing like them. Mostly the changes are in the techniques used rather than the actual language changes. But, there are some very fundamental differences. Security procedures that allow you to hide and protect code is very different between the languages. For anyone wanting to discuss how Python is Object Oriented this is where I will kill you. In a true OO language, code should scope and be internal to the class, never external. I included Python here not because I believe its a great OO language (I don't think it is, but it is a fantastic scripting language), but because the techniques used are very OO based. If you are not familiar with Object Orientation as a separate subject, I would suggest learning that. Then using a strong OO language like Java or Ruby to learn how to implement what you learned. To move from one OO language to another, as long as you know good proper OO techniques, you will be better off re-applying your OO knowledge into that other language rather than try and reapply what you know from your other language.

4) Functional - XQuery
Functional is the new kid on the block. I am still getting tripped by this one, so maybe somebody else on this list can better explain it. My experience with it reminded me more of a disected procedural language with objects to make things easier. But like I said, I get slapped around by functional programming every time I go near it... I probably don't know it near well enough to comment on it.

Hope that helps
Kevin Fries


On Wed, Mar 23, 2011 at 9:57 AM, Kevin Fries <[email protected]> wrote:
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

---------------------------------------------------
PLUG-discuss mailing list - [email protected]
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss




---------------------------------------------------
PLUG-discuss mailing list - [email protected]
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss

Reply via email to