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.

Hi Coder,

Having thought about it, I guess I'm coming round to your way of thinking. It's hardly like they are pushing Ada or Cecil as the languages at the forefront of Pi programming and it is always good to learn about new ways of doing things.

Perhaps I should look at the Cecil article again and give it a bash !

Steve

Steve,

> and it is always good to learn about new ways of doing things

exactly!  Here are some concrete examples.

In Fortran 66, like in assembly language, the only control structures

available are the goto, conditional goto, and subroutine call.  Later,

languages such as C and Pascal popularized "structured programming" with

higher level control structures such as if/then/else and do-while/repeat-until

loops.  The main advantage of these control structures is that when

reading a particular line of code, it's always clear how you must have

gotten to that line, because "spaghetti code" with arbitrary forward and

backward jumps isn't allowed.

Fortran users didn't need to switch to C or Pascal to take advantage of

this concept.  They could continue to use Fortran, but with preprocessors

such as Ratfor, or even without using a preprocessor, they could

simply make disciplined use of goto's.

In the 80's, modular languages became popular, with separation of

interface from implementation, for much the same reason.  When

you are reading code in a module, you want to know that you could

only have entered the module through one of the subroutines in the

module's interface.  This discipline can be practiced in any language,

even if the language does not enforce it.

With the popularity of object-oriented concepts such as inheritance

and dynamic dispatching, it is possible to use those concepts in

languages such as C that don't provide any direct support, but do

allow indirect subroutine calls.

coder27 wrote:

 

Steve,

> and it is always good to learn about new ways of doing things

 

exactly!  Here are some concrete examples.

 

In Fortran 66, like in assembly language, the only control structures

available are the goto, conditional goto, and subroutine call.

        DO 10 I=1,100

10    WRITE(6,20)

20    FORMAT(27HYOU FORGOT THE DO STATEMENT)

        STOP

I should also pick on you for not mentioning computed GOTO and assigned GOTO

coder27 wrote:

 

Later, languages such as C and Pascal popularized "structured programming" with

higher level control structures such as if/then/else and do-while/repeat-until

loops.  The main advantage of these control structures is that when

reading a particular line of code, it's always clear how you must have

gotten to that line, because "spagetti code" with arbitrary forward and

backward jumps isn't allowed.

Structured programming constructs were already popular from the time of Algol 60, but primarily among computer scientists.  Fortran programmers viewed them with suspicion and claimed they optimized poorly.

C and Pascal frown on using gotos, but provide them in the language so it's still possible to write spaghetti code.  It's also possible to move spaghetti logic to the conditional flags of the the form "while not found and not error do begin {bunch of nested hard-to-follow logic} end".  Handling error conditions is often much easier to follow using a goto as an exception.

It's also worth mentioning that at the time of Fortran 66 and Algol 60 it was common practice to flowchart your program before coding it, so the structure was clear despite gotos.  Much easier to tell if there's spaghetti logic or other wooly thinking with a flowchart.  It was also standard practice to hand-check programs before submitting card decks since turn-around was too slow to permit hacking.

JMO/YMMV

John Beetem wrote:

 

It's also worth mentioning that at the time of Fortran 66 and Algol 60 it was common practice to flowchart your program before coding it, so the structure was clear despite gotos.  Much easier to tell if there's spaghetti logic or other wooly thinking with a flowchart.

 

JMO/YMMV

Flowchart use is still very much standard practice here - possibly because I have a head like a sieve! The influence of BASIC can still be felt here 30-odd years on...

Perhaps modular programming will really come of age when all we have to do is draw a flowchart and our friendly compiler will burp out the code for us. Heresy perhaps, but I'm not a subscriber to the "it's supposed to be hard, dummy" whatnot. We'll still need a few smart folks to write the compilers, after all. Life's too short to learn proper code and be creative!

John,

  Good points.  I was really sloppy forgetting to mention Fortran's Do loops,

which were there from the beginning.  But Fortran, along with Cobol and Basic

took a long time to adopt the if/then/else and while-loop constructs that are now

considered fundamental, although enlightened and disciplined programmers can

avoid writing spaghetti code in any language.

Fortran creator John Backus is quoted as saying: "we did not regard language

design as a difficult problem, but merely a prelude to the real problem: designing

a compiler which could produce efficient programs."

Of course, now the tables have turned, and efficiency is no longer a major concern

for most programming languages, but language design is considered a difficult problem.

Jonathan,

You wrote:

> Life's too short to learn proper code and be creative!

I'm not sure exactly what you meant.  Some people think there is a conflict

between creative programming and disciplined programming, but I don't.

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.

coder27 wrote:

 

Jonathan,

You wrote:

> Life's too short to learn proper code and be creative!

 

I'm not sure exactly what you meant.  Some people think there is a conflict

between creative programming and disciplined programming, but I don't.

 

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.

Well... You're absolutely right in that the actual coding is only a small part of the whole conceive -> write -> tweak iterative thinger, but:

some people are just plain better at dreaming up an effective original concept and others may be better at the discipline of turning it into code. Another person still may be better suited to testing every possible combination of user situations in order to shake out bugs in a repeatable manner, document them clearly and suggest ways in which workflow could be improved with regard to the ordinary mortals who will be the end users (coders are by no means ordinary mortals).

I don't think that this concept is anything new. It possibly started around the time when two cavemen (one of whom was good at knapping arrow heads but couldn't run very fast, while the other was a talented hunter who hated spending his evenings chipping away at lumps of flint) decided to cut a deal regarding the division of labour and mammoth steaks. Perhaps Open Source v2.0 will be more collaboration / barter friendly - because we can't all excel in every discipline and so there's a lot of talent going to waste out there. But if Open Source can't figure out a way to get people with complementary skills together (and given that the bits of the web dedicated to Open Source seem to be stuck forever in the 1990's) then programming will have to become more intuitive. It'll be the same unambiguous language(s) underneath, but wirapped in a smarter interpretation shell. Why teach a million people to think like machines when you can build one machine that can think for itself, just a little?

It'll never catch on, of course. Nobody wants to knock down the Tower of Babel.

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

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