<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.32.2">
</HEAD>
<BODY>
On Sat, 2011-10-15 at 10:47 -0400, Michael B. Trausch wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
On Fri, Oct 14, 2011 at 06:42:11AM -0400, Ron Frazier wrote:
> Hello all,
>
> Those of you that have read some of my prior posts know I've been
> threatening for some time to relearn programming after 16 years out
> of the loop. I discussed it here before, and we had discussions
> about the various merits, or unmerits of different languages. I
> really was planning to learn C++, after you guys convinced me to not
> target C#.
I will re-raise my recommendation that you plan to be versatile.
Today it isn't how fluent you are in a single language that matters,
but your ability to achieve fluency with relative ease in multiple
languages. And C# isn't a bad language at all; it is a very nice one,
with a very nice runtime environment that has a 100% free software
implementation that is available. No reason to avoid it, really.
> I have, sitting next to me, some of the best C++ textbooks out
> there, including one by the inventor of C++. The problem is, no
> disrespect to the authors, that these things are BORING, and
> intimidating. I mean, I have to go through 400 pages of for next
> loops, if then's, and variable setting, etc. to even get to putting
> a GUI hello world program on the screen. And, that's IF they even
> discuss GUI programming.
That is because GUI programming is, technically, outside the domain of
learning the language. Programming for a GUI is (largely) the same
regardless of what language you are coming from. GTK+, for example,
exposes the same API to Python, Java, C, C++, and C#, among other
languages. If you learn how to write GTK+ programs in one language,
then you can write GTK+ programs in other languages, too. Of course,
GTK+ is written in C/GObject, and everything else is a set of bindings
to it.
(I can't say anything about Qt since it isn't allowed on my system.
:-))
> Now, I know you have to learn the basics, and I know these things
> are foundational, but I think this is the least enticing way to
> teach it. Not only that, programming desktop computers doesn't
> excite me nearly as much now as it did a decade and a half ago when
> it was relatively new. Embedded programming interests me to a
> point, and I could do that in C++ sometimes, but I don't necessarily
> want to be programming thermostats and microwave ovens either.
> Robotics interests me, but it can be very difficult and expensive to
> develop your own robotics lab.
I suspect that much like the embedded programming I am (slowly!)
working on getting involved in, most of the expense will be up-front.
I need to create an area in my garage that I can use for assembling
circuitry and devices, and I need to increase my stock in "components"
so that I have enough general-purpose stuff. It seems that the best
places to get things from are all mail (or net) order, you can't just
run out and pick up an Atmel microcontroller at the local corner
store. (Though I heard something about Radio Shack possibly starting
to carry such things in their stores... never found anything to
substantiate that, though.)
> The other thing that interests me that I might be able to start
> development for on my own, is mobile computing, specifically
> Android. I recently heard that Android is the most popular smart
> phone OS on the planet. And, it's pretty much the only game in town
> for non IOS tablets. The thing is, you program Android in Java.
> So, I have to choose between Java and C++ since I cannot really
> learn two languages at once. So, I've decided to jump over to Java,
> before investing lots of time in C++, which I may come back to
> later. By the way, my introductory Java and Android books are just
> as boring as the C++ books, but I guess I'll muddle through.
Learning programming isn't nearly as exciting as doing programming.
:-)
That said, if you know Java well, it's not difficult to learn C++ and
the inverse is true. It may be easier to think of programming
languages as nothing more than a representation of a program (after
all, that is exactly what it is). You can write a program in one
language and then rewrite it in another language and it will be
substantially similar in both (unless you're talking about, say, C++
and Scheme or some other set of drastically different languages). The
more representation formats (notation formats, maybe?) that you are
familiar with, the better off you'll be.
> So, having said all that, do you guys have any thoughts on setting
> up a cross platform Java development environment, learning Java,
> learning Android, etc. I'm thinking using the Sun / Oracle JDK on
> both Windows and Linux, plus the Eclipse IDE, and whatever device
> emulators the Android books recommend.
All you _need_ is the Sun JDK and the Android SDK. You can create
your programs with a high-powered text editor such as Emacs. The
Android SDK comes with an Android emulator and you can set that up to
run different formats (phone, tablet) and versions of Android to do
all your testing on.
Eclipse is, I believe, the "supported" way to create Android
applications using the SDK, but every time I use it I wind up going
back to Emacs, which is far more responsive and easier for me to work
with. I truly hate environments that would have me go for the mouse.
> When I can, I'll get an Android tablet to try things out on. I have
> two good books on Android 2 from Apress. They've now come out with
> similar books on Android 3. All of them say to learn Java first
> though. I think there will be a lot of Android 2 out there for a
> while, so it might be fine to start with the books I have. Any
> thoughts and advice are appreciated.
Insofar as books for learning to program, I recommend the "How to
program" series from Deitel and Dietel. Java: How to Program was the
book that I used in my Java class, and as far as programming books go,
it was nice. As always, follow the examples, enter and run the code
yourself, and do all the exercises. They even have optional things
throughout the book that you can do, though you do not have to in
order to gain a working understanding of the language.
> Maybe, someday 8-( I'll see a GUI hello world that I created on a
> tablet device. The very large learning curve for this is
> intimidating and frustrating.
There is nothing "simple" about creating graphical user interfaces.
That is one reason that we have created such high-level abstractions
for them. HTML, for example, and XML are often used to describe GUI
environments because doing so programmatically can be lengthy and
tedious. The event-driven approach to programming in GUIs is also a
bit difficult to get a handle on when what is usually taught first is
procedural programming. (That said, once one "gets" event-driven
programming, I think they find that they'd rather not do it any other
way!) However, with event driven systems you have to be aware of the
events your program will have to process or your program could "fail
catastrophically" (e.g., crash) and that's of course no good.
To do "Hello World" in plain C using the Win32 API, if memory serves,
requires somewhere between 100-200 lines of code. To do the same in
plain C on GTK+ is less (maybe 50 lines, if I remember correctly),
owed in part to the fact that GTK+ has a completely different design
and you don't have to configure every little thing before displaying
something.
You can, in a high level langauge such as Java, display a Hello, World
on both of them in around 20 lines of code. Though when you think
about it, that is a very heavily abstracted 20 lines of code. Very
easy for us programmers. Turns into millions of lines of assembly
code on the computer's side, though.
But that's what all abstractions do: make things easier for us, and
slightly more difficult for the computer (meaning that it requires
more memory, more processing power, or more secondary storage than it
would otherwise). But then again, if those abstractions prove to be
too costly, you get rid of them in the late optimization stages of a
program's lifecycle.
</PRE>
</BLOCKQUOTE>
As the available computers become more powerful, the overhead costs of using abstractions is less meaningful for most applications. I can remember when a computer with 64K of RAM was hot-stuff with an 8-bit processor. Now 64-bit processors with multiple Gb of RAM and massive hard drives are available and abstractions causing much less noticeable penalties. That is assuming the penalties are even noticeable to the user.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
--- Mike
_______________________________________________
Ale mailing list
<A HREF="mailto:Ale@ale.org">Ale@ale.org</A>
<A HREF="http://mail.ale.org/mailman/listinfo/ale">http://mail.ale.org/mailman/listinfo/ale</A>
See JOBS, ANNOUNCE and SCHOOLS lists at
<A HREF="http://mail.ale.org/mailman/listinfo">http://mail.ale.org/mailman/listinfo</A>
</PRE>
</BLOCKQUOTE>
<BR>
<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
-- <BR>
<FONT SIZE="4">Jay Lozier</FONT><BR>
<FONT SIZE="4">jslozier@gmail.com</FONT>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>