241–250 of 466 posts
Earlier quoted context omitted.
C programmers use void pointers for generics. :)
And so, basically, does Go.
Details: http://research.swtch.com/interfaces
Earlier quoted context omitted.
> Operator overloading is consistently one of the worst ideas I see in programming languages Except when not having it is the worst. Working with BigDecimal in Java is hell because it does not have operative overloading, meaning while you avoid boostfs::path path("/some/path"); path /= "yourfile.txt"; you get saddled with bullshit like x.add(x.add(ONE).pow(2).subtract(x))
Now this is ugly: x.add(x.add(ONE).pow(2).subtract(x)) Especially because sometimes it is difficult to decide whether you should have x.foo(y) or y.foo(x). However, add(x, sub(pow(add(x, ONE), 2), x)) Is perfectly acceptable in my opinion (add some indentation if it's difficult to read). As long as you can pass parameters and return values without tricks (ie. passing pointers), this is quite nice. You should even be…
I comletelly agree with this, it is very confusing API.
You should even be able to do this in Java with "import static"
Yep, you should define a static methods add, sub, pow etc with BigDecimal parameters and then use import static.
Something along
class BigDecimalMath { public static BigDecimal add(BigDecimal x1, BigDecimal x2) { return x1.add(x2); } }
Also JVM JIT would very likely inline such code, so you should not really worry about an added method call.
there we Go again. why spend time writing about something you don't like? Is it a therapy for programmers with strong opinions?
Because you may be forced to use it at work.
Go is "trendy" and will fall right in line with Ruby on the trendy block. They'll have block parties together and "Go" swing dancing. Wait, that was a fad too and a pun.
Earlier quoted context omitted.
Then good that it stopped years ago: https://golang.org/doc/ >>> The Go programming language is an open source project to make programmers more productive. Go is expressive, concise, clean, and efficient. Its concurrency mechanisms make it easy to write programs that get the most out of multicore and networked machines, while its novel type system enables flexible and modular program construction. Go compiles quickly…
"expressive" "concise" "novel type system" "flexible type system" Just a few things that need correcting. Really ... "novel type system" ...
Go isn't expressive, nor concise, nor does it have a flexible type system. But if any of its claims are true, it's that its type system is at least a little novel.
Sure it's not the most exotic type system out there, but its interfaces are very useful and they aren't found in many other languages (not implicitly satisfied interfaces, that is).
Earlier quoted context omitted.
> you still added the ability for + to throw an exception, which it will never do with ints. Not quite true, the language could implement checked over- or under-flows (I believe Swift does)
"Not quite true, the language could implement checked over- or under-flows (I believe Swift does)" I am one of the apparently about ten people who thinks that should be the universal default. The vast bulk of people disagree, and I was trying not to poke the sleeping dog. :)
There's a handful of us, a handful!
FWIW Rust checks for overflow in debug mode, and while that's elided by default when compiling with optimisations it can be re-enabled with a -Z flag:
> rustc test.rs
> ./test
thread '' panicked at 'arithmetic operation overflowed', test.rs:4
> rustc -O test.rs
> ./test
Overflowed!
> rustc -O -Z force-overflow-checks=on test.rs
> ./test
thread '' panicked at 'arithmetic operation overflowed', test.rs:4
We'll see in the next few years... We'll see...
Earlier quoted context omitted.
Using go for goroutines and channels is a bit like using Perl for regular expressions. The features have been added in a way that makes them easy to use and serves as a nice idiomatic platform, but fundamentally it's functionality other languages can provide via library support.
> but fundamentally it's functionality other languages can provide via library support. Implementing goroutines and channels requires language and runtime support for green threads that are n:m multiplexed on top of native threads. It can not be implemented as a library in most languages, at least not efficiently. Any language with thread support can set up threads and put a concurrent queue between them, but that's…