The MagPi Magazine - Aimed at learners - Printed edition Kickstarter

I hate to be so negative, but the writing in this magazine seems to be getting worse. I have read every one so far, but in the most recent one there seems to be a number of things that just leave the user hanging or have obviously been written by someone who is an expert in what they are doing, but can't convey that information properly to a beginner.

I did look at the Kickstarter on this, but couldn't justify it on the grounds that better information is either available freely on the web, or via one of the many books popping up recently that are cheaper than the bound set of these magazines.

I was however happy to see the Ciseco Eve Kickstarter get funded and I have my board from them already :-)

Steve

I hate to be so negative

Yea it's not like you have a history of that in Rapberri Pi forums or anything. Oh, wait a minute.

John Beetem wrote: You can have upper NPN drivers provided that you can get the base voltage higher than the emitter voltage.  The L298 diagram doesn't show the details of the AND gates that drive the upper NPNs.  I suspect they convert TTL input levels to "Vs".

You're right. I found a data sheet for the L293 and the first stage transistors on the motor drivers are tied to the motor supply.

> Nobody wants to knock down the Tower of Babel.

Really??  I think everyone is disgusted by the folly of

umpteen different ways to say the same basic thing, such as

http://brianary.blogspot.com/2011/02/then-what-elif-elsif-elseif-or-else-if.html

I'm minded of Esperanto:

"Wouldn't it be great if everyone in the world spoke the same language!"

"Awesome, except we'll have to invent a completely new language - 'cos all of the old ones are pish..."

http://en.wikipedia.org/wiki/Esperanto

It's tricky. Language is a living thing - it evolves due to the influence of it's environment. Easyish for humans, but hard for a computer lingo. Therefore you will always have issues with future proofing and backwards compatibility (or both!). My point being that the stuff that happens under the hood (if, for, else, elseif, panic...) could be completely invisible to a user, given a smart interface that could say "I can't let you do that Dave" when you're drawing an illegal loop, or whatever.

I stand by my "Babel" assertion - there are an awful lot of people out there who are of the attitude that "back in the day I had to put up with  wobbly RAM packs / punch cards / dekatrons etc. so I don't see why the young 'uns should have it easy."

One of the less savoury functions of language is to intentionally mystify, unfortunately.

coder27 wrote:

 

Some people think time spent coding is important, but usually it is far

outweighed by later phases of the software lifecycle, including testing,

debugging, maintenance, and enhancements.  Taking an enlightened

and disciplined approach to code writing can more than pay for itself in

the later phases.

 

Ludwig Wittgenstein wrote: "The limits of my language means the limits

of my world."  I think that's applicable to programming languages too.

My opinion is that if you code your application properly, your "later phases of the software lifecycle, including testing, debugging, maintenance, and enhancements" require a lot less effort.  You didn't mention documentation.  IMO you should always try to do that first, because once your problem and software architecture and major data structures are documented well the coding and other phases are smoother.  Why?  Because design problems become obvious when you start writing about them, but when you just start coding you run into roadblocks and have to kludge-upon-kludge your way around them.

Coding an application properly includes using a language that's well suited to your application so it's clear that your code is solving the correct problem.  If no language is suitable, use a language that you can extend towards your application.  You don't want "coding" to be synonymous with "encryption".

Jonathan Garrish wrote:

 

... there are an awful lot of people out there who are of the attitude that "back in the day I had to put up with  wobbly RAM packs / punch cards / dekatrons etc. so I don't see why the young 'uns should have it easy."

 

One of the less savoury functions of language is to intentionally mystify, unfortunately.

I did most of my early programming with punched cards on a shared computer (sometimes batch, sometimes sign-up-for-an-hour-a-day minicomputer).  I am extremely grateful that I had to go through this Purgatory because it taught me a lot of discipline that makes me a more accurate programmer with a non-shared interactive environment.  When you have limited access to a computer, you spend the off-line time flow-charting, thinking, and reviewing your code, often finding problems and corner cases you would have missed in a hacking environment.  Punched cards also had the huge advantage of forcing you to keep your programs as small as possible, since there were only 2000 SLOC per box of cards and you could only "comfortably" carry two boxes.  So I was always thinking about small, elegant ways to do things instead of copy-and-pasting code found "whereever" and trying somehow to hack it together.

I don't get your comment about languages intentionally mystifying.  I think most languages, and particularly the ones that are surviving, really try to provide clean, efficient ways for programmers to express their ideas.  I don't think C++, SmallTalk, or even APL are intentionally trying to mystify -- I think it's just that their creators find those notations good for what they wanted to express, and perhaps others just don't think about things that way.

The principle that I always tried to instill in my ElecEng students each year was that programming languages are just tools in a toolkit, and you need to pick the right one for the job.  The common metaphor of banging in screws with a hammer is much more than just a funny image.  It's absolute reality that you will not do a good job if you adopt that approach.

That's why we exposed them not only to the lingua franca of C but also to machine and assembly code, and to Smalltalk, and to Ada, and to LISP and Occam and other specialist languages of various kinds, each one better than the others in some particular domain of application.  It might have blown a few narrow minds, but minds are resilient and they will have been expanded by the experience and become better engineers.

"But I only know language X" is the epitaph of the poor engineer without any actual understanding of what languages do in the grand scheme of things, and without the ability to recognize when their single tool is failing them because they lack a basis for comparison.  The answer is always "Go learn more".  They don't bite, and each one you learn makes the next one even easier to pick up.

And if you know several languages and hence are able to recognize that language Y would be better but you're not an expert in it, then great, you now know who to hire to do a good job for you.  You still win.

Morgaine.

Addendum.  It may be worth pointing out that if the only languages sought out are those that feel comfortable and familiar, then very little that is new will be learned.  It would be tantamount to sabotage of the motive behind the advice to learn more languages, since it would deliberately narrow the breadth of experience gained.  Not only would that be a bad move for learning, but also a waste of one's time.  Seek out the new and different.

Hi

It all depends what you want to do. Is the RPi a learning tool or a doing tool? If you want to learn then go the roundabout way, learn the good and bad bits of each route. If you want to do something today go the familiar quickest route.

So is MagPi primarily an educational tool? I think it is.  Problem is that a bad examples can be good learning experiences in the right environment and a complete put-off in the wrong place. I don't know anything like enough about different languages - insufficient education I am afraid - but I do know a bit about hardware. I get bogged down in all the new software stuff, which to me seems insufficently explained,  just as I see others getting bogged down in what seems the absolute simplest hardware - but its not really so simple. If you are operating anywhere near the limits (and how do you know that?) you need to be able to read a datasheet, you need to understand what hFE is, why it is quoted as x, but is likely to be less depending on VCE, what VCESAT is, hell even what saturation is, why PTOT assumes TCASE=25C, and so on.

I have suggested elsewhere that MagPi do a language comparision on the RPi  - just the "Hello World" example in as many languages as possible - always starting from the same point - a freshly made SD card.

It is so easy to say 'PRINT "HELLO" ' without mentioning the need to download the package, install, setup, make, get the missing jScript, oh did I mention this dependency and you didn't realise you needed Apache or HTTTP (and you dont what they are - ny fuwl now that), what you have both? and Python and PHP? you can't do that!

One great advantage of the RPi over a PC is that you can very easily go back to square one. You can have as many setups as you have SD cards. If only my various RPi's would boot more than about one time in 3 and didn't need coaxing each time (and yes my power supply is good, and my Polyfuses  bipassed (all of them - I like to live dangerously)).

And later consider how the starting points can or can't be expanded to cover GPIO, web access, whatever. How particular add-on package might provide the GPIO accesss to any language (except that one of course) and so on.

End of ill-considered steam of conciousness rant.

My 15 year old son has been inspired by the idea of a RPi and I've got him one for Xmas.  A few have mentioned getting an RPi book and an electronics text book as a good starter and I like this idea. I'd guess the Raspberry Pi User Guide by Eben, but I haven't got a clue about an electronics book. 

He's doing GCSE Electronics, so perhaps a study guide or would it be more value at AS/A2 level.  I've an engineering background but it's in aeronautics rather than electronics/computer science so the electronics book would be for me as well!

Has any body got any suggestions for both please.

Steve

Hello Steve,

My suggestion would be either Starting Electronics by Keith Brindley or Success in Electronics by Tom Duncan, possibly also Make:Electronics by Charles Platt.

However, I'm only pretty much a beginner myself so I'd wait until someone comes along that *really* knows what they are talking about before hitting Amazon.

In another thread someone mentions 'The Art of Electronics' By Horowitz and Hill. General consensus regards it as the bible but it is 1) Expensive (Have a look on abebooks.co.uk for a chance for a cheaper one) and 2) Damn scary if you are a beginner !

Steve

Hi

I think you are wise to consider a text book. The web is a fine thing for jumping in and finding odd items but to find a structured course - which is the only way to a full understanding - is quite a task.  Having said that have a look at http://www.wjec.co.uk/index.php?subject=49&level=7&list=docs Anyone with any kind of engineering background would find GCSE electronics a breeze -  once you find a structure to follow.

If I were not so old I might consider becoming a teacher!

Hi

H&H has been around in various editions for years. As you say it is the Bible (other bibles may be available). If I remember rightly it starts from nothing and gets to Thevenein's theorum in about 20 pages passing through everything from Ohm's law to capicitors in parallel on the way and so equations - and there are plenty - are often just stated with little explanation. it is a first year degree text book and expects you to work at it, and probably to have recourse to a well-qualified teacher.

I used to find Schaum's Outline series quite useful - always plenty of examples at the end of each chapter - useful when I couldn't think of any new and original questions for the end-of-year's exams!

You say you are only just beginning electronics - your recommendations are therefore likely appropriate.

Electronics - Circuits and Systems , by Bishop pub. Newnes,2011 looks quite a good practical starting place

Regards

Graham

Hi

H&H has been around in various editions for years. As you say it is the Bible (other bibles may be available). If I remember rightly it starts from nothing and gets to Thevenein's theorum in about 20 pages passing through everything from Ohm's law to capicitors in parallel on the way and so equations - and there are plenty - are often just stated with little explanation. it is a first year degree text book and expects you to work at it, and probably to have recourse to a well-qualified teacher.

I used to find Schaum's Outline series quite useful - always plenty of examples at the end of each chapter - useful when I couldn't think of any new and original questions for the end-of-year's exams!

You say you are only just beginning electronics - your recommendations are therefore likely appropriate.

Electronics - Circuits and Systems , by Bishop pub. Newnes,2011 looks quite a good practical starting place

Regards

Graham

Graham & Steve,

Thanks for the links and and recs, I'll have a look.

Steve