Does the application have to be a fully-native one? I think an interpreted app would be possible, but distributing it would need distribution of a runtime.
Perhaps if the idea of developing apps on the device turns out to be of strategic importance for the platform, the main mobile OS makers would add some sort of compilation service to the OS. If this is true it would still need a killer-app to prove it.
From testing with a few children, I do feel that Basic's mandatory line numbers make usage of goto much more easier to learn. I did have to spend some time explaining labels to my students. So I kind of agree with your hunch!
I don't know with what to replace it though, it always seemed like a choice between structured loops which have their own problems (the need to explain blocks) or the return of line numbers...
Your third scheme is a new option, but not without drawbacks. The advantage of unrestricted label/goto is that the concept is learned once and applied for many types of control flow. But I think the other main case that needs to be handled is exiting loops. Maybe I could also have an exit <label> keyword, and try with some sample programs to see if it could be sufficient.
I'm still inclined towards leaving goto though. I think it's more raw and "operative" in a sense, and more creative kids might be able to come up with fun uses for it (I've recently added computed goto to the language too).
I know Scheme; actually implemented my own toy lisp at some point - continuations and all. Still, Racket (or Gambit...etc) is much more than the basic language, and I don't want to spend days reading - once again - how to draw a line on the screen or render a web form or use modules or do any of the stuff needed for a non-trivial application all before I get started.
I could do that if I really needed, but it wouldn't be casual programming any more. This is where all the autocomplete stuff comes in for me. I just discover the libraries I need when I need them.
As for quickfix, it means I could write the program top-down by calling function that don't exist yet, using uncreated data structures, and then with a few clicks have the IDE create all the skeleton code waiting to fill-in.
I think such tools would be valuable in any language.
To read code (or math) I find life easier when I can "read" it inside my head. The terse and heavy symbolic syntax make understanding code less comfortable for me.
The other thing is that currying + lack of parens around function arguments makes it not visually clear where each argument goes or what expressions are part of what. Only someone familiar with each function and it's arity (in some Haskell-relevant sense) could read the stuff at a glance.
Certainly does a lot of what I wish in a casual programming tool! I just wish the IDE had the autocomplete, quickfix, refactoring features of Eclipse...
There are many facets to the problem, some of them are easily solved with the technology we have. We need to learn from the tools people already casually program with: VBA, Matlab, Excel, Turbo pascal in its days...etc.
They may have many defects as languages, but they got a lot of the 'casual' right; we could start from there.
The problem with casual programming is that problems of a given type (say parsing some files) arise from time to time; so unless its part of your day job, investing in learning those tools doesn't seem so worthwhile until the same type of problem arises weeks later.
IMO a truly casual programming tool is about the quickest route from "need" to "working code".
The languages are mostly fine (until some next-gen language surprises us all); I think the current problems lie generally within tooling and infrastructure, which in turn come from our mentality and the existing workflow that we're used to.
That said, I enjoyed reading your very insightful post :)
(author here) I'm not a Mac user, but took a look at Automator now. It seems a big step in that direction. Still, I'm not sure it makes the casual programming problem solved. Maybe I misrepresented the problem; let me give some more examples on casual programs that could be made easier...
* Quickly testing small game ideas or demos (programming as self-expression).
* Solving an ACM problem or one of those programming job puzzles without too much setup.
* Writing the blog tagger example in the blog post, and other "do my web tasks for me" code.
I think a good casual IDE could be written for various types of needs, not just automating the OS or Apps..which are certainly an important part of the problem.
I know about currying, but there's still a certain meaning to arity even in this case.
It might be argued that on the long run the current syntax is better for the veteran Haskeller, but it's still some barrier to entry. I wonder if a Haskell IDE could have a 'clarify calls' mode that shows where each function argument goes or comes from..
Whenever I try to learn e.g Haskell, the small things stand in my way; for example everything looks like a series of identifiers separated by whitespace, and the only way to understand it is to manually parse it in my mind, knowing the arity of every function, data constructor, and the like. Probably a minor thing to most Haskellers, but still an obstacle to me..
Besides being easily able to visually parse a source file, a usability issues in some languages for me is 'voicing' the code in my head or reading it to another programmer; a problem I also have with mathematical notation sometimes.
When creating my own language for teaching programming, I decided to have a 'canonical reading style' so that teachers and students always know how to read a given code snippet out loud or in their head, facilitating understanding and communication.
Any information on how actors compare to CSP/Channels in that regard? I guess they'd offer similar power but there might be some subtle advantages of one over another.
I made a language for teaching programming to kids that uses CSP as a basis for the GUI where each event is a channel, so I'm quite interested in any literature in this area.
It might win hands down now, but probably not for a 1000 years.
Lisp certainly includes certain 'timeless' aspects, such as lambdas and homoiconicity, but other features (like conses everywhere, IMO) are simply implementation details of the time Lisp was first created.
I'm concerned that Lisp advocates, by repeatedly saying that Lisp is the final step in language design, the ultimate language,...etc might distract some from looking for additional, newer, insightful concepts in computation and language design.
The future is also too long to assume our current generation languages will define it. While Lisp is a major step forward, I think it is by no means the end of language progress in the current couple of decades, let alone 1000 years.
Incidentally, I've heard that 'Pharaoh' comes from an ancient Egyptian word meaning 'big house' or 'big palace'.
Another speculation is that it's related to the Arabic word فارع, meaning 'very tall'. So it's might be nearer than expected to the intended meaning :)
If 'Enpharaoronate' were a real word it would fit very well in translating a famous Egyptian proverb from Arabic: "Said to the Pharaoh: what Enpharaoronated you? He said: I didn't find anyone to stop me."
Perhaps if the idea of developing apps on the device turns out to be of strategic importance for the platform, the main mobile OS makers would add some sort of compilation service to the OS. If this is true it would still need a killer-app to prove it.