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).
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.
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 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 :)
As a person who did a good bit of that professionally back in the day (I wrote interface layers between it and deeper C++ code), I'd have to say, it's probably not "the thing" you really need, but it does sound quite close to what you requested.
(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.
Yeah, Automator is essentially a sort of group of visual DSLs for some very defined domains. Your examples here are definitely more in the realm of general programming languages.
It's definitely not as easy as the environment you speculate, but Xcode and iOS development have been making big inroads lately, even with total beginners. Certainly, it could be made a lot easier, but efforts to do this in the past have tended to fall flat as people think that the skills they learn won't be useful in "real" environments later on.. which turns it into quite the chicken and egg problem :-)
I wonder, however, if JavaScript and Web oriented development environments will ultimately fill the gap you're identifying. The browser is an ideal environment for the tasks you outline, and JavaScript is a fine 'base' language for DSLs to fall on top of while still giving access to the full language.
I think there are two problems here, both of which could be chipped away at, but neither will be completely solved anytime soon.
First, you have the fact that users don't know enough to solve abstract problems with programming. As programmers we have this deep base knowledge that we subconsciously draw upon. It's impossible to create a platform that makes it trivially easy to "test small game ideas" without narrowing the scope to trivial game types. People need a foundation to figure out how to put the pieces together. Fortunately, a lot of this is just familiarity with computers, so every new generation gets better at this, making the problem more tractable over time.
The other, is that software is truly an organic ecosystem. There is no designer that is coordinating the software world. The closest we have are closed platforms like Apple provides (which is still limited in overall scope) or standards (which are defined in a deliberately narrow scope for modularity's sake). So to make a single uniform environment that could do everything a casual programmer might want to do, and make it consistent, you'd have to write some kind of monolithic standard and convince a large minority of all software writers to support it in some fashion. The UNIX philosophy and POSIX are attenots to do something like this, but as you alluded to, it's still highly non-trivial to get your footing underneath you. To create an even higher-level standard seems almost impossibly difficult, but I suppose it's possible that progress could be made by focusing purely on a new high-level language and GUI. I'm not holding my breath though.
Are you prolific or at least very capable at using grep, sed, awk, tr, sort, uniq, cut, wc, and cat?
I don't think you need to read a book about shell scripting, but I think if you are familiar with these tools, there's a whole lot of things you can do with pipes. If you are opposed to learning them (and regular expressions), then there's no language that will ever please you.
Most importantly, except for some caveats, these languages are portable and preinstalled on most everything posix.
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".
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...
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.
> 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.
This is why I gave you the link above.
This particular scheme comes with all that included and easily accessible. It's quite simple, just check that out. And the editor is, IMO, A LOT better than Eclipse (though I may be biased, I despise Eclipse).
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.
Well, Haskell functions are curried, so you could think of the arity as always being 1. ;-)
If you're writing code, you can always use redundant parentheses at first. Then you refactor, gradually removing the parentheses or replacing them with an appropriate combination of ($) and (.).
Another useful thing to learn is how to write point-free code. An example:
These are essentially the same function, but the latter is often preferred. Note also that they have the same type, namely String -> String.
If you're reading code and you find it hard to parse, you probably need to read easier code (for instance, from LYAH or RWH), but more likely you need to write more code of your own.
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..
There are plenty of things to criticize in the Haskell syntax rules — they're hard to get used to and they're not so beneficial that the learning curve seems worthwhile — but parsing isn't as ambiguous as it seems at first. When you see a sequence of identifiers separated by spaces, the first one has to be a function accepting all the others as arguments.
It's different (and complicated to explain) if there are newlines involved, though. Haskell isn't a whitespace-insensitive language.
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.
I think they can be solved with a little design, creativity, and focus on common use cases before generality.