I had the pleasure of meeting Andrew Smith (the author of this article) at PyCon a few weeks ago. He was really interesting to talk to.
He said he was interviewing one of the people who walked on the moon a while back. The guy stepped out of the interview to take a phone call, and when he came back he said he just learned that one of the other men who had walked on the moon had just died. Andrew reflected on this, and recognized that these men are dying and soon there will be no one left alive who has walked on the moon.
He decided to track down each of the people who were still living who had walked on the moon, and hear their stories firsthand. The premise of the conversations was, "What do you do after you've walked on the moon?" He wrote a book about it, called Moondust. I haven't read it yet, but it's in my Amazon cart at the moment.
You might want to read the one-to-three-star reviews before ordering. If they are to be believed, Moondust is less about the astronauts and more about Andrew Smith.
Very well written article. I think everyone can definitely emphasize with the confusion that comes with having to dig through APIs and tooling for the first time.
When a friend asked me to teach him some python the most stressful part for him was setting up the editor, understanding the command line and how an API worked as well. Like the author he grasped fundamental python pretty quickly.
I think there's still no really good solution to make the whole process appealing. You can have people write puzzle solutions which circumvents the API and documentation issue but doesn't produce a real project, you can give them an IDE which avoids the command line but doesn't teach much and often is too complicated for a simple script, and so on but there's always some nasty issue for beginners in the process.
The Lazarus IDE short circuits most of these problems and can quickly build some very "real" feeling apps that can solve real problems for people just learning to code.
It is object pascal (with the attendant quirks) but it seems to be code-ish enough that people can transfer on to more modern languages without too much fuss.
Jeff Duntemann has uploaded a draft of his upcoming ebook, FreePascal from Square One, a revised version of his earlier books on Turbo Pascal and Borland Pascal:
The book’s mission is to be what Assembly Language Step By Step is to assembly language: An absolute beginner’s tutorial on programming in Pascal. This includes people who have not yet learned what programming is and have never written a line of code in their lives.
I second the comment on javascript. I hate the language so much I keep hitting refresh daily on webassembly to monitor its penetration. Javascript is just a joke and like everything that makes no sense it gets the votes from the industry.
Hm. Have you taken the time to learn all the new features and develop something with them? Most people who work with JavaScript these days seem to like it quite a lot, myself included. Since ES6 released it's become a solid language with a few strange quirks, whereas it used to be a crappy language with a few useful features.
ES6 is really nice but it’s still JavaScript so it’s untyped and therefore much less pleasant to work with at any kind of scale than, say, Java+IntelliJ which is like butter. Not sure which static typed languages will be WebAssembly-able, though? Go? Rust?
JS isn't "untyped", it's dynamically typed. And this is absolutely not a problem at scale if your development practices are up to scratch - or at least, not a bigger problem than the myriad of other design tradeoffs that every major language has to deal with.
Static typing is massively overvalued. It has non-zero value, but it's a tradeoff with other things, and the amount of importance that people tend to place on it is absolutely out of proportion with the actual value it provides.
EDIT: This extends beyond just 'static typing', as well. The design of programming languages is an exercise in tradeoffs, and people rarely take the time to understand the tradeoffs introduced by their pet language feature, instead presenting it as some inherently ideal thing where any language that doesn't have it must therefore be bad.
Are you serious? If you job involves using a scripting language in the browser, then at least have to decency to look into TypeScript. I converted to TypeScript after having worked on a code base in JavaScript and realized that just adapting one module to TypeScript, the conversion revealed stuff I had no idea it could have possibly slept thru jslint. I am talking major stuff like string to number and non-existent method calls. Ugh.
I used to think that until I tried Rust and found that, without effort, my programs never crashed or had runtime errors. This is possible to achieve in JavaScript, but I do now seriously miss having the compiler do all my safety checks for me!
I still like JS, but I do now appreciate some of the criticisms more.
As somebody who writes both JS and Rust: yes, Rust does prevent most runtime errors.
But this isn't without a cost; it's much more expensive to build abstractions in Rust than in JS (although still cheaper than in most languages), for example, and the strictness does create problems with interoperability ergonomics in some places, especially when working with multiple third-party dependencies.
This goes back to my earlier remark about tradeoffs; strictness is not without its costs. The tradeoffs may be worth it to you, or not, or only for some projects - but it means that it makes no sense to paint things like dynamic typing as inherently bad; it just makes different tradeoffs.
I do share your sentiment of missing such 'upfront error-reporting'; that's precisely why I'm working on better tooling for this, of which the variable-renaming is just one aspect :)
I’m not the best programmer but personally I avoid building abstractions as long as possible, deferring until the abstraction is as obvious as possible. The cost then becomes basically irrelevant because the value is so great. Writing JS even with ES6+ is really unpleasant for me. Abstractions or no asbractions, my mental capacity is quite limited compared to a compiler with 2 cores and 8GB of memory.
It's not scaling issue, it's a refactoring / maintenance issue. Weakly typed languages cost much more to maintain because you can't have good refactoring tools.
In a strongly typed language, if I want to rename a parameter that is used in 20 places, I can hit "Rename," rename it, and it will rename all 20 instances with perfect precision, and that's it. With weakly typed languages, you have to search and replace, which is much more prone to error. This is much more of an issue for JS applications that are much larger than just doing some stuff on a page.
I agree, it's a tradeoff. Many languages these days can do both. The best is strongly typed until you are dealing with JSON or something of that nature.
There is absolutely no reason why this wouldn't be possible in a dynamically typed language. I'm in the process of building such a tool for JS, in fact.
You don't need static typing to do codebase-wide renaming, it just makes it a little easier to build the refactoring tools, but since that is a one-time cost it's not really a particularly important factor in the language design. Other language design decisions have much more influence on this development cost, too, such as reassignability and scoping rules.
"Strong typing" is also something totally different from "static typing" - I'm not sure why you're bringing it up here. The two are not interchangeable terms.
EDIT: Actually, doesn't Webstorm already do such mass-renaming for JS?
EDIT 2: I also object to the use of the word 'refactoring' to refer exclusively to renaming variables. Proper refactoring involves much more work, most of which isn't automatable regardless of the language you're using.
> You don't need static typing to do codebase-wide renaming.
But you do. WebStorm isn’t magical. It can’t understand your untyped code like it can understand typed code.
The more I’m reading your comments on this thread the more I’m not sure you’ve ever used a static typed language with a good IDE. If I am correct, I think it makes more sense for you to try Java/IntelliJ and then weigh in on this subject. You may have a very different opinion.
Yeah I mean of course it’s not untyped. What runtime doesn’t have types? C?
> Static typing is massively overvalued.
Have you every worked extensively with Java/IntelliJ or some other combo like C#/VS? It’s night and day compared to wading through the muck of an untyped codebase.
I can accept we might have different tastes, but whenever people say they advantage of static typing isn’t that great I assume they are either exceptionally gifted and don’t benefit much from a static language/compiler or are ignorant on the subject and don’t know better.
You really shouldn't have global variables in the first place, and this misses the point entirely; the type of something isn't what's important, the semantic meaning of it is. The type can be mentally inferred from that.
Hungarian notation 'solves' a problem here that doesn't exist in the first place.
Apache Groovy's original use case was for scripting classes already written in Java, for stuff like testing and glue code. It added closures to Beanshell, which was the de facto language for scripting Java at the time.
New leadership, er, took over in late 2005 and re-oriented it as a DSL for Grails, and later Gradle. Grails has since died, with virtually no-one upgrading to version 3, or starting new projects in it. The Grails 2 plugin scene is dead. Many sites are converting their Gradle build scripts to Basel, so it's also starting a slow decline.
Around 2012, Groovy was repurposed again with static typing to compete with Java and Scala on Android. But it never succeeded, and the leadership was retrenched 3 yrs ago from VMWare and couldn't find anyone else to financially support them.
Groovy remains OK for scripting Java classes, but it's fast becoming irrelevant now that Java itself has lambdas and type inference.
Yeah with lambdas and local type inference in Java it’s less and less relevant but it’s still dynamic and that can be great for tests and little scripts with Grape. I really enjoy Grape despite using it so rarely that I always need to look up how to do things.
I wonder if a guided introduction to JavaScript, restricted to just the good parts and using some tools such as a linter to enforce that, would have made it more approachable to the author. Maybe use TypeScript in strict mode, along with a project template for a minimalist framework (e.g. Vue).
I loved Python for years, going back to when I discovered it in the Red Hat Linux installer in 1999. But it seems to me that Python has been sliding into irrelevance for a while. Even now, 10 years after the introduction of the ihone App Store, I don't know of any mature way to develop a mobile app with a native UI in Python. The same goes for using Python in the browser. So for the things that most people actually want to do with code, Python is relegated to the server (assuming there is one), and they have to learn something else anyway. So, might as well start with the something else that will get you the farthest.
The error in the author's code seems to be better described as an "unnecessary function call" than a "stray parentheses". I spent more time looking for that stray parentheses than I should have before noticing the call to .title().
For people without a specific goal in mind I'd recommend getting them set up with the Python3 turtle module. It's fairly self-contained and allows for immediate results. Additionally it's very easy to nudge people when they are using the turtle module. e.g. after introducing loops ask if they can draw a square using only one forward() and one rotate(). after introducing functions you can ask if they can make a functions to draw N-gons. what happens if you try to draw a 100-gon? etc etc.
After use of the turtle module is comfortable python offers no end to possibilities in other areas.
That said, "best" is surprisingly subjective when it comes to programming, so feel free to go a different route if that feels more appropriate.
He said he was interviewing one of the people who walked on the moon a while back. The guy stepped out of the interview to take a phone call, and when he came back he said he just learned that one of the other men who had walked on the moon had just died. Andrew reflected on this, and recognized that these men are dying and soon there will be no one left alive who has walked on the moon.
He decided to track down each of the people who were still living who had walked on the moon, and hear their stories firsthand. The premise of the conversations was, "What do you do after you've walked on the moon?" He wrote a book about it, called Moondust. I haven't read it yet, but it's in my Amazon cart at the moment.