This probably makes me sound like an old man, but probably the biggest thing keeping my interest in Python too low to really learn it was the syntax. I really like the c-like syntax of many languages, and Python’s use of significant whitespace instead of braces just seemed too foreign to me.
That said, even if it gives me the syntactic sugar I crave I don’t know how much I’d be willing to trust a little-used language that compiles to something more common, because I’d worry about how its maintenance goes.
If the software goes unmaintained, would the syntax of Python outgrow it and break it? Maybe new features wouldn’t be usable? So while that syntactic sugar is indeed tasty, I don’t think this is what I need to get going in Python.
Just stupid serial protocols to talk between devices. Often you have problems with picking commands and responses out of noise and or garbage. Think half duplex RS485. Protocols that use one token for delineating messages have poor error recovery/synchronization. I think pythons grammar is rather poor as a result. Other languages are far better. It's important because it effects tooling because tooling often has to deal with broken input.
Eh, I wouldn't assign that too much importance. Most C/C++ tooling practically gives up on a missing closing brace and almost never gives the right error message.
C and vastly more so C++ have a lot of other problems. C compilers can give the right error message 95% of the. But They have an excuse since they are older languages. Python was developed in an era when people knew better.
Java and C# are examples of well designed grammars. Tooling was a first class requirement for C# and it shows. Where python will never have great tooling.
haha yes I wish emacs could do that too but the thought of a redundant pass in every block would probably bother me more than the lack of auto-outdent.
That colon that starts every indented block is like an unmatched opening brace though.
I thought Pascal was weird, but that's because I learned BASIC first. I thought C was weird but that's because I learned Pascal before.
There happen to be a handful of popular languages that are C-like in scope syntax, but it is important to get beyond the first thing you happened to learn. It is like only eating the cuisine from the country where you were born.
I learnt BASIC when I was young, and then (Borland Turbo)Pascal after that, and C family languages (including C and Java and such) after that. Then I learnt Python, and even wrote a lot of it at Uni and for various jobs -- enough that I'm pretty firm in my distaste for significant whitespace, and I don't believe it's because I started with C.
It may be popular, but it presents a number of challenges in Python and in other languages like YAML. If you're going to buck the C trend, at least make it somewhat ergonomic like Lua which I learnt recently and kind of like.
It’s funny both you and the GP comment followed the same exact steps as I did. I guess I technically learned Pascal with with Turbo Pascal and also with Delphi. But yeah it’s funny because Python is where I ended up. What I like about it is that it seems very pragmatic. There is no sloppiness in it but also no high dogma of how things ought to be if you want to be sure your program is correct. It lets you get stuff done and gets out of your way.
Me three, and I think the intented blocks were a masterstroke. Why do so many others have redundant braces or begin/end markers while still need to indent?
I started with x86 Asm and was exposed to C and Pascal at roughly the same time (as well as XPL0: https://en.wikipedia.org/wiki/XPL0 , which is described as a mix of the two but is really like "C with Pascal syntax"), and much prefer the brevity of the C syntax. I suspect that's the reason a lot of other languages also adopted it.
If you can’t get over the syntax differences I can’t imagine why you’d ever want to program in Python. You don’t need to force yourself to like or use Python in the same way some people just don’t want to eat fish, or choose to be vegetarian. It’s not for everyone. Why try to shove a square peg in a round hole?
Lots of great statistical and NLP libraries are written in Python. I'd actually argue Python is one of the few languages without a great alternative for certain niches right now.
Interop comes in many flavors. If I were to consider Julia a replacement for Python, I'd need to know that Julia can interop seamlessly with it, like Kotlin can with Java.
How do you feel about the user experience for Julia/Python interop?
I am the opposite. I love the whitespace significant syntax in Python. I indent my code in languages like C and Java anyway, so why bother with braces. Also, a missing brace takes a long time to find, because autoformatting tools go crazy and the error isn't usually quick to find by the compiler so it fails tens of lines below where the brace is actually missing.
Opposite. I can't stand languages that require programmer to do menial tasks such as add additional punctuation to indicate blocks that are clear from indentation. Or for end of line when there's a carriage return.
And that produce visual noise and based on many formatting standards enforce wasted vertical space (curly on its own line) being able to see more code on screen without scrolling.
I have to type that whutespace. Whitespace indentation and line breaks are the most significant visual elements. Why would the compiler ignore that?
Very nice. But with the linked project, although the braces are optional, when you do use them I'm presuming they're checked for correctness (i.e. they match the indentation level and are properly matched).
So would you in C if you do not redeclare the variable inside of the block. Also in JavaScript (although in JavaScript the type is not declared; in C it is). I don't know how it is working in Python, though.
It's not the curly braces that create the scope as such. It's the block, and the curly braces just happen to create the block. In C++ you can even do this, for example (I was surprised to find it doesn't work in C):
int i = 1;
if (true) int i = 2;
std::cout << i << '\n';
// Prints 1
In any case, the semanics of blocks (whether they create scopes) is totally orthogonal to the syntax of blocks. You can just as easily imagine the reverse: the current colon-indent syntax where blocks do create scopes.
Another issue, which other replies have alluded to but not quite spelt out. You'd need to add a syntax to distinguish between regular assignment and declaration. In C you can still choose to assign to the outer-scope variable from a nested scope of you wish, so you don't want i=1 in a nested scope to always declare a new variable that shadows a variable in the outer scope.
Oh and one more thing. Your snippet (or equivalent) won't work in all C-style braces languages: in C# it is a compilation error to shadow a variable from an outer scope in the same function (presumably because it's a common source of bugs and extremely easy to just choose a different name for one of the variables).
We might as well chuck away "def" for a function signature. When I started learning python way back, this particular aspect of Python was an eye-sore. Why wouldn't they use any one of these: func, function, fun, etc. or just like C, no need for a word. void foo(){} is already sufficient structure to indicate that its a function.
In the absence of a return type, and with an LL(1) parser, there needs to be a keyword to indicate the start of a function definition. `def` is a little unusual, but it's also used by Ruby.
I once designed a Python-like language and used `function`, because the language made a distinction between `function`s and `method`s.
That's too late. The parser needs to know whether it's looking at a definition or a call before that - for example, to know whether to parse "args" as a `parameters` or an `arglist` [0].
Here's a code snippet using SRFI 49, for Scheme. (A 2003 formalisation for a macro system that had been rocking around for a few decades, for a very old Lisp):
define
fac x
if
= x 0
1
* x
fac
- x 1
Python's keywords are sometimes shorter, but they are familiar to most Lispers, which some of the founders were.
I can imagine preferring Python syntax. I can't much imagine wanting Python slowness, which is inherent to the language semantics. People can disagree about syntax, but who wants slowness?
Converting is probably just a matter of a Makefile rule that would turn the code into standard C. It's just another code generator, like lex or yacc.
Is the word "pass" still needed? It should look for empty braces and add "pass" automatically in that case, I should think, isn't it? (Doesn't "pass" just means doing nothing?)
Regarding indentation versus braces:
In the beginning, I always thought python's only weakness is that it relies on indentation for code structure and I feared that some day my code will be messed up because of that. However that fear quickly disappeared as soon as I got my editors set up correctly... and the mess up never happened.
This is fantastic - I have always loved C-style syntax. The braces and indentations make code easy to read. I am always scared of Python's 2/4 space requirements - hard when you wear thick eyeglasses :)
More like “python, but rah (bad),” from where I’m standing.
I’m surprised that there’s anyone who prefers brackets to indentation, unless the joke is going over my head. It’s much easier to spot an incorrectly indented segment than see that there are 3 closing brackets in one spot and 2 in another instead of 2 and 3 as it should be
reply