I tried a few (not all) of the examples with plain old Python (granted, these are multi-liners, not one-liners, but I think they're easier to read). I'm not sure I see the advantange of curly braces.
# --- Example 1
# pwk
pwk 'if "braces"=="bad": { print("Be gone!"); exit(99) } else: { print("Howdy!") }'
# vs
# python
python -c 'if "braces"=="bad": print("Be gone!"); exit(99)
else: print("Howdy!")'
# --- Example 2
pwk 'def s2i(s): { return int(s) } print(s2i("41")+1)'
python -c 'def s2i(s): return int(s)
print(s2i("41")+1)'
# --- Example 3
ls / | pwk 'for s in sys.stdin: try: { print(os.listdir("/"+s.strip())) } except: pass'
ls / | python -c 'import sys, os
for s in sys.stdin:
try: print(os.listdir("/"+s.strip()))
except: pass'
You're braver than I -- whenever a shell/terminal indicates to me it expects multiline now, I press, in that order, Ctrl+C, Ctrl+D, Ctrl+Z, and Ctrl+Alt+Del.
Face it - Python just ain't fit for one-liners. Give Perl and Ruby some credit as they were designed for conciseness and the command-line. Python may dominate data science, AI and ML but it's deficiencies bleed through when you try to compose something elegant and concise.
I agree about Perl; haven't done a lot of one liners with Ruby when I was using the language. Perl was made to be really compact to the detriment of being hard to read. I think Python strikes a nice balance, and you can compress it to a point. In discussions like these I always like to bring out my one-liner k-nearest neighbor classifier [1]! Explanation here [2] (better on a desktop).
I really don't understand the love of one liners. Yes it's cool to see how much can be done in one line but it's so much harder to read. Isn't legibility far better than compactness?
Aye, in general legibility >> compactness. Apart from the intellectual exercise (fun; !work), one-liners imo come in handy in:
>some_complex_tool | 'my one liner' | some_other_complex_tool > result.txt
Not putting the one-liner logic into a separate script avoids an additional lookup for someone learning what is going on, along with any deployment/path/.. dependencies to that separate script.
It depends on the context. I like one-liners because it's much easier to iterate over a command line and building them is a bit of a personal challenge since it's not worth writing a script or saving to a file.
I don't know about most people, but interactively I use short flags and when writing Bash scripts I try hard to use long flags and will often break things up specifically for clarity.
Only advantage I can think of is that you can just paste it in a shell prompt, if you're not comfortable with making a script, changing permissions, etc.
It's a shame Python doesn't natively support easy invocation from command line. It really shoots down a whole class of applications where bash is getting used but Python would be so much better.
I've ended up using Groovy for this level of scripting, and it works really well.
It doesn't? If I write this into a file (/tmp/test.py):
#!/usr/bin/env python
print("Hello, world!")
and mark it as executable (chmod +x /tmp/test.py), I can just execute it as /tmp/test.py like I would do with any bash file.
If you mean invocation as "execute a command that I'm passing", 'python -c' does exactly that.
Even as a complete shell it works including changing directories and using standard python to do file IO, though it won't execute any system executables and doesn't do piping like you'd like from a shell. It's not intended for that purpose so I can't really blame python for that.
CoffeeScript code bases are the scariest code bases on the planet, the nightmares. To me CoffeeScript inherited all the inconsistencies of JavaScript, then made the syntax inconsistent as well. It least it had optional chaining.
It's weird right? I come from Rails and thought CoffeeScript (CS) could make it way more readable, like Python but with cool string interpolations!
But you're absolutely right, it made my code really hard to reason about. I don't know why this is the case but it was always harder to read my own CS than raw JS. I found myself putting blocks into the CS2JS just to read inner workings.
While it made me less verbose and short-term faster, longer term it made me slower.
I like python and I enjoy weirdo one-off languages, so I'm predisposed to like this. But why keep the colons? It would look nicer without.
...
I just attempted to type out an example and found a reason not to do this... it's the same reason c needs parentheses around the conditional. On the balance, I prefer parentheses over the vestigial colon.
Your friends are going to insist on properly indented code no matter what your compiler/interpreter wants, so rather than following one set of rules for your friends and a different set of rules for your compiler, why not teach the compiler to think like your friends so that you only have one set of rules to think about?
I still think one of Go’s best contributions was formatting with ‘go fmt’. It’s refreshing to see so many language communities just embrace a format on save standard and keep it moving.
Reading Python has always been a bit of a headache for me, but that probably has as much to do with the lack of type annotations as it does the lack of braces.
Auto formatters are the future, why should humans ever have to manually format or discuss how it should look ever again.
However, languages that have a line length limit are the blight of them. There isn't a python formatter that won't make everything mush. My if clause that is 81 chars wide doesn't need to be broken up. Similar, my strings don't need to be reflowed.
Go fmt ignores line length, and always produces a formatted file that is pretty as a result.
You can change the max line length in black (the Python formatter I hear mentioned most often). How would you feel about setting it to something really large, like 1000, to emulate having no line length limit?
Yeah that makes a bit more sense, thinking back to arguments about aligning hash key/value pairs in code reviews and how that just never seems to come up anymore (thank god)
That’s a pretty bizarre rationale given that other languages didn’t need semantic whitespace (or a formatter) to maintain consistency, and the consistency was even achievable for larger code units than individual files. Formatters are definitely the way to go, but baking it into the syntax was never necessary or even helpful IMO.
I think it's Python's only real strength. The language is ugly, the interpreter is a genuinely deficient way of making software ("Why use a compiler when you can just write thousands of unit tests to check for syntax errors!?"), and the mechanisms for abstraction are fairly weak - even after all that, n00b Python code is fairly readable.
If you haven't read Landin's "The Next 700 Programming Languages", you should. I don't know if it's still outside the ACM paywall, but you'll find it in a web search if not. It introduced the offside rule -- not actually what Python has -- inspired by mathematical notation. Note "it can be mixed freely with [...] punctuation" (e.g. Haskell). The paper talks about "physical representations", relevant to syntax highlighting mentioned below (or "fontification" in Emacs, reminiscent of typefaces in the publication language of ALGOL).
That might be a bit TOO contrived, at least for me. I could see this coming up for someone working with jurassic hardware not under their control though.
Anyway, to play along. I think curly braces help tell what is happening in long source files with deep nesting. But also you could just render whitespace characters as something visible to count them to judge indentation at a glance to get your bearings. Of course the real answer here is don’t write long source files with deep nesting, but unfortunately other people are allowed to write code :p
I say that from experience: when I was first learning to program I found C much easier than python for this exact reason, and I was not using syntax highlighting.
That might be because I was much more prone to nesting back then. These days I get annoyed when I have two levels of indentation inside a function and treat three as a reminder to refactor. But when I started programming I'd build pyramids 8-10 levels deep and argued with people who tried to help simplify it.
this is interesting, both because I've had a somewhat similar experience (my code is now much less indented than it was 10 years ago), and also because it does seem to hold some explanatory power for why some people seem to react so violently to Python's semantic whitespace.
I hear the argument quite frequently that semantic whitespace makes it hard to move code around (or that it causes code to get messed up in various ways) and I keep wondering why that doesn't describe my own experience as a daily user of Python. Maybe a lot of it is that I tend to avoid more than a couple of levels of indentation like the plague, and therefore it's rare for there to be any confusion about where a particular line of code would "belong".
Maybe they are using some arcane programming tool from the 80s...
'{}' has the advantage that it expresses structure in a single line - copy a block of code from one place to another and your editor can throw it almost anywhere and the structure is preserved...
Modern day text editors all preserve indent wonderfully and can indent/outdent as a matter of course...but to some troll insisting on using ed or notepad or Microsoft Word I can see the difficulty.
This meaningful whitespace thing in python is dreck. Hate it. I am not a python hater; this is from experience on projects (though this is now less of a problem because of IDE help). I like python and I choose it for my personal projects. I will probably use this.
"pwk" is both code and "executable" -- you can open it with any text editor. I didn't want to name it "pwk.py" to save on typing on the command line.
--m
It's sort of just pedantry because I know what you mean, but FYI it is an executable when you mark it (chmod +x) as such; what you mean to say is that you assumed it was a binary, the output of a compiler, with the input (source) not provided.
