While concurrency is important in some applications by far the vast majority of all applications involve CRUD operations against a database.
I don't know that that's the vast majority of all applications, but its certainly a huge portion of the market. But then, lots of languages do that well.
Erlang (and lots of the other "cool" languages) suck at that. I mean suck really bad not just suck a little.
Considering Erlang's origin, that's not surprising; perhaps the most important role that languages like Erlang play outside of their own focussed domain is that the implementation of features in such specialized languages often inspires the implementation of similar features in more general languages.
Switching back to Scheme and functional languages (its true of concurrency features, too, I think, though its more clear for functional features), you see a lot of that recently with functional features being added to newer interations of popular languages.
Scheme is incomprehensible to humans - it has no syntax whatsover besides parentheses.
Its clearly not incomprehensible to humans, otherwise humans couldn't read or write code in it, and they clearly do both. Further, being almost syntax-free doesn't mean being unreadable: REBOL doesn't have much more in the way of fixed syntax than Scheme (being a somewhat less pure functional language with a loosely similar idiom), but is (generally) very readable (though, of course, you can make it unreadable, since you roll your own obscure and unreadable syntax just as easily as creating clear and expressive constructs.)
Most modern C compilers will do tail-call optimization. However, it is not a requirement of the language (an implementation that fails to do so will still be "C"), and so implementation-agnostic portable code shouldn't count on it, and the language itself provides strong support for programming constructs that make sense when you can't count on tail-call optimization.
Functional programming languages that require tail-call optimization as part of their definition, tend not to support such constructs as well (or, when they do, to do so as syntactic sugar for a recursive implementation), but rather use recursive functional idioms to address the same situation. These may be less natural appearing if you've spent lots of time working with imperative languages where those approaches aren't the natural solution (and where likely you've had "don't use recursion unnecessarily" beaten into your head), but recursive expressions of algorithms tend to be both compact and clear.
even trivial tasks like a for-loop you have to either code yourself or rely on non-portable extensions.
Isn't a central point of Scheme that it is properly tail-recursive, functional programming language? While I'm not all that familiar with Scheme, wouldn't you usually use a recursive function rather than a for-loop in such a language?
A for-loop isn't a task, its a construct that is natural in the idiom of certain languages for accomplishing certain tasks. Its not the idiomatic way to approach those tasks in all languages, though.
BASIC with line numbers is still pretty good for "snippets" of algorithm that you can just copy and paste into an interpreter and it will run. You can't do that with most modern languages because the have some "overhead" cruft you must have just to begin to run.
Lacking even proper procedures/functions, its not IMO, even a particularly good way, compared to modern options, to clearly express algorithms. As for being good for copying and pasting into an interpreter, I don't see how it is much better than many other interpretted environments in that respect.
Pascal might also work well for that. But, try finding a Pascal that will run on your modern PC.
Its not really all that hard to find both free and commercial Pascal interpreters and compilers for modern OS's. Not that Pascal would be my first choice, here.
So, what's left?
REBOL is interpreted, available free (as in beer) for a wide number of platforms, and, while perhaps not ideal for mathematical algorithms, is at least superior to old-school BASIC in that regard. Further, its immediate (console) environment is much richer, which means most of the time you wouldn't need to set up a whole program and "run" it (the equivalent of a BASIC program with line numbers), you could set most algorithms up by defining appropriate functions in the immediate environment, and try them with different values just by making different calls to the appropriate function with different parameters from the immediate environment, so (unlike BASIC) you could dispense with dealing with I/O (input because the parameters to the function will replace input, output since the immediate environment will show you the result of the function call when it returns) and focus on just expressing the algorithm. So I think REBOL is an ideal choice, here.
Those restrictions are there for a reason. I agree they are sometimes onerous. However, they make it so that the organization actually must do charitable things, and they make impossible to do the "screw everyone and take the money" things.
Yes, the restrictions exist for a reason. But they do not merely require that the organization must do charitable things, even if that is the intend. They very narrowly circumscribe the activities of the organization (particularly in the case of organizations that are not merely tax exempt, but also have tax-deductible donations.) Now, where these restrictions are compatible with what you are trying to do, that's not a big deal. Where they aren't, they are a big deal. If your vision includes at its core activities that are incompatible with the restrictions, then you've got a choice to make.
Choosing not to get non-profit status does not make your operation intrinsically evil. It may make people more cautious dealing with it, both because they don't get the same advantages from contributing and you aren't held to the restrictions that tax-exempt operations are. But if you've got a vision for doing good that is incompatible with the restrictions placed on tax exempt operations, then its the only way to realize that vision.
And, no, the restrictions on tax-exempt organizations do not make it impossible to do the "screw everyone and take the money" things, as you say, even if they are theoretically intended to. Scams using tax-exempt charities are not all unheard of.
I think what Brin wants (and I'm in the same boat though my kids are still just toddlers) is something comparable to learning to write in BLOCK letters, i.e., a temporary stepping stone to more sophisticated methods or languages or cursive writing.
I think StarLogo TNG's use of drag-and-drop blocks is a pretty interesting approach to exactly this need. The blocks have text which allows them to be read like typed-in code, and colors and shapes that indicate function and syntax.
It SHOULD be extensible with libraries for doing more complex things (just as the old erector sets of the 40s and 50s could have motors added to them for more advanced structures). I'd say model it on C or Java but remove the non-human readable aspects.
So, you want an extensible, maybe object-oriented, programming language with less punctuation or more human-readability than a C-like language, but similar expressiveness?
There needs to be some kind of readily available interpretive programming language that allows people to start out programming in linear fashion, and later eases them into object-oriented coding.
Others have suggested Python. REBOL also is, IMO, a good choice.
Way outside the box, Oz almost basically meets the description (though compiled, it has an immediate environment, can be programmed basically linearly for very basic uses, and supports scaling up into more advanced models: OO, sure, but not just the OO model, also functional, logic/constraint programming, concurrent programming, distributed programming, etc.) OTOH, teaching kids Mozart might be challenging, but maybe not: it might be easier to grok without having a lot of programming preconceptions to break down.
As you point out, the OS API these days is too complex for someone just learning to write a graphical game such as those we played with in those good old days.
Well, sure, if you are using the OS API directly.
Perhaps someone might (or already has) come up with a programming environment that simplifies the API so that a kiddie can write something like Gorilla or Frogger or name-your-favorite with at least the same level of complexity as it was doing these in Basic with peeks, pokes, and all the (then) gory details.
There are a number of game-oriented languages (several of which are BASIC-descendants, plus things like StarLogo TNG and other Logo descendants) that allow you to do it fairly easily.
That's a point I hadn't thought to make last time this story came around. I started programming on a Commodore64 when I was 7. Not a prodigy; I programmed about as well as you'd expect a 7 year old to program. Copied short snippets from books and whatnot. By ten, I was using basic programming flow to draw interesting patterns on the screen. At the age of thirteen, I tried my first truly ambitious project: a 'Dragon Warrior'-style RPG.
It was a catastrophe. When I first started composing this, I was going to blame it on BASIC itself, then on the crappy line editor I was trying to use. But as frustrating as these things were, my greatest shortcoming was that I had no adult supervision. When you try and teach yourself, rather than learning from an expert, you tend to not realize when you've missed something very, very important.
I'm not sure its a matter of learning from an expert; I was about the same age when, with my dad supervising (mostly, helping me figure out the big-picture design and what it needed to do, I did the actual programming), I did a household budget management system in a series of BASIC programs and DOS batch files. My dad didn't know much more about BASIC than I did, and probably not much more about programming in general, but he did know more about organization and planning. We had pretty much learned BASIC together.
So I think active adult guidance is definitely a plus, but I don't think that it needs to be from an "expert".
but they'll still at some point have to transition from
print "hello world!"
to
print("hello world!");
or something similar if they're actually going to do anything more than write their tutorial programs and a few simple games.
I don't know that I'd call all the programs that people have made with REBOL "tutorial programs and...simple games". Its not like there is a law that useful programming languages must enclose function parameters in parentheses.
I'd say that true structured languages do have a limitation in that regard in their utility for kids; so yes, "linear" languages may have an advantage. But they don't have to be BASIC-like spaghetti code languages. In REBOL, for example, you can, from the console just give:
print "Hello, World!"
You get the proverbial greeting echoed. A REBOL program to do that would require only one line besides the REBOL header, which for introductory purposes could be empty, so:
REBOL [ ]
print "Hello, World!"
But when you flesh out a REBOL program, you can use most of the traditional features of structured and object-oriented programming. Its easy entry, but an easy transition to more structured programming rather than the brick wall in that regard that old-school BASIC presents. I think REBOL would be a great language for kids.
Joking aside, on MS Windows you can get cygwin as a free download to give you shells to write scripts in.
Downloading cygwin just to get "shells to write scripts in" is kinda silly, since you can write and run scripts on windows without it, and if you just want a free interpretted programming environment, downloading cygwin to get unix-style shell scripting ability is something of an odd choice.
Why should kids learn programming when they'll only be able to compete for a programming job if they take an East Indian's dollar-a-week salary?
Not all jobs that programming skills help at are first and foremost programming jobs. In plenty of business and scientific jobs, having programming skills is a competitive advantage. And many of those jobs make more than programming jobs in India.
A more interesting question to me is why does everyone feel that kids have to be able to program?
By everyone do you mean "science fiction author David Brin", or "everyone on Slashdot"?
In either case, I think the background of the "everyone" might answer the question.
If it's your life ambition, yeah. Now were's the stories lamenting why Johnny can't spell.
You mean "Now, where are the stories..." surely.
Or Johnny can't read. Or even Johnny can't do math?
There are fairly frequent stories about those topics in major mainstream media outlets. This is "News for Nerds." Different focus.
Now we're stuck with either mono-platform compiled code or HUGE runtimes that no everyone will have (yes, Java, I'm looking at you)..
OR REBOL, which is a small environment (fits on a floppy, not that anyone has those any more), that not everyone has, but is available on enough platforms that virtually anyone who wants it could have it. And the free (as in beer) version has more than enough features to serve as a good intro to programming environment.
Interesting, I did not even know Excel VBA existed and by your comment about it being the last thing you would want to try to get a kid interested in I am glad I know nothing about it. I was thinking more along the lines of Excel macros when he mentioned Excel.
"Visual Basic for Applications" (VBA) is the macro programming language for Microsoft Office, available in each of the Office components.
RTFA - BASIC because it's what was in the textbooks at school.
Isn't, then, the problem with the school purchasing textbooks that were designed for the 1980s?
The artical wasn't about the lack of BASIC per se, but about the lack of support for learning the roots of the higher languages.
I'm not sure what you mean by "roots" and "higher". I don't need to learn BASIC to understand the roots of, say, C++.
I don't see how learning a modern derivative of Logo (which, along with BASIC, was a common teaching language in the 1980s) is any less conducive to learning the roots of other languages than learning BASIC.
When I write my own code, I write from a minimalist stance (no I don't write my own tcp/ip stacks etc), it might not be as portable or modifiable as code writen using standard libraries and structured as modules with blind objects. On the other hand, it's usualy clean, elegant, and faster than doing it with libraries.
This is all well and good, but what does this have to do with whether you started out programming with BASIC, StarLogo, KPL, or anything else? If you start with any programming language and are the kind of person that's interested in learning, you'll branch out, and learn languages with different modules just to be able to do different things. At some point you'll quite likely end up learning some OO languages, some functional languages, some assembly language, and some quirky things that don't categorize all that well, among others.
To put it in perspective, I have worked with people who think that cobbling together widgets is real programming & can't understand how to do anything more than the simplest coding to make them work nice together.
Yeah. And there are lots of people like that. And, you know what, many of them probably learned BASIC at one point.
Programming, to him, isn't about objects & high level processes, it's about understanding the processes of logic and math that transform blocks of code into something entirely different - whether the magic of a moving ball on a screen, or seeing the difference in performance for a shuttle short vs an indexed sort vs tree sort - and then understanding why each creates the results it does.
Sure, that's what programming is about. But learning that doesn't require learning BASIC as your first language, nor is it, IMO, particularly aided by doing so. OTOH, it is probably aided by learning some programming language young, and having a good enough experience that you seek to learn how to do more and keep doing that over a period of several years.
...the absence of either:
1) Quirk-compatible implementations of old-school BASIC interpreters for modern machines, or
2) Relevant, currently usable example programs in children's math textbooks.
NOT the absence of "programming for kids".
Though, if you really thinking simple, instant-gratification, learning languages aren't available for young protoprogrammers today, might I suggest looking at StarLogo TNG (and its 2d relative, OpenStarLogo).
Also, a number of less education-focussed languages have many of the features that made BASIC accessible to young learners (an immediate interpreter environment, friendly vocabulary compared to, say, C's intimidating, punctuation-heavy syntax), like REBOL.
I can't see that there is a real problem here in terms of availability of suitable languages for learning.
Excel VBA is manifestly a programming language by most reasonable definitions, though its about the last thing I'd want to try to get a kid interested in.
BASH is also not a programming language but it allows you to run scripts
How is a "script" any different than an "interpreted program" like a C64 BASIC interpreter would let you run?
Nah, you're just too insecure to admit that there are actually ways to rank the functionality of these things.
No, I've admitted that, several times, in this thread.
There are many ways to rank the functionality of things, not one correct way.
MySQL is good specifically in situations where you're going to do a lot of simple transactions on fairly simple data.
Which is, in fact, what a lot of web applications on LAMP infrastructure do.
That it's superior in that one, very narrow, situation, however, does not make it superior as an RDBMS
"Superior as an RDBMS" is mostly a meaningless, or at least equivocal and ambiguous, category.
or even equal to other software in the category.
Sure, in the sense that "different" is not "equal".
Likewise: PHP. PHP is an inferior programming language and that's that.
"Inferior programming language" is meaningless.
It's good at RAD and it has a very gentle learning curve.
And, in that, it is superior to languages that lack those features for uses where those are key features. Making it not unqualifiedly an "inferior programming language". Its like saying "A hammer is an inferior tool. It's good at driving nails, and that's it."
Perl is a better language. C is a better language yet.
There are certainly things for which C is better than Perl, and certainly there are things for which Perl is better than C. Your standard for saying that C is in some trascendent, unqualified sense "better...yet" compared to Perl is...what?
That PHP is good in one narrow field does not make it superior or even equal in its category.
True, again, because "superior" in the nonspecific sense you are using it is meaningless and, therefore, nothing could make anything superior in that sense.
It's really not that complicated of a concept.
It isn't a matter of complicated. It is a matter of wrong.
If you have two quarterbacks and one can throw the ball 75 yards consistently but can rarely get the ball anywhere near his receiver beyond five yards, he's very good at doing one particular thing, but he's still an inferior quarterback.
Really? If the other one can consistently hit a receiver out to 80 yards, but almost always fumbles the snap, I'm not sure if I could agree that the one you describe is "still an inferior quarterback": you can't label something inferior to something else when you describe the features of only one of the two things being compared. Further, the function of a quarterback on a football team is much more narrowly defined than that of a programming language or data storage solution, so it makes a lot more sense to talk about an inferior quarterback than an inferior programming language or datastore, without reference to a use for the latter.
Contrary to what some people would like to believe, not everything is equal just because it does certain things well that other products do on a more average scale.
I don't know what "some people" you are talking about, but I've never said "everything is equal". I would say that ranking tools without reference to application is generally meaningless except in the narrow case where the ranking holds without exception for all conceivable, or at least realistic, tasks.
Assuming the Zune allows violation of the Creative Commons license in this way, who is liable? Is it Microsoft, for making the device, or the user, for distributing Creative Commons-licensed material in a way that's incompatible with its license?
Well, let's see:
Assuming (Napster, KaZaA, Grokster,...) allows violation of copyright in some way, who is liable? Is it (Napster, Sharman Networks, Grokster...), for making the service, or the user, for distributing commercial, copyright-protected material in a way that's incompatible with the right's of the copyright owner?
I dunno. So far, seems to be "both". Why would CC licensed material be any different material under more traditional copyright licenses?
Now let's pretend that the plaintiff in the case wasn't a spam company with a stupid name, but instead is a regular user who gets put on the list by mistake.
Then their recourse is to:
1) File suit in a jurisdiction that Spamhaus can't afford to ignore, and/or
2) Make their case in the court of public opinion, and try to ruin Spamhaus' reputation as a an accurate spam identifier.
Slashdot Mirror
I don't know that that's the vast majority of all applications, but its certainly a huge portion of the market. But then, lots of languages do that well.
Considering Erlang's origin, that's not surprising; perhaps the most important role that languages like Erlang play outside of their own focussed domain is that the implementation of features in such specialized languages often inspires the implementation of similar features in more general languages.
Switching back to Scheme and functional languages (its true of concurrency features, too, I think, though its more clear for functional features), you see a lot of that recently with functional features being added to newer interations of popular languages.
Most modern C compilers will do tail-call optimization. However, it is not a requirement of the language (an implementation that fails to do so will still be "C"), and so implementation-agnostic portable code shouldn't count on it, and the language itself provides strong support for programming constructs that make sense when you can't count on tail-call optimization.
Functional programming languages that require tail-call optimization as part of their definition, tend not to support such constructs as well (or, when they do, to do so as syntactic sugar for a recursive implementation), but rather use recursive functional idioms to address the same situation. These may be less natural appearing if you've spent lots of time working with imperative languages where those approaches aren't the natural solution (and where likely you've had "don't use recursion unnecessarily" beaten into your head), but recursive expressions of algorithms tend to be both compact and clear.
Isn't a central point of Scheme that it is properly tail-recursive, functional programming language? While I'm not all that familiar with Scheme, wouldn't you usually use a recursive function rather than a for-loop in such a language?
A for-loop isn't a task, its a construct that is natural in the idiom of certain languages for accomplishing certain tasks. Its not the idiomatic way to approach those tasks in all languages, though.
Lacking even proper procedures/functions, its not IMO, even a particularly good way, compared to modern options, to clearly express algorithms. As for being good for copying and pasting into an interpreter, I don't see how it is much better than many other interpretted environments in that respect.
Its not really all that hard to find both free and commercial Pascal interpreters and compilers for modern OS's. Not that Pascal would be my first choice, here.
REBOL is interpreted, available free (as in beer) for a wide number of platforms, and, while perhaps not ideal for mathematical algorithms, is at least superior to old-school BASIC in that regard. Further, its immediate (console) environment is much richer, which means most of the time you wouldn't need to set up a whole program and "run" it (the equivalent of a BASIC program with line numbers), you could set most algorithms up by defining appropriate functions in the immediate environment, and try them with different values just by making different calls to the appropriate function with different parameters from the immediate environment, so (unlike BASIC) you could dispense with dealing with I/O (input because the parameters to the function will replace input, output since the immediate environment will show you the result of the function call when it returns) and focus on just expressing the algorithm. So I think REBOL is an ideal choice, here.
Yes, the restrictions exist for a reason. But they do not merely require that the organization must do charitable things, even if that is the intend. They very narrowly circumscribe the activities of the organization (particularly in the case of organizations that are not merely tax exempt, but also have tax-deductible donations.) Now, where these restrictions are compatible with what you are trying to do, that's not a big deal. Where they aren't, they are a big deal. If your vision includes at its core activities that are incompatible with the restrictions, then you've got a choice to make.
Choosing not to get non-profit status does not make your operation intrinsically evil. It may make people more cautious dealing with it, both because they don't get the same advantages from contributing and you aren't held to the restrictions that tax-exempt operations are. But if you've got a vision for doing good that is incompatible with the restrictions placed on tax exempt operations, then its the only way to realize that vision.
And, no, the restrictions on tax-exempt organizations do not make it impossible to do the "screw everyone and take the money" things, as you say, even if they are theoretically intended to. Scams using tax-exempt charities are not all unheard of.
So, you want an extensible, maybe object-oriented, programming language with less punctuation or more human-readability than a C-like language, but similar expressiveness?
I know, call me crazy, but why not Ada?
Others have suggested Python. REBOL also is, IMO, a good choice.
Way outside the box, Oz almost basically meets the description (though compiled, it has an immediate environment, can be programmed basically linearly for very basic uses, and supports scaling up into more advanced models: OO, sure, but not just the OO model, also functional, logic/constraint programming, concurrent programming, distributed programming, etc.) OTOH, teaching kids Mozart might be challenging, but maybe not: it might be easier to grok without having a lot of programming preconceptions to break down.
I'm not sure its a matter of learning from an expert; I was about the same age when, with my dad supervising (mostly, helping me figure out the big-picture design and what it needed to do, I did the actual programming), I did a household budget management system in a series of BASIC programs and DOS batch files. My dad didn't know much more about BASIC than I did, and probably not much more about programming in general, but he did know more about organization and planning. We had pretty much learned BASIC together.
So I think active adult guidance is definitely a plus, but I don't think that it needs to be from an "expert".
I'd say that true structured languages do have a limitation in that regard in their utility for kids; so yes, "linear" languages may have an advantage. But they don't have to be BASIC-like spaghetti code languages. In REBOL, for example, you can, from the console just give:
print "Hello, World!"
You get the proverbial greeting echoed. A REBOL program to do that would require only one line besides the REBOL header, which for introductory purposes could be empty, so:
REBOL [ ]
print "Hello, World!"
But when you flesh out a REBOL program, you can use most of the traditional features of structured and object-oriented programming. Its easy entry, but an easy transition to more structured programming rather than the brick wall in that regard that old-school BASIC presents. I think REBOL would be a great language for kids.
...the absence of either: 1) Quirk-compatible implementations of old-school BASIC interpreters for modern machines, or 2) Relevant, currently usable example programs in children's math textbooks.
NOT the absence of "programming for kids".
Though, if you really thinking simple, instant-gratification, learning languages aren't available for young protoprogrammers today, might I suggest looking at StarLogo TNG (and its 2d relative, OpenStarLogo).
Also, a number of less education-focussed languages have many of the features that made BASIC accessible to young learners (an immediate interpreter environment, friendly vocabulary compared to, say, C's intimidating, punctuation-heavy syntax), like REBOL.
I can't see that there is a real problem here in terms of availability of suitable languages for learning.
No, I've admitted that, several times, in this thread.
There are many ways to rank the functionality of things, not one correct way.
Which is, in fact, what a lot of web applications on LAMP infrastructure do.
"Superior as an RDBMS" is mostly a meaningless, or at least equivocal and ambiguous, category.
Sure, in the sense that "different" is not "equal".
"Inferior programming language" is meaningless.
And, in that, it is superior to languages that lack those features for uses where those are key features. Making it not unqualifiedly an "inferior programming language". Its like saying "A hammer is an inferior tool. It's good at driving nails, and that's it."
There are certainly things for which C is better than Perl, and certainly there are things for which Perl is better than C. Your standard for saying that C is in some trascendent, unqualified sense "better...yet" compared to Perl is...what?
True, again, because "superior" in the nonspecific sense you are using it is meaningless and, therefore, nothing could make anything superior in that sense.
It isn't a matter of complicated. It is a matter of wrong.
Really? If the other one can consistently hit a receiver out to 80 yards, but almost always fumbles the snap, I'm not sure if I could agree that the one you describe is "still an inferior quarterback": you can't label something inferior to something else when you describe the features of only one of the two things being compared. Further, the function of a quarterback on a football team is much more narrowly defined than that of a programming language or data storage solution, so it makes a lot more sense to talk about an inferior quarterback than an inferior programming language or datastore, without reference to a use for the latter.
I don't know what "some people" you are talking about, but I've never said "everything is equal". I would say that ranking tools without reference to application is generally meaningless except in the narrow case where the ranking holds without exception for all conceivable, or at least realistic, tasks.