What's the easiest program language you've had?

[George]

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]

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]

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]

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]

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]

This is ancient history but in terms of terms, Commodore Assembly was probably the simplest I ever worked in.

Assembler language?? 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]

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]

Assembler language?? 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]

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]

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]

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

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]

Logo! 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]

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)

[George]

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.

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]

Sinclair ZX Basic was uber easy!

clop

[Strange]

ML. Stuff just works.

[George]

Logo! 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]

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]

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)

Is PHP very intuitive? MySQL sounds pretty basic, too.

[Rhaedas]

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]

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]

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. [I bought 4 for friends.]

[George]

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]

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. [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]

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]

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]

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]

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

6510 on the C-64. Almost the same. The 1541 diskdrive 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]

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]

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.