[ale] I've decided again to learn programming again

Sat Oct 15 11:58:28 EDT 2011

On Sat, 2011-10-15 at 10:47 -0400, Michael B. Trausch wrote: 

> 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.
> 

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.

> 	--- Mike
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo

-- 
Jay Lozier
jslozier at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20111015/07bf58ab/attachment-0001.html 