What does HackerNews think of pytudes?

Peter Norvig's notebooks: https://github.com/norvig/pytudes

Peter Norvig's Pytudes was recently posted here. I think that's some of the best code I've read, although they're only small problems and not a bigger project. Still very much worth a read, he goes through the whole problem solving through code process.

https://github.com/norvig/pytudes

Prolog is excellent for bikeshedding, in fact that might be its strongest axis. It starts with everything you get in a normal language such as naming things, indentation, functional purity vs side effects, where to break code into different files and builds on that with having your names try to make sense in declarative, relational, logical and imperative contexts, having your predicates (functions) usable in all modes - and then performant in all modes - having your code be deterministic, and then deterministic in all modes. Being 50 years old there are five decades of learning "idiomatic Prolog" ideas to choose from, and five decades of footguns pointing at your two feet; it has tabling, label(l)ing, SLD and SLG resolution to choose from. Built in constraint solvers are excellent at tempting you into thinking your problem will be well solved by the constraint solvers (it won't be, you idiot, why did you think that was a constraint problem?), two different kinds of arithmetic - one which works but is bad and one which mostly works on integers but clashes with the Prolog solver - and enough metaprogramming that you can build castles in the sky which are very hard to debug instead of real castles. But wait, there's more! Declarative context grammars let you add the fun of left-recursive parsing problems to all your tasks, while attributed variables allow the Prolog engine to break your code behind the scenes in new and interesting ways, plenty of special syntax not to be sneezed at (-->; [_|[]] {}\[]>>() \X^+() =.. #<==> atchoo (bless you)), a delightful deep-rooted schism between text as linked lists of character codes or text as linked lists of character atoms, and always the ISO-Standard-Sword of Damocles hanging over your head as you look at the vast array of slightly-incompatible implementations with no widely accepted CPython-like-dominant-default.

Somewhere hiding in there is a language with enough flexibility and metaprogramming to let your meat brain stretch as far as you want, enough cyborg attachments to augment you beyond plain human, enough spells and rituals to conjour tentacled seamonsters with excellent logic ability from the cold Atlantic deeps to intimidate your problem into submission.

Which you, dear programmer, can learn to wield up to the advanced level of a toddler in a machine shop in a mere couple of handfuls of long years! Expertise may take a few lifetimes longer - in the meantime have you noticed your code isn't pure, doesn't work in all modes, isn't performant in several modes, isn't using the preferred idiom style, is non-deterministic, can't be used to generate as well as test, falls into a left-recursive endless search after the first result, isn't compatible with other Prolog Systems, and your predicates are poorly named and you use the builtin database which is temptingly convenient but absolutely verboten? Plenty for you to be getting on with, back to the drawing boar...bikeshed with you.

And, cut! No, don't cut; OK, green cuts but not red cuts and I hope you aren't colourblind. Next up, coroutines, freeze, PEngines, and the second 90%.

Visit https://www.metalevel.at/prolog and marvel as a master deftly disecting problems, in the same way you marvel at Peter Norvig's Pytudes https://github.com/norvig/pytudes , and sob as the wonders turn to clay in your ordinary hands. Luckily it has a squeaky little brute force searcher, dutifully headbutting every wall as it explores all the corners of your problem on its eventual way to an answer, which you can always rely on. And with that it's almost like any other high level mostly-interpreted dynamic programming / scripting language.

How exactly do you use clojure's repl? You're not supposed to write things in the repl window.

As for functional programming, if your rebuttal is that python has list comprehensions, you still need to do some more digging into it. I suggest you read Peter Norvig's pytudes, he writes python in a functional way and uses both higher order functions (which are there, but really meh) and list comprehensions. They are not the same thing. Clojure also has immutable structures which is imo just as important for functional programming.

Not to say that python can't be used for it (pytudes really looks like art). For clojure maybe you can watch the parent of the dead series on YouTube (there's an ongoing reboot of the series). The repl workflow is so different from other languages that you really need to see people code in clojure live to understand it.

https://www.parens-of-the-dead.com/

https://github.com/norvig/pytudes

Seconding Alan Downey's Think Python. The current online version is here:

https://greenteapress.com/wp/think-python-2e/

For code examples, I like Peter Norvig's pytudes:

https://github.com/norvig/pytudes

PAIP is still on my list to work through.

Last time I tried I got as far as the first substantive program (https://github.com/norvig/paip-lisp/blob/main/lisp/gps.lisp), was generally confused by the code, and was then not surprised when the following sections pointed out all the faults (i.e. bugs) with the initial approach and suggested various improvements. I've come to trust my own "how can this possibly work?" confusion as a strong signal that a design is probably buggy or fragile, so it was nice to see it confirmed here.

Which is not to say that what this book teaches is not useful, but I wouldn't go to it looking for best practice and robust software engineering techniques. Much of what I saw in this book wouldn't pass code review in many situations ("too fragile" or "too clever"). Most of what he's talking about are techniques that "allow a programmer to delay making decisions". This is a different kind of programming than very the very concrete kind of programming that can dominate day to day professional work. I suspect that these kinds of "delayed decisions" are best applied sparingly, but applied correctly they can be powerful.

To get a flavor of the "Norvig approach" to things, his Advent of Code solutions in IPython notebooks are fun: https://github.com/norvig/pytudes

Peter Norvig has provided some good examples here: https://github.com/norvig/pytudes

In general, he has some examples of good idiomatic python on his site as well: https://norvig.com/

If someone is interested in the previous years of Advent of Code they are available as notebooks in Peter Norvig's pytudes repository: https://github.com/norvig/pytudes

> we can’t say anything more than "roughly order of magnitude"

This, to me, is the core of it. "10x" is just a shorthand for the compound interest of good decisions. Nobody would be surprised to learn that teams with good managers are 10x more productive, or that factories with a good safety culture have 0.1x the accident rate.

Where it gets confusing is that developers have substantially more scope for compounding than their roles suggest. They're generally not managers, executives, or cultural leaders, and yet their decisions seem to compound anyway. Why is this?

For the answer, I encourage you to watch the YouTube channel "Primitive Technology", where a brave and often shirtless soul spends weeks and months constructing tools and structures from scratch. He does so with a deftness and skill that is captivating, yet the stuff he makes is, by modern standards, totally useless. It's not his fault; it's just that technology compounds, and no amount of individual skill can ever make a skyscraper out of wattle and daub.

Only in software, the most questionable of all the engineerings, do we build the processes and tools we depend on while we're using them. If you showed up to a job site talking about making your own concrete mixer to get the building done faster you'd be laughed right back to wherever you came from. Yes, in cutting-edge applications and prototype manufacturing it's different, but almost every other area of engineering takes stuff that works and uses it to make more stuff that works.

To be clear, this isn't a long-form argument for "we should have stuck with Rails", nor is it "software is just getting started, give it some time". Rather, I believe that software development is essentially and unavoidably compounding. Every design decision, abstraction, function and data structure is a piece of your foundation that you build and then stand upon to build some more. We're creating abstract machines, and when they become concrete enough to rely upon they no longer need software developers.

Which is why it's so ridiculous to imagine this 10^x developer who crushes code 24/7, laughs in the face of process or documentation, and communicates only via a colourful aura of cheeto dust and misanthropy. It's an adolescent fantasy of expertise, no different from Doctor House or Detective Batman. Sophomoric macho bullshit. The 10x isn't the person, it's the compounding effect of good decisions.

Peter Norvig is a great developer, but try airdropping him into some dumpster fire codebase that's 99% finished, riddled with bugs and way behind schedule. Is he going to grab his wizard hat and 10x his way out of it overnight? No. He's going to have to slog through the mess like anyone else. His expertise doesn't result in faster typing, but in better decisions. Decisions that work well now, but enable even better work later.

Most importantly, this kind of compounding doesn't just apply to you, but to the people you work with and the environment you work in. To enable that, you need communication, leadership and generosity. Here's the man himself, describing his work at Google [0]:

> I've varied from having two to two hundred people reporting to me, which means that sometimes I have very clear technical insight for every one of the projects I'm involved with, and sometimes I have a higher-level view, and I have to trust my teams to do the right thing. In those cases, my role is more one of communication and matchmaker--to try to explain which direction the company is going in and how a particular project fits in, and to introduce the project team to the right collaborators, producers, and consumers, but to let the team work out the details of how to reach their goals.

Or some quotes from his essay "Teach yourself programming in ten years" [1]:

> Talk with other programmers; read other programs. This is more important than any book or training course.

> Work on projects with other programmers. Be the best programmer on some projects; be the worst on some others. When you're the best, you get to test your abilities to lead a project, and to inspire others with your vision. When you're the worst, you learn what the masters do, and you learn what they don't like to do

> Work on projects after other programmers. Understand a program written by someone else. See what it takes to understand and fix it when the original programmers are not around. Think about how to design your programs to make it easier for those who will maintain them after you.

Or check out his lavishly documented walkthrough of approaches to the Travelling Salesperson Problem[2] (just one of many similarly educational "pytudes"[3]). Or the leading AI textbook he co-wrote[4]. Or the online AI course he co-developed[5]...

That's what real 10x looks like. Not some myopic ubermensch who divides the world into "code" and "dumb", but a thoughtful decision-maker who treats great work as a garden to grow, rather than a race to win.

[0] https://www.quora.com/What-does-Peter-Norvig-do-exactly-at-G...

[1] http://norvig.com/21-days.html

[2] https://nbviewer.jupyter.org/github/norvig/pytudes/blob/mast...

[3] https://github.com/norvig/pytudes

[4] http://aima.cs.berkeley.edu/

[5] https://www.udacity.com/course/intro-to-artificial-intellige...

Small git clone in javascript:

http://gitlet.maryrosecook.com/docs/gitlet.html

Small Lisp interpreter in Python:

http://khamidou.com/compilers/lisp.py/

If you are interested in annotation formats other than side-by-side, many Jupyter or IPython notebooks would qualify, for example Peter Norvig's programming exercises:

https://github.com/norvig/pytudes