Do you mean DEKALB, a subsidiary of Bayer Crop Science? Monsanto doesn't sell anything. They closed up shop years ago and sold the assets to Bayer and BASF.
8,634 karma · joined June 23, 2011
Do you mean DEKALB, a subsidiary of Bayer Crop Science? Monsanto doesn't sell anything. They closed up shop years ago and sold the assets to Bayer and BASF.
Normally in Pascal you would not match on the enumeration at all, but rather on the sum types.
type
Foo = (Bar, Baz)
case foo:
Bar: ... // Matches type Bar
Baz: ... // Matches type Baz
The only reason for enumerations in Pascal (and other languages with similar constructs) is because under the hood the computer needs a binary representation to identify the type, and an incrementing number (an enum) is a convenient source for an identifier. In a theoretical world where the machine is magic you could have the sum types without enums, but in this reality...Thus, yes, in practice it is possible to go around the type system and get the enumerated value out with Ord(foo), but at that point its just an integer and your chance at exhaustive matching is out the window. It is the type system that allows more flexibility in what the compiler can tell you, not the values generated by the enumeration.
> Go only has enums by convention
"Enums by convention" would be manually typing 1, 2, 3, 4, etc. into the code. Indeed, that too is an enumeration, but not as provided by the language. Go actually has enums as a first-class feature of the language[1]. You even say so yourself later on, so this statement is rather curious. I expect you are confusing enums with sum types again.
[1] Arguably Pascal doesn't even have that, only using enums as an implementation detail to support its sum types. Granted, the difference is inconsequential in practice.
The term you are looking for is sum types (albeit in a gimped form in the case of Pascal). Enumerations refer to the value applied to the type, quite literally, and is identical in Pascal as every other language with enumerations, including Go. There is only so much you can do with what is little more than a counter.
That's the point. It's a rejection of the keyboard jockeys who become more concerned with the code itself than the problem being solved.
If you choose Rust, and it turns out to be the wrong choice, how will the customer be impacted?
If you choose Go, and it turns out to be the wrong choice, how will the customer be impacted?
Go calling convention is that you have to assume T is invalid, unless proven otherwise, because we know there are developers who have no business being developers that will screw you over if not careful. The Go style guide promotes documenting in a function comment that your function does return a valid T so that users don't have to guess about whether or not you are competent.
But the convention on the function authoring side is to always ensure T is valid. Just because others shouldn't be writing code does not mean you need to be among them.
As Go promotes limiting use of third-party packages by convention, as a rule most of the functions you call are going to be your own. So most of the time you can be sure that T is valid, regardless of error state. Yes, sometimes you are forced to rely on the error, as we discussed already in earlier comments. Such is life.
Only in the same way that a cook that has spent his career in an Italian restaurant doesn't have expertise in cooking Chinese food. An employer on the hunt isn't going to care about such trivial differences (HR box tickers might, but crypto startups probably don't have that).
Granted, I can understand why you'd be leery about working at such places.
But the first followup question is: For each choice, what are your risks if you were to find out you chose wrong?
Maybe you have a good problem of your own to solve, but in my experience the most interesting problems are usually those that other people have.
Solving someone else's problem is what a job is.
You can. But making radio waves does not imply a broadcast. At least not in the traditional sense. I'll grant you that colloquially we have sometimes come to refer to any radio transmission as a broadcast, but that is not the usage here.
> BUT, if you don't know you are making radio waves are you still a broadcaster?
If you didn't know a chicken emerged from an egg, is it still a chicken? My experience with young children who don't yet understand that process would say yes. No doubt there are career radio broadcasters out there who are not familiar with the science of radio.
It's not about not knowing of the existence of something, though. We know the chicken came from an egg. We just don't know what kind of egg it was. Was it a chicken egg or was it a flibberdoodle egg? If it was a chicken egg, how did the flibberdoodle lay a chicken egg? If it was a flibberdoodle egg, how did a chicken come out?
I'm not sure that is analogous. The chicken/egg question is about at what point we started identifying an egg as being a chicken egg as opposed to being an egg from another animal. In other words, did the first chicken egg come from a chicken (meaning the chicken came first), or from a proto-chicken (meaning the egg came first)?
A closer variation might be: Which came first, the radio broadcast or the radio broadcaster? Before the radio broadcast and radio broadcaster there was radio and people using radio, but they did not reach a wide public audience. At some point the early small-scale experimental radio use turned into broad utilization, but when and which was earlier on the timeline?
Anyway, the veracity of that legend doesn't matter, but it is here merely to illustrate the idea that perhaps we subconsciously build our roads on lines that chickens won't cross, rather than them being aware of the road?
Did the proto-chicken lay a chicken egg which hatched the first chicken, or did the proto-chicken lay a proto-chicken egg which hatched the first chicken?
There was certainly a fad when social media was new to get all worked up about finding out about something someone did in the past, where people were even losing their shit over something that would normally be innocuous like a photo of a teacher enjoying a beer at a party. But, I think we're kind of over it at this point. Fashion trends don't last forever.
Consider the case of (T, error). T should always be useable, regardless of error. At very least, if there is nothing more relevant to provide, the function should return the zero value for T. And we know that in Go the zero value is to be made useful. Go Proverb #5.
In practice, this often means something like (*Type, error), where the zero value for *Type (nil) is returned on failure. In which case the caller can check `if t == nil`. No need to consider the error at all. It is there if your requirements dictate a need for the error (e.g. reporting the failure), but for using the result it is entirely unnecessary.
If you leave the caller in a state where T can be invalid, you screwed up horribly or are purposefully being an asshole. Don't do that. That is Go 101 type stuff.
While Marx believed that was necessary to see post-scarcity, it very well could be that he was wrong. This may come as a surprise to you, but he wasn't an all-knowing genie, just a feeble human. At this point in time we seem to be going down the right road without needing to do that. As before, I think we can agree that American innovation has brought us closer to post-scarcity than anything else the world has ever known.
If you are trying to say that Harris isn't a Marxist, then sure, that's fair. But we're clearly talking about "communist", not "Marxist". That these words happen to share the same last three letters does not imply that they are the same word.
If you are trying to say that Harris isn't a member of the Communist Party, as an earlier poster seemed to mistake, that is also fair. Clearly she is not that either. But, again, we're talking about "communist" not "member of the Communist Party". It is possible for a communist to be a member of the Communist Party, just as a liberal may be a member of the Democratic Party, but being a communist/liberal does not imply alignment with a political party. For our Canadian friends, being a liberal does not imply support of the Liberal Party either. Ideologies and political groups are quite distinct from each other.
> Communism is not about post-scarcity, to the contrary. It's an economic system that seeks to distribute finite resources equitably
Perhaps you just phrased it poorly, but communism is more of a lack of a system. It doesn't even have a state to administer a system! Those things go away when you have post-scarcity, naturally. Communism is not about post-scarcity, but you need post-scarcity to allow it to happen. You fundamentally cannot go stateless, classless, and moneyless without post-scarcity. Hence why communists seek post-scarcity. It is the change that ushers in communism.
> So arguing that any of Harris or Trump have anything to do with communism is either very dishonest or coming from a place of deep ignorance.
Or just boring old semantics. That is what you seem to present here, offing that Harris is not a communist simply by redefining communist (granted, it appears as though you may be struggling to get out what you are trying to say, so it might just be that).
Regardless, I spelled out my definition. Even it is not the same as your pet definition, it is the one that was given. The context is set. Under that definition, how is Harris not a communist?
The product is not a full-stack web application. What makes you think that they brought in people with that kind of experience just for this particular feature?
Especially when they claim that they chose that route because it was what was most convenient. While you might argue that wasn't the right tradeoff, it is a common tradeoff developers of all kinds make. “Make It Work, Make It Right, Make It Fast” has become pervasive in this industry, for better or worse.
But it seems most programmers here are only around for the MVP and are content to let the future of maintaining their garbage be someone else's problem. Which, I expect, is also the fundamental aversion they have to Go, which is trying to create a world where you still want to work on the same codebase in 30 years.
Not that Go is perfect. It most certainly isn't. But you are going to spend more time obsessing over things that aren't even all that important in practice when your "launch and dash" lifestyle is being threatened.
I know of no programming language that provides a consistent way to deal with values correctly, if the venerable if statement (or whatever is equivalent) is not it.
What is this magical fairy language that you speak of or envision?