Made with KolourPaint and screenshots from Kate (with the GitHub theme).
well, the
: String
is supposed to be optional right? type inference should know what it is. In truth though, return type polymorphism makes us write more type annotations than I would like.My attempt of an honest answer to my best knowledge:
As @TootSweet@lemmy.world mentioned, to make a programming language closer to spoken English language, most likely (hi, Python, I am looking at you too). Which infuriates me immensely: when programming, I do not speak languages, I express data structures and operations on them, stacked one upon another. The last thing I need here is ambiguity, loose structure and information duplication (forgot correct term for the last one) that are typical to natural languages of human communication
char[] a; // like a boss
char**
Enlightenment is realizing that variables don’t have nor need a type, they are all just arrays of bits.
True enlightenment is realizing that variables don’t exist, it’s all just a sequence of bits in RAM that we assign meaning to as desired.
Ascension is realizing that bits don’t exist, it’s all just trapped electrons in transistors which we imagine to be bits.
Transcendence is realizing that transistors or code doesn’t exist, and it’s just some quarks and electrons attracted and repulsed by weird forces, vibrating and convulsing in a soup with entropy constantly rising until the heat death of the universe, of which we make futile attempts to make sense or purpose.
deleted by creator
`void* isOdd(void* ptr);"
Look at what you made me do.
The Go programming language documentation makes a big deal about how it “reads from left to right.” Like, if you were describing the program in English, the elements of the Go program go in the same order as they would in English.
I say this as someone who likes Go as a language and writes more of it than any other language: I honestly don’t entirely follow. One example they give is how you specify a type that’s a “slice” (think “list” or “array” or whatever from other languages) of some other type. For instance a “slice of strings” would be written
[]string
. The[]
on the left means it’s a slice type. Andstring
on the right specifies what it’s a slice of.But does it really make less sense to say “a string slice”?
In Go, the type always comes after the variable name. A declaration might look like:
var a string
Similarly in function declarations:
func bob(a string, b int, c float64) []string { ... }
Anyway, I guess all that to say I don’t mind the Go style, but I don’t fully understand the point of it being the way it is, and wouldn’t mind if it was the other way around either.
Edit: Oh, I might add that my brain will never use the term “a slice of bytes” for
[]byte
. That will forever be “a byte slice” to me. I simply have no choice in the matter. Somehow my brain is much more ok with “a slice of strings”, though.Go’s syntax is vastly superior once you have more complicated signatures, then the left-to-right truly matters. For example a variable that contains a pointer to a function that takes a function and an int and returns another function (like a decorator).
In C the order becomes very hard to understand and you really have to read the thing several times to understand the type of fp:
int (*(*fp)(int (*)(int, int), int))(int, int)
In Go, you can just read from left to right and you can easily understand what f’s type is:
f func(func(int,int) int, int) func(int, int) int
It’s just much more readable.
To be honest I always disliked variable declaration without value assignment, so to me both options suck. :)
What about you declare (then it gets allocated in stack) it and pass it to a different context for assignment?
Well, I don’t know your use case well enough, but I guess you might have perfect reason for that behavior.
One thing that comes to my mind is the old Try in C#
bool parsedSuccessfully = int.TryParse("123", out int result);
But I guess more popular approach would be to use Error as Values, right?
Outcome<Exception, Int> result = int.TotallyNewParse("123");
char c; scanf("%c", &c);
Great example.
Wouldn’t
getchar()
be more appropriate here? Last time I used C it was 16 years ago.Yes, and no, sir, you missed the point. The procedure here is to allocate then give away, not reading a fixed-length returned value.
Say you can only afford to have ten bytes in the stack. You allocate
char s[10];
then give it to a library to parse something. Also telling it to abort if it’s going to be longer than ten bytes, of course.