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

Sat Oct 15 19:26:54 EDT 2011

Ron,
Thanks for starting this thread with such a well-delivered original post!

I will say +1 for having a project, even a little project, as opposed to
ingesting several dry books and looking at Morpheus to say "I know C++." in
a matter-of-fact way.  I am able to make far better headway now when my code
is put into use.  Now that I am using the internet and textbooks to solve
real problems, the actual programming goes faster and is more fun.

Wolf

On Sat, Oct 15, 2011 at 11:58 AM, planas <jslozier at gmail.com> wrote:

> **
> 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 listAle at ale.orghttp://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists athttp://mail.ale.org/mailman/listinfo
>
>
>
>   --
> Jay Lozier
> jslozier at gmail.com
>
> _______________________________________________
> 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
>
>

-- 
This Apt Has Super Cow Powers - http://sourcefreedom.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20111015/b28b1900/attachment.html 