Stumbled upon norvig's pytudes years ago during a leetcode grind. His elegant approach to problems always had this touch of clarity that only few possess. Python, with its expressive syntax, combined with norvig's penchant for crafting illuminating examples, has definitely provided me with numerous 'aha' moments. I recall, early in my career when learning about bayesian probabilities, that it was peter's "how to write a spell checker" that made the abstract concrete for me. it's really heartening to see such a legend continuously contributing to and enriching the programming community.
Ditto. His Udacity course opened me up to how expressive, yet understandable, code can be with some careful thought. Lots of wow moments comparing my solutions to his.
It's inspirational to me that norvig still does these things. That he gets joy out of it so late in life, that he's still more than mentally adept at it, etc. Makes me feel like pursuing programming as a craft for life is a worthwhile option.
Norvig has always been a huge inspiration for me. I read his sudoku solving blog (https://norvig.com/sudoku.html) when I was first teaching myself to code and it really helped me nurture a love for solving fun problems.
Etudes for Programmers is really hard to find to purchase - looks like it is around 450 USD on my local Amazon store and none in local libraries. Does anyone have a link to a PDF of it instead?
> No one is using Python like that in the professional world. The most complex you'll see are simple comprehensions.
It is possible that blub-Python and "let's code it in Java-flavoured Python" rules your particular slice of the profession, but in my world of getting shit done I see more FP and using simple built-in data structures in a >1 KLoc line script/module than I do of traditional OO and GoF styles. Most objects I deal with in Python are from libraries I call and not from our own code. Different strokes I guess, but I think you underestimate the breadth of Python usage and how much of it is semi-complicated scripting that picks from FP-style and OO-style depending on what is easiest to accomplish the task.
$DIVINITY, I hate Java-flavoured Python with a passion. Sometimes I dive into corporate stuff that seems like it was done by the yard by interns measured in LOC per day, or literally code-generated from some overly abstract spec.
Worse, sometimes I will have to dig down into accessors of accessors to find the actual logic for a library (which is why I often implement my own, shorter and easier to debug ones).
I write Python in a mix of FP style (with the occasional class for handling specific contexts or tasks) that aims to be as concise and readable as possible, and yes, I will use global variables in a module if it saves me the trouble of herding some constants or common state around and making function invocations unnecessarily long.
I think OP refers more to the "code-golf" part than FP: the repo contains code that uses OO when necessary and FP (although in a very light way) when it can. The biggest issue is that it tries to be as short as possible, which makes it hard to understand. Code should be simple, not short. Instead of looking at Loc, we should look at "how much time does someone need to understand this part of the code".
I have the same impression. Reading the code, he uses global variables [1], obscure variable (k, bw, fw, x) and module names ("pal.py" instead of "palindromes.py"), doesn’t respect conventions about naming in general (uppercase arguments [2], which even the GitHub syntax highlighter is confused about). This feels like code you write for yourself to play with Python and don’t plan to read later.
Some parts of the code feel like what I would expect from a junior dev who started learning the language a couple weeks ago.
When your code is under 200 LOC and not expected to be maintained for the next 10 years.. then a lot of the things you just mentioned don’t matter as much. This is not for running in an enterprise but for exercising the brain.
> When your code is under 200 LOC and not expected to be maintained for the next 10 years.. then a lot of the things you just mentioned don’t matter as much. This is not for running in an enterprise but for exercising the brain.
The things I mentioned do matter in any situation. If you don’t take good habits when you exercise your brain, you won’t take them when you code "for real". In addition to that, this repository is not just to exercise the brain of the author, but to serve as example code for others to read it; it has a README and most functions have a docstring.
Python is supposed to be whatever you want it to be. It's free software. Who cares what people do in the "professional world"? This is Pytudes and it's quite fun. Learning to program in different paradigms helps your mind to grow, even if you won't use them yourself.
I see quite a lot of higher-order functions in "real" Python anyway. I'm not sure what other FP concepts there are in Pytudes.
> No one is using Python like that in the professional world. The most complex you'll see are simple comprehensions.
I'm always surprised what I find when I move into a codebase. A lot of it is just what was fashionable when the application started. 90s and 00's everything is over objectified complete with lots of factories and tons of getters and setters. 10's you started seeing a lot more FP style usage, and now I'm seeing a lot more async code.
> Python is supposed to be a readable language for newbies, like Golang.
Python is supposed to be readable because most developers spend more time reading code than writing it.
So it’s supposed to be ‘exemplary’ and ‘beautiful’ but literally the first script I opened had global variables used. That’s not my idea of elegant Python.
In Python every module is an object. It therefore makes less sense (in less situations it makes sense) to use classes, and a 'global' is a variable global to the module. It's like having a class, and calling attributes of the class 'globals', because they can be accessed by all methods of the class.
This and the fact Python is often used in the context of writing simple utilities, where globals (even without the defense above) are perfectly fine (because it's not a huge codebase with namespace collisions etc.).
Using absolute axioms like "globals are always bad" and religiously applying them is a toxic attitude in my opinion.
Elegant means written in the simplest, clearest way possible.
Agreed, a complex application riddled with global variables is not elegant.
In a fifty line self-contained script, global variables are often the simplest way to go. Turning the code into a reusable class with member variables, which will never be reused, is not simpler. YAGNI.
