jamodio
Posts: 49
Joined: Sun Feb 19, 2012 4:30 pm

Re: Programming with *insert language here*?

Sun Mar 25, 2012 9:15 pm

I believe BASIC is a must to bring back some of the history of the old BBCmicro, Sinclairs, Commodore, etc.

PASCAL is an excellent language for introduction to structured programming, and followed obviously with C, and C++.

COBOL is an interesting language to teach how to program large scale transaction systems.

LOGO and ADA could be good for introduction to AI.

Some other mentions like PERL, PHYTON are good to teach scripting languages.

Given that we have a good graphic interface I don't know what would take to implement something like SCRATCH from MIT.

User avatar
jwdietrich
Posts: 13
Joined: Wed Nov 30, 2011 11:52 am
Contact: Website

Re: Programming with *insert language here*?

Sun Mar 25, 2012 9:15 pm

W. H. Heydt said:


Anyone know of a decent, free, COBOL compiler for Linux?


You might want to try OpenCOBOL for Linux (http://www.opencobol.org)

User avatar
ukscone
Forum Moderator
Forum Moderator
Posts: 4164
Joined: Fri Jul 29, 2011 2:51 pm
Contact: Website

Re: Programming with *insert language here*?

Sun Mar 25, 2012 9:31 pm

W. H. Heydt said:


*insert language here*, eh?

I've done full develompent work in COBOL on machines with a fraction of the memory and a fraction of the speed of an R-Pi.

Anyone know of a decent, free, COBOL compiler for Linux?


opencobol is pretty good. I've tested cross compiling it on the various raspberry pi rootfs's and it builds, runs and passes all tests. i actually use it for "serious" programs on other arm devices i own.

User avatar
SN
Posts: 1014
Joined: Mon Feb 13, 2012 8:06 pm
Location: Romiley, UK
Contact: Website

Re: Programming with *insert language here*?

Sun Mar 25, 2012 9:50 pm

The question as to what is the best programming language has no right answer.

Everyone has their favourite and can justify why their suggestion is the right one.

I would suggest that some research and hands on trials with the target audience be performed if they haven"t already.

I"m actually looking at a first principles approach to this - ignoring any language choice and just starting with asking the unconstrained question "how would i like to be able to make the computer do what i want it to do?"
Steve N – binatone mk4->intellivision->zx81->spectrum->cbm64->cpc6128->520stfm->pc->raspi ?

rmm200
Posts: 259
Joined: Sat Mar 03, 2012 10:25 pm

Re: Programming with *insert language here*?

Sun Mar 25, 2012 10:01 pm

We have a wide variety of programming backgrounds represented here.

I would love to see a poll of languages NOT recommended for school children.

There are any number of good modern OO scripting languages, which makes avoiding the bad choices just more important.

My short list of languages to avoid:

Basic (any flavor). Unmaintainable and teaches REALLY bad habits.

Cobol. Has anyone - ever - been turned onto programming by Cobol?

Lisp. Cool language - but way too cryptic. I still show an aversion to nested parens...

Pascal. Good educational language, but just too hard to work around the rigid data typing in real life. And no I/O.

User avatar
SN
Posts: 1014
Joined: Mon Feb 13, 2012 8:06 pm
Location: Romiley, UK
Contact: Website

Re: Programming with *insert language here*?

Sun Mar 25, 2012 10:06 pm

@rmm200 - the answer to your question is clearly "C"
Steve N – binatone mk4->intellivision->zx81->spectrum->cbm64->cpc6128->520stfm->pc->raspi ?

User avatar
rurwin
Forum Moderator
Forum Moderator
Posts: 4258
Joined: Mon Jan 09, 2012 3:16 pm
Contact: Website

Re: Programming with *insert language here*?

Sun Mar 25, 2012 10:39 pm

I have successfully taught programming using Lisp. I'd agree that it was a somewhat odd choice, but Python did not exist.

Pascal is a good language to learn with. IMHO, your objections do not apply to a learning situation. It certainly did not stop us at under-graduate level in the early 80's.

User avatar
SN
Posts: 1014
Joined: Mon Feb 13, 2012 8:06 pm
Location: Romiley, UK
Contact: Website

Re: Programming with *insert language here*?

Sun Mar 25, 2012 11:27 pm

I learned LISP at Edinburgh University - I created an AI system as a Project using it.  very clever stuff.  EMACS parentheses reflecting was deadly useful.  Also coded in PROLOG back then too (no-one's mentioned this little beauty yet, nor FORTH )
Steve N – binatone mk4->intellivision->zx81->spectrum->cbm64->cpc6128->520stfm->pc->raspi ?

User avatar
johnbeetem
Posts: 945
Joined: Mon Oct 17, 2011 11:18 pm
Location: The Mountains
Contact: Website

Re: Programming with *insert language here*?

Mon Mar 26, 2012 3:31 am

rmm200 said:

My short list of languages to avoid:
Basic (any flavor). Unmaintainable and teaches REALLY bad habits.

Cobol. Has anyone - ever - been turned onto programming by Cobol?

Lisp. Cool language - but way too cryptic. I still show an aversion to nested parens...

Pascal. Good educational language, but just too hard to work around the rigid data typing in real life. And no I/O.


My opinions:

Basic has a very short learning curve, which gets you into writing simple programs very quickly.  As such, it is good for kindling interest in computing.  You can write bad code in any language.

I've never heard of anyone programming in Cobol for fun.  There may be counter-examples, but I haven't heard of any.

Lisp is an amazing language where everything is built on top of a tiny collection of primitives, and non-primitives are easily combined into functions which can be treated as more primitives.  Lisp systems are highly interactive and make it really easy to test new functions and build complex systems quickly.  Great language for working with sets and other collections of objects.  Great language for reasoning about programs.  But IMO you do need a good teacher to get started.
I used IBM Pascal/VS on mainframes for serious programming with excellent results.  Standard Pascal is indeed limited, but some extended versions are excellent IMO.

User avatar
ukscone
Forum Moderator
Forum Moderator
Posts: 4164
Joined: Fri Jul 29, 2011 2:51 pm
Contact: Website

Re: Programming with *insert language here*?

Mon Mar 26, 2012 4:06 am

John Beetem said:





I've never heard of anyone programming in Cobol for fun.  There may be counter-examples, but I haven't heard of any.


One of the projects I did for my computer classes in college was a version of space invaders written in cobol

W. H. Heydt
Posts: 11019
Joined: Fri Mar 09, 2012 7:36 pm
Location: Vallejo, CA (US)

Re: Programming with *insert language here*?

Mon Mar 26, 2012 4:10 am

rmm200 said:


Personal bias showing here:

If there is truly a Hell for programmers - it will run on Cobol.



I beg to differ...Hell for programmers would run on RPG.

W. H. Heydt
Posts: 11019
Joined: Fri Mar 09, 2012 7:36 pm
Location: Vallejo, CA (US)

Re: Programming with *insert language here*?

Mon Mar 26, 2012 4:12 am

And just to add to amusement... I learned programming on FORTRAN IID and SPS IID on an IBM 1620 Mod I.

A REAL programmer can write a FORTRAN program in ANY language.

peterpi
Posts: 42
Joined: Wed Jan 04, 2012 3:28 pm

Re: Programming with *insert language here*?

Mon Mar 26, 2012 7:36 am

lazybum said:


An OOP language
supplies a decent runtime library
running on ARM given the CPU power
capable of talking to Gertboard (if I didn't mishear, any would do which can write chars to a stream, so pretty much any?)

C++ would be an excellent choice, apart from the fact that you find it cumbersome.

The "C with classes" sort of C++ that many enjoy writing is cumbersome to use, but modern C++ with strings, STL, exceptions, RAII & functors is remarkably high-level and expressive.

If you're willing to compromise on point 2, then Lua is a beautiful language.

User avatar
ArborealSeer
Posts: 300
Joined: Tue Jan 24, 2012 9:48 am
Location: South West, UK

Re: Programming with *insert language here*?

Mon Mar 26, 2012 7:40 am

W. H. Heydt said:


A REAL programmer can write a FORTRAN program in ANY language.



Hah!

As it matches the trajectory I followed when learning, I agree that BASIC -> Pascal -> C/C++ is a good route.

As I'm not experienced in it I'm not sure how Python would fit in there.

I learned a lot from Pascal, which made the jump to C/C++ a lot easier back then.

I'm much happier with C/C++ now but agree Pascal is a lot more friendly, and easy to learn from the off.

I was also forced to learn COBOL, under Xenix at college

One branch of where I work provides products to developers, so previously I did projects providing access libraries and example code for many flavours of many languages (including Fortran), under many environments too. And with the advent of the internet i've learned php and js.

I think the only one I've never used on the list above so far is Lisp! (No C# actually.. since I work on other stuff now).

From our commercial experience, most people either use VB or C/C++, with some now using C#. (it's mostly Windows but we do support some Linux, but there aren't many users)
Pi Status > Farnell, Arrived 24/5- RS, Arrived 1/6

Zobeid Zuma
Posts: 11
Joined: Thu Mar 29, 2012 4:04 pm

Re: Programming with *insert language here*?

Thu Mar 29, 2012 6:11 pm

These are my prejudices, so take them with a grain of salt....

I'm very pleased that Python and C are going to be supported right up front.  Those two languages alone can cover a huge amount of both educational and practical territory, and everything learned with them is very directly applicable to widely used systems.

BASIC was great in its heyday, despite all the flak it took (and still takes) for instilling bad habits.  It made programming accessible to beginners.  However, I do think Python is well suited to take the place of BASIC in a modern environment, and there's really no need to turn the clock back.

C is like the Latin of computer languages.  It may not be used as much as it was, but a whole wide swath of modern languages are more-or-less derived from it.  And of course, it's hard to beat when you need speed performance.

I am very biased against C++ and somewhat biased against OOP generally, which I think has been overhyped and overused.  OOP is useful for some purposes, but the trend of using it for everything under the sun, and trying to teach it from day one to students, seems like madness to me.  Programming concepts are fairly hard for a beginner to learn, and teaching OOP only raises the bar even higher.

If there's a need for an OOP environment with greater performance than Python, then I'd suggest Objective C as a possible middle ground.  Apple have been doing a lot to freshen up ObjC and keep it relevant, and AFAIK it's been working pretty well for them.

User avatar
johnbeetem
Posts: 945
Joined: Mon Oct 17, 2011 11:18 pm
Location: The Mountains
Contact: Website

Re: Programming with *insert language here*?

Thu Mar 29, 2012 7:02 pm

Zobeid Zuma said:

C is like the Latin of computer languages.  It may not be used as much as it was, but a whole wide swath of modern languages are more-or-less derived from it.  And of course, it's hard to beat when you need speed performance.
I believe it's Algol which has the honor or being the Latin of computer languages.

I am one of those who considers C to be a portable assembly language which uses high-level language notations.  As such, it's a great way to do tasks that previously required ASM in order to be efficient such as operating systems, compilers, data communications, and embedded systems.  IMO C is still usually the top choice for those applications.  It's actually quite recent that C beat out ASM as the primary language for embedded systems.  We still hear talks at the Embedded Systems Conference on how C++ really can be used in embedded systems, yet the audiences remain skeptical.  When you need to know what your program is doing with memory, it's hard to beat C.

User avatar
rurwin
Forum Moderator
Forum Moderator
Posts: 4258
Joined: Mon Jan 09, 2012 3:16 pm
Contact: Website

Re: Programming with *insert language here*?

Thu Mar 29, 2012 7:53 pm

These days there is on excuse for any language to be inefficient, unless it is tied up with dynamic typing or memory allocation and recovery. All the efficiency of C is no bar to a bad compiler. I've even seen a compiler take X += 1 and calculate the address of X twice. But a good compiler can take Algol or FORTRAN and produce a program every bit as efficient as the best C code. To my mind the thing that keeps C at the top is how easy it is to reach the expressiveness of assembler. Try writing a big-endian to little-endian converter in Python or Lisp. Try writing something that requires bitwise boolean operators in a language without them. That sort of stuff is inherently non-portable, but it is absolutely necessary for some very common tasks that crop up far more frequently than computation theory says they should. When you hit a problem like that a FORTRAN or Algol programmer will either code around it inefficiently or reach for a library implemented in assembler; a C programmer will just implement it in C.

User avatar
ArborealSeer
Posts: 300
Joined: Tue Jan 24, 2012 9:48 am
Location: South West, UK

Re: Programming with *insert language here*?

Fri Mar 30, 2012 5:54 am

rurwin said:


These days there is on excuse for any language to be inefficient, unless it is tied up with dynamic typing or memory allocation and recovery. All the efficiency of C is no bar to a bad compiler. I"ve even seen a compiler take X += 1 and calculate the address of X twice. But a good compiler can take Algol or FORTRAN and produce a program every bit as efficient as the best C code. To my mind the thing that keeps C at the top is how easy it is to reach the expressiveness of assembler. Try writing a big-endian to little-endian converter in Python or Lisp. Try writing something that requires bitwise boolean operators in a language without them. That sort of stuff is inherently non-portable, but it is absolutely necessary for some very common tasks that crop up far more frequently than computation theory says they should. When you hit a problem like that a FORTRAN or Algol programmer will either code around it inefficiently or reach for a library implemented in assembler; a C programmer will just implement it in C.


yup you got it bang on, most of the projects i had to do with the languages i previously mentioned did just those kinds of bitwise shifting/rotating and XORing for one part of a layered authentication system.. nightmare! we had the caveat that this part of it needed to be in the compiled app, not in an external library (which is indeed how we got around a lot of other stuff) – which also reminds me of one thing you didn;t mention… buffers. some languages really dont have a good concept of a BYTE array!
Pi Status > Farnell, Arrived 24/5- RS, Arrived 1/6

AlArenal
Posts: 141
Joined: Sun Feb 26, 2012 6:58 pm
Location: Germany
Contact: Website

Re: Programming with *insert language here*?

Fri Mar 30, 2012 10:50 am

Because you've all done a good job of mentioning the cool stuff (Prolog, Lisp, Forth, ..) you leave no choice but to come up with this one: Smalltalk (and maybe Objective-C)

Unfortunately my attempt to compile SqueakVM on an emulated Pi using the Debian release failed. But Squeak could be cool to introduce kids to coding..

User avatar
gordon@drogon.net
Posts: 2020
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
Contact: Website

Re: Programming with *insert language here*?

Fri Mar 30, 2012 11:42 am

Alex Langer said:


Because you"ve all done a good job of mentioning the cool stuff (Prolog, Lisp, Forth, ..) you leave no choice but to come up with this one: Smalltalk (and maybe Objective-C)

Unfortunately my attempt to compile SqueakVM on an emulated Pi using the Debian release failed. But Squeak could be cool to introduce kids to coding..



No-ones mentioned IMP-77 yet...

Sadly, I suspect no-one will port it to ARM either, although there is a working x86 compiler for it.

It was used in the 70's to teach and write Operating systems in at Edinburgh Uny - EMAS and Mouses (at Moray House). Sadly, I wasn't a student at Edinburgh Uny, but at another fine institution in Edinburgh, so did get a little bit of exposure to it... It was another Algol derieved language, and after that, C (which I've been coding in for the past 30 years) was easy... I decided to put a little bit of IMP-77 in my BASIC interpreter in the form of the CYCLE...REPEAT loop construct.

while a <> 5 cycle

.. do something

repeat

until a = 5 cycle

.. do something

repeat

for i = 1 to 5 cycle

.. do something

repeat

cycle

.. do something

repeat while a <> 5

all good fun!

Gordon
--
Gordons projects: https://projects.drogon.net/

plugwash
Forum Moderator
Forum Moderator
Posts: 3466
Joined: Wed Dec 28, 2011 11:45 pm

Re: Programming with *insert language here*?

Fri Mar 30, 2012 12:09 pm

John Beetem said:

We still hear talks at the Embedded Systems Conference on how C++ really can be used in embedded systems, yet the audiences remain skeptical.  When you need to know what your program is doing with memory, it's hard to beat C.
The thing with C++ is it gives you a massive range of tools. At one extreme you can get heavilly into the template metaprogramming. At the other extreme you can write in C++ as if it was C.

In particaular C++ gives you the tools to build your own types that feel natural to use. In C you can create a complex number type but you have to do all your work on it using functions which gets ugly fast. In C++ you can create one that can be used with operators like any other numerical type. The same applies to various types of string.

W. H. Heydt
Posts: 11019
Joined: Fri Mar 09, 2012 7:36 pm
Location: Vallejo, CA (US)

Re: Programming with *insert language here*?

Fri Mar 30, 2012 5:04 pm

rurwin said:


Try writing something that requires bitwise boolean operators in a language without them.


I once had to help someone extract the 4 lower order bits from a byte in COBOL (shop standard...I'd've done in easily in ALC if given the choice).  It took very little code, but it did depend on knowing some of the intricacies of how the compiler generated the machine code AND knowing how the actual machine instructions behaved with nominally malformed data.  The environment was COBOL II or an IBM mainframe running MVS in the late 1980s.

COBOL "redefines" is a far more powerful construct than many experienced COBOL programmers realize...

tufty
Posts: 1456
Joined: Sun Sep 11, 2011 2:32 pm

Re: Programming with *insert language here*?

Sat Mar 31, 2012 7:42 pm

rurwin said:


Try writing a big-endian to little-endian converter in Python or Lisp.


Assuming you"re running under an operating system that"s half-way-sane, you"d probably use something sensible that"s already built into the OS, rather than trying to write it yourself.

Most modern Lisps have some sort of FFI interface, after all.  And python has many ways of doing this built in.


That sort of stuff is inherently non-portable


It may be if you hack it together.  If you"re sensible, though, it"s a case of

#include <endian.h>
Yes, I know it was an example pulled from your hat, but it wasn"t a very good one.

Simon

<edit>

I should probably point out that if you're doing something like this in Lisp, you're probably really working in some domain-specific language, as you're going to want to avoid using the built in numeric stack if you're specifically dealing with byte/word sized values.

C (and, by extension, C++) has woeful number handling. Great if you're dealing with machine-storage-sized values, useless otherwise. int, in C, does not mean integer.

User avatar
rurwin
Forum Moderator
Forum Moderator
Posts: 4258
Joined: Mon Jan 09, 2012 3:16 pm
Contact: Website

Re: Programming with *insert language here*?

Sun Apr 01, 2012 12:16 pm

tufty said:

Most modern Lisps have some sort of FFI interface
FFI is Foreign Function Interface; like I said, Lisp needs a library written in a different language.

Yes, I know it was an example pulled from your hat, but it wasn"t a very good one.
I was aware of that. Most bit-twiddling operations I get into are so domain-specific that they'd be worse examples.

C (and, by extension, C++) has woeful number handling. Great if you're dealing with machine-storage-sized values, useless otherwise. int, in C, does not mean integer.
Limiting integers to machine word-size keeps integer maths time-determinate and efficient, but C gets used in a lot of cases where it shouldn't. On the other hand, there are very few languages where int does mean integer. Python and Lisp are the only two I can think of.

tufty
Posts: 1456
Joined: Sun Sep 11, 2011 2:32 pm

Re: Programming with *insert language here*?

Sun Apr 01, 2012 7:01 pm

rurwin said:


tufty said:


Most modern Lisps have some sort of FFI interface


FFI is Foreign Function Interface; like I said, Lisp needs a library written in a different language.


Indeed.  However, most "base" bit-twiddling functions already exist in Lisp, and the nybble/btye/word swapping functions already exist in libraries that should be more or less universal.  Like I said, bad example.



C (and, by extension, C++) has woeful number handling. Great if you're dealing with machine-storage-sized values, useless otherwise. int, in C, does not mean integer.


Limiting integers to machine word-size keeps integer maths time-determinate and efficient, but C gets used in a lot of cases where it shouldn't. On the other hand, there are very few languages where intdoes mean integer. Python and Lisp are the only two I can think of.


Oh, there's lots of languages with full number stacks.

In terms of efficiency, binary numbers aren't particularly efficient unless you restrict yourself to machine word sizes.  Increment and decrement (which one might want to be particularly efficient in programming terms), for example, are O(logN) for the general case of binary representation - other representations exist[1] which are O(1) for increment and decrement.  In real terms, these might be slower on existing machines (which are tied to 2s complement binary operations), but there's nothing stopping you having a full number stack which is totally deterministic for the type of operations which are particularly useful in programming, and no worse than a generalised 2s complement binary representation for the rest.

I would argue that "hanging on" to machine word sized integers, and (again machine word sized) floating point representation for everything else, is, in this day and age, particularly archaic.  Did the Y2K "bug" (no, not tied to machine words, but related in terms of restricting representable data) teach us nothing? The cumulative errors of floating point? The fact that 0.0 is not equal to 0 (and, in many cases, not even equal  to 0.0)?

Here's a fun little story.  A good few years ago, I was working for a company who dealt with outsourcing.  In this case, we were dealing with a warehousing system - stock control, order handling, the lot.  As is usually the case with outsourcing deals, we inherited a system where the binaries didn't match to any set of source we had, documentation was nonexistent, and there were numerous manual procedures that had to be carried out every N days/weeks/months or the whole crumbling heap would fall down around your ears, which latter we were strictly unaware of, of course.  I, for my sins, was the one who had to do 24 hour support for this particular pile of festering - umm - "stuff".

So, at 3am one fine morning, my beeper went off.  Bleary-eyed after a night on the beers, I hop into a taxi, and off to work I go. The order processing batch job has fallen over.  So, find out what's causing it to crash, go in, manually remove the offending order line, schedule the job to run again, go and chat with the operators.  Half an hour later, *blam*, down she goes again (these were big orders, and being processed on a small minicomputer).  Super.  Trudge upstairs from the machine room, find the offending line, edit it out, reschedule, back downstairs again and nip out back for a smoke.  Three quarters of an hour later, *blam*. Find offending line, edit out, note that the item code is the same for all 3 lines I've now removed, make a preemptive strike on all lines with that item code, reschedule.  I'm now royally bored with the whole thing, so start working out what the item actually *is* (can't do this on the live system, of course, so have to restore a backup to a test environment, involves much trudging up and down stairs looking or tapes that actually work).  Turns out it's cocktail sticks.  The ordering system has changed, and instead of putting in orders by the box (100,000 per box or so), it's putting in orders by the unit.  So previously reasonable orders of (say) 100 boxes of cocktail sticks are coming through with a volume field of 10,000,000, which number is too big for the internal integer representation used by the program.

No, of course we didn't have anything resembling up to date source for the program.  Took me 2 weeks to reverse engineer it from the binary.

Simon

[1] skew binary, for example

Return to “General discussion”