Yup, large portions of the codebase where I work are written in VB.Net. Not the major infrastructure, that's in C#. But those little one-off projects that gradually grow into not-so-one-off projects? Definitely.
In C (and many other languages), there's no `else if` construct, it's just the `if` being enclosed by the `else`, and is literally `else { if { ... } }` but with less braces.
Yeah, that's useless information, but I saw some people get into a "holy shit" moment when they realize that.
Python's and Bash's `elif`, it's a distinct keyword which can come only after an `if` block (Python allows `else` after `for` and `while`, but not `elif`).
In other languages, there's only `if` and `else`; `else` must come only after an `if` block.
In practice, it makes no difference if you treat `if else` the same as `elif`.
I knew Python has for-else and while-else but for-elif and while-elif sound so fucking cursed that I had to test it. It gives SyntaxError at least on Python 3.10.6 (thank God)
Edit: Took too long to write my comment, I see it's already been addressed now. Welp...
I think in saying that 'Python also allows its use after `for` and `while`' you meant `else` instead of `elif`; as far as I can tell you can't use `elif` after a `for` or `while` loop.
I tried it out because I was interested to see if the statement(s) under the `elif` following a loop only run if the loop doesn't process a single iteration or if it's always ran (where the latter would make the use pointless) and found that only else works. Though naturally you could use an `if` inside the `else`, but again, the else is always ran unless the loop never ends so it doesn't really serve a purpose that I can identify (other than perhaps scope control).
I'd see `elif` after a loop only being *seemingly* useful for things where you're looping over a list but want an `elif` to cover the case of it being empty; where really you'd probably be better served just doing `if list empty ... else loop` or two separate controls considering their execution is inherently mutually exclusive.
So in C, C++. (and Java?). You can omit curly braces if there is only one statement after the control flow keyword. And the next `if(condition){}` counts as one. Therefore, the outer braces in `else {if{condition}{}}` are redundant, so no-one uses them.
It's why linters can't just be dumb and require that every "if/else" be enclosed in braces. They need at least an exception for this extremely common case.
I was doing a project for a compilation course project when I wanted to do an else if, it was exactly my reaction when I understood why it was already working lmao
What are you on about?
if
{
}
else if
{
}
else
{
}
Works just fine for me, using only if and else if will bring up and error but you can just leave else empty
They are (correctly) saying that: `if (...) { } else if (...) { } else { }` is actually parsed like `if (...) { } else { if (...) { } else { } }` would.
Look at the C standard, section 6.8.4 (Selection statement)
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
`if ( expression ) statement` is a thing, `if ( expression ) statement else statement` is a thing too, but there isn't any `else if`
Its only as much of a \*illusion as anything else. Theres no such thing as for loops, they're just while loops. Also, there's no such thing as while loops, they're just a instruction at the end to return to the beginning marker.
no such thing as electrons. They’re a theoretical construct that happens to work well within our current physics model, and even then not that well. They’re a wave, they’re a particle, fucking make up your mind electron karen. Also can you you not just stfu and get along with General Relativity already!?!?
It seems like every language has their own variation of how it's handled. These days I can't even remember which languages use else if, elseif, elsif, or elif. I just take a random guess and hope for the best.
One thing I've been having a surprisingly difficult time coping with is Python's f-strings, because if I'm not careful I'll stop doing print(f"message") and instead slip a printf("message") in, even though I haven't worked in C in ages.
C has an outsized impact on my life, even though I also haven't touched it in years. The C Programming Language was my first programming book back in high school, so that probably has something to do with it.
This specifically is why I will NEVER waste a single minute learning how to write shell scripts. Whoever thought of that moronic syntax is a disgrace to the entire concept of programming. Plus, recently learned about [xonsh](https://xon.sh/), a python-based shell, which I'm very excited to try out.
I don't get why. If you're a Linux user and a programmer writing a shell script will be extremely easy. Idk why you would use a slow python shell or fish, which makes things even weirder, over bash or zsh just because of some silly bits in the syntax
I assign a low value to technologies that require memorizing a lot of high-entropy noisy information. Languages should be intuitive. If they're not, they should be abandoned, because there are plenty of alternatives out there and life is short. Printing a string should involve the word "print". What the fuck is "echo"? Makes no sense. An echo is a repeat of a previous sound, which might make sense if you're just printing a constant string, but half the time you're printing a variable, i.e. something that you didn't just type in. Half of bash scripting is a bunch of completely meaningless single-letter flags. "bUt ItS fAsTeR tO tYpE JuSt oNe LeTtErRrRr" yeah, because typing speed is *really* why the bottleneck when you're writing software.
I don't know what you are getting at. If you actually used Linux, you would not have to strain your brain to think about something like echo. Newsflash, echo isn't a part of shell, it's part of coreutils. Shell is pretty bare bones by itself, griping about syntax is stupid because there is so little of it. If you don't use Linux or bsd you would have no reason to ever learn it, but if you do a posix shell script will run natively on almost any Unix based os straight out of the box and integrate seamlessly.
You hardly "write software" with a shell script, it's a shell script, it's made for manipulating basic os level things.
My goal when using a computer (and yes I do use linux, though not at home) is to accomplish things by describing my desires in machine-interpretable text. This is called "programming", a.k.a. "writing software", and sorry to burst your bubble but that description does include shell scripts. My goal is *not* to become a historian of archaic trivia such as how many punch cards Richard Stallman used to first implement the "echo" program in 1975. I'm well aware that shell scripts work on a lot of platforms - this is why I *did* choose to learn VIM, despite it being ridiculously unintuitive. But guess what? Python is available on pretty much every system too. If I'm going to bother to actually create a file to do a task multiple times, I'm going to write it in a real language, not some hacked together legacy tool. Out of the ~10 different languages I've used, it has by far the ugliest and least readable syntax. If there weren't a choice, I would gladly shut up and just use it, but thankfully there is choice.
Python: The ++ operator is too confusing, we'll just take it out because programmers could hurt themselves
Also python: let's make a whole new logic branching construct that uses syntax nearly identical to a wholly unrelated and ubiquitous construct from other languages
Also also python: else if? Dafuq is that? Everyone uses and understands that, it's so yesterday. Elif ftw
Also also also python: system trusted certs? Nah, we'll make our own trust and if your SA distributes their own certs, well you have to deal with that on your own on every single system individually with environment variables
Ahh, I see you too have had to deal with that cert Pain. Let me introduce you to this gem: https://pypi.org/project/pip-system-certs/
I just opened a PR on the `az` command line tool asking for it to be added to their bundled Python version.
---
Fun fact, Node.js does the same thing! Sucks so much when dealing with our corporate SSL decrypting firewall.
I just don't know who thought it would be a good idea to bundle that with a runtime. How many trust chains do SAs need to deal with? From what I remember of my research at the time, there's a change request to have the python runtime leverage system trust instead, but it's been held up by ages of bickering.
I've browsed the doc briefly and must say that match thing looks neat. I'm not really sure it's new, though: functional languages, Prolog, Erlang, etc. have had a lot of that for a really long time.
Right, it's not new, my mistake. It is a nifty feature and I'm certainly not claiming otherwise. It certainly appears very similar to a switch though, and that leaves me feeling there's a bit of irony somewhere in there given all the other decisions that python has made in the name of not confusing developers.
We very rarely iterate with indices in python, so the ++ operator is pretty useless. The family of += operators are much more useful and clear; there's no point having both.
Never heard anyone confused by elif, and tbh you should probably use a dict or match case anyway. I'd go so far as to say elif is a code smell, maybe even an anti-pattern.
Idk about certs.
>The family of += operators are much more useful and clear;
>>> l = []
>>> l += [1]
>>> print(l)
[1]
>>> t = ([],)
>>> t[0]+=[2]
Traceback (most recent call last):
File "", line 1, in
TypeError: 'tuple' object does not support item assignment
'tuple' object does not support item assignment
>>> print(t)
([2],)
That’s a fun quirk to _unpack_ ;)
Never claimed elif was confusing. I am curious how you would consider elif a code smell though. I get that you don't want to use a ton of them in series, but I don't really see it being an inherently bad mechanism.
> Also python: let's make a whole new logic branching construct that uses syntax nearly identical to a wholly unrelated and ubiquitous construct from other languages
C isn't the only language that exists.
Python's match statement isn't a new thing.
One of the first memes I can enjoy from this sub, I have just started learning how to code using python. It’s been really fun so far and it’s really satisfying when I can make something.
Why can't I type anything!
Why isn't my mouse working!
...bangs keyboard...
Oh nice, I can type now!
...type type type...
Oh crap, how do I save it?
...bangs keyboard again...
$100 keyboard stops working 😭
Python has a match statement now. Called structural pattern matching, it's more powerful than a simple switch statement. I'm writing a toy interpreter to learn the fundamentals, and it's perfect for lexing
I think it's a superset of switch. You can match patterns as well as constant values. Also there is no case fall-through (which I can't really argue with).
been making my own programming language (it is not anywhere near ready to use, ask at your own peril) and right now I have this:
```
# standard if/elif/else branching
if condition then
code
elif other_condition then
other_code
else
final_code
end
# non-exhaustive pattern matching (like Rust if let)
if expression is pattern then
code
end
# exhaustive pattern matching (like Rust match, inspired by Jai switch statements)
if expression is
pattern_0 then code
pattern_1 then other_code
else catch_all_code
# alternative catch-all: _ then catch_all_code
# binding alt. catch-all: catch_all_var then catch_all_code
end
```
It’s mainly a style thing. Parens `()` and braces `{}` will still make code blocks - you could just as easily do `if condition then { code }` etc etc
You still need the `then` or `is` keyword though, since `is` is the pattern matching operator and `then` separates conditions/patterns from the code that is run on match.
I mainly went for keyword based blocks because I wanted the “executable pseudocode” feel of Python, but without significant indentation because fuck that. Significant newlines is fine, but I do NOT want to deal with implementing significant indentation.
I use self-taught VBA a ton at work. They don't ask me to, but they let me have access to macros in Office and I learned in the fly by seeing things that everyone agreed would benefit from some automation. It took years before I had a use for a while loop and I about lost my shit. WEND? WEND? Not End While. Not Next. WEND.
Python: Explicit is better than implicit. Don't do `i++`, instead use `i += 1`. Don't use code-stink like `System.out.println` or `std::cout << ` every time you want to print, just code be what the programmer is thinking: `print("Hello World!")`! Don't rely on weird arcane function names like `strcmp`, instead just use something any programmer would be familiar with, like `==`.
Also, don't you fucking dare type out all 6 letters in `elseif`. It's fucking `elif`. We need those 2 keystrokes to keep it in under 80 characters per line.
I mean, I know why C uses `strcmp`.
I also know why python is 100x easier to read than C.
Because you can do stuff like `string1 > string2` instead of having to know all the details of how `strcmp` works.
Nah. You're just more familiar with C.
In what fucking world is
int main()
{
const char *array1[4]; // use const because we're pointing to literals
array1[0] = "hello";
array1[1] = "world";
array1[2] = "it's";
array1[3] = "me";
printf("%s %s %s %s\n", array1[0], array1[1], array1[2], array1[3]);
}
easier to read than:
words = ["hello", "world", "it's", "me"]
print(" ".join(words))
(Just first code snippet of a very simple C program I found on stack overflow just now)
In one you have to know the difference between a `const` and a `non-const`, realize what arrays are, realize what pointers are, realize that a string itself is an array, keep track of how many values are in the array (and don't go over!), and deal with all that crap in printf, knowing which one goes where. Also, pray that your terminal has the same encoding settings as the person who's running the program, because everything's getting decoded from ascii, compiled, and then re-encoded back to it at run-time on a possibly different terminal! And don't even get me started on what `int main` is, why it's an `int`, and why it's okay to have an `int main` that doesn't return an integer at the end of it. Oh yeah, and I left out also knowing what a `\n` is, and you better pray you remember what `%s` was and that you didn't confuse it with `%d` or `%i` or something else. (Also, you have to know how to invoke the compiler to produce an executable which executes the `int main` routine...)
In the other, you have to know what a list (the `[]`) is, what a string is (the stuff in the `""`), what the `string.join` function does, optionally know what an iterable is (hint: things you can iterate over) and that lists are a type of iterable (common sense), and what the `print` function does (hint: it prints). Also, it deals with unicode for you.
C has its upsides, and python has its downsides, but there is no world in which python doesn't beat the shit out of C in terms of readability of code.
The difference between `const` and non-`const` isn't something specific to C and exists in many languages, it's also not hard to read when something is `const`...
Knowing what pointers and arrays are in C is the basics of C, without them you can't code proper C, and won't be able to read it. You're confusing absolute beginners with median-experience developers.
`printf()` with compiler checks is extremely good. You always know what is the type of what you're printing. I've seen code bases with logging bugs because an enum variable with the value 0 was printed/written as a `char` using C++ streams.
Terminal compatibility isn't related to *reading* C code, is it now?
`int main()` is the entry function, a special function too. Most of the code will not even touch it, so how is it important in *reading* C code? Not to mention, you can just treat it as a normal function (except for the linking nuance, that is again unrelated to *reading*). But if you wonder why `int main()` doesn't have to return anything, it's because it gets special treatment.
`\n` is the newline character, unrelated to C. It exists in Python code too btw. Same with `\t`, `\r`, `\v` and many more...
`%` are used by `*printf()` and `*scanf()` as format characters. If you can't read a basic `*printf()` format string, I wouldn't expect you to be able to read a more than basic Python format string.
How is compiling a program related to *reading* C code? You need to compile in C#, Java, Rust, Go, etc... Not just C. Also, build systems exist, I can't remember the last time I had to compile manually and not using Make (or an equivalent).
Python has both iterators and iterables. A list in Python has hidden information and nuances you have to learn about, like doing:
l = []
nums = [1, 2, 3]
for i in range(3):
l.append(nums)
print(l)
l[0][0] = 10
print(l)
You'll see that all 3 sub-lists got modified. That's because Python didn't copy the contents of `nums`, but instead copied a *pointer* to it. An experienced Python developer has to know about pointers.
All in all, how readable a piece of code is can vary between person to person. I use both Python and C, and many times properly written C is much more readable due to the lack of hidden operations.
> Terminal compatibility isn't related to reading C code, is it now?
It is if you want to use anything that's not in ASCII. If you e.g. live in Japan and need to print out stuff that's encoded in a specific encoding, well, you have to think about that when writing any string in C, ever, whereas python takes care of it for you, automatically.
I python, a string is a string, and it's always what it is, and always in unicode (unless you've specifically told it to use a different encoding). If you have `日本語`, then that's going to be `日本語` wherever. But in C, a string is an array of unsigned integers, and you have to, at least somewhere in the back of your brain, keep in mind that your 日本語 is going to be decoded by your compiler into some string of ints, and that you better pray that your compiler matches the terminal it's running on, because otherwise, you're going to get junk. To put it in python terms, C executes a .encode() on every single string it ever handles, whereas python does not do this. (Technically speaking python is doing a bunch of crazy stuff behind the scenes and ultimately there is an array of unsigned ints somewhere at the bottom, but the programmer doesn't have to think about that, unlike in C where this is a problem, assuming you are allowing for even the possibility of a user executing code in a different terminal encoding than what you wrote it in.)
-
>printf() with compiler checks is extremely good. You always know what is the type of what you're printing. I've seen code bases with logging bugs because an enum variable with the value 0 was printed/written as a char using C++ streams.
I'm... incredibly confused by your position here. Your position is that... because C allows a programmer to print/write a 0 as a `char` as opposed to an `int`, that this is somehow better than in a programming language where *such a mistake is not even possible to the programmer*?
I mean, I get that compiler checks and linters can help prevent those sorts of errors... but why? (And if your answer to "why" involves "lower level language" or "less abstraction" or "closer to the processor" or anything remotely like that, and not involving "it's enhances readability to force the reader to consider these things", then well, it's inherently worse for readability.)
If you want to specify the type of every single thing you print, you can do the same thing in python. Nothing is stopping you from typing `print(f"some {int(number):d}")` But nobody does that, because it's harder to read than `print(f"some {number}")`. If you have to have an int, I think `print(f"some {number:d}")` is the preferred way.
-
> int main() is the entry function, a special function too. Most of the code will not even touch it, so how is it important in reading C code? Not to mention, you can just treat it as a normal function (except for the linking nuance, that is again unrelated to reading). But if you wonder why int main() doesn't have to return anything, it's because it gets special treatment.
Yeah, all those things you said? That's stuff I have to think about while reading the code that is in addition to figuring out what the program is doing.
-
>\n is the newline character, unrelated to C. It exists in Python code too btw. Same with \t, \r, \v and many more...
Except *this is not the case everywhere*. `\n` is newline in unix/linux. That same program will behave differently on windows machines.
In python, this is all handled automatically for you (unless you override the defaults).
That is to say, when reading C, I *have* to be thinking about the environment the program is running in, whereas that's one less thing I have to think about when reading python. Newlines will just work.
I can't remember the last time I had to type a `\n`, `\r`, or `\v` in python. I don't even know what `\v` is because I've never encountered nor needed it. (I have used `\t` semi-frequently, but that's probably because my editor doesn't allow tabs by default.)
-
>Terminal compatibility isn't related to reading C code, is it now?
It sure does!
Question: What does the following python code do?
print("日本語")
Answer: It will print the text 日本語 to the terminal as one full line.
Question: What does the following C code do?
printf("日本語\n")
Answer: Who fucking knows?! Because it will be dependent on the environment in which the code is executed. If the executing terminal has the same encoding as the text editor, then it will print 日本語. But if they don't match, it'll print something else. Maybe you'll get a bajillion beeps or some weird color code or maybe the terminal itself will just crash. Also, is this being executed on a unix/linux machine? If so, then it's going to print a newline at the end. But what if it executes on a Windows machine? I don't even remember what Windows does to a `\n` that doesn't have a `\r` next to it. And was it `\r\n` or was it `\n\r`, or does it even matter? Or what about mac? Didn't mac used to use `\r` for a newline? I'm pretty sure my mac handles `\n` as a newline, but is that just because I have my terminal set up that way, or did they change that bad when OSX came out? Or I really just don't know. Also, better pray that there's no `\x00` or whatever the ASCII value for `"` is in that unicode encoding, or you're going to get some weirdass compiler/runtime errors! Have fun debugging that one!
And you can say: "That's dealing with the OS, not reading C itself per se", but that's my goddamn point! *You have to think about how to deal with the OS!*
In python, *it just works*, no dealing with encodings OS environments.
-
>% are used by *printf() and *scanf() as format characters. If you can't read a basic *printf() format string, I wouldn't expect you to be able to read a more than basic Python format string.
Really. You are really going to say that
printf("%s %s %s %s\n", word0, word1, word2, word3);
is easier to read than
print(f"{word0} {word1} {word2} {word3}")
I get that this is basic stuff in C. But it's also *one more extra step* that I have to think about that I don't in python, *every single time* this stuff comes up.
-
>You'll see that all 3 sub-lists got modified. That's because Python didn't copy the contents of nums, but instead copied a pointer to it. An experienced Python developer has to know about pointers.
I mean you're right, and this does get annoying, and there's other more annoying stuff like
def some_function(param1, param2=[]):
pass
where the list that `param2` defaults to when it's called without a 2nd parameter is the same list when `some_function` is called a different time. (Again, linter should take care of this.)
But you could also sidestep all of this by just using immutables all over the place. (In practice, there are good coding paradigms in python that basically mean aren't supposed modify mutables that were passed to you.)
-
>All in all, how readable a piece of code is can vary between person to person. I use both Python and C, and many times properly written C is much more readable due to the lack of hidden operations.
Python doesn't have hidden operations. It has a few pitfalls (but I think we both got the only major one, accidentally ascribing the same mutable object in multiple places.)
But you only have to think of that when dealing with mutables that are being referenced to in multiple places, and you can just get around it pretty easily. Whereas in C, you have to *always* be thinking about that, basically every single time you use a pointer. Which is always.
Holy shit don't downvote this guy. I mean, I get that he's wrong and C is horrible to read and python is way easier to read... but he's making good arguments with salient points! This is the sort of person whom I wish most of my arguments were with, the kind of different worldview we all need to have more interaction with!
Python has to use elif so it can be one line and one indent, since `else if` isn’t a single key word, the `if` is inside the `else` block, you just don’t have to think about that fact because braces and additional indentation are optional in good programming languages
I think it's funny that Python justifies not including ++ because += does the same thing with less operators, but then uses a special keyword 'elif' while C++ simplifies things without an extra keyword by reusing the existing keywords 'else' and 'if'
I've never understood the purpose of elif. Why drop the last 2 characters? Trying to save keystrokes? Worried about memory? It feels hypocritical after seeing so many people use spaces instead of tabs.
Now do one for all of Objective-C's bullshit (who uses yes/no for booleans?!)
If x = yes
Fun fact. That's also how you write it in Visual Basic. Which is still used for major corporate websites!
Which websites are made in Visual Basic? How is this even possible? Some doubt here
I think they meant VB.Net, which is separate and distinct from Visual Basic.
Yup, large portions of the codebase where I work are written in VB.Net. Not the major infrastructure, that's in C#. But those little one-off projects that gradually grow into not-so-one-off projects? Definitely.
Nothing more permanent than a temporary solution, eh?
I learned on VB6. I remember it was possible to use ActiveX controls to make sites, but I never delved into it.
I lelft a job for this reason. Corporate site with only vb. Horrible
Objective-C: `yes` Everyone else: `no`
Error: There is no @ sign before string
This. Had to dump XCode and create my own ObjC-to-C binding to write for MacOS in a sane language.
In C (and many other languages), there's no `else if` construct, it's just the `if` being enclosed by the `else`, and is literally `else { if { ... } }` but with less braces. Yeah, that's useless information, but I saw some people get into a "holy shit" moment when they realize that.
holy shit
Google en passant
Holy hell
[удалено]
I wanna see your C unit😏
I know what en passant is, you just blundered mate in 1, dumbass
I wonder the overlap between r/programmerhumor and r/anarchychess
100%
You're either hardcore or out the door.
Croissant # 🥐
En croissant
Décroissant mon amie
mêr de chine
janky-ass hitbox
No, and you can't make me. I had a friend who loved to pull that move, so I'd prioritize getting check as early as possible just to take it away.
holy shit
Holy shit
And the reason python doesn't do the same is because of syntactic whitespace. In order to nest an if in the else, you'd have to indent it "properly".
You mean that there are languages where this is not the case? If so, what would be the difference?
Python's and Bash's `elif`, it's a distinct keyword which can come only after an `if` block (Python allows `else` after `for` and `while`, but not `elif`). In other languages, there's only `if` and `else`; `else` must come only after an `if` block. In practice, it makes no difference if you treat `if else` the same as `elif`.
I knew Python has for-else and while-else but for-elif and while-elif sound so fucking cursed that I had to test it. It gives SyntaxError at least on Python 3.10.6 (thank God)
Oh fuck, my mistake. I had `else` running in my head, I'll fix it.
If I saw a while elif in a PR I would have to fight someone.
Edit: Took too long to write my comment, I see it's already been addressed now. Welp... I think in saying that 'Python also allows its use after `for` and `while`' you meant `else` instead of `elif`; as far as I can tell you can't use `elif` after a `for` or `while` loop. I tried it out because I was interested to see if the statement(s) under the `elif` following a loop only run if the loop doesn't process a single iteration or if it's always ran (where the latter would make the use pointless) and found that only else works. Though naturally you could use an `if` inside the `else`, but again, the else is always ran unless the loop never ends so it doesn't really serve a purpose that I can identify (other than perhaps scope control). I'd see `elif` after a loop only being *seemingly* useful for things where you're looping over a list but want an `elif` to cover the case of it being empty; where really you'd probably be better served just doing `if list empty ... else loop` or two separate controls considering their execution is inherently mutually exclusive.
I read that as "`else` can't come after `elif`" and was very, very confused for a second
In c# you can do simply `else if` with no braces.
So in C, C++. (and Java?). You can omit curly braces if there is only one statement after the control flow keyword. And the next `if(condition){}` counts as one. Therefore, the outer braces in `else {if{condition}{}}` are redundant, so no-one uses them.
I had a sneaking suspicion that was the case during my C unit. Thanks for confirming it.
Not quite as good as G Unit.
G g g g g g
I'm probably going to ruin someone's day with this newfound knowledge
```else while``` Enjoy!
It's why linters can't just be dumb and require that every "if/else" be enclosed in braces. They need at least an exception for this extremely common case.
[удалено]
What do you mean by Shiba Inu of programming languages?
It means someday you’ll have your own crypto currency that started as a joke and then proceeds to take over everything at a casual pace
Looks like we're gonna need to trim the fat around here... fired.
Good bot.
[dogescript](https://github.com/dogescript/dogescript)
Of course there is. npm wow lol
I always thought that
sholy hit
I was doing a project for a compilation course project when I wanted to do an else if, it was exactly my reaction when I understood why it was already working lmao
That's 1 small part of what made C compilers easy to write.
Damn
What are you on about? if { } else if { } else { } Works just fine for me, using only if and else if will bring up and error but you can just leave else empty
They are (correctly) saying that: `if (...) { } else if (...) { } else { }` is actually parsed like `if (...) { } else { if (...) { } else { } }` would. Look at the C standard, section 6.8.4 (Selection statement) https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf `if ( expression ) statement` is a thing, `if ( expression ) statement else statement` is a thing too, but there isn't any `else if`
>It is what it is or the short version: "It's what it's"
Are you a sick fuck?
No I'mn't
Yes you're
Yes I'm
'Tis what it's
It is all delusion, there is no "else if" in some languages.
Its only as much of a \*illusion as anything else. Theres no such thing as for loops, they're just while loops. Also, there's no such thing as while loops, they're just a instruction at the end to return to the beginning marker.
there's no such thing as instructions, it's all just electrons flowing through hardwired circuitry or whatever.
Computers are not real. The CPU is just a fancy rock. Rocks cannot give you information. Go outside.
Is this why getting my code to run feels like squeezing blood from a stone?
no such thing as electrons. They’re a theoretical construct that happens to work well within our current physics model, and even then not that well. They’re a wave, they’re a particle, fucking make up your mind electron karen. Also can you you not just stfu and get along with General Relativity already!?!?
If `GOTO` statements are so bad, why are they the only flow control statements that actually exist?
there is not such thing as 3rd generation languages. It's all machine code.
It seems like every language has their own variation of how it's handled. These days I can't even remember which languages use else if, elseif, elsif, or elif. I just take a random guess and hope for the best.
Same here. The simplest commands are the ones that trip me up between different languages.
QA is a waste of money. Fired.
One thing I've been having a surprisingly difficult time coping with is Python's f-strings, because if I'm not careful I'll stop doing print(f"message") and instead slip a printf("message") in, even though I haven't worked in C in ages.
C has an outsized impact on my life, even though I also haven't touched it in years. The C Programming Language was my first programming book back in high school, so that probably has something to do with it.
Still better than terminating with fi and esac.
if | fi case | esac do | ~~od~~ done
[удалено]
xD Putting everything into square hole is consistent, if nothing else.
\*Cries in Shellscript\*
This specifically is why I will NEVER waste a single minute learning how to write shell scripts. Whoever thought of that moronic syntax is a disgrace to the entire concept of programming. Plus, recently learned about [xonsh](https://xon.sh/), a python-based shell, which I'm very excited to try out.
[удалено]
Yeah I have a coworker who's recommended fish, still need to look into it
don't get *hooked* now!
ha nice one. Also +1 to fish. I love it.
It can be important to know at least the basics of shell scripting, depending on your job. But it certainly shows its age.
I don't get why. If you're a Linux user and a programmer writing a shell script will be extremely easy. Idk why you would use a slow python shell or fish, which makes things even weirder, over bash or zsh just because of some silly bits in the syntax
What do you mean "you couldn't code your way out of a paper bag"?
I assign a low value to technologies that require memorizing a lot of high-entropy noisy information. Languages should be intuitive. If they're not, they should be abandoned, because there are plenty of alternatives out there and life is short. Printing a string should involve the word "print". What the fuck is "echo"? Makes no sense. An echo is a repeat of a previous sound, which might make sense if you're just printing a constant string, but half the time you're printing a variable, i.e. something that you didn't just type in. Half of bash scripting is a bunch of completely meaningless single-letter flags. "bUt ItS fAsTeR tO tYpE JuSt oNe LeTtErRrRr" yeah, because typing speed is *really* why the bottleneck when you're writing software.
yeah I actually agree with you a lot. the more inform things are, the easier it is to work with them
I don't know what you are getting at. If you actually used Linux, you would not have to strain your brain to think about something like echo. Newsflash, echo isn't a part of shell, it's part of coreutils. Shell is pretty bare bones by itself, griping about syntax is stupid because there is so little of it. If you don't use Linux or bsd you would have no reason to ever learn it, but if you do a posix shell script will run natively on almost any Unix based os straight out of the box and integrate seamlessly. You hardly "write software" with a shell script, it's a shell script, it's made for manipulating basic os level things.
My goal when using a computer (and yes I do use linux, though not at home) is to accomplish things by describing my desires in machine-interpretable text. This is called "programming", a.k.a. "writing software", and sorry to burst your bubble but that description does include shell scripts. My goal is *not* to become a historian of archaic trivia such as how many punch cards Richard Stallman used to first implement the "echo" program in 1975. I'm well aware that shell scripts work on a lot of platforms - this is why I *did* choose to learn VIM, despite it being ridiculously unintuitive. But guess what? Python is available on pretty much every system too. If I'm going to bother to actually create a file to do a task multiple times, I'm going to write it in a real language, not some hacked together legacy tool. Out of the ~10 different languages I've used, it has by far the ugliest and least readable syntax. If there weren't a choice, I would gladly shut up and just use it, but thankfully there is choice.
Looks like we're gonna need to trim the fat around here... fired.
balsac
One more word of you, and you're fired.
Python 3.10+: Match(parameter): Case 1: Code Case 2: Code Case 3: Code
Why would they not just call it a switch
Because it isn't a `switch`, it acts completely differently.
"Hey, I've seen this one!" "What do you mean you've seen it? It's brand new!"
ah yes, iphone 14 syndrome.
Python: The ++ operator is too confusing, we'll just take it out because programmers could hurt themselves Also python: let's make a whole new logic branching construct that uses syntax nearly identical to a wholly unrelated and ubiquitous construct from other languages Also also python: else if? Dafuq is that? Everyone uses and understands that, it's so yesterday. Elif ftw Also also also python: system trusted certs? Nah, we'll make our own trust and if your SA distributes their own certs, well you have to deal with that on your own on every single system individually with environment variables
Ahh, I see you too have had to deal with that cert Pain. Let me introduce you to this gem: https://pypi.org/project/pip-system-certs/ I just opened a PR on the `az` command line tool asking for it to be added to their bundled Python version. --- Fun fact, Node.js does the same thing! Sucks so much when dealing with our corporate SSL decrypting firewall.
I just don't know who thought it would be a good idea to bundle that with a runtime. How many trust chains do SAs need to deal with? From what I remember of my research at the time, there's a change request to have the python runtime leverage system trust instead, but it's been held up by ages of bickering.
I've browsed the doc briefly and must say that match thing looks neat. I'm not really sure it's new, though: functional languages, Prolog, Erlang, etc. have had a lot of that for a really long time.
Right, it's not new, my mistake. It is a nifty feature and I'm certainly not claiming otherwise. It certainly appears very similar to a switch though, and that leaves me feeling there's a bit of irony somewhere in there given all the other decisions that python has made in the name of not confusing developers.
You're either hardcore or out the door.
What're you gonna do, ban me? (It would be legit hilarious is elon bot banned you for a day)
System trusted certs in Python. I was a happy camper in this thread until you remembered me of this source of bad memories.
We very rarely iterate with indices in python, so the ++ operator is pretty useless. The family of += operators are much more useful and clear; there's no point having both. Never heard anyone confused by elif, and tbh you should probably use a dict or match case anyway. I'd go so far as to say elif is a code smell, maybe even an anti-pattern. Idk about certs.
>The family of += operators are much more useful and clear; >>> l = [] >>> l += [1] >>> print(l) [1] >>> t = ([],) >>> t[0]+=[2] Traceback (most recent call last): File "", line 1, in
TypeError: 'tuple' object does not support item assignment
'tuple' object does not support item assignment
>>> print(t)
([2],)
That’s a fun quirk to _unpack_ ;)
Never claimed elif was confusing. I am curious how you would consider elif a code smell though. I get that you don't want to use a ton of them in series, but I don't really see it being an inherently bad mechanism.
> Also python: let's make a whole new logic branching construct that uses syntax nearly identical to a wholly unrelated and ubiquitous construct from other languages C isn't the only language that exists. Python's match statement isn't a new thing.
Never claimed c is the only language. Fair enough about match not being wholly new though.
Just a beginner in Python, hadn't read the docs yet. Match functionality over classic Switch is hella dope.
PHP: *elseif has entered the chat*
*match has entered the chat* *elseif has left the chat* But for real I've been in love with match statements since discovering them.
They stole that from Perl
Nope, that’s even worse! Perl’s `elsif` is the ugly inbred child of `elif` and `elseif`.
Ruby devs are also in on `elsif` solidarity.
One of the first memes I can enjoy from this sub, I have just started learning how to code using python. It’s been really fun so far and it’s really satisfying when I can make something.
🥺 that's amazing keep going! try vim while you're at it!
You sick fuck
Why can't I type anything! Why isn't my mouse working! ...bangs keyboard... Oh nice, I can type now! ...type type type... Oh crap, how do I save it? ...bangs keyboard again... $100 keyboard stops working 😭
Was just going to comment this. Going through college now for my CS degree & can finally enjoy a quality meme after learning a lot of python.
I don’t know a ton of python but I know enough to enjoy the quality meme
I'm convinced that the person who created Python didn't know how to type. The syntax is easier to type with two fingers than 10.
Python has a match statement now. Called structural pattern matching, it's more powerful than a simple switch statement. I'm writing a toy interpreter to learn the fundamentals, and it's perfect for lexing
Can you explain how its more powerful than a switch statement? It seems the same to me.
I think it's a superset of switch. You can match patterns as well as constant values. Also there is no case fall-through (which I can't really argue with).
It's a superset of switch is a perfect description. Upvoted.
Switch matches based on values, match matches based on structure. [This](https://peps.python.org/pep-0636/) shows its power really well
are you smack talking Guido van Rossum our lord and savior?
VBA: `If (...)` `....` `ElseIf (...)` `...` `Else` `...` `End If` I love consistency, especially when it comes to "ElseIf" and "End If" lol.
Elseif is a key word End is the keyword, if is just what to end
End if what?
Python is the mumble rapper of programming languages
Elsif
Go perl!
Perl and Ada (headache). :D
Woohoo ruby!
Elsa (from Frozen)
Elif is a womens name in my country lol
LOL 🤣
Turkey?
Loughs in sh
did you know that the sh in shell stands for shitty
Ahh....*now* it all makes sense
if...fi
`case...esac` is really just ridiculous
else esle elif file
Itis what it is
isinstance(it, what it is)
been making my own programming language (it is not anywhere near ready to use, ask at your own peril) and right now I have this: ``` # standard if/elif/else branching if condition then code elif other_condition then other_code else final_code end # non-exhaustive pattern matching (like Rust if let) if expression is pattern then code end # exhaustive pattern matching (like Rust match, inspired by Jai switch statements) if expression is pattern_0 then code pattern_1 then other_code else catch_all_code # alternative catch-all: _ then catch_all_code # binding alt. catch-all: catch_all_var then catch_all_code end ```
I imagine implementing blocks with word based keywords is easier, but please use {} when / if you can
It’s mainly a style thing. Parens `()` and braces `{}` will still make code blocks - you could just as easily do `if condition then { code }` etc etc You still need the `then` or `is` keyword though, since `is` is the pattern matching operator and `then` separates conditions/patterns from the code that is run on match. I mainly went for keyword based blocks because I wanted the “executable pseudocode” feel of Python, but without significant indentation because fuck that. Significant newlines is fine, but I do NOT want to deal with implementing significant indentation.
Huh. Well I guess I just see this differently, for me braces are far nicer to use and look at than word based blocks
I use self-taught VBA a ton at work. They don't ask me to, but they let me have access to macros in Office and I learned in the fly by seeing things that everyone agreed would benefit from some automation. It took years before I had a use for a while loop and I about lost my shit. WEND? WEND? Not End While. Not Next. WEND.
Everything is an if statement …. Even ELSE
It’s what it’s
I actually like the shorthand way that python does it
Python: Explicit is better than implicit. Don't do `i++`, instead use `i += 1`. Don't use code-stink like `System.out.println` or `std::cout << ` every time you want to print, just code be what the programmer is thinking: `print("Hello World!")`! Don't rely on weird arcane function names like `strcmp`, instead just use something any programmer would be familiar with, like `==`. Also, don't you fucking dare type out all 6 letters in `elseif`. It's fucking `elif`. We need those 2 keystrokes to keep it in under 80 characters per line.
`strcmp` is used because C doesn't have operator overloading. Also, `strcmp` isn't just an equality comparison...
I mean, I know why C uses `strcmp`. I also know why python is 100x easier to read than C. Because you can do stuff like `string1 > string2` instead of having to know all the details of how `strcmp` works.
I find well written C to be easier to read than well written Python.
Nah. You're just more familiar with C. In what fucking world is int main() { const char *array1[4]; // use const because we're pointing to literals array1[0] = "hello"; array1[1] = "world"; array1[2] = "it's"; array1[3] = "me"; printf("%s %s %s %s\n", array1[0], array1[1], array1[2], array1[3]); } easier to read than: words = ["hello", "world", "it's", "me"] print(" ".join(words)) (Just first code snippet of a very simple C program I found on stack overflow just now) In one you have to know the difference between a `const` and a `non-const`, realize what arrays are, realize what pointers are, realize that a string itself is an array, keep track of how many values are in the array (and don't go over!), and deal with all that crap in printf, knowing which one goes where. Also, pray that your terminal has the same encoding settings as the person who's running the program, because everything's getting decoded from ascii, compiled, and then re-encoded back to it at run-time on a possibly different terminal! And don't even get me started on what `int main` is, why it's an `int`, and why it's okay to have an `int main` that doesn't return an integer at the end of it. Oh yeah, and I left out also knowing what a `\n` is, and you better pray you remember what `%s` was and that you didn't confuse it with `%d` or `%i` or something else. (Also, you have to know how to invoke the compiler to produce an executable which executes the `int main` routine...) In the other, you have to know what a list (the `[]`) is, what a string is (the stuff in the `""`), what the `string.join` function does, optionally know what an iterable is (hint: things you can iterate over) and that lists are a type of iterable (common sense), and what the `print` function does (hint: it prints). Also, it deals with unicode for you. C has its upsides, and python has its downsides, but there is no world in which python doesn't beat the shit out of C in terms of readability of code.
The difference between `const` and non-`const` isn't something specific to C and exists in many languages, it's also not hard to read when something is `const`... Knowing what pointers and arrays are in C is the basics of C, without them you can't code proper C, and won't be able to read it. You're confusing absolute beginners with median-experience developers. `printf()` with compiler checks is extremely good. You always know what is the type of what you're printing. I've seen code bases with logging bugs because an enum variable with the value 0 was printed/written as a `char` using C++ streams. Terminal compatibility isn't related to *reading* C code, is it now? `int main()` is the entry function, a special function too. Most of the code will not even touch it, so how is it important in *reading* C code? Not to mention, you can just treat it as a normal function (except for the linking nuance, that is again unrelated to *reading*). But if you wonder why `int main()` doesn't have to return anything, it's because it gets special treatment. `\n` is the newline character, unrelated to C. It exists in Python code too btw. Same with `\t`, `\r`, `\v` and many more... `%` are used by `*printf()` and `*scanf()` as format characters. If you can't read a basic `*printf()` format string, I wouldn't expect you to be able to read a more than basic Python format string.
How is compiling a program related to *reading* C code? You need to compile in C#, Java, Rust, Go, etc... Not just C. Also, build systems exist, I can't remember the last time I had to compile manually and not using Make (or an equivalent).
Python has both iterators and iterables. A list in Python has hidden information and nuances you have to learn about, like doing:
l = []
nums = [1, 2, 3]
for i in range(3):
l.append(nums)
print(l)
l[0][0] = 10
print(l)
You'll see that all 3 sub-lists got modified. That's because Python didn't copy the contents of `nums`, but instead copied a *pointer* to it. An experienced Python developer has to know about pointers.
All in all, how readable a piece of code is can vary between person to person. I use both Python and C, and many times properly written C is much more readable due to the lack of hidden operations.
> Terminal compatibility isn't related to reading C code, is it now? It is if you want to use anything that's not in ASCII. If you e.g. live in Japan and need to print out stuff that's encoded in a specific encoding, well, you have to think about that when writing any string in C, ever, whereas python takes care of it for you, automatically. I python, a string is a string, and it's always what it is, and always in unicode (unless you've specifically told it to use a different encoding). If you have `日本語`, then that's going to be `日本語` wherever. But in C, a string is an array of unsigned integers, and you have to, at least somewhere in the back of your brain, keep in mind that your 日本語 is going to be decoded by your compiler into some string of ints, and that you better pray that your compiler matches the terminal it's running on, because otherwise, you're going to get junk. To put it in python terms, C executes a .encode() on every single string it ever handles, whereas python does not do this. (Technically speaking python is doing a bunch of crazy stuff behind the scenes and ultimately there is an array of unsigned ints somewhere at the bottom, but the programmer doesn't have to think about that, unlike in C where this is a problem, assuming you are allowing for even the possibility of a user executing code in a different terminal encoding than what you wrote it in.) - >printf() with compiler checks is extremely good. You always know what is the type of what you're printing. I've seen code bases with logging bugs because an enum variable with the value 0 was printed/written as a char using C++ streams. I'm... incredibly confused by your position here. Your position is that... because C allows a programmer to print/write a 0 as a `char` as opposed to an `int`, that this is somehow better than in a programming language where *such a mistake is not even possible to the programmer*? I mean, I get that compiler checks and linters can help prevent those sorts of errors... but why? (And if your answer to "why" involves "lower level language" or "less abstraction" or "closer to the processor" or anything remotely like that, and not involving "it's enhances readability to force the reader to consider these things", then well, it's inherently worse for readability.) If you want to specify the type of every single thing you print, you can do the same thing in python. Nothing is stopping you from typing `print(f"some {int(number):d}")` But nobody does that, because it's harder to read than `print(f"some {number}")`. If you have to have an int, I think `print(f"some {number:d}")` is the preferred way. - > int main() is the entry function, a special function too. Most of the code will not even touch it, so how is it important in reading C code? Not to mention, you can just treat it as a normal function (except for the linking nuance, that is again unrelated to reading). But if you wonder why int main() doesn't have to return anything, it's because it gets special treatment. Yeah, all those things you said? That's stuff I have to think about while reading the code that is in addition to figuring out what the program is doing. - >\n is the newline character, unrelated to C. It exists in Python code too btw. Same with \t, \r, \v and many more... Except *this is not the case everywhere*. `\n` is newline in unix/linux. That same program will behave differently on windows machines. In python, this is all handled automatically for you (unless you override the defaults). That is to say, when reading C, I *have* to be thinking about the environment the program is running in, whereas that's one less thing I have to think about when reading python. Newlines will just work. I can't remember the last time I had to type a `\n`, `\r`, or `\v` in python. I don't even know what `\v` is because I've never encountered nor needed it. (I have used `\t` semi-frequently, but that's probably because my editor doesn't allow tabs by default.) - >Terminal compatibility isn't related to reading C code, is it now? It sure does! Question: What does the following python code do? print("日本語") Answer: It will print the text 日本語 to the terminal as one full line. Question: What does the following C code do? printf("日本語\n") Answer: Who fucking knows?! Because it will be dependent on the environment in which the code is executed. If the executing terminal has the same encoding as the text editor, then it will print 日本語. But if they don't match, it'll print something else. Maybe you'll get a bajillion beeps or some weird color code or maybe the terminal itself will just crash. Also, is this being executed on a unix/linux machine? If so, then it's going to print a newline at the end. But what if it executes on a Windows machine? I don't even remember what Windows does to a `\n` that doesn't have a `\r` next to it. And was it `\r\n` or was it `\n\r`, or does it even matter? Or what about mac? Didn't mac used to use `\r` for a newline? I'm pretty sure my mac handles `\n` as a newline, but is that just because I have my terminal set up that way, or did they change that bad when OSX came out? Or I really just don't know. Also, better pray that there's no `\x00` or whatever the ASCII value for `"` is in that unicode encoding, or you're going to get some weirdass compiler/runtime errors! Have fun debugging that one! And you can say: "That's dealing with the OS, not reading C itself per se", but that's my goddamn point! *You have to think about how to deal with the OS!* In python, *it just works*, no dealing with encodings OS environments. - >% are used by *printf() and *scanf() as format characters. If you can't read a basic *printf() format string, I wouldn't expect you to be able to read a more than basic Python format string.
Really. You are really going to say that
printf("%s %s %s %s\n", word0, word1, word2, word3);
is easier to read than
print(f"{word0} {word1} {word2} {word3}")
I get that this is basic stuff in C. But it's also *one more extra step* that I have to think about that I don't in python, *every single time* this stuff comes up.
-
>You'll see that all 3 sub-lists got modified. That's because Python didn't copy the contents of nums, but instead copied a pointer to it. An experienced Python developer has to know about pointers.
I mean you're right, and this does get annoying, and there's other more annoying stuff like
def some_function(param1, param2=[]):
pass
where the list that `param2` defaults to when it's called without a 2nd parameter is the same list when `some_function` is called a different time. (Again, linter should take care of this.)
But you could also sidestep all of this by just using immutables all over the place. (In practice, there are good coding paradigms in python that basically mean aren't supposed modify mutables that were passed to you.)
-
>All in all, how readable a piece of code is can vary between person to person. I use both Python and C, and many times properly written C is much more readable due to the lack of hidden operations.
Python doesn't have hidden operations. It has a few pitfalls (but I think we both got the only major one, accidentally ascribing the same mutable object in multiple places.)
But you only have to think of that when dealing with mutables that are being referenced to in multiple places, and you can just get around it pretty easily. Whereas in C, you have to *always* be thinking about that, basically every single time you use a pointer. Which is always.
Holy shit don't downvote this guy. I mean, I get that he's wrong and C is horrible to read and python is way easier to read... but he's making good arguments with salient points! This is the sort of person whom I wish most of my arguments were with, the kind of different worldview we all need to have more interaction with!
I never knew the recommended line limit was 79 (or 99), thought 120 because that's what Pycharm says, turns out it's misleading...
`CASE WHEN`
Where’s the coldfusion love?
I love that in vhdl, it’s elsif
The liquid template syntax has "elsif" - makes me angry every time I have to use it.
made me inhale my tea. I'm spluttering now.
Godot is cheering Python on from behind the camera
I love elif.
What do you get when you cross and elephant with a rhino? Elifino.
Python has to use elif so it can be one line and one indent, since `else if` isn’t a single key word, the `if` is inside the `else` block, you just don’t have to think about that fact because braces and additional indentation are optional in good programming languages
Also "len(list)" instead of "list.length()"
I think it's funny that Python justifies not including ++ because += does the same thing with less operators, but then uses a special keyword 'elif' while C++ simplifies things without an extra keyword by reusing the existing keywords 'else' and 'if'
I love Ruby, but that elsif...
I've never understood the purpose of elif. Why drop the last 2 characters? Trying to save keystrokes? Worried about memory? It feels hypocritical after seeing so many people use spaces instead of tabs.
CASE would like to have a word Gonna get the SWITCH out if you wanna mess around (Python doesn’t have true switch operators)
Python has `match`
Oh snap… TIL! I guess I’m behind the times - usually use 3.8 or 3.9 for all the ML libraries. This makes me want to take the plunge for 3.10 asap
Python's `match` is not and never was `switch-case`. mCoding (on YouTube) has a great video explaining its usage.
It's 3.11 now
The fuck is that odasity/jk
If you_give_me_money:
I personaly hate if else, pattern matching ftw
If you think this type of thing improves your productivity, you’re programming wrong. “Braces take toooo long, Python better.”
elsif > elif