MS SmallBASIC

[rubikwizard]

Hi

I received my RasPi yesterday and I am having great fun playing with it! I have been reading the wiki and it says that Microsoft SmallBASIC is expected to work on the RasPi (http://elinux.org/RPi_Programming). Surely this cannot be correct? It is a Windows only application as far as I know?

I ask as I am a teacher of GCSE Computer Science and currently use SmallBASIC with my classes but I am looking at Python for next year.

Thanks.

[john_wage]

SmallBASIC != MS Small Basic

[rubikwizard]

john_wage said:


SmallBASIC != MS Small Basic


I realise that, but the wiki links to the MS Small Basic website. This is where the confusion is. Maybe it should be linking to http://smallbasic.sourceforge.net/ … ?

[chrisw2]

basic256 (educational BASIC programming environment for children) is available from the debian armel repository and I can see no reason for it not to run "out the box" on the Pi.

http://basic256.org/index_en

[rmm200]

Please do give Python a serious look.  Your students will thank you.

I really think there is more bad code written in Basic then all the other languages combined. It teaches bad habits...

[Robert_M]

rmm200 said:


Please do give Python a serious look.  Your students will thank you.

I really think there is more bad code written in Basic then all the other languages combined. It teaches bad habits...



I've only been seeing this assertion since I came to the R-Pi forum, but I've never seen anyone explain why. Even when I look online I see it repeated without much reason given. I saw one reference going back to the guy who originally coined it that implied he was either trolling or speaking about a version of the language that was obsolete when he made the statement.

Not being a programmer, I would think any start would be a good start. Plus, it provides a ready tool for accessing a huge pool of existing software to experiment with. So let me politely ask, what bad habits does it teach?

[Robert_M]

Perhaps I should start by saying the reasons why I don't think it teaches bad habits.

Generally, it requires being able to type well and proofread your work. And to do this using words, phrases and functions that are generally understandable to the non-professional. It also teaches you to seperate how you think something should work from how the machine actually performs the tasks. It begins the process of training the thought process, "okay, if I want Y to happen, I have to make X happen, first."

I can accept that it's not taken seriously as a programming language for professional or business development purposed.

I also freely admit that my appreciation is tinted with nostalgia, since BASIC is the language I was first exposed to over thirty years ago.

[rmm200]

My biases come from trying to maintain or convert code originally written  in Basic. These programs were comment-free, because the language provides no tools or incentives to work with comments. Encapsulation? you have to be kidding... code references variables all over the program space. Debugging is a nightmare.

Object oriented code is not just a buzzword - it leads to maintainable code. Basic is as far from that goal as you can get. People that learn in Basic typically have a hard time switching to the object oriented paradigm. Why start your students off with a handicap?

Sometime ask me what I really think about Basic.

[W. H. Heydt]

rmm200 said:


Object oriented code is not just a buzzword - it leads to maintainable code. Basic is as far from that goal as you can get. People that learn in Basic typically have a hard time switching to the object oriented paradigm. Why start your students off with a handicap?

Sometime ask me what I really think about Basic.


OO leads to "maintainable code" to the direct degree to which the programmer writing in an OO writes maintainable code.  You can write maintainable code in *any* language...and a competent programmer can maintain code that would probably horrify you.  (Want to take a shot at an 11K line main post program for a banking application?  Been there, done that.)

BASIC isn't OO because it pre-dates OO.  It has more to do with FORTRAN (indeed, I have never formally "learned" BASIC, but I can write in BASIC because I already knew FORTRAN before BASIC existed).
What OO did was to invent new terms for old concepts and then insist that the new term didn't mean the same as the old one (this is, in far to many cases, a lie).

[markb]

rmm200 said:



Object oriented code is not just a buzzword - it leads to maintainable code.



So non OO code is unmaintainable - How did we ever create things like Unix before the wonderful world of object orientation? Or get to the moon?

[Chris.Rowland]

There's a lot of language snobbery around.  In reality the language has much less effect than the attitude of the programmer.

A good programmer will generate well written, understandable and maintainable code in almost any language(*).  A bad programmer will generate obfuscated and unmaintainable code regardless of what language and tools are available.

(*) I'm thinking of XAML here, it's almost impossible to comment it well because the language is so fussy about where command element can be put.

[Jim Manley]

Deciding what software development language is to be used before considering any of the project requirements is sheer folly. If you only have a hammer, everything starts looking very much like a nail, whether or not it can withstand hammering. That wastes precious resources (how much is your time worth?).  Not every language is created equal, and even different implementations of the same language can vary widely (the lone exception being Ada – there is one, and only one, _validated_ and _verified_ version, per release).

There are versions of BASIC that can be compiled, others that allow very structured software to be developed, and yet others that encourage the production of infamous "spaghetti code". Object-oriented software cannot be developed in all languages, at least not by the textbook definition of OO, where data abstraction, encapsulation, messaging, modularity, polymorphism, and inheritance are _required_. Some of these can be simulated through tortuous incomprehensible mangling of data structures and flow-of-control mechanisms, but, others are just simply impossible if not designed into the implementation of the language.

The sooner people forget the words "programming" and "programmer", the better off we all will be. We should be teaching software development or, in the ideal, software engineering. It has been well-documented over the last half-dozen decades that maintainable, extensible, minimal-error software involves a _lot_ more than implementation (aka "programming", but, even that isn`t an equivalence). In fact, the average software developer spends only about 15% of their time on a project actually implementing the software (aka "programming", but, again, that isn`t an equivalence, either).

Before you even type a single character of source code, you`d damned well better know what the hell it is you`re supposed to be developing. The number one cause of software project failure is not understanding requirements in all their variety (user experience, performance, accuracy, reliability, extensibility, etc.). Getting the wrong answer at the speed of light in binary isn`t a very useful way to spend your time, just as it is using any language.

Once you know what the requirements really are (and prototyping may be necessary to really understand them, but, only after _some_ level of requirements extraction from customers and users), you still don`t get to put fingers to keys.  You really need to design anything much more complex than a Hello World! program. Did you know that the combinatorics for any software more than about a few dozen lines in length can result in programs with more bugs than can be discovered in a person`s lifetime through testing (which includes debugging – we`ll get to that in a minute).

This is why design is critical – it`s not some egg-headed exercise in mental gymnastics, especially if more than one person is going to work on the project, the people working on a project haven`t done so together extensively before, or only one person is involved, but, they will need to revisit the software only occasionally over extended periods of time (ask any software developer how often they`ve returned to source code they wrote, and didn`t have the foggiest idea about what they had done or, more importantly, why). Design also includes determining how much code you can reuse that was developed elsewhere, by yourself or others, often in the form of libraries, but there are other choices.

This should have an immense influence over your implementation language choice – if there are already libraries that do most/all of what needs to be done, _use_them_!!! Even if you`ve never used the language they may be implemented before, you are much more likely to be successful using code that`s already functional and (mostly) debugged (assuming it`s coming from a reputable source). Learning languages you`re not familiar with will only broaden your experience and professionalism. There are great tutorials and even world-class courses available on-line for free (e.g., MIT, UC Berkeley, Stanford University, Carnegie-Mellon University, etc., and perhaps these now exist at Cambridge, and other top-tier universities around the world).

Once you`ve got the requirements and design reasonably defined, then you can start implementation, but, again, there are more and less effective ways to do that. If you don`t write the comments first, you are asking for trouble – they are how you, or especially others, will be able to come back later and understand what you did and why. They should flow directly from the design, and reflect every single requirement that the customer/users voiced that you agreed to implement (customers/users aren`t always right, but, their wallets are). In fact, I always cite requirements by number/name, via URL, if possible, within my comments. Then, write just the definitions of all of the functions, procedures, subroutines, or whatever calling structure the program will have. Do _not_ attempt to fill them in with any internal data structures or executable statements other than calling and return types of statements.
You want to be able to run the program with nothing but calls to these functional interfaces where you simply enter them and then immediately return without actually doing anything. This is absolutely critical, and virtually no one but the most expert software engineers does it. If you can`t get the flow of your program correct purely at the interface level, you have already doomed yourself to debugging hell and probably project failure, in terms of cost and schedule.

Only after all of the interfaces have been correctly implemented and tested for proper flow should you next add the internal data structures that will be used within each function/procedure/subroutine/etc. Then, run the program again, without any other implementation added, yet. Fix all of the inevitable syntactic errors and only then should you proceed to the executable statements that actually do the heavy lifting in software. Again, start from the top/outside and work downward/inward as you did with the interfaces.

When you implement a conditional or looping block, don`t include any of the internal statements to be executed within, just immediately terminate the block and then test it. If you`re using a source code editor that features auto-completion of blocks (e.g., when you type a left curly brace, it immediately includes the matching right curly brace to the right of the cursor), congratulations.  However, if you`re not, you _must_, I repeat, _must_ immediately complete the block, test the code, and then go back and fill in the remaining statements when you`ve killed the bugs you _will_ introduce. Keep doing this block-wise expansion and testing until, eventually, all of your code is written. This technique alone will save a considerable amount of your lifetime wasted in unnecessary debugging, no matter what language you`re using.

There are specific variations necessitated by certain languages and implementations of them (e.g., languages that allow function/procedure/subroutine/etc., interfaces to be defined separate from their implementations), but, it shouldn`t take much imagination to figure out how to adapt the above strategy I described. If you do all of this correctly, you will spend much less time debugging problems that may be nearly impossible to find by anyone, much less yourself (forest and the trees problem). In fact, the only bugs you should find should be design mistakes where you and/or the customers/users didn`t correctly identify requirements. There are various strategies where you can start developing the user interface elements and have the users test them to validate they make sense before you even design the back-end software that`s going to be doing the actual processing (e.g., a database, web CGI, or other services).  Again, getting the wrong answer at the speed of light is not a good way to expend valuable resources. Figure out what the software is supposed to do before solving anything else.

Real engineers (software, or otherwise) will tell you that there are three fundamental, conflicting goals that need to be resolved in planning and executing any project: time-to-develop, cost, and quality – but, you only get to pick any two of these to be satisfied. You can achieve high quality at low cost, but, it`s gonna take time that no one ever seems to be able to comprehend. You can expend a lot of resources producing something very quickly, but, it`s gonna be crap by almost every measure. You can buy quality over a short period of time, but, you are _going_ to pay through the nose, and pretty much every other orifice from which money can be extracted, in the most painful ways, of course.

If I`ve saved anyone even five minutes of debugging hell, this will have been worth writing. In any case, enjoy!

[colincoach]

Cobol anyone??????

[mole125]

Chris Rowland said:


A good programmer will generate well written, understandable and maintainable code in almost any language(*).  A bad programmer will generate obfuscated and unmaintainable code regardless of what language and tools are available.


I agree, however good programmers are a rare commodity, even actively bad programmers are rare. The majority of programmers are purely mediocre (to varying degrees).

A mediocre programmer tends to follow the path of least resistance and the obvious design patterns placed in front of them. The design of a language can have a significant impact on which patterns are obvious and so what they end up producing. OO coding by its very nature encourages (or even practically forces) encapsulation and the seperation of concerns which tends to make more maintainable and understandable code. Poor variable scoping and GOTOs traditionally make BASIC encourage lumping code together and mixing up all the concerns together in one big block.  Good programmers can use both well and design good programmes. Bad programmers can make a real mess of OO coding and make things harder to understand. But it is the mediocre case (which most beginners fit into) who are the ones to consider.

[jamesh]

rmm200 said:


Please do give Python a serious look.  Your students will thank you.

I really think there is more bad code written in Basic then all the other languages combined. It teaches bad habits...


Maybe because so many BASIC programs are written by beginners, rather than BASIC being a bad language to start with.

I've seen good code in BASIC, I've seen bad code in BASIC, I've seen much more unmaintainable bad code in C and C++ than I have seen in BASIC (mainly due to a complete lack of comments), but then I no longer deal with BASIC at all.

[gjs]

JamesH said:


rmm200 said:


Please do give Python a serious look.  Your students will thank you.

I really think there is more bad code written in Basic then all the other languages combined. It teaches bad habits...


Maybe because so many BASIC programs are written by beginners, rather than BASIC being a bad language to start with.

I've seen good code in BASIC, I've seen bad code in BASIC, I've seen much more unmaintainable bad code in C and C++ than I have seen in BASIC (mainly due to a complete lack of comments), but then I no longer deal with BASIC at all.


+1.

And whoever thinks that BASIC is not OO needs to look at Visual Basic.  It's compatibility with C# demonstrates (to me, anyway) that there is no fundamental difference betwen these two, and possibly any other language.  It is how they are used to solve a particular problem that makes the difference between "good" and "bad".

[bobc]

Most programmers seem to write their bad code in C or C++ nowadays.

[rubikwizard]

Thanks for all the responses to my original question! I had no intention of starting yet another 'language war' thread. I simply wanted to know if MS Small Basic would work - as indicated by the wiki, when I suspected that it would not! I was surprised to see it listed there, that is all. This thread reminds me of the playground when I was at school (Spectrum vs C64, Amiga vs Atari ST etc.)

I am fully aware of the merits and downfalls of all the languages and am quite proficient in many of them. As a teacher I firmly believe that the 'best' language is one that the teacher is proficient in and enthusiastic about. Personally I am very experienced in Z80 and 6502 assembly programming which really helps me to teach parts of the A-Level curriculum. I also have a lot of experience in BASIC (Spectrum, C64, BLITZ(Amiga and PC), VB, VB.NET), Turbo Pascal, C, ASP and PHP.

In my opinion the language does not matter - it is the enthusiasm of the teacher for that language which makes a difference.

I hope that my comments do not re-fuel the 'language war' !!!!!!!!

BTW C64 was much better than Spectrum and the Atari ST was useless compared to the Amiga. I am right, so there. !!!!!

[SN]

gjs said:


JamesH said:


rmm200 said:


Please do give Python a serious look.  Your students will thank you.

I really think there is more bad code written in Basic then all the other languages combined. It teaches bad habits...


Maybe because so many BASIC programs are written by beginners, rather than BASIC being a bad language to start with.

I"ve seen good code in BASIC, I"ve seen bad code in BASIC, I"ve seen much more unmaintainable bad code in C and C++ than I have seen in BASIC (mainly due to a complete lack of comments), but then I no longer deal with BASIC at all.


+1.

And whoever thinks that BASIC is not OO needs to look at Visual Basic.  It's compatibility with C# demonstrates (to me, anyway) that there is no fundamental difference betwen these two, and possibly any other language.  It is how they are used to solve a particular problem that makes the difference between "good" and "bad".


Except that what you call Visual Basic is NOT Visual Basic, its Visual Basic.NET - the original Visual Basic (v4/5/6 anyway) was an OO halfway house BUT was (IMHO) easier than VB.Net and you could get genuine binary EXE's out of them

[W. H. Heydt]

rubikwizard said:


Thanks for all the responses to my original question! I had no intention of starting yet another 'language war' thread.

Don't worry much about it.  You're perfectly safe so long as don't express a preference for either vi or emacs.

[colin B]

W. H. Heydt said:

 You"re perfectly safe so long as don"t express a preference for either vi or emacs.

What about vim, then you could scrub your Pi clean whilst editing!

[chrisws]

Hi There,

I'm Chris from the SmallBASIC project (smallbasic.sf.net). I just bought a Pi, it's really cool.

I was able to build the FLTK version of SmallBASIC without any problems. I noticed there are a few other FLTK based programs available for Pi which is great.

I hope someone will make SmallBASIC available in RaspbianRepository, it should be trivial since the debianisation work is already done.

Cheers,
Chris

[chrisws]

If you would like to try this yourself, the instructions are here:

https://raw.github.com/smallbasic/Small ... ter/README

Just follow the steps for building under ubuntu and get the code from https://github.com/smallbasic/SmallBASI ... master.zip in lieu of the sourceforge svn repository.

Cheers,
Chris

[wobblestar5]

This is a very easy to use BASIC that I've been using for some time in Windows. It would be nice to have it in the raspberry repository.

I've just installed it from source ... after a bit of a struggle (linux newbie).

Mark

[Jim Manley]

This is a very easy to use BASIC that I've been using for some time in Windows. It would be nice to have it in the raspberry repository.
I've just installed it from source ... after a bit of a struggle (linux newbie).

Since the purpose of the Pi is educational, perhaps you would like to enumerate the process you carved out of the wilderness for other newbies to learn from in a new wiki page linked to the eLinux.org Pi Hub programming wiki page: http://elinux.org/RPi_Programming