Order of Kilopi
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.
I say there is an invisible elf in my backyard. How do you prove that I am wrong?
The Leif Ericson Cruiser
Established Member
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.Originally Posted by Van Rijn
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.
Established Member
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
Order of Kilopi
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.
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.
Established Member
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
Order of Kilopi
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.
Established Member
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.
Order of Kilopi
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.
Order of Kilopi
Order of Kilopi
32K! Luxury. When I were a lad all we had was 1K. And you were lucky if it was bytes...
Order of Kilopi
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?"
Established Member
/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.
Established Member
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...n0.html#intro0
While you can download trial versions and see more about it at: http://www.bbcbasic.co.uk/bbcbasic.html
JOhn
Order of Kilopi
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.
Established Member
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.
Order of Kilopi
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++.
__________________________________________________
Reductionist and proud of it.
Being ignorant is not so much a shame, as being unwilling to learn. Benjamin Franklin
Chase after the truth like all hell and you'll free yourself, even though you never touch its coat tails. Clarence Darrow
A person who won't read has no advantage over one who can't read. Mark Twain
Order of Kilopi
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.
I say there is an invisible elf in my backyard. How do you prove that I am wrong?
The Leif Ericson Cruiser
Order of Kilopi
Order of Kilopi
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.
Established Member
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!"
Order of Kilopi
Yes, but I had assumed that something easier to learn had come around since C++ is an old timer.
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.
That's a nice summary of how it is and always has been, no doubt.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.
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.
Order of Kilopi
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.
Established Member
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
Established Member
I hated the envelope command for making sounds with it. How many parameters can one function need.
clop
Established Member
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.
Moderator
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.
____________
"Dumb all over, a little ugly on the side." -- Frank Zappa
"Your right to hold an opinion is not being contested. Your expectation that it be taken seriously is." -- Jason Thompson
"This is really very simple, but unfortunately it's very complicated." -- publius
Moderator comments in this color | Get moderator attention using the lower left icon:
Recommended reading: Board Rules * Forum FAQs * Conspiracy Theory Advice * Alternate Theory Advocates Advice
Banned
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).
Established Member
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.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.
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.
Order of Kilopi
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.
Banned
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?
Posting Permissions
Reply With Quote