181–190 of 220 posts
Earlier quoted context omitted.
Why do you feel this is worth pointing out?
I think that it is very impressive that he is having these thoughts at such a young age. That's it, I wasn't saying that his opinion should be discredited!
Earlier quoted context omitted.
People don't hate Java for being boring, per se. They hate it for being inflexible, verbose and having a bureaucratic culture.
People hate Java because it's unremarkable but successful. There's nothing particularly innovative or wild about it, but equally, nothing particularly awful (plenty of mediocre, of course). Whether despite or because of that, it somehow became the most widely-used language in places you get paid to sit and write code. It always feels cool to hate popular things, and it always feels cool to hate boring things. Hence,…
> I’ve been using Go since November and I’ve decided that it’s time to give it up for my hobby projects. I’d still be happy to use it professionally, but I find that programming in Go isn’t “fun” in the same way that Python, Haskell, or Lisp is. I can't leave go, but indeed I think absolutely the same. The thing is that GO was designed to replace c++ thing that absolutely failed. So we have a python/ruby replacement…
>The thing is that GO was designed to replace c++ thing that absolutely failed. I was so excited for GO to become a nice replacement to C++. GO has awesome build times. C++ has awful build times. This is partly due to all the extra work the C preprocessor has to do make sure all the headers are present. The big lose for me is the fact that GO has absolutely no operator overloading. This is one of the biggest wins in…
Completely true for scientific computing, but I've been subjected to libraries written in scala recently and operator overloading there has lead to some very difficult to read and use libraries.
Earlier quoted context omitted.
I thought the debate was about polymorphism. It's apparently not worth including because...? It's not already in the language spec? Because the people who advocate it are using the wrong tool? Surely there's a better argument than this.
Lack of polymorphism isn't even close to the most common objection to Golang. The most common objection is the lack of generics, which make it tricky to write reusable container libraries. Golang comes pretty close to flat-out rejecting object orientation. It's only barely more object-friendly than C is. If you're the kind of programmer that wants to model a problem domain or build code with the Smalltalky feel that…
Also, I personally look at Nimrod as a faster and slightly cleaner Python with a few extras, and I don't try to break the compiler using all of its cutting edge features. If you use it that way you will be happy.
Earlier quoted context omitted.
As someone who thinks that more advanced type systems and proof-carrying-code are some of the biggest advances in theoretical computer science and practical programming in the last few decades, but also is a C# compiler developer, I have also noticed this. Haskell is really interesting, but C# developers get shit done. I'm not sure what the cause is, but it definitely gnaws at me.
It's not a good thing - for production software - for a language to be too much fun to use. It means that developers spend all their time using the language and not enough time solving problems . The suckiness of Java/C# tends to encourage people to solve their problem and move on quickly to the next problem, because it's honestly not much fun trying to extend the language or build abstractions. Haskell & Lisp progra…
I find Ruby, C[0] and Go really fun. The reason I get shit done is because they are so fun! I can't wait to do something else in them!
Also, the elegant utility library code that took four hours to write can—and likely will—be reused, and save you hours upon hours.
Meanwhile, the Java hacker will always have +1 hour of coding, because he never learns.
[0]: I realise calling C fun is weird, but I enjoy writing C code, and it's my guilty pleasure, I guess.
It's ironic that the "better" the language (for some hazy definition of "better") the less actual work seems to get done with it. So Go can be pretty annoying at times, and so can Java (I've said before that I find the two almost identical, but that's beside the point now); and C is horrible and completely unsafe and downright dangerous. Yet more useful working code has probably been written in Java and C than all ot…
There are lots of examples like this in Haskell, where you come to a point at which the abstractions provided to you don't work, mostly when the problem has more structure than you can hope to capture in the type system and some generic operations. In an imperative program it is much easier to "teach" or "tell" the computer what to do, when the compiler or language can not do it for you, whereas in a pure functional language you essentially have to give up at that point.
>Ok, it’s only a few characters, big deal. Now what does this do? >b.Mul(b).Sub(big.NewInt(4).Mul(a).Mul(c)) >Or in Haskell >b * b - 4 * a * c umm.. correct me if I'm wrong, since I'm not well versed in either Haskell or Go, but doesnt the Golang version read better in terms of scoping. I mean just by reading the Go version, I know what it will evaluate to, but in the Haskell version I dont know the precedence order…
I do, and I don't even know Haskell: (b * b) - (4 * a * c) edit: I don't know go, but I assume the go example is intentionally unreadable. But complaining about infix multiplication and subtraction is... curious.
Earlier quoted context omitted.
Maybe it already is. That doesn't mean it would happen. People do not genuinely optimize for what they want, they tend to optimize for what they want given what they know today and their internal biases. I'm not willing to claim that Haskell is perfect, but I am willing to claim it is better. I'm also willing to claim that if it had anything resembling the community, say, C# has (to pick a random example) then it'd s…
> People do not genuinely optimize for what they want, they tend to optimize for what they want given what they know today and their internal biases. Absolutely. Which means that there are substantial switching cost, which a slight marginal improvement can't overcome. But if benefits are so immense, they should be able to. I think Haskell's supporters tend to overstate its advantages (and it certainly has plenty of t…
Ultimately, choose the tools with tradeoffs beneficial to your goals, obviously. Engineering of any kind is nothing if not about understanding tradeoffs.
That all said, I do think there are upgrade paths for both technologies—JVM languages with better semantics and "ML-alike" implementations with better runtimes. I'd be more than happy to use either.