PDA

View Full Version : What's the easiest program language you've had?



George
2010-Jul-22, 08:06 PM
This probably is a career or hobby-specific question, but I have to take my hat off to the dBase III+ folks who made programing easy and intuitive.

Fortran and Basic were pretty cool, admittedly. I quit Cobol class since, for my interest, it was too much "squeeze for the juice".

NEOWatcher
2010-Jul-22, 08:17 PM
It depends on your definition of "easy"

I would say certain forms of "basic" are easy in that the phrasing is more "english" yet retains the visible structure of what you're doing, doesn't have some confusing punctuation, and some operation symbols are multipurpose and easy to follow in context (eg. instead of stuff like "=" vs ":=") . It's easy to go back and edit too.

This is coming from professional experience in Basic(from simple to dotnet), Fortran, Pascal, C(from simple to dotnet), Progress 4GL, SQL, LISP (and some others that I can't think of [or don't want to admit to] at the moment).

I don't know what DBase language is like. If it's anything like Lotus Notes formula language, then it's real easy to create, but changes and debugging are a nightmare. And; because it's 4GL, the more advanced you get using it, the more time you spend outwitting what it does for you rather than programming in logic.

PetersCreek
2010-Jul-22, 08:37 PM
This is ancient history but in terms of terms, Commodore Assembly was probably the simplest I ever worked in. Of course, actually doing the stuff that higher level languages did was another matter. That's why I programmed mostly in Commodore BASIC and used code calls for things that benefited from fast execution.

IsaacKuo
2010-Jul-22, 08:43 PM
I don't know what DBase language is like. If it's anything like Lotus Notes formula language, then it's real easy to create, but changes and debugging are a nightmare. And; because it's 4GL, the more advanced you get using it, the more time you spend outwitting what it does for you rather than programming in logic.
xBase languages are primitive. It's easy to create something that does something very very simple, but anything involving more than one table is a nightmare. You're dealing with a dynamic environment which is okay when you're entering commands interactively but it gets crazy when you're dealing with a program.

For example, field/variable names are sensitive to the currently selected table. Fine, if there's only one table to worry about. But it's one of many factors you need to manually save and reset in a subroutine or program loops or branching. There are a zillion little environment settings that you need to set or change in order to get the desired functionality out of your command--and it's entirely up to you to figure out what the settings were previously, saving them temporarily in some place that won't get overwritten (a real problem with recursive loops), and then restoring them before leaving a subroutine or program block.

In contrast, consider bash shell scripts. The functionality of a lot of commands depend on environment variables, but at least it's easy to "cordon off" environment variable changes to within the scope of the current shell script.

Ugh...I'd rather not think about it.

I've just reminded myself why usable computer programming languages have scoping...

George
2010-Jul-22, 08:48 PM
It depends on your definition of "easy". Yes, I should qualify that. I am referring primarily to the
ease of learning the language initially as opposed to how nicely it works thereafter.

This is coming from professional experience in Basic(from simple to dotnet), Fortran, Pascal, C(from simple to dotnet), Progress 4GL, SQL, LISP (and some others that I can't think of [or don't want to admit to] at the moment). I’m no “programmer”, which is one reason I have posed the question. But I am more familiar with the first four, though SQL is probably a good choice of easy- to-learn software. When Pascal was introduced, it seemed to have a steeper learning curve than I wanted to mess with. The other three were relatively easy and I enjoyed Fortran do-loops, I even enjoy saying “do loops”. 

I don't know what DBase language is like. It may not even be considered a true “language” by professionals as it is structure on C or some version of it I recall writing some C++ code to replicate the dBase programs since I could compile executable files for distribution, something dBase did not allow.
I bought dBase back when PCs had come out because every computer store, and there were many back then as you may well remember, could not sell me a software package that could handle many business needs, such as inventory control. There were some main frame programs available, of course, but small business couldn’t touch the investment, much less the upkeep. Almost every PC store I went to kept telling me to write the program myself using dBase. So, I did. It was surprisingly easy. Today, we use an IBM industry package that still can not do what we programmed long ago. Well, unless we pay for all the custom programming time, that is. 

But that was long ago, what is similar in simplicity today?

George
2010-Jul-22, 08:52 PM
This is ancient history but in terms of terms, Commodore Assembly was probably the simplest I ever worked in. Assembler language?? :eek: Even for the old Commodore that had to be a non-intuitive memorization thing, like DOS, right?


Of course, actually doing the stuff that higher level languages did was another matter. That's why I programmed mostly in Commodore BASIC and used code calls for things that benefited from fast execution. How fast is fast on a Commodore? ;)

IsaacKuo
2010-Jul-22, 08:55 PM
Anyway, my answer would be MATLAB (or Octave, a largely compatible free software alternative). Very quick and easy to do the things it's meant for (math, especially with matrices). As a special purpose language, it doesn't need the complexity of a jack-of-all-trades.

As for general purpose languages, I suppose Python is the easiest I've dealt with.

PetersCreek
2010-Jul-22, 08:57 PM
Assembler language?? :eek: Even for the old Commodore that had to be a non-intuitive memorization thing, like DOS, right?

Yes, indeed it was. I got pretty good at remembering frequently used hex values, too.


How fast is fast on a Commodore? ;)

It's all relative isn't it? It was often the difference between a snappy screen refresh and watching everything update line-by-line.

George
2010-Jul-22, 09:18 PM
xBase languages are primitive. So is vanilla ice cream but I like it. ;) Rbase, I think it wsa called, was another popular xBase package, and probably just as easy.


It's easy to create something that does something very very simple, but anything involving more than one table is a nightmare. Yes, xBase stuff was great till Windows came along. dBase IV was their Windows launch and when I tried it, most the user-friendliness had disappeared. There was no dBase V that I recall.


You're dealing with a dynamic environment which is okay when you're entering commands interactively but it gets crazy when you're dealing with a program.
For me, it was more the opposite; we rarely used dBase in an interactive [command] mode. For one project, we had almost 20,000 lines of code in little-ole dBase. :) [Most was simply duplication and tweaking for a few specific user choices.]


For example, field/variable names are sensitive to the currently selected table. Fine, if there's only one table to worry about. The beauty, at least the DOS version, was that our original user need was for simple operations. Once these smaller programs were quickly written (without any training), then much more comprehensive programs were written to handle the larger departmental requirements, but even these weren't bad due to the intuitive nature of dBase III+. Data file selection was simply Select X, where "X" was either the number or letter of your database file. [Even here number and letter were synonymous (e.g. database 1 was also database A).] I think the variables required only a little more thought when many programs were being called, as I recall, but it wasn't that big a deal. What struck me was how intuitive it was. I don't think there was much that required a mental mind wrapping around certain commands or functions that is often required in learning even the other basic languages like C.


There are a zillion little environment settings that you need to set or change in order to get the desired functionality out of your command--and it's entirely up to you to figure out what the settings were previously, saving them temporarily in some place that won't get overwritten (a real problem with recursive loops), and then restoring them before leaving a subroutine or program. I think this was one of the distasteful aspects of dBase IV that I quickly encountered, now that you mention it. It wasn't a problem in dBase III, at least not the stuff I wrote.


I've just reminded myself why usable computer programming languages have scoping... So, now that I have qualified "easy", what do you think would be the easiest today? What would you hand to a non-programmer willing to learn something quick to do a variety of programing that was not command interactive?

George
2010-Jul-22, 09:23 PM
Yes, indeed it was. I got pretty good at remembering frequently used hex values, too. Ah yes, both words, "assemler" and "hex", combined nicely to give me the warning I needed, metaphor not excluded. :) Running along side pure chip language code with assembler was beyond my interest, though we all admired those who could, especially given the high cost of a few kilobytes of ram. :)


It's all relative isn't it? It was often the difference between a snappy screen refresh and watching everything update line-by-line. Man, you're really old! ;)

PetersCreek
2010-Jul-22, 09:40 PM
...especially given the high cost of a few kilobytes of ram. :)

True, too. To save money, I scratch built my own ram module for the VIC-20...including...etching the PC board. I didn't save that much money, to be honest but I enjoyed every minute of it.


Man, you're really old! ;)

I'm young...with decades of experience. Now hush, young'n. :D

Back on topic, I made abortive attempts to learn Fortran and other languages but at the time, I couldn't conceive of life without line numbers. Since then, I've only worked with scripting, mark-up, and application languages, such as VBA.

slang
2010-Jul-22, 09:43 PM
Logo (http://en.wikipedia.org/wiki/Logo_%28programming_language%29)! Turtle up! Turtle down!


Man, you're really old! ;)

Phft! :) Anyway, fast on a commodore 64 was a whopping 1 MHz clock frequency. You could make it run a little faster by switching from PAL to NTSC output. Of course you couldn't see anything on screen anymore, but it was 25% faster in that mode. :)

Rhaedas
2010-Jul-22, 09:53 PM
How fast is fast on a Commodore? ;)

1 megahertz. That's 1. But it was a quality megahertz. :)

Most recently the programming language I've been exposed to and enjoyed learning is PHP. Using that and MySQL, I've been able to do amazing things. (imo) :D

George
2010-Jul-22, 10:01 PM
True, too. To save money, I scratch built my own ram module for the VIC-20...including...etching the PC board. I didn't save that much money, to be honest but I enjoyed every minute of it. That's impressive. I only remember the 64 version, but I had already been hooked on the Apple II before the Vic 20 arrived. We did all-nighters playing Ultima and learned words like gelatinatious, but not necessarily how to spell them, I fear.


I'm young...with decades of experience. Now hush, young'n. :D For those who don't see the joke, I was being facetious. I'm likely older. :)


Back on topic, I made abortive attempts to learn Fortran and other languages but at the time, I couldn't conceive of life without line numbers. :) I loved Fortran, but only because it was taught in college, so I didn't have to learn it on my own. Back in those days (early 70's), the college of "computer science" didn't exist. It was taught under Ind. Engr., at least at A&M. First, we had to take a sliderule course as freshmen, though not a pre-requisite to Fortran.


Since then, I've only worked with scripting, mark-up, and application languages, such as VBA. What would you recommend for a rookie in today's world that wanted to learn on their own?

clop
2010-Jul-22, 10:02 PM
Sinclair ZX Basic was uber easy!

clop

Strange
2010-Jul-22, 10:12 PM
ML. Stuff just works.

George
2010-Jul-22, 10:16 PM
Logo (http://en.wikipedia.org/wiki/Logo_%28programming_language%29)! Turtle up! Turtle down! That one looks relatively easy. I don't recall hearing about even though it is really old like.......uh, me. ;)


Anyway, fast on a commodore 64 was a whopping 1 MHz clock frequency. Ah, Apple II speed, apparently. Considering the price, IIRC, it was quite a bargain. The Apple II was originally about $1,300, according to Wiki, which was a lot of money back in '77.


You could make it run a little faster by switching from PAL to NTSC output. Of course you couldn't see anything on screen anymore, but it was 25% faster in that mode. :) :) I wonder when it will be when no one believes we did that kind of stuff?

Van Rijn
2010-Jul-22, 10:16 PM
So is vanilla ice cream but I like it. ;) Rbase, I think it wsa called, was another popular xBase package, and probably just as easy.


Rbase was easier and very different from dBase. Rbase was a (more or less) relational database system, but dBase wasn't. I had learned Rbase first, then later did extensive coding in Clipper (a p-code compiler that used DBF database files and a coding language very similar to dBase III+). I didn't do that much directly with dBase, though I used it occasionally.

Clipper had some big advantages for small database applications in the late '80s and early '90s: It was similar to dBase, but it ran faster, it was easier to set up a Clipper executable on a user's system (or a network) than dBase running scripts, it didn't require licenses for the users of the created executables, and the users couldn't mess with the code.



Yes, xBase stuff was great till Windows came along. dBase IV was their Windows launch and when I tried it, most the user-friendliness had disappeared. There was no dBase V that I recall.


Borland had a Windows based dBase 5.0, but it didn't do well. It had a lot of problems. What I remember is that it seemed almost impossible to write a script that wouldn't eventually crash. As I recall, memory leaks were one of the causes. Anyway, by that time, the market was moving away from dBase.

George
2010-Jul-22, 10:18 PM
Most recently the programming language I've been exposed to and enjoyed learning is PHP. Using that and MySQL, I've been able to do amazing things. (imo) :D Is PHP very intuitive? MySQL sounds pretty basic, too.

Rhaedas
2010-Jul-22, 10:32 PM
Is PHP very intuitive? MySQL sounds pretty basic, too.

It shares a lot with Java, Perl, C...they all are similar in how they do things. PHP is a server side scripting language, so it can't do everything, but it sure eliminated me ever making boring static webpages again.

Apple II and C-64 used the same processor, the Motorola 6502.

George
2010-Jul-22, 10:32 PM
Rbase was easier and very different from dBase. Rbase was a (more or less) relational database system, but dBase wasn't. Ok, I recall almost buying it but didn't.


I had learned Rbase first, then later did extensive coding in Clipper (a p-code compiler that used DBF database files and a coding language very similar to dBase III+n Clipper (a p-code compiler that used DBF database files and a coding language very similar to dBase III+). I didn't do that much directly with dBase, though I used it occasionally. Ah ha. I couldn't recall the program I bought for compiling, but I am almost positive it was Clipper.


Clipper had some big advantages for small database applications in the late '80s and early '90s: It was similar to dBase, but it ran faster, it was easier to set up a Clipper executable on a user's system (or a network) than dBase running scripts, it didn't require licenses for the users of the created executables, and the users couldn't mess with the code. Yes I recall all of that. A company called eSoft introduced its own dBase compiler that was exclusive to its bulletin board. We were in hard economic times and we decided to combine our construction equipment product knowledge with my dBase skills and presented a bulletin board for buyers and sellers of used equipment to get together via low cost membership into our system. This was in 1991. Boats and airplanes were next on our list had we been successful. Unfortunately, modems were not quickly put to work in that industry back then, though they quickly became standard equipment.


Borland had a Windows based dBase 5.0, but it didn't do well. It had a lot of problems. What I remember is that it seemed almost impossible to write a script that wouldn't eventually crash. As I recall, memory leaks were one of the causes. Anyway, by that time, the market was moving away from dBase. That is interesting to learn.

George
2010-Jul-22, 10:42 PM
Apple II and C-64 used the same processor, the Motorola 6502.Back then, I also recall a Z80 used here and there. It was the 8088 and 8086 that became the more indelible model names for me.

Of course, the really exciting event came when TI made the paradigm shift from 8 bit to the 16 bit buses. Boy, I thought that was gonna really be grand. Yesh! They weren't bad when the price dropped to their discard pricing of $49. :sad: [I bought 4 for friends.]

George
2010-Jul-22, 10:46 PM
Sinclair ZX Basic was uber easy! Wow, I had forgotten about the Sinclair. I remember working with one, but can't recall just what I was doing or whos it was.

Van Rijn
2010-Jul-22, 11:10 PM
Of course, the really exciting event came when TI made the paradigm shift from 8 bit to the 16 bit buses. Boy, I thought that was gonna really be grand. Yesh! They weren't bad when the price dropped to their discard pricing of $49. :sad: [I bought 4 for friends.]

There were a couple of things I hated about the TI 99/4. One was the "closed box" approach. What I loved about the Apple II was that both the hardware and software were open (and I learned a lot by coding and studying the hardware). The closed box approach made the TI useless for me, and on a more general level, limited development and helped lead to its loss of market.

The other issue is that they initially had a ridiculous keyboard on it. I think they eventually changed that. There were a few companies that tried non-standard keyboards, and most of them eventually changed. Appparently the thinking was that most people at that time hadn't spent much time with typewriters or computers, so would be happy with a cheap, non-standard keyboard. The problem was that the folks that were familiar with computers, the ones that would be programming or recommending them, wouldn't put up with that nonsense.

PetersCreek
2010-Jul-22, 11:14 PM
Apple II and C-64 used the same processor, the Motorola 6502.

Was it the 6502 or the 6510? I'm too lazy to look it up at the moment. The VIC definitely used the '02 but I might be thinking of the C-16 (which I upgraded to) and the C-128 for the 6510. They both used the same instruction set as I recall, so one just needed memory map to make the change in assembly. Wasn't the BASIC somewhat extended for those models?

clop
2010-Jul-22, 11:20 PM
Wow, I had forgotten about the Sinclair. I remember working with one, but can't recall just what I was doing or whos it was.

Every month I used to get "Sinclair Programs", a magazine chock full of 1KB and 16KB programs for ZX80, ZX81 and ZX Spectrum that other people had written and sent in. You can learn a lot about programming when you spend weeks typing in other peoples programs.

clop

baskerbosse
2010-Jul-23, 12:07 AM
The RPN langage I had on my HP28c was probably the easiest to use language I have used.
For computers, I'd say C.

Peter

slang
2010-Jul-23, 12:27 AM
Apple II and C-64 used the same processor, the Motorola 6502.

6510 (http://en.wikipedia.org/wiki/MOS_Technology_6510) on the C-64. Almost the same. The 1541 diskdrive (http://en.wikipedia.org/wiki/Commodore_1541) was powered by a 6502, though. 160 kilobytes on a single floppy. Cut a small hole in it, and it could be used double sided. 320 Kb! Phooey at the terabyte drives of today!

Perl.. !! This thread is supposed to be about easy languages ;) Perl is code on crack! Steepest learning curve I've encountered so far. But once past that first hurdle.. man, what a powerful tool it is!

Logo was a bit of a joke entry, it was known back then as a tool to get kids to operate computers. Well, that was its image anyway. The Commodore BASIC was very easy to learn. In fact, I was able to learn some BASIC programming from a book before I ever owned a computer. It was easy to "do some stuff". But it hardly qualified as a structured programming language. More recent BASIC versions are nothing like that old CBM version. Still, in a general sense, languages that use common english words are probably easier to learn than symbol heavy languages. At some point in your programming 'career' that difference disappears though.


There were a couple of things I hated about the TI 99/4. One was the "closed box" approach. What I loved about the Apple II was that both the hardware and software were open (and I learned a lot by coding and studying the hardware).

Exactly the same for the CBM-64. Designed to be open, lots of ports, and I still have the fully commented ROM listing. Fun to hack around with and burn a new version into an EPROM.

Van Rijn
2010-Jul-23, 12:28 AM
The Sinclair was about the only computer that could justify the chiclet keyboard, since they were going for a low-cost design. I didn't use it, but I liked the idea of the low cost computer, since it got them in more peoples' hands.

Rhaedas
2010-Jul-23, 12:30 AM
Was it the 6502 or the 6510?

Wow, you're correct. And the odd thing is that I swear all the books on programming and memory maps I had back then said 6502. Same difference, I guess. According to Wiki, it's still used widely in embedded systems. Solid design.

Van Rijn
2010-Jul-23, 12:38 AM
I'd go with early versions of BASIC as the easiest to learn.

I first learned BASIC on a DEC PDP 11/35. It seemed like an easy language to learn compared to, say, Fortran IV that I learned a year or so later (Fortran 77 is much nicer than Fortran IV, and in Fortran IV, you are pretty much required to use GOTO - I prefer assembly on at least a couple of CPUs I know over Fortran IV).

I won't say it was easy, but I think the most fun I've ever had learning a computer langauge was with Forth.

baric
2010-Jul-23, 12:56 AM
I'd go with early versions of BASIC as the easiest to learn.


Ya, the first language I learned was a version of Basic with line numbers. A numbered procedural language is extremely limited for anything but the simplest tasks, but it's a great way to learn to program.

I pretty much do everything in Java now. I love the modularity of UI design, the C-like syntax and the Smalltalk-like object model. It's not a programming languages for novices.

clop
2010-Jul-23, 01:28 AM
Learning to program on the Sinclair ZX series taught you an awful lot about programming efficiency. When you have just 1 kilobyte of RAM to play with you develop a wickedly lean programming style. Plus you learn all kinds of little tricks, like LET F=PI/PI used less memory than LET F=1 because PI/PI forced F to be stored as an integer variable. I hate the fact that even simple programs nowadays take up like 4 MEGAbytes. There should be lessons specifically on "lean programming".

clop

NEOWatcher
2010-Jul-23, 01:37 AM
Wow, you're correct. And the odd thing is that I swear all the books on programming and memory maps I had back then said 6502. Same difference, I guess.
I can't remember which was which, but I had a manual for one of them from college, and it worked just fine for working with the c-64.
There was also a C compiler available for it with a mini DOS like environment. It was a bit quirky at times (because of disk swapping) but the programs turned out fairly efficient.


The Sinclair was about the only computer that could justify the chiclet keyboard, since they were going for a low-cost design.
It's (zx81) the first computer I had. I got it as a build your own kit. Unfortunately; I ended up paying the extra $50 anyway, because I missed a resistor that wasn't obvious on the plans.
I had the extra 16K memory plug in (which you couldn't rely on staying plugged in), and a graphics module for it. (2X2 pixels per character)

I even programmed machine language on it. It was so fun* to poke bytes into the BASIC Rem statement.

*tedious.

baric
2010-Jul-23, 02:29 AM
Learning to program on the Sinclair ZX series taught you an awful lot about programming efficiency. When you have just 1 kilobyte of RAM to play with you develop a wickedly lean programming style. Plus you learn all kinds of little tricks, like LET F=PI/PI used less memory than LET F=1 because PI/PI forced F to be stored as an integer variable. I hate the fact that even simple programs nowadays take up like 4 MEGAbytes. There should be lessons specifically on "lean programming".

clop

haha! I know what you mean. I learned to program under the same kind of constraints (although I had the luxury of 32K for my program and data!)

This reminds me of a story when I was in my Design class in college. Our professor was polling classmates for how they would structure a simple conditional where you alternate an N value between 1 and 2.

There were lots suggestions for the obvious 'If N = 1 then N =2 else N=1'. Some students got cute and suggested adding range-checking for N, etc.

When he asked me, I said "N = 3 - N". He paused and asked if I was an engineering major (lol). I said "No, but I've had to write programs in 32K of memory!"

He and I got along real well after that :P

swampyankee
2010-Jul-23, 02:41 AM
I would say the easiest is dependent on what you're trying to do. I've used (among others) Fortran (-66, -77, -90, -95), Perl (5, but not 6), SQL, and C/C++ to build significant applications. Since these languages are Turing complete, all of them are equally capable of any computational task, but for most applications where the maximum possible performance is not required, I'd tend to use Perl.

agingjb
2010-Jul-23, 07:28 AM
I was most productive in IBM 370 Assembler, with extensive use of macros, and, for the early IBM PC, C with a very few assembler routines to tweak hardware as necessary.

The easiest programming language was probably REXX.

swampyankee
2010-Jul-23, 11:27 AM
I was most productive in IBM 370 Assembler, with extensive use of macros, and, for the early IBM PC, C with a very few assembler routines to tweak hardware as necessary.

The easiest programming language was probably REXX.

I have an IBM 370 Assembler story. One of my employers got a NASA contract to write a helicopter performance program. The program was being developed on the company's 370, but the product was to be run on a CDC 6600 machine. The developer1working on the program was giving great progress reports, excellent results vs test data for all the test cases, good performance, etc. About a month before delivery, the contract manager said "show me your source code." (arguably, he should have said this much sooner). All in IBM 370 assembly. Oops! That won't work on a CDC. Contract default, send a large check to NASA.

Considering the size of the contract, I'm surprised that somebody didn't write a IBM Assembler -> CDC Assembler translator.

----------------

1: I think he was a programmer, not an engineer, but this occurred before I worked there.

George
2010-Jul-23, 01:29 PM
There were lots suggestions for the obvious 'If N = 1 then N =2 else N=1'. Some students got cute and suggested adding range-checking for N, etc.

When he asked me, I said "N = 3 - N". He paused and asked if I was an engineering major (lol). I said "No, but I've had to write programs in 32K of memory!"

He and I got along real well after that :P :)

Strange
2010-Jul-23, 02:30 PM
I said "No, but I've had to write programs in 32K of memory!"

32K! Luxury. When I were a lad all we had was 1K. And you were lucky if it was bytes...

Larry Jacks
2010-Jul-23, 02:56 PM
32K! Luxury. When I were a lad all we had was 1K. And you were lucky if it was bytes...

Reminds me of an old Dilbert comic where two graybeards were trying to outdo one another with tales from the Old Days

"When I was startiing out, all we had were ones and zeros!"
"You had ones?"

baric
2010-Jul-23, 03:29 PM
32K! Luxury. When I were a lad all we had was 1K. And you were lucky if it was bytes...

/clap if that was a Monty Python reference :P

Yes, I had the Color Computer PLUS with 32K memory and Extended Basic. I wallowed in the royal excess of a 160K 5 1/4" floppy drive (single sided, but double density!).

Cassette storage was for the peasants. LET THEM READ TAPE.

JohnD
2010-Jul-23, 06:18 PM
BASIC has ben mentioned but not BBC BASIC.
Written originally (and obviously!) for the BBC Micro, which may be where the 32K mentioned above comes from.
It has been implemented for many other platforms and operating systems, inc. Windows, UNIX, C++ and the Mac.
It is a fully structured Basic with definable Procedures and Functions.
It is interpreted but has it's own compiler

The Author, Richard Russell has his own website http://www.compulink.co.uk/~rrussell/bbcwin/manual/bbcwin0.html#intro0
While you can download trial versions and see more about it at: http://www.bbcbasic.co.uk/bbcbasic.html

JOhn

Larry Jacks
2010-Jul-23, 07:46 PM
In my pre-PC days, I learned to program a TRS-80 Model III (48K of RAM and dual floppies, whoohoo!) in GW-BASIC. When TRSDOS was booted and the BASIC intrepreter loaded, there was about 32,000 bytes left over for the program and data. People came up with all sorts of ways to stretch that amount of RAM with one of the most common being leaving out all comments and spaces in your lines of code. It'd look something like: 100 IFS!<100THENGOTO3000ELSEGOSUB1000.

That was awful in just about every way. When I switched over to PCs (640K of RAM), I could boot the system and the intrepreter and have most of a 64K segment available for the program and data. Compared to the TRS-80, that was a big improvement but the segmeneted memory still limited the size of my programs. Later, I was able to write much larger programs using Microsoft QuickBasic 4.0, Borland Turbo Pascal and Turbo C/C++. I really loved those early integrated programming environments. For DOS console programming, those were all easy to use languages.

Back then, I also programmed in other languages including Aspect, Ada, JOVIAL, Modula II, and a 4GL whose name escapes me at the moment. I didn't like any of those languages very much.

When I moved to Windows programming, I used Visual Basic, VB.Net, C++ and Java. I also did some work in an expert systems language called CLIPS. When it comes to knocking out a quick Windows program to meet a specific need, I found it hard to beat VB and VB.net.

Today, I consider myself a recovering programmer. I do system analysis now using UML. Occassionally, I get to knock out a custom database to meet a specific purpose but that's about the extent of it.

dgavin
2010-Jul-23, 08:15 PM
My current best picks over all are .Net C# and Cobol v3

I actually categorize the languages i use by three areas, ease of use, flexibility (maintainability), run speed.

.Net C#/VB Good, Poor, Good - The OO Paradigm it uses prevents working with directly allocated structures in memory. This is a problem when you try to write processes that use their own customized buffering of data, or integrating with legacy data from mainframe or record based file sources. As such it's not very flexible in allowing programmers to build more advanced forms of processes. Would be much more flexible of a language if they reintroduced a set of primitives inside of structures that were allocated as a block/offset instead of each needing independent allocation, this would also speed up memory allocation and garbage collection. The underlying byte arrays of all data-types should be accessible and changeable without going through the System.Reflection methods (no more immutable strings, etc...).
Compared to Java though it is a much cleaner and better performing language.

Cobol v3 Fair, Good, Excellent - The main issue with COBOL now adays, is integrating with other languages is a pain. However for high performance applications, only assembler can beat it, and then not by much. It's also unbeatable for dealing with huge amounts of data, either on disk storage or in main core.

Java Poor, Bad, Poor - It's not the worst language I've ever used, but it's close. Run speeds are far too slow to use in high performance or large data handling applications. It has the same issues with working with memory that .Net has, but it's compounded in JAVA.

Natural (Natural Construct) Excellent, Poor, Good - The first OO language, that also incorporated some RAD/5thGL architecture. Very complex application could be built in months, that would take years in other languages. However it wasn't very flexible at all, even trying to call an OS service from it was shakey at best.

Basic Average, Fair, Bad - The slowest of the interpreted languages, great as a learning tool or for scripting facility, but not a good choice for professional work.

HenrikOlsen
2010-Jul-23, 09:31 PM
As so many have said before, it depends a lot on what the application is supposed to do.

There are several languages where you can put together a program in a fairly short time with very little prior training.
This makes it feel like it's an easy language for the inexperienced.
Unfortunately, to get it from the toy stage to a real product, using that same language, takes a nightmarish about of work even for an experienced programmer. I count Visual Basic as one of those.

For programs where execution speed isn't the absolutely essential criterion, I tend to use Perl (5) because of several nice features such as a very nice back end independent database API which makes it possible to get very close to not needing to care about what kind of server the data are on, plus nicely nonrestrictive OOP.
And with tk it works quite OK for making Windows programs too, in a way that makes you not care what system you're running it on.

Web server applications, either Perl or php, there I tend to adjust based on who has to support it after me.
If speed matters, C or C++.

Van Rijn
2010-Jul-23, 10:25 PM
About a month before delivery, the contract manager said "show me your source code." (arguably, he should have said this much sooner). All in IBM 370 assembly. Oops! That won't work on a CDC. Contract default, send a large check to NASA.

Considering the size of the contract, I'm surprised that somebody didn't write a IBM Assembler -> CDC Assembler translator.


I doubt that would have worked well. The architecture of the CDC computer was very different from the IBM 370. My university had a later Cyber computer, and from what I can find online the general architecture was similar to the older CDC 6600. From personal experience, COMPASS (CDC assembler) was very different from IBM 370 assembler.

The best that could probably be managed would be an interpreter, but that would be slow, and give up the advantages of machine language. If they wanted it to run on the CDC, there wasn't much choice but to write a new program for the CDC.

swampyankee
2010-Jul-23, 10:50 PM
I doubt that would have worked well. The architecture of the CDC computer was very different from the IBM 370. My university had a later Cyber computer, and from what I can find online the general architecture was similar to the older CDC 6600. From personal experience, COMPASS (CDC assembler) was very different from IBM 370 assembler.

The best that could probably be managed would be an interpreter, but that would be slow, and give up the advantages of machine language. If they wanted it to run on the CDC, there wasn't much choice but to write a new program for the CDC.

The program was supposed to be written in Fortran (well, FORTRAN), which has somewhat fewer portability issues than just about anything else.

cjameshuff
2010-Jul-23, 11:54 PM
Look at JavaScript. It's a simple, but surprisingly capable language, and you're rather unlikely to have a computer that doesn't have an interpreter for it. The biggest downside...you're also unlikely to have a standalone interpreter that'll run JavaScript as a standalone script...you'll be limited to stuff you can do through a web browser interface unless you go through some effort to find and install such an interpreter (and libraries to make it useful as such a language, like file I/O). Even used through a web browser, though, when combined with the <canvas> tag, it gives you a nice little environment that allows immediate visual feedback. I found the ability to *see* what my code was producing to be a great benefit in learning to program. GUIs are complicated and huge masses of text are boring, but you can cram a lot into procedurally generated imagery. Other languages sharing this benefit are Logo and (on a fast computer) POV-Ray (which has a rather primitive language that still allows you to construct wonderfully complex 3D scenes).

Ruby is more useful as a general purpose scripting language. If you're processing text files or automating tasks, it's a good choice. Cleaner than Perl, without some of the stupid design decisions of Python. Easy to get started with, but not limiting. Slow, though.

C++. Yes, C++. The basic syntax is really not very different from any other common language, it's not at all difficult to write a simple program that still accomplishes something useful. Mastering it will take a great deal of time, but you don't need to master it to be productive in it. And it's fast. Get some good libraries for graphics output and things like GMP for numerics, and have fun.

The "simplicity" of languages like BASIC is misleading. You can take the same kind of code you'd write in BASIC and write it in C++ or some other more-capable langage, and it's unlikely to be significantly more complicated...it's could easily be a little simpler. What those "more advanced" languages give you is mainly tools for making life easier, which will give you a better way of doing things when you learn them. With BASIC, you're stuck doing things the "simple" way, which often involves orders of magnitude more work.

If you need a little configuration or control language to embed in another program, look at Lua. It's simple and limited in functionality on its own, but it's meant to be easy to embed in another program, not to write entire applications in.

And a weird one to end things with: PostScript. It's nothing like the above languages. It's fairly simple enough to learn, actually, but getting into the right mindset to actually do things in it might be a hurdle. It's non-interactive, which is a downside for learning, but the visual output is a benefit as it is for Logo or JavaScript+<canvas>. Just making drawings is pretty simple, though.

JohnD
2010-Jul-25, 08:23 AM
The "simplicity" of languages like BASIC is misleading. You can take the same kind of code you'd write in BASIC and write it in C++ or some other more-capable langage, and it's unlikely to be significantly more complicated...it's could easily be a little simpler. What those "more advanced" languages give you is mainly tools for making life easier, which will give you a better way of doing things when you learn them. With BASIC, you're stuck doing things the "simple" way, which often involves orders of magnitude more work.

If you need a little configuration or control language to embed in another program, look at Lua. It's simple and limited in functionality on its own, but it's meant to be easy to embed in another program, not to write entire applications in.

james,
Have you ever tried BBC Basic? I don't think it can be described as a "simple" langauge. It has been compared favourably to C++, it allows named procedures, which can be selected from libraries of procedures, and includes an assembler, so that control codes can be included. As a complete novice I wrote a mouse driver in assembler for BBC Basic, in the 8086 version for early PCs.

John
PS Though I have been told the "BASIC rots your brain!"

George
2010-Jul-25, 04:37 PM
C++. Yes, C++. The basic syntax is really not very different from any other common language, it's not at all difficult to write a simple program that still accomplishes something useful. Mastering it will take a great deal of time, but you don't need to master it to be productive in it. And it's fast. Get some good libraries for graphics output and things like GMP for numerics, and have fun. Yes, but I had assumed that something easier to learn had come around since C++ is an old timer. :) For a non-programmer, as you say, mastering it does take a lot of time, usually time that nascent programmers or businessmen aren't willing to invest. Nevertheless, C++ and Basic seem to be some of the "most juice for the squeeze" for those just starting, and probably will never care to advance for whatever reason.

This is why I liked dBaseIII+ since it was -- is it still around? -- easier to learn than C++, though more restrictive than any real programmer would like, no doubt. For simple projects, it worked fine. [It does, or did, have a Y2K problem that is easy to fix with a simple call routine.] Admittedly, I already knew Fortran and a little BASIC before attempting dBaseII (III came later), so I had a clear advanatage in overcoming the learning curve. Nevertheless, a co-worker, who had never programmed before, starting writing code behind my back and we suddenly engaged in friendly competition in seeing who could write the most attractive screen presentation, which was a bit cumbersome in dBase. :)


The "simplicity" of languages like BASIC is misleading. You can take the same kind of code you'd write in BASIC and write it in C++ or some other more-capable langage, and it's unlikely to be significantly more complicated...it's could easily be a little simpler. What those "more advanced" languages give you is mainly tools for making life easier, which will give you a better way of doing things when you learn them. With BASIC, you're stuck doing things the "simple" way, which often involves orders of magnitude more work. That's a nice summary of how it is and always has been, no doubt.

So for those who only need a few specific applications to meet there special needs, and a thousand or more lines of code is not needed to accomplish the task, BASIC (some easier than others, apparently) seems to be one and a few others have also been mentioned but I am unclear just how intuitive they are. Perhaps Postcript, JAVA or Logo would be best for those into simple graphics.

cjameshuff
2010-Jul-25, 04:52 PM
Have you ever tried BBC Basic? I don't think it can be described as a "simple" langauge. It has been compared favourably to C++, it allows named procedures, which can be selected from libraries of procedures, and includes an assembler, so that control codes can be included. As a complete novice I wrote a mouse driver in assembler for BBC Basic, in the 8086 version for early PCs.

John
PS Though I have been told the "BASIC rots your brain!"

I have not tried BBC BASIC (I've used the Apple IIe, C64, Tandy COCO2, and MSVB dialects). It appears they made many improvements, but starting a new language by basing it on BASIC would be nothing but a handicap. The end product certainly doesn't look comparable to C++, it appears that it just adds some of the structured flow control of languages like Pascal and C.

The only thing BASIC and its derived languages have going for them is marketing. They really have no advantage in ease of use, while having many disadvantages. And yes, they do teach poor programming habits while failing to teach necessary programming skills, so "BASIC rots your brain" is not inaccurate.

baskerbosse
2010-Jul-25, 11:26 PM
The only thing BASIC and its derived languages have going for them is marketing. They really have no advantage in ease of use, while having many disadvantages. And yes, they do teach poor programming habits while failing to teach necessary programming skills, so "BASIC rots your brain" is not inaccurate.

I have to agree.
-Be careful.
Easy to learn is not the same as easy to use.
(there are lots of useless things that are easy to learn ;-))

/Peter

clop
2010-Jul-26, 12:36 AM
BASIC has ben mentioned but not BBC BASIC.
Written originally (and obviously!) for the BBC Micro, which may be where the 32K mentioned above comes from.
It has been implemented for many other platforms and operating systems, inc. Windows, UNIX, C++ and the Mac.
It is a fully structured Basic with definable Procedures and Functions.
It is interpreted but has it's own compiler

JOhn

I hated the envelope command for making sounds with it. How many parameters can one function need.

clop

jj_0001
2010-Jul-26, 10:15 PM
I was most productive in IBM 370 Assembler, with extensive use of macros, and, for the early IBM PC, C with a very few assembler routines to tweak hardware as necessary.


Hmm, how many kinds of jumps and unconditional branches were there, then? :)

I vote for Algol 60, as implimented on the G20 and GE Timesharing Mk 1.

slang
2010-Jul-26, 11:35 PM
I totally understand the sentiments against early BASIC's, and the drawbacks of learning to program in it. They really were not good programming languages, for the several reasons already mentioned. But they were most certainly the easiest to learn and use, for simple things and for beginners.

In the end, it doesn't really matter which language you learn. Once you get good at it, and start some playing around with other similar languages, you'll soon find out that most languages have a large subset of identical instructions/words/functions. Once you get a grasp, an intuitive sense, of what you can, and cannot do in programming, and what the limitations of computers are, it's much easier to pick up new languages. After all, you already have a pretty good sense of what that language should be able to do, and now you only need to find out how.

There's a caveat about procedural (C, Pascal, Perl, etc) and object oriented (C++, Java, etc) languages. The latter is very, very different, and requires a completely different way of thinking, at least to use it to its full potential. Procedural is probably the easiest to learn, and parts of it will come back in OOP.

After BASIC and Pascal, I learned C, and still love it. And perl. But that's love and hate. :) I've worked with many others, scripting, assembler, 4GL/database, OOP, and procedural. But whenever I need to do something silly quick, I still tend to go to C. And that's not advocating which language is best, I've always said that the best language is the one you can use best. Not one that is theoretically better but you might need to learn first..

mugaliens
2010-Jul-27, 03:33 AM
WATFIV. Then again, I only know (knew) two languages, and the other one, Basic, not very well (it's ok for basic graphics, though very slow).

agingjb
2010-Jul-27, 07:35 AM
Hmm, how many kinds of jumps and unconditional branches were there, then? :)

I vote for Algol 60, as implimented on the G20 and GE Timesharing Mk 1.

Unstructured Gotos? In Assembler, as few as I could contrive, which, in time, meant that my code was, in effect, the compilation of a fully structured language, so, with practice, none. In C, none. In the small assembler routines needed to tweak hardware for C, none.

The Algol 60 report was interesting as a model for the formal definition of a language. The Algol 68 report was even more interesting, although some have regarded it as a trifle opaque.

kleindoofy
2010-Jul-27, 06:04 PM
... The easiest programming language was probably REXX.
Yup, I was going to say the same thing.

I've been using Kedit (ascii editor) for over 25 years. It contains an internal Rexx subset (Kexx) and is fully programmable.

In fact, for ascii text manipulation I don't really use anything else anymore. The latest version has fantastic string operators that I've never seen anywhere else.

I presenty have "macros" (de facto programs) that have over 3500 lines of code, including subroutines, the works. I've even used it for mutiple run keyed file sorts (with context extraction).

Just a few weeks ago I had to write a programm that simulated BibTeX. A publisher had a TeX file that was riddled with dynamic BibTeX commands, They wanted all the bibliographic information hardwired into the text because it had to be converted. No problem. Kexx took care of the whole thing, i.e. parsing the BibTeX database, and formatting everything the way the publisher wanted it, including lots of very complicated cites.

The best thing is that if you have learned another structured language, Rexx (Kexx) can be used almost intuitively.

mugaliens
2010-Jul-27, 06:40 PM
The best thing is that if you have learned another structured language, Rexx (Kexx) can be used almost intuitively.

From Wikipedia: "KEXX is a commercial radio station located in Phoenix, Ariz..."

No, wait...

xedit or XEDIT may refer to:
xedit, a text editor for the X Window System on Linux and UNIX
XEDIT, a visual text editor for the VM/CMS operating system
xedit, a simple xml/xsl editor available at "http://greschenz.dyndns.org"

I gather it's the first one?

kleindoofy
2010-Jul-27, 06:51 PM
... XEDIT, a visual text editor for the VM/CMS operating system ... I gather it's the first one?
No, it's the one I didn't delete from the quote.

Xedit was the text editor on IBM main frames which ran VM/CMS. It had a full Rexx version.

Kedit was a slightly altered version which was ported to IBM PC's (DOS) back in around 1985 and has been through a number of versions. It has the Rexx subset Kexx.

http://de.wikipedia.org/wiki/KEDIT (only German, no English available) and http://www.kedit.com.

pzkpfw
2010-Jul-27, 08:42 PM
In my pre-PC days, I learned to program a TRS-80 Model III (48K of RAM and dual floppies, whoohoo!) in GW-BASIC. ...

Some of my first programming (basic and assembly) was on TRS-80 Model I's, with the disk expansions. (I have a model I in a box in my garage right now).

It used "Microsoft Level 2 basic", and I thought the Model III did too. Wasn't "GW-basic" the thing that came with DOS on PC's?

Larry Jacks
2010-Jul-27, 08:56 PM
It used "Microsoft Level 2 basic", and I thought the Model III did too. Wasn't "GW-basic" the thing that came with DOS on PC's?

Could be. I have not had that computer for over 20 years.

Strange
2010-Jul-27, 09:11 PM
In my first job, the "old hands" took pride in doing all their scripting in the TECO editor's macro language.

It has been observed that a TECO command sequence more closely resembles transmission line noise than readable text.
http://en.wikipedia.org/wiki/Text_Editor_and_Corrector

kleindoofy
2010-Jul-27, 09:31 PM
... Wasn't "GW-basic" the thing that came with DOS on PC's?
If I'm not mistaken, GW-basic started with DOS 3.3, which was the most stable version until DOS 5.0.

That was when the first affordable color monitors became available. GW-basic could do color "graphics" and play music, albeit with the system loudspeaker which was more a beeper than a loudspeaker.

kleindoofy
2010-Jul-27, 09:58 PM
... TECO editor's macro language. ...


TECO is not just an editor, but an interpreted programming language for text manipulation. Arbitrary programs (called 'macros') for searching and modifying text give it great power ...
That sounds like Kedit's Kexx.


TECO does not really have syntax; each character in a program is an imperative command, dispatched to its corresponding routine.
That doesn't sound like Kedit's Kexx.


*-5DIGoodbye$0TT$$
printf("Goodbye world!\n");
http://en.wikipedia.org/wiki/Text_Editor_and_Corrector
Heavens.

Here's a typical Kexx line that will, e.g., read a substring (substr) from the line the cursor is on (curl.3()), from the column number of the cursor location (curs.2()) for a length comprised of the length of the cursor line (len.1()) minus the column number of the cursor location (curs.2()) +1, into a array variable with the dynamically replaced name vname with the running variable number i.


V.vname.i = substr(curl.3(),curs.2(),len.1()-curs.2()+1)

That's an easy line to write for parsing part of a database line. If one has the help file open, the commands are more are less intuitive. That macro line is about as basic as it gets. The more powerful stuff starts further down the line.

Van Rijn
2010-Jul-27, 11:57 PM
In my first job, the "old hands" took pride in doing all their scripting in the TECO editor's macro language.


I did a bit with TECO at my university, more for fun than for practical use (back then I always liked to see what I could make the computer do). But, I do remember TECO as being very hard. It was very tricky getting something to work correctly, and anything you did was essentially unreadable after you left it for a day. REXX (and the KEXX near-clone for the KEDIT editor) code on the other hand, is very readable and easy to get started in.

dgavin
2010-Jul-28, 12:15 AM
In my first job, the "old hands" took pride in doing all their scripting in the TECO editor's macro language.

It has been observed that a TECO command sequence more closely resembles transmission line noise than readable text.

If you think TECO was bad, you should of seen IBM's language APL. It was basically a keyboard symbol (with over 500 symbols mapped to alt, APL, and FN key combos with standard keys) based language. Programs that might take 400-800 line in Cobol, C or even more n MacroAssem, could be done in 2-3 lines in APL. Great way to spead up coding.

Debugging it was a living nightmare though as it was very akin to transmission line noise like you mentioned with TECO.

cjameshuff
2010-Jul-28, 12:43 AM
The best thing is that if you have learned another structured language, Rexx (Kexx) can be used almost intuitively.

Never came across REXX code before, but looking at some examples, it looks like a very clean and simple language...and far better than any of the BASIC family. A bit verbose for my tastes (I prefer things like the use of curly brackets to enclose blocks of code, for example), and its approach to data structures seems rather eccentric, but I've downloaded the Regina interpreter and will take a look when I need a break from figuring out Lua. (Currently writing Lua bindings to an orbit simulator, which itself is written in C++.)

DonM435
2010-Jul-28, 01:28 PM
In the early 1980s I worked at a small state college that had remote terminals into a IBM 370-type mainframe.

I did a lot of programming in SAS, mostly the 1979 edition. With it, you could attach big data files on disk (or tape) storage, read them in under your own variable definitions, and with a few commands sort. merge, extract, create new files, run detailed statistics and such. No fancy interface, just Fortran/PL1 type statements in text. Batch-submit and wait for the output. Very unforgiving -- if you had an error, you had to do it over. Once you had a library of programs a new task just involved some updating or tweaking.

I've since done similar things in SQL and Excel, but it seems more involved, and I don't have that same sense of control.


There was an interactive language called APL that a few people (super-nerds!) swore by. It had a really esoteric character set (it required its own IBM typeball) wherein you typed these sqaures, triangles, dots and arrows, sometimes combining them. You did all the defining, selecting, sorting, merging and such of entire multidimensional arrays and matrices. A real APL geek could write a program that did tons of work on a single line.

It gave me a headache. But they had a superb text editor that I could use to write term papers and such.

kleindoofy
2010-Jul-28, 07:32 PM
... PL1 ...
Oh, the memories.

I used PL1 extensively on the old IBM mainframes and on the two portations to PCs (CPM and DOS).

It's really a shame that IBM never updated, resp. modernized PL1 after the initial portation to DOS 1.0.

I really liked the sytnax, but it was a drag that you couldn't even do a clear screen on DOS without linking in a short piece of assembler code for the DOS routine call.

Oh well.

dgavin
2010-Jul-28, 07:37 PM
There was an interactive language called APL that a few people (super-nerds!) swore by. It had a really esoteric character set (it required its own IBM typeball) wherein you typed these sqaures, triangles, dots and arrows, sometimes combining them. You did all the defining, selecting, sorting, merging and such of entire multidimensional arrays and matrices. A real APL geek could write a program that did tons of work on a single line.

It gave me a headache. But they had a superb text editor that I could use to write term papers and such.

APL still being used in some places. Also known as the 'A' Programming Language. APL2, Dyalog APL, and A+ are more modern versions of the language. Nothing quite like programming with triangles, squares, dots, circles, emlat's and other symbols!

JohnD
2010-Jul-28, 08:54 PM
Example of APL from http://en.wikipedia.org/wiki/APL_(programming_language)
" (~R∊R∘.ŚR)/R←1↓⍳R " (finds all prime numbers from 1 to R)
And you read it BACKWARDS!

Some say that BASIC rots your brain.

John

kleindoofy
2010-Jul-28, 09:05 PM
... And you read it BACKWARDS! ...
That sounds like it works with a first in / last out stack.

Hmm, can that be?

Strange
2010-Jul-28, 09:12 PM
Example of APL from http://en.wikipedia.org/wiki/APL_(programming_language)
" (~R∊R∘.ŚR)/R←1↓⍳R " (finds all prime numbers from 1 to R)
And you read it BACKWARDS!

If you enjoyed that, you might like some more esoteric programming languages (http://en.wikipedia.org/wiki/Esoteric_programming_language). Some we would not be able to discuss here. But a new one to me was Chef, which is designed to make programs look like recipes:

Hello World Souffle.

Ingredients.
72 g haricot beans
101 eggs
108 g lard
111 cups oil
32 zucchinis
119 ml water
114 g red salmon
100 g dijon mustard
33 potatoes

Method.
Put potatoes into the mixing bowl.
Put dijon mustard into the mixing bowl.
Put lard into the mixing bowl.
Put red salmon into the mixing bowl.
Put oil into the mixing bowl.
Put water into the mixing bowl.
Put zucchinis into the mixing bowl.
Put oil into the mixing bowl.
Put lard into the mixing bowl.
Put lard into the mixing bowl.
Put eggs into the mixing bowl.
Put haricot beans into the mixing bowl.
Liquefy contents of the mixing bowl.
Pour contents of the mixing bowl into the baking dish.

Serves 1.

Or how about Whitespace, which only considers the layout of whitespace and ignores all non-whitespace characters.

kleindoofy
2010-Jul-28, 09:17 PM
Hello World Souffle.

Ingredients.
108 g lard

Method.
Put lard into the mixing bowl.
Put lard into the mixing bowl.
Put lard into the mixing bowl.

Serves 1.
Sounds more like a "Goodbye World Souffle."

Kills 1.

George
2010-Jul-28, 09:39 PM
If you enjoyed that, you might like some more esoteric programming languages (http://en.wikipedia.org/wiki/Esoteric_programming_language). Some we would not be able to discuss here. But a new one to me was Chef, which is designed to make programs look like recipes:

Hello World Souffle.

Ingredients.
72 g haricot beans
101 eggs
108 g lard
111 cups oil
32 zucchinis
119 ml water
114 g red salmon
100 g dijon mustard
33 potatoes

Method.
Put potatoes into the mixing bowl.
Put dijon mustard into the mixing bowl.
Put lard into the mixing bowl.
Put red salmon into the mixing bowl.
Put oil into the mixing bowl.
Put water into the mixing bowl.
Put zucchinis into the mixing bowl.
Put oil into the mixing bowl.
Put lard into the mixing bowl.
Put lard into the mixing bowl.
Put eggs into the mixing bowl.
Put haricot beans into the mixing bowl.
Liquefy contents of the mixing bowl.
Pour contents of the mixing bowl into the baking dish.

Serves 1.

Or how about Whitespace, which only considers the layout of whitespace and ignores all non-whitespace characters.
:) A simplified hybrid for old Fortran and Cobol programmers who are writing robotic chef code. :)

swampyankee
2010-Jul-29, 12:00 AM
INTERCAL (http://www.muppetlabs.com/~breadbox/intercal-man/)!

Forth (http://www.forth.com/forth/) is interesting, especially as it was originated by an astronomer.

Of course, Ook (http://www.dangermouse.net/esoteric/ook.html) is fabulous (http://dictionary.reference.com/browse/fabulous)3.

DonM435
2010-Jul-29, 02:14 AM
:) A simplified hybrid for old Fortran and Cobol programmers who are writing robotic chef code. :)

Hmm, if you combined Basic with Cobol, you could have BASEBOL. (Batter up!)

DonM435
2010-Jul-29, 02:16 AM
Method.
Put lard into the mixing bowl.
Put lard into the mixing bowl.
Put lard into the mixing bowl.


Sounds more like a "Goodbye World Souffle."

Kills 1.

Ahh! Lard forever. The dreaded infinite loop.

Celestial Mechanic
2010-Jul-29, 04:32 AM
Example of APL from http://en.wikipedia.org/wiki/APL_(programming_language)
" (~R∊R∘.ŚR)/R←1↓⍳R " (finds all prime numbers from 1 to R)
And you read it BACKWARDS!

Some say that BASIC rots your brain.

JohnA good example of why many people refer to APL as a "Write-Only Language". ;)

NEOWatcher
2010-Jul-29, 12:19 PM
Hmm, if you combined Basic with Cobol, you could have BASEBOL. (Batter up!)
Been there, done that, but it wasn't named that. It was a DEC invention: DIBOL.
Some years ago, our company was putting in a system, and I needed to learn it. Luckily, I only had to read it rather than try and write with it.

swampyankee
2010-Jul-29, 08:50 PM
I'm trying to remember all the programming languages I've actually had to do some sort of work in.

I'm still thinking for most stuff, I'd use Perl. In the past I've used:
C
C++
CLIST (IBM's somewhat blecherous scripting language for interactive TSO jobs)
COBOL (not happily :( )
Catia's FSD and IUA facilities.
Fortran
IITRAN (which was actually quite nice)
JCL (IBM's blecherous scripting language for batch jobs)
JavaScript
Korn shell
Mortran (a simulation language used at Pratt & Whitney)
PL/1
Panvalet (mostly its macros)
RAMIS II (a database system)
SQL
Speakeasy (kind of like APL written for humans)
UG's embedded language (I can't remember its name)
Univac 1108 Assembler
VBScript
awk
emacs Lisp
sed

I want to try Haskell, Smalltalk, Eiffel, and Erlang.

Oddly (or not), since my ability to pick up human languages is roughly nil -- I'm monolingual despite quite a lot of trying -- I can pick up a programming language fairly quickly.

Any of the modern, dynamic languages should be quite easy to learn: Perl (my favorite), Python, and Ruby. Lua and TCL have their adherents, too.

kleindoofy
2010-Jul-29, 09:10 PM
Can we include TeX and PostScript as programming languages?

If so, TeX is relatively easy to start out with, but gets tricky fast when you have crazy things to do.

PS is amazingly powerful, but freehand scripting anything which includes more than a few lines and squares gets complicated in no time.

HenrikOlsen
2010-Jul-29, 10:41 PM
PS is amazingly powerful, but freehand scripting anything which includes more than a few lines and squares gets complicated in no time.
I remember writing a mail merging application where I let the printer do the line breaking in the letters through a PS subroutine.
These days I would be quite tempted to write such a program as a pipeline including TeX/LaTeX as the layout/typesetting step.

DonM435
2010-Jul-30, 08:26 PM
The state's two-year colleges in South Carolina purchased most of their minicomputers from a firm named Mohawk Data Sciences. They used a language called MOBOL. Circa 1980,I spent a week in a MOBOL class in Atlanta, and I could write MOBOL programs. It was screen-oriented, so that you could compose user-friendly data entry programs. (But you had to do it in code: drag 'n drop hadn't been invented yet.)

The Illinois Institute of Technology had their own computer language, named IITRAN. That was the first one that I learned. I would later realize that it must have been an attemp to improve upon early BASIC.

swampyankee
2010-Jul-31, 02:46 AM
The state's two-year colleges in South Carolina purchased most of their minicomputers from a firm named Mohawk Data Sciences. They used a language called MOBOL. Circa 1980,I spent a week in a MOBOL class in Atlanta, and I could write MOBOL programs. It was screen-oriented, so that you could compose user-friendly data entry programs. (But you had to do it in code: drag 'n drop hadn't been invented yet.)

The Illinois Institute of Technology had their own computer language, named IITRAN. That was the first one that I learned. I would later realize that it must have been an attemp to improve upon early BASIC.

IIT alum? I attended '71 to '75. What I had heard was that IITRAN was developed because IIT replaced their IBM360 with a Univac 1108, and could no longer run PL/1.

It was a pretty nice language, though.

DonM435
2010-Jul-31, 03:08 AM
I took one summer class at IIT, but I attended St Xavier College. They had terminals to IITs computer, as they didn't have one of their own.

kleindoofy
2010-Jul-31, 03:12 AM
... could no longer run PL/1. ...
Does anybody know why IBM abandoned PL/1 like they did?

swampyankee
2010-Jul-31, 03:32 AM
Does anybody know why IBM abandoned PL/1 like they did?

I know that PL/1 was still being used on z/OS when I was doing some work at CSC in late 2008. IIT -- where I went to school -- couldn't use PL/1 as IBM would not permit it to be ported to anybody else's hardware at the time.

As for IBM's business decisions, I seem to remember one of the expansions for "IBM" was "idiotic business moves."

peteshimmon
2010-Jul-31, 08:18 AM
Fascinating thread, surely a good history
will come along soon of software in the last
fifty years and why the subject has matured
to various languages at present.

It was a funny time thirty years ago when
the micro-computer boom started. We already
had Commodore Pets and Tandy in the late
seventies and the exclusive Apple but the
drive to get really cheap machines to the
masses took off. Sinclair, Oric, Dragon...
all sorts. And the magazine racks had more
computer mags than Womens mags! That was
a weird thing.

I have my collection of "discard" sales
as you say. But I could never stay in
long enough to become proficient in
them. Like most I expect. But the
schoolkids who wanted too had all the
machines they needed.

And thats a thing! If there was just
one worldwide micro available for
twenty to thirty years when I was a
kid, there would have been millions
of programmers expert in one standard
language.

But it could never have been, the technology
was changing too fast when it arrived!

kucharek
2010-Jul-31, 08:56 AM
The easiest program language is Whitespace (http://en.wikipedia.org/wiki/Whitespace_%28programming_language%29). Even your grandmother wouldn't be confused when you give her a printout of a Whitespace program. :razz:

My favourite language at the other end of the scale of easy reading is Brain**** (http://en.wikipedia.org/wiki/Brain%66%75%63%6b) :wall:

@Mods: I hope it isn't against the rules that I had to tweak the URL so it wasn't auto-censored. The link just goes to the Wikipedia article of an interesting esoteric programming language with a tongue-in-cheek - name

peteshimmon
2010-Jul-31, 06:30 PM
One thing I meant to say, the one board
micro-computer could easily make a comeback
if some manufacturer puts some modern chips
on a board with rubber keyboard and flash
memory. Language on rom, always felt that
was better, more secure. Hundred times
faster than three decades ago. The trick
is keeping features down and price. Monitor
would be a small flat screen television.
Futuristic image on box and weeee...
kiddies might love them.

Strange
2010-Jul-31, 07:48 PM
One thing I meant to say, the one board
micro-computer could easily make a comeback
if some manufacturer puts some modern chips
on a board with rubber keyboard and flash
memory. Language on rom, always felt that
was better, more secure. Hundred times
faster than three decades ago. The trick
is keeping features down and price. Monitor
would be a small flat screen television.
Futuristic image on box and weeee...
kiddies might love them.

A lot of embedded processors still have these sort of development systems. And there is quite an active hobbyist market aroud some of them. At the cheaper end, you have things like the BeagleBoard (http://beagleboard.org/) and at the other end more multi-media oriented devices (http://www.ziilabs.com/products/platforms/ziidevelopmentkit.aspx).

By the way, the embedded processor market is much larger (in both volume and value) than the PC market.

kleindoofy
2010-Jul-31, 08:05 PM
... couldn't use PL/1 as IBM would not permit it to be ported to anybody else's hardware at the time. ...
Yeah, that's what I meant.

I have a PL/1-86 compiler for DOS 1.0 from Digital Research (1982) right here on my machine. It's only 14K. You have to link with link86.exe (42K) to get an .exe. There's also a nice little rasm86.exe (38K) for compiling assembler code to link into the PL/1 program.

It still runs just fine but has some very serious drawbacks. If one just wants to do data crunching for personal use, it's ok and the programs runs like lightning on new machines. Beyond that it's basically a no go.

Thanks to the compiler, all programs written with it that run through to the end without any problems are nice enough to print "End of Execution" on the screen.

Like I wrote above, it's a shame IBM stopped it at that. PL/1 is a nice language.

DonM435
2010-Aug-01, 02:04 AM
Back when I was using SAS, I learned that the package had been originally been composed in Fortran, but was by then mostly PL1. Pretty sure it went to C or C++ once that was around.

cjameshuff
2010-Aug-01, 03:37 AM
A lot of embedded processors still have these sort of development systems. And there is quite an active hobbyist market aroud some of them. At the cheaper end, you have things like the BeagleBoard (http://beagleboard.org/) and at the other end more multi-media oriented devices (http://www.ziilabs.com/products/platforms/ziidevelopmentkit.aspx).

Don't forget the boards based on small 8-bit and 32-bit microcontrollers. Some are even targeted directly at the hobbyist market, one of the more popular ones being the Arduino. (don't take this as a recommendation...I think you're better off ignoring the whole Arduino software environment, and the hardware is overpriced and has some rather basic design errors that never got corrected for backwards compatibility reasons, like the un-breadboardable pin headers...but it is popular) And there's the Uzebox project, that shows some of what you can do with one of these little 8-bit processors: http://belogic.com/uzebox/

There's also the Parallax Propeller based systems...built around a multi-core processor that was more or less designed for the hobbyist market. And the Make Controller board, targeted largely toward robotics projects.

It's actually far easier to generate analog video signals than digital ones, though. The TV-as-display approach seems unlikely to work for long. There's a good selection of hackable graphical LCD and OLED displays, though, which will give you better quality display with less CPU overhead. And there's those multimedia-oriented boards and things like the BeagleBoard, which often have specialized video hardware onboard.

Also, putting the language in ROM or flash really has nothing to do with security. Putting the program there helps reliability in embedded systems, especially in Harvard architecture systems where all code is in ROM/flash, because the program can't get corrupted by power glitches or program errors. But for a general purpose computer, you'll need the ability to write to non-volatile memory, and for something like the old 8-bit computers with a BASIC interpreter in ROM, the programs themselves coexisted along with the data in RAM. A lot of modern embedded systems load code into RAM for execution for speed reasons...flash just isn't fast enough for processors faster than 30 MHz or so, though some get around it by loading multiple instructions at a time.

JohnD
2010-Aug-03, 05:01 PM
I'm amazed.
I've never heard of Whitespace, or the other one. (Post 92, above)
"The easiest program language", eh?
Lets see, I'm all for 'easy'. So I follow the link to the Wiki article.

This is a language that uses only 'space' and 'tab', with a few text remarks. My grandmother could read it?
As for the 'other one' that uses exclusively punctuation marks - this has to be a computer scientist's esoteric joke, right?

JOhn

Nick Theodorakis
2010-Aug-03, 05:12 PM
They are meant to be jokes, as is LOLCODE (http://lolcode.com/):



HAI
CAN HAS STDIO?
I HAS A VAR
IM IN YR LOOP
UP VAR!!1
VISIBLE VAR
IZ VAR BIGGER THAN 10? KTHXBYE
IM OUTTA YR LOOP
KTHXBYE


Nick

JohnD
2010-Aug-04, 05:46 PM
Thanks!
At least I can recognise a joke, evn if it is a strange language!
John

slang
2010-Aug-05, 12:23 AM
I've heard you have properly learned a language if you can make and understand jokes in it. Still, considering these rather exotic computer languages, what is just a joke to some, is an amazing technological achievement using very few assets to others. Not a very society changing achievement for sure, nor a serious effort for enbetterment of the world, but no easy tasks either. Is building a Golden Gate bridge replica from matchsticks a joke? Surely not to the one doing the building!

kleindoofy
2010-Aug-05, 12:51 AM
... an amazing technological achievement ...
Hmm, well, all the LOLCODE has done is to substitute keywords such as "do," "end," "leave"/"exit", etc. and operators such as "+," ">," etc. with "IM IN YR LOOP," "IM OUTTA YR LOOP," "KTHXBYE," and "up," and "BIGGER THAN," etc.

The compiler still reads and interprets keywords, so it's really only a joke.

DonM435
2010-Aug-05, 03:55 AM
It's probably whatever you master first that defines "easy," and it takes a lot of practice in something new to dislodge that early preference.


I've had people tell me that Assembler was the easiest, probably because of the intricate level of control it gave them. The language remains mostly a mystery to me, but I can undestand the appeal.


If I had to write a program really quick, like to defuse an atomic bomb, I'd choose Fortran were it available. No time for camel casing or balancing the curly braces or checking the array bounds.


Cobol was supposed to be self-documenting. It's just like English, they said. DO-THIS. DO-THAT. DO-SOME-OTHER-DARN-THING. MOVE IN-REC TO OUT-REC. WRITE OUT-REC. STOP RUN. Miller time! I liked the idea.

But when I was studying it, the preferred method involved things like PERFORM 0030-INIT-MODULE THRU 0030-INIT-MODULE-END, and woe if you didn't indent it just right. It seems that you weren't allowed to use variable names like X and Y no matter how generic the task. No, your names had to have at least 40 characters and six hyphens.


Someone once said that when they make it possible for programmers to write in English, they will discover that programmers cannot write in English.

Hlafordlaes
2010-Aug-05, 12:36 PM
@OP,

My vote goes to PICK Basic. Could do some really powerful stuff easily. RBase was fun, too, but could not overcome the "invoice problem" (could not screen update a total of line items, eg for POS apps).

ngc3314
2010-Aug-05, 01:55 PM
A lot of this must have to do with familiarity and how well a language's structure maps to one's way of thinking. Me, I learned FORTRAN so long ago that I still capitalize it, and have been known to write a class payroll assignment in it, as well as code to parse text files extracting spectral-line measures. A brief flirtation convinced me that C is much wordier than I care for in anything I've needed to do. The champion there must be COBOL - I had to change a COBOL program once in a summer job, but at least got paid for the suffering. And then there were NEAT/3, FORTH, and a PDP-8 halfway house to assembler whose name I had to look up - FOCAL.

I'm interested to see how lines blur - some responses have been what I would once have called scripting or interpreting environments rather than languages as such (IDL, Python). For many of us, if it is an effective tool for the job, it doesn't matter.

If I may briefly hop on my curmudgeonly soapbox - too many incoming grad students in physics have learned, at that point in their careers, zero programming languages. I hasten to point out to them that this could be a serious handicap to be remedied immediately - someday they will come across a problem easily solved with programming that just can't be done with spreadsheets. (Back to ground level)

NEOWatcher
2010-Aug-05, 02:17 PM
A lot of this must have to do with familiarity and how well a language's structure maps to one's way of thinking.
Yes; And memory management (in the early days) had a lot to do with it. For instance, FORTRAN has traditionally been non-recursive (fixed memory locations for subroutine variables and references) while others are (variables are stacked). Then there's other levels of scoping for the various languages. There's also the structure of how variables are referenced. (I wonder how many part time programmers really understand the difference between by-reference, and by-value).

Earlier on, the language was important as to what capabilities it had, and how easy it was to corrupt the use of those capabilities (like the dreaded "GOTO"). String conversion and manipulation has also stood out as being different between languages.

Nowadays, the line is starting to disappear. Not only are languages adopting concepts of other languages for versitility, but the objects are becomming more important than the languages that reference them.


A brief flirtation convinced me that C is much wordier than I care for in anything I've needed to do.
Interesting. I've always seen C as a very compact syntax. The difference might be programming style.


The champion there must be COBOL - I had to change a COBOL program once in a summer job, but at least got paid for the suffering.
I got my hands on a COBOL text book in college, and it showed me why I shouldn't persue it. I had a brief flirtation with it in my career, but luckily I didn't have to actually change anything, and only read the flow to figure out how some things were working.


I'm interested to see how lines blur - some responses have been what I would once have called scripting or interpreting environments rather than languages as such (IDL, Python). For many of us, if it is an effective tool for the job, it doesn't matter.
As a tool, or small applications, I agree. But; when you get into serious development, it's going to make a big difference, mostly in efficiency.


someday they will come across a problem easily solved with programming that just can't be done with spreadsheets. (Back to ground level)
Let me add... they will also need to understand previous work which may have relied on programming. (particularly in modelling)

George
2010-Aug-05, 03:30 PM
Cobol was supposed to be self-documenting. It's just like English, they said. DO-THIS. DO-THAT. DO-SOME-OTHER-DARN-THING. MOVE IN-REC TO OUT-REC. WRITE OUT-REC. STOP RUN. Miller time! I liked the idea. That's why I took a class on Cobol (years ago)


But when I was studying it, the preferred method involved things like PERFORM 0030-INIT-MODULE THRU 0030-INIT-MODULE-END, and woe if you didn't indent it just right. It seems that you weren't allowed to use variable names like X and Y no matter how generic the task. No, your names had to have at least 40 characters and six hyphens. That's why I dropped-out after the first class. :)

orionjim
2010-Aug-05, 03:38 PM
...

And then there were NEAT/3, FORTH, and a PDP-8 halfway house to assembler whose name I had to look up - FOCAL.

...


I was wondering if anyone would remember Focal on a DEC PDP-8. That was my first exposure to programming and seemed fairly easy.

The first real program I wrote was a program that would give me four numbers n1, n2, n3 & n4 that when combined as n1/n2 * n3/n4 would give a value closest to a ratio that I input and the calculated error. It took 23 minutes for the program to run, which at the time was unbelievably fast.

That was about 1971. In 1976 I bought a HP-67 programmable calculator that would do the same calculation in 18 minutes. I tried the same thing about 15 years ago on my home computer and when I hit the enter key the result was there. I tried timing it using the computers clock and I got results from .23 seconds to .31 seconds.

Jim

slang
2010-Aug-05, 11:33 PM
A lot of this must have to do with familiarity and how well a language's structure maps to one's way of thinking.

Exactly. It's nice to know that Perl is very good at handling text strings, but if you can get a result in familiar Pascal in minutes, while properly learning Perl may take months... And not everyone is able to "break a problem up in chunks" or to see real world things as abstract objects. Some get it naturally, some with training, some never.

cjameshuff
2010-Aug-05, 11:51 PM
I've had people tell me that Assembler was the easiest, probably because of the intricate level of control it gave them. The language remains mostly a mystery to me, but I can undestand the appeal.

Assembly is *simple*. You have some registers, a memory space or two, and a list of instructions that perform various extremely basic operations on data. There might be some macros or some other quirks of the assembler, but you have basically no syntax other than that for specifying an instruction and that for marking a location in the program with a label. You don't have if-else statements and other flow control statements, you do the job with jumps and conditional branches. It's not difficult in concept, but it is tedious and error-prone. And since you're telling an assembler what instructions you want the processor to run instead of telling a compiler what you want to do, error messages are going to be extremely generic, and the stupidest things imaginable will be accepted as long as they produce a valid sequence of instructions...the assembler has no information about your intent, and can't do anything to check that your code does what it should.



Someone once said that when they make it possible for programmers to write in English, they will discover that programmers cannot write in English.

It's not that programmers can't write in English, it's that programs can't be written in it. The required precision and structure would make it utterly unlike anything any English speaker would ever say or write. The myriad ways to let imprecision slip through would just be maddening.

English is really just too imprecise and ambiguous. English-like languages do exist, and it sounds like a good idea at first, but figuring out how to phrase things in an acceptable manner is tiresome, exasperating experience. There's the saying that a picture is worth a thousand words...programming languages, like sketches and diagrams, are a very different type of communication than "natural language". Pictures aren't a substitute for natural language, but they are far better suited for some tasks, and the same goes for programming languages.

cjameshuff
2010-Aug-06, 12:16 AM
Yes; And memory management (in the early days) had a lot to do with it. For instance, FORTRAN has traditionally been non-recursive (fixed memory locations for subroutine variables and references) while others are (variables are stacked).

Tail recursion is a wonderful thing. In some languages, if you make a single call in the return statement of a function, the compiler will work out that it's possible to return from that function *before* doing the call. This avoids having the no-longer-used call context stuck on the stack underneath the new call, and allows arbitrary levels of recursion in fixed memory space.

It's essentially a loop, and doesn't allow all types of recursion, but can be a more natural way to express some things. And there's some particular tricks that can be done with it to implement things like state machines...I rather wish it was possible in C (which is almost universal in embedded programming).



Interesting. I've always seen C as a very compact syntax. The difference might be programming style.

I've not used enough Fortran to know how it compares, but while C's basic syntax is compact, there's practically no built-in support for things like containers. This means big libraries of functions for managing common data structures, which you have to go through to do even the simplest operations, combined with lots of casting to get around the lack of a decent template or macro system...so yeah, C programs tend to be rather verbose. It's not the language itself, but all the stuff you have to do to use it.

DonM435
2010-Aug-06, 01:27 PM
If I were in charge, I'd want every graduate to complete at least one course in programming. Even if you're pursuing a career in languages, arts or whatever, it would help your thinking processes.

You're talking to a very different form of intelligence, one that combines the gloriously brilliant and the abysmally stupid in one package, one that's free of imagination and also of prejudice. You'd learn to give concise instructions, without expendable adjectives, and see the consequences of those instructions in all their success or failure.

swampyankee
2010-Aug-06, 04:05 PM
Since I usually make my living by writing computer software, I've gotten to muck around with a few languages. Some languages are easier than others, but the real work of programming is language-independent. Using any computer language to solve a complex problem, like n-body interactions when log(n) is about 10 or high-Reynolds number flows over complex objects or quantum chromodynamics or numerical relativity for realistic metrics is going to be hard, regardless of the chosen language.

NEOWatcher
2010-Aug-06, 04:54 PM
Since I usually make my living by writing computer software, I've gotten to muck around with a few languages. Some languages are easier than others, but the real work of programming is language-independent. Using any computer language to solve a complex problem, like n-body interactions when log(n) is about 10 or high-Reynolds number flows over complex objects or quantum chromodynamics or numerical relativity for realistic metrics is going to be hard, regardless of the chosen language.
True, but that's not always the real work. When you need to communicate with the user in a non-cryptic way and allow for user editing capabilities, the language does start to get important. Maybe not the language constructs themselves, but the objects, display and manipulation functions available for the language.

swampyankee
2010-Aug-07, 03:34 AM
True, but that's not always the real work. When you need to communicate with the user in a non-cryptic way and allow for user editing capabilities, the language does start to get important. Maybe not the language constructs themselves, but the objects, display and manipulation functions available for the language.

I've probably written more lines of code to deal with i/o than any other programming issue. Indeed, I've read that most of the code in a typical, numerically intensive, scientific application without graphics is involved in i/o.

forrest noble
2010-Aug-07, 06:10 AM
George,

I think G.E.'s Basic was the easiest for me, and yet was pretty versatile (late 1960's). Fortran was more versatile but required more effort. Today's Script languages are relatively easy but are less versatile concerning mathematical applications.

DonM435
2010-Aug-07, 04:22 PM
Have you ever seen LabVIEW? I've worked with it just a bit.

What you do is to drag object symbols that represent hardware (and software) constructs into your work space, then "wire up" the inputs and the outputs appropriately. All of the programming concepts (branches, decisions, tests) are there, it's just that you do it visually rather than with words and statements. You do type in labvels and a number now and again, but much of the tiem the keyboard is superfluous. You'd think it would be language independent and even accessible to non-readers, but properly-used comments and labels would be a barrier to that.

I suppose the idea is that every hardware component should be delivered with an accurate software representation to be directly connected to it, or else the representation should be created. Then, wire it up correctly, and that's it! (Your mileage may vary.)

It should appeal to people whose focus has been primarily hardware. But I suspect that some of us are just not so visually oriented. I hate having control panels -- computer, TV, automobile, air conditioner, etc. -- with pictures instead of labels. ("Which is "START"? Ah, it must be this thing that looks sort of like a hand holding a --, what is that thing? Guess I have to try it. Click. Oh no!") Also bad if you're color blind or nearsighted, I'd guess.

cjameshuff
2010-Aug-07, 05:59 PM
I think G.E.'s Basic was the easiest for me, and yet was pretty versatile (late 1960's). Fortran was more versatile but required more effort. Today's Script languages are relatively easy but are less versatile concerning mathematical applications.

They're all unbelievably slow at anything that's not available as an optimized, natively-compiled function of a library, but there's quite a lot of numerical libraries available for the major scripting languages.



It should appeal to people whose focus has been primarily hardware. But I suspect that some of us are just not so visually oriented. I hate having control panels -- computer, TV, automobile, air conditioner, etc. -- with pictures instead of labels. ("Which is "START"? Ah, it must be this thing that looks sort of like a hand holding a --, what is that thing? Guess I have to try it. Click. Oh no!") Also bad if you're color blind or nearsighted, I'd guess.

As a highly visually oriented programmer...no, it's just a poor fit to the problem being solved. Only fairly trivial programs map well to such a flow diagram. As an abstraction, it exposes too much information that's of little importance while failing to expose or even represent other information, takes too much limited screen space to display anything of importance, and turns any modification or addition into tedious hunting down of needed components and wiring them together.

Program source code isn't just a mess of words and symbols, it's generally formatted in a way that makes its structure visibly identifiable. Not just flow of execution, but matters of scope, precedence, data structures, logical grouping, and so on. And diagrams of several different sorts are certainly helpful in describing specific aspects of a program, more advanced editors and IDEs have quite a bit of support for automatically generating visual hints for scoping, things like call trees and class diagrams, etc. However, "visual programming" systems that attempt to represent and manipulate programs solely through flow diagrams all seem fundamentally poor matches to the sort of information representation and manipulation you need to do to write programs. Their success is once again only due to marketing...like BASIC (and quite often spreadsheets), they're advertised as "letting non-programmers program", when in reality they only waste time and effort by making their users do things in a particularly clumsy and unwieldy way.

George
2010-Aug-07, 06:03 PM
George,

I think G.E.'s Basic was the easiest for me, and yet was pretty versatile (late 1960's). Fortran was more versatile but required more effort. Today's Script languages are relatively easy but are less versatile concerning mathematical applications. I haven't heard of it, but I have been out of touch for the last few decades.

Oddly enough, I have decided to learn VBA to assist me with Excel report generation. I assume GE and other Basic languages will be similar.

Thanks.

forrest noble
2010-Aug-07, 08:12 PM
George,


I haven't heard of it, but I have been out of touch for the last few decades. me too, concerning most of today's programming languages.

The late 60's and early 70's were the days of time-sharing with large IBM computers, something like dial-up today using internet software programs with no screen, only a receiver for data input via a teletype which was also the printer. Of course there was generally little application software then, even difficult to find any to purchase concerning most applications. For each application you had to program it yourself. It was most times just as fast as PC's today and in the same way you had to pay for computer time (exterior servers) which was similar to internet access charges today.


cjameshuff,


They're all unbelievably slow at anything that's not available as an optimized, natively-compiled function of a library, but there's quite a lot of numerical libraries available for the major scripting languages.

Got it.

George
2010-Aug-07, 11:18 PM
The late 60's and early 70's were the days of time-sharing with large IBM computers, something like dial-up today using internet software programs with no screen, only a receiver for data input via a teletype which was also the printer. Well, that beats waiting in line to use the card punch machine, then waiting again in the line to feed it to the card reader knowing it would probably malfunction if there were more than 3 people with large stacks ahead of you.

I want to say that the card size was that of the census card invented by Ben Franklin. Is this remotely correct?

swampyankee
2010-Aug-08, 01:19 AM
Well, that beats waiting in line to use the card punch machine, then waiting again in the line to feed it to the card reader knowing it would probably malfunction if there were more than 3 people with large stacks ahead of you.

You forgot having the operators drop the deck before putting it into the reader.


I want to say that the card size was that of the census card invented by Ben Franklin. Is this remotely correct?

The card size was set because it was the same size as the dollar bill when the US Census first used punched-card tabulators for, iirc, the 1880 census. The first use of a punched card as a programming device was probably by Joseph-Marie Jacquard for use in looms (http://www.columbia.edu/acis/history/jacquard.html), in the early 19th Century.

kleindoofy
2010-Aug-08, 02:28 AM
You forgot having the operators drop the deck before putting it into the reader. ...
Not to mention other problems:

http://img535.imageshack.us/img535/5499/hangingchad.jpg

George
2010-Aug-08, 04:38 AM
The card size was set because it was the same size as the dollar bill when the US Census first used punched-card tabulators for, iirc, the 1880 census. The first use of a punched card as a programming device was probably by Joseph-Marie Jacquard for use in looms (http://www.columbia.edu/acis/history/jacquard.html), in the early 19th Century.Thanks.

slang
2010-Aug-08, 09:41 PM
http://img535.imageshack.us/img535/5499/hangingchad.jpg

For some reason I imagine this fellow just having decoded "42". :)

HenrikOlsen
2010-Aug-14, 02:58 PM
I'm interested to see how lines blur - some responses have been what I would once have called scripting or interpreting environments rather than languages as such (IDL, Python). For many of us, if it is an effective tool for the job, it doesn't matter.
Personally, I consider the distinction between a scripting language and a programming language to be whether the actual actions of the program are performed through invocation of external programs (apart from the interpreter) or done through facilities within the language, rather than being a distinction between interpreted vs. compiled languages, since I see the latter as an implementation detail rather than intrinsic to the language.

As such, Python, Ruby and Perl all count as "real" languages in my book, but the lines are a bit blurry.

Strange
2010-Aug-18, 10:06 AM
A graphical representation of the history of prgramming:
http://media.smashingmagazine.com/cdn_smash/wp-content/uploads/2010/06/aboutprogramming04.jpg

zenedee
2012-Nov-02, 07:19 AM
Better to study friendly language first , that means if you are not experienced in computer programming start with simple languages like basic , vb.net c# http://csharp.net-informations.com etc.. If you take C# you can start with a simple language with Object Oriented features. Also its syntaxes are very similar to Java and C++ . So once you learned this language you can change to C++ or Java Later.

zene.

Hlafordlaes
2012-Nov-02, 03:13 PM
Another former user of RBase here. I loved that program; too bad it could not handle the invoice problem, or I'd have ended up using it to manage a video rental section of a store I was running.

But my true love was PICK Basic. Easy, yet extremely powerful. I think I still suffer from withdrawal.

billslugg
2012-Nov-04, 02:18 PM
The oldest computer ever used for financial gain was the PENNSTAC unit built by EE students at Penn State in the late 50's and used, among other things, to predict milk production in cows. It was programmed using PENNSBAR. On the first day of Comp Sci 101 our Freshman year, we were taught one of the expressions in PENNSBAR (a write command) and then asked to use it to swap two numbers in memory. You need a dummy variable and three write commands. There had to have been a conditional command in there somewhere, but we never learned it. Those two commands make it Turing complete. The computer, with its thousands of vacuum tubes, was in the lobby of EE West for many years.

mkline55
2012-Nov-15, 02:16 PM
My vote goes to Basic of REXX. I first learned Fortran, PL/1, COBOL, IBM Assembler/360, and some DEC assembler language . But your mileage may vary. If you like knowing what every bit is doing, then an assembler language makes sense, but don't use it for business unless your business requires it, as finding others to support your code can be a problem. If you just like to get results fast on a non-mainframe, try a flavor of Basic. On the PC, Visual Basic is okay for batch or interactive use. If you are on a mainframe and just need quick and dirty, use REXX. SAS is tricky to learn to control, as it makes too many assumptions. If you first learn about object oriented languages, then C, C++, C#, Perl, PHP, and Java have a lot in common. Choose one appropriate for the environment.

TooMany
2012-Nov-15, 10:01 PM
If you mean easy in terms of getting something substantial done with the least effort, then C# with .NET Framework is the best I've worked with (started with FORTRAN in 1971). My first boss had worked with one the big vacuum tube computers. They had a crew constantly replacing tubes.

HenrikOlsen
2012-Nov-19, 11:04 AM
Visual Basic, which has as the logical consequence that Visual Basic is also the language with the worst programming I've ever seen.

DonM435
2012-Nov-19, 01:33 PM
I remember being told that COBOL was self-documenting. You'd write MOVE INPUT-RECORD TO OUTPUT-RECORD and then PRINT OUTPUT-RECORD. What could be easier?

But, back when I studied that language (briefly), there was a "structured' approach, so you'd see stuff like PERFORM 0110-INPUT-TO-OUTPUT-MOVER THROUGH 0110-INPUT-TO-OUTPUT-MOVER-END UNTIL ALL-THE-RECORDS-ARE-GONE and wonder what was going on. Somehow the pre- and post-housekeeping were elevated to the same level as all the main processing, which went on several levels deep, and was disguised with something like PERFORM 5010-DO-EVERYTHING.

It was probably worse that the less-literal, more symbolic languages.

Solfe
2012-Nov-19, 02:46 PM
I tried Yerk and Mops which is FORTH based. I am not sure how I feel about it.

cjameshuff
2012-Nov-19, 04:05 PM
I tried Yerk and Mops which is FORTH based. I am not sure how I feel about it.

PostScript is similar to Forth in being a stack-based language. They rather require you to pull out your brain and re-seat it sideways. However, the interpreters are very simple and small, and programs tend to be very compact...good for small systems.

The various BASIC languages are really no easier to learn than more powerful languages, you just run into their limits sooner. I've never seen anything that you couldn't do at least as simply in C, C++, Java, etc as you could in one of the BASICs, there's just more capabilities that you have access to when needed. The BASIC languages teach bad habits and force convoluted approaches to make up for the inadequacies of the language, instead of allowing the programmer to expand their skills to suit the problem at hand.

A weakness of C is its library...basically nothing in the way of standard data structures. C++ gives you the STL, which while not perfect, can greatly reduce the amount of code you need to write to accomplish a task. Ruby, my favored high level language, has a much more extensive and flexible standard library, a lot of syntactic sugar, and is a much more dynamic and flexible system that is very easy and fast to write code in, but sometimes difficult to debug.