521–530 of 614 posts
Earlier quoted context omitted.
Go is definitely fast enough to do data science.
Sure, it’s much faster than Python, agreed. But is it fast enough to implement highly optimized numerical algorithms in a way that can compete with Fortran or C? That I’m not so sure of, and if not you’re stuck with the crappy FFI.
Earlier quoted context omitted.
>> Selecting your own definition for a word Is that accurate? I said: >> To complicate something is to combine and intertwine it with other concerns. To fold them together is to complicate them. The dictionary defines complicate as: >> to make complex, intricate, involved, or difficult With etymology: >> complicat- folded together complicate combine, entangle. intertwine earlv 17th century >> instead of actually givi…
I think the code you linked shows exactly why generics are needed for these kinds of methods. By introducing a single generic, you could reduce it from 500 lines to 20, and make it work for all types, not just the built-in ones. It would also remove the need to have different method names. I think that makes it less complex, as the developer doesn't need to think about the exact underlying type of the array when call…
No one is writing 500 lines of code - just as when you use the generics syntax you don’t write the code that is generated by the compiler in response.
You could save about 10 lines, specifically these 10:
https://github.com/logic-building/functional-go/blob/master/...
You would still need the comparable ~40 lines of “generic” code:
https://github.com/logic-building/functional-go/blob/master/...
Earlier quoted context omitted.
Right, the design goals are it is a language for people not clever enough to deal with programming languages. "The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software.…
Thanks for refs. > people not clever enough to deal with programming languages. Add older folks to this cohort. They've lost steam, are lazier and less patient with obstacles and less fortunate with time.
Earlier quoted context omitted.
Yes, it’s a trade-off. In an organization with thousands of developers the right trade-off is likely different than an org with 20. What I don’t understand is why people insist on making Go like every other language that already does what that are looking for. You want a language with generics, purely functional blah blah blah, great there are tons of choices, use one of them. Why insist on reducing the diversity in…
Because in many shops IT decides what languages people use, given the platforms, not devs. Also quitting the job isn't always an option. That is why some of us have to put up with languages that we rather not.
Earlier quoted context omitted.
Right, the design goals are it is a language for people not clever enough to deal with programming languages. "The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software.…
Thanks for refs. > people not clever enough to deal with programming languages. Add older folks to this cohort. They've lost steam, are lazier and less patient with obstacles and less fortunate with time.
Approaching 50 here, and no major issues dealing with project deliveries across Java, C#, JavaScript, TypeScript, C++, Transact SQL, PL/SQL, PowerShell, bash, ....among plenty of other stuff, naturally depending on project specific workloads.
Maybe it is some devs that can't fathom how to transport water buckets to the top with all those stairs.
Earlier quoted context omitted.
Because in many shops IT decides what languages people use, given the platforms, not devs. Also quitting the job isn't always an option. That is why some of us have to put up with languages that we rather not.
So you want to diminish the diversity in programming languages because it’s an inconvenience to you personally. I respect the honesty.
The old ways of code generators are good enough.
Earlier quoted context omitted.
This is what policies are for, not entirely new languages: if you don't like generics and don't trust the end developers at your organization to not use them in stupid ways you should maybe (I say "maybe" as this problem just seems so lame of a problem to have: if your army of end developers can't be trusted then you should fire them and hire some real developers) have a way to turn off generics that isn't "use a lan…
I’m not talking about generics specifically. I’ve been coding for decades. Go is by far the easiest language I’ve used when it comes to jumping into an arbitrary code base and making sense of it. Again I ask, why insist that go become the same as all the other languages when you can just use one of those? Why demand less diversity?
Earlier quoted context omitted.
It enables one to conditionally set up cleanup within the function. If it was block scoped, you couldn't do something like `if shouldDoSideEffect { defer something() }` If it was scope-based, there would be just as many people complaining that it isn't function based.
You could just do `defer if shouldDoSideEffect { something() }`
They _should_ be identical, unless shouldDoSideEffect changes.
Yes, mutability is bad. One shouldn't change that. But avoiding "you're holding it wrong" footguns was the original goal, right?
Don't get me wrong, having both would be nice. Maybe something like `after` for function scope and `defer` for block scope. But that starts to erode the "simplicity" of Go, I guess.
I wish I understood how people can say 'this will result in so much more weird boilerplate garbage code' as it solves a problem that has resulted in an absolutely ludicrous amount of weird boilerplate garbage code. You're not trading off generic code vs non-generic code. Problems are generic. For solving generic problems , you're trading off the generic code that best expresses them, for codegen, dynamic downcasting,…
It’s not a satisfying answer, but the truth is that there just isn’t that much Go code out there suffering from a lack of the kind of basic generics being introduced. It exists, but it’s not the norm. Instead, what is likely to happen is, a lot of problems that generics can be applied to, they more often will be, simply because the option is on the table, regardless of whether it really improves anything. Go taught m…
The problem you're describing already exists, there's no preventing it or getting rid of it, and generics are tame by comparison - at least they semantically mean exactly what the developer intended them to mean, don't come with non-obvious performance downsides, and don't clobber existing concepts like error handling.
As for optionals vs separate bools, love 'em or don't, but yes, there is a downside, which is in my view possibly Go's only regression from C: no longer being able to stick the function call in the if-statement directly without additional fanfare.
Earlier quoted context omitted.
> But I also don't know any languages where errors _aren't_ values (look, i know you understand how exceptions work, please bear with me) yes, Exception objects are technically values, but you don't return them to the caller; you throw them to the, uh, catcher. basically, you get a special, second way of returning something that bypasses the normal one! but in the EaV approach, errors just are returned like every oth…
Exceptions can still be treated as syntactic sugar for EaV; it just means that every expression has an implicit unwrap-and-propagate.