Timeline for Why do "modern" languages not provide argv and exit code in main?
Current License: CC BY-SA 4.0
29 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 10, 2024 at 15:22 | answer | added | supercat | timeline score: 4 | |
| Sep 10, 2024 at 15:14 | comment | added | ScottishTapWater | C# still does this | |
| S Sep 10, 2024 at 11:17 | history | suggested | bindiff | CC BY-SA 4.0 | Replace the magic number that looks like a bus route number in Brno with a more generic number. |
| Sep 10, 2024 at 9:18 | review | Suggested edits | |||
| S Sep 10, 2024 at 11:17 | |||||
| Sep 10, 2024 at 2:47 | vote | accept | 404 Name Not Found | ||
| Sep 10, 2024 at 0:11 | answer | added | Karl Knechtel | timeline score: 8 | |
| Sep 9, 2024 at 20:45 | answer | added | Davislor | timeline score: 10 | |
| Sep 9, 2024 at 18:55 | answer | added | Kaia | timeline score: 11 | |
| Sep 9, 2024 at 18:47 | comment | added | Peter - Reinstate Monica | Maybe the question is rather "why are modern languages wordier than C", and the answer is "because computers have a million times more RAM and disk space than 50 years ago, so we don't need to sacrifice readability any more to save memory". | |
| Sep 9, 2024 at 18:12 | answer | added | Dietrich Epp | timeline score: 66 | |
| Sep 9, 2024 at 17:44 | comment | added | Kaia | Worth noting that C/C++ compilers have also varied their main's args, e.g. char *envp[] | |
| Sep 9, 2024 at 17:37 | answer | added | Matthieu M. | timeline score: 26 | |
| Sep 9, 2024 at 15:26 | comment | added | 404 Name Not Found | It's non-standard (i.e., -std=gnu17 rather than -std=c17), but you can use void main(void);, exit(), and platform-specific extern int __argc and extern char **__argv from stdlib.h if you really wanted to. A hassle, but it's doable. | |
| Sep 9, 2024 at 14:51 | comment | added | JimmyJames | You can easily emulate the C-style main in these languages, but you can't (to my knowledge) easily do the reverse. That seems like an advantage to me. | |
| Sep 9, 2024 at 14:41 | history | edited | 404 Name Not Found | CC BY-SA 4.0 | more example on c |
| Sep 9, 2024 at 14:40 | comment | added | 404 Name Not Found | My reference point is C/C++, so yes, I consider that "hidden". | |
| Sep 9, 2024 at 13:44 | comment | added | RedGrittyBrick | For Go, do you feel os.Args[] and os.Exit() are "hidden"? | |
| Sep 9, 2024 at 12:52 | history | became hot network question | |||
| Sep 9, 2024 at 12:30 | comment | added | kaya3 | If I want to parse from a config file instead, the output will be the same type of config object, but the config file will have a different format, so it needs a different parser. | |
| Sep 9, 2024 at 12:12 | history | edited | 404 Name Not Found | CC BY-SA 4.0 | reword |
| Sep 9, 2024 at 12:06 | comment | added | 404 Name Not Found | The library API may be simpler but I feel whether it's better is debatable. I'd rather have it take a string array since I feel it's more flexible with regards to how I get those arguments instead of hardcoding the platform's behavior. Perhaps I want to read a config file instead and parse its contents as arguments - reflector seems to do that with its config file. | |
| Sep 9, 2024 at 11:32 | comment | added | kaya3 | std::env::args() is longer than argv, but not longer once you add the parameter declaration String[] argv. As for parsing the args and passing them around, absolutely, but your argument parser needs to access the arguments, and it's more convenient for it to fetch them from std::env::args() itself than for you to have to pass them along yourself. Particularly, you are probably using a library like arg to do the parsing, and that library's API is simpler if it doesn't require you to be a middleman. | |
| Sep 9, 2024 at 7:32 | comment | added | 404 Name Not Found | I can buy std::env::args() being more convenient to access throughout random places in my program, but I'd argue that's a short term hack - it would be better to collect and parse all the arguments first into an application-specific "state" object, at which point it's no different from using std::env::args() directly other than the data being in a more convenient format for my program. Similarly for std::process::exit(), I prefer to let upstream handle problems, or bubble it up to main if there's nobody handling it. | |
| Sep 9, 2024 at 7:21 | comment | added | 404 Name Not Found | Perhaps a more accurate word would be "shorter", then. std::env::args() is longer than argv, and std::process::exit() is longer than return. It could be shortened to args() and exit(), but then I would need use std::{env::args, process::exit}; which is also longer than #import <stdio.h>. | |
| Sep 9, 2024 at 7:13 | comment | added | kaya3 | ... an import. And arguably std::env::args() and std::process::exit(...) are more convenient than declaring the args as a parameter of main and returning from it, because you can call them from anywhere in a program. | |
| Sep 9, 2024 at 7:12 | comment | added | kaya3 | In what sense is std::env::args() less convenient than String[] args? You are only going "out of your way" in Rust because you wrote a separate cmain function and called it from the real main function. Your simple program would be a lot simpler if you just wrote for arg of std::env::args() in the main function. Likewise I'm not sure how std::process::exit(...) is significantly less convenient than return. These are things you will write at most once per project; it's more inconvenient to type #include <stdio.h> in C, when modern languages don't hide console output behind ... | |
| Sep 9, 2024 at 6:15 | answer | added | Eldritch Conundrum | timeline score: 28 | |
| S Sep 9, 2024 at 4:52 | review | First questions | |||
| Sep 9, 2024 at 6:41 | |||||
| S Sep 9, 2024 at 4:52 | history | asked | 404 Name Not Found | CC BY-SA 4.0 |