> Side note: While I definitely applaud the idea of trying to create a language that is geared towards beginners and good for learning on, I don't know if I can get behind recommending such a language that is still under development being suggested to beginners.

I second this. Especially when python itself is very beginner friendly.

IMHO the best advice on learning a skill is just do some projects with it. I am not exactly sure, which should come first, the 1. or the 2. point made in the article.

Though I would dare to say the 2. point is more important.

By doing python projects first you familiarize with it and then if you are still on - you should read zen of python, pep8, etc..

I strongly agree. Dealing with a language in development is hard enough when you're an experienced programmer, I can't imagine trying to learn programming with an unstable language.

I tend to agree as well. The Pyret option is probably better done with a mentor by your side. If no mentor is available like they probably have in the Bootstrap (http://www.bootstrapworld.org/) program then Python is more than likely the better option. So I'd expect 99% of the people to stick with Python anyway which is fine.

Agreed - you need to experiential context to grok the concepts about best practices. Otherwise, it is just cargo-cultism. Most the great programmers I know learn by working on increasingly more complex projects and then deep-diving into the details whenever they come across something they don't know. They make this process move faster, not by doing tutorials and writing code from scratch (after the initial bootstrapping of learning a new language/framework), but by reading code from others, especially successful project. And again diving into to understand the WHY behind the implementation and this reinforce the choice and knowledge of the HOW.

>By doing python projects first you familiarize with it and then if you are still on - you should read zen of python, pep8, etc..

Would you mind recommending some projects for a python beginner?

I find scratching one's own itches is always the best way to learn a new language. Solve a problem that you have.

Problems are not all the same: choose one that stresses and challenges the language, to gain confidence in its strengths and practical expertise.

For example, I once tried to learn Haskell and I started from little exercises (https://wiki.haskell.org/H-99:_Ninety-Nine_Haskell_Problems)... I got familiar with syntax and basic concepts, but I was dissatisfied both with the easy, abstract questions and with the simplistic, inefficient answers using basic standard library features that are more or less the same in any language. What was "real" Haskell code like? I expected dealing with serious libraries, memory management etc. would be uglier, more difficult and more cumbersome than exceptionally terse toy examples.

So I attempted something not merely useful and small, but with a well defined practical objective, depending on external standards, requiring production quality libraries and with performance challenges: converting the metadata dump from MAME (a nearly 200MB XML file) into an easy to use SQLite database.

The task was a good test of programming language productivity because, having already used ElementTree and APSW I was sure I could write it in Python quite easily. (And I did; a complete Python implementation, able to roundtrip data back to the XML format for testing purposes, took me less time than an aborted Haskell attempt that could parse a dumb document tree using a ridiculous amount of memory.)

This project allowed me to discover many things about Haskell that are not found in enthusiast-written tutorials: the mess of incompatible and undocumented libraries, the impracticality of basic language design decisions (text handling, lack of namespaces leading to name conflicts, etc.) and my profound disgust for the commonplace syntactic tricks.

Of course, a similar challenge for Python is likely to have a better outcome: learning the difference between good and really good libraries, finding a use for many language features, remembering useful idioms nd design patterns, etc.

You have the standard things like a calculator, card game (start with blackjack), anagram maker/solver...

With the web you can move to things like an address book, todo list, message board (regular or reddit/hn clone)...

A web search engine.

In which case you may want to follow Udacity Com Sci 101 which includes building a search engine in python. (Free, video based https://www.udacity.com/course/intro-to-computer-science--cs...)

I get so frustrated with picking up a new language because they all seem to either be "from scratch, here is how to add two numbers" or cookbooks that assume too much knowledge.

the learnxinyminutes stuff is sometimes good. It'd be nice if there was a resource that taught languages from the perspective of already knowing another (any) language in that same family.

Show me definitions, modules, packages, namespacing, whatever, and get out of my way.

I agree with your gripes here -- absolutely agree there are a lot of languages that get it wrong.

I think there are some books that really get it right though, that show you how to do stuff, but also try to get out of your way. Some examples (in order of adherence to this point, to the best of my ability):

- Practical Common Lisp

- Learn You a Haskell For Great Good

- Clojure For The Brave and True

I read c# spec when it was in beta, going fast through it, skimming less informative parts, taking quick notes as bullet points in form of single statement or question. It was one of the best experiences, it put me in flow mode and I learned a lot in very short time. I used c# later professionally and never had problems. Great thing about language specs is that is very precise, without mistakes. The art is to read+skim+note it quite fast.

> Great thing about language specs is that is very precise, without mistakes.

I'd also add "concise" to the list of required traits for a good language spec. If you don't believe me that's important, go check out the C++ specification. IIRC it contains some 50 pages of rules on how to choose implementations of an overloaded function.

And if you're looking at modern C++, you also get to learn about lvalues, glvalues, xvalues, rvalues, and prvalues!

prvalues are the ones that return a promise about a system's future state which are commonly expected to prove false, right?

Was this not a direct (possibly knee-jerk) reaction to the ease with which you could shoot yourself in the foot, and undefined behavior C allows?

>I often suggest the read-a-chapter-write-a-program-based-on-it route

After doing some of https://javascript30.com/ I want the "30 day challenges" style tutorials in every language - I love it. I'm not sure how well it works for long term learning but it's really helped with my motivation.

> I often suggest the read-a-chapter-write-a-program-based-on-it route

Learning Perl (the llama book) was great for that. At first, I would think that I understood just from reading the chapter, but doing the exercises at the end of each chapter made me actually learn it.

Absolutely agree! In a previous life, I was working at a company where perl was just about the most recent scripting language they were using (for better or for worse), and that book was an absolute godsend. Reading through Chapter 8 around was all I needed to be productive, and I've recommended the book ever since (especially while I was at that job)

Allen Downey's Think Python is that book for Python, though focused more on teaching good programming habits than scripting.

Smalltalk was developed that way...

Also, MIT switched from scheme to python.

\tangent I agree with your approach of mixing theory and practice. So what's the best way to learn fluid simulation? It's discouraging spending so long on maths without the gratification of Something Actually Working.