mohamedsa

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.

The biggest hurdles are probably screen size & lack of symbols on the default keyboard layout.

I think they can be solved with a little design, creativity, and focus on common use cases before generality.

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

Thanks for the insights!

Thanks! I've read a couple of chapters in HTDP, and while I'll probably be alone in this, I don't like their design recipes approach very much.

Seems artificial, treating the highly complex and unsolved problem as if it can already be put into pre-made recipes...

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 :)

VBA was a very nice step towards the goals I've described!

Yes, I do feel that JavaScript could be a very possible way towards achieving those goals :)

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

We seem to be in agreement then..

يسعدني أنها أعجبتك! هلا أريتني لغاتك التي اخترعتها؟ بريدي موجود في البروفايل لو أردت ذلك :)

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.

> Pharaos are big in a metaphorical sense.

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

1) Since early 2010 (but changed the idea several twice, began working on my first idea early 2008). 2) Nope 3) No again.

Am I missing something? The Winter 2010 application deadline is already over; so is the RFS just a source of potentially good business ideas or is there something I don't know?

As a non-American who applied to YC twice the article was a pleasant surprise. However I'm not sure America is as attractive to non-American founders as some people think. I'll explain (my arguments are mostly personal perceptions...I have no practical evidence yet on any of this since my own startup is still at the "wrote some code" stage).

Let's suppose there are 2 types of founders: people who have enough money & connections, and the young "live on Ramen noodles" type founders.

For the "money & connections" type, a lot of foreign countries offer cheap but still qualified programmers and don't put too many obstacles on founding companies so if your country is like that it might make sense to stay. For the "Ramen" type, many of them may not afford America's often high living costs.

As for the argument that the US provides a better/more free market... even this is changing: The internet probably allows relatively easy selling to worldwide customers from any country.

All that said, the American dream probably still lives on and many people would likely provide counter-examples to my limited point of view. Of course pg didn't claim that coming to the US is a no-brainer for every single talented hacker. There are probably enough of those who are interested to satisfy the 10,000 founder/year goal.

Very durable writable DVDs that could keep the data even after multiple scratches, the passage of decades...etc

I don't know of a readily available solution, but there are some discussion threads on comp.lang.lisp about "tree shaking" and how to could be used to remove unused parts of the runtime before writing the image. Some of those posts are quite interesting. And it seems some of those techniques are already implemented in commercial Lisp offerings.

For the time being, I think the way to go is to use Lisp for the cases that suit it best. My aim for using Lisp is for internal-use code generation or web stuff, so code size is not a big deal. Also if your program is already large and complex (which Lisp was designed for, being an AI language) then the initial runtime size wouldn't be too significant compared to the size of the program.