Earlier quoted context omitted.
We'd love to receive these test cases as pull requests if you have the time to contribute them. :) https://github.com/TechEmpower/FrameworkBenchmarks
checking out the documentation now. is there a google group or some place I can post questions to if I need help?
Frameworks Round 6
131–135 of 135 posts
Re: Frameworks Round 6
#132Earlier quoted context omitted.
This seems like a decent, helpful comment to me. Don't know why it received two vitriolic replies.
Because it's completely factually wrong. Go is not AT ALL dynamically typed.
Go is more dynamically typed than Haskell. That is, it leaves nullability to runtime. It leaves parameteric polymorphism to runtime.
Whenever there's a static type that Go cannot express (and there are plenty of those!) it is effectively dynamically typed about that property.
Re: Frameworks Round 6
#133Earlier quoted context omitted.
On the dynamic..static axis, Go is much closer to the dynamic side than to Haskell's side. I am not a teacher or researcher, I am a practicing programmer writing code that is used by critical systems as well as ambitious projects that will (hopefully) be used by many real people. A red black tree is just an example with invariants that everyone is likely to know, so it's a nice way to illustrate the point about the p…
Ok, look, I understand that you spent a lot of time learning Haskell, and desperately want that time to not have been in vain. You have to back off the preaching though. The conversation you joined wasn't about Haskell. You barged in and made it about Haskell. On the way, to justify your comments, you have put forth some pretty ridiculous claims. Go being dynamically typed, Haskell being 30-50% quicker to develop in,…
I don't need to "want that time not to have been in vain", I am already developing with Haskell and reaching extremely high productivity levels. What I want is for people to spend less time improving the eco systems of poorly designed languages that repeat past mistakes.
Go is more dynamically typed than Haskell. It isn't a 0/1 thing. Parameteric polymorphism is dynamically typed in Go. Nullability is dynamically typed in Go. These are huge parts of the languages.
Instead of engaging in a discussion, you're repeating mistakes in a condescending tone.
Your last part of the comment is only appropriately responded by "You are giving the Go community a bad image by pounding me with ignorance with every reply, I kindly request that you study the matter before replying further".
Re: Frameworks Round 6
#134Earlier quoted context omitted.
> I'm not saying you write tests to protect against NPEs. I'm saying that you write tests to ensure correctness of your code, and as a side-effect NPEs are flushed out of your code. This is my theory explaining why NPEs are not a timesink for me. You never know when you have enough coverage to rule out NPEs or any other bug. And to get confidence about lack of NPEs you want to have coverage of all lines involving der…
> You never know when you have enough coverage to rule out NPEs or any other bug. And to get confidence about lack of NPEs you want to have coverage of all lines involving dereferences, which means you need near 100% test coverage to have a reasonable level of confidence. This is not true. In the example I spoke about above, if I take a CacheClient, and a ServiceXClient when my type is being constructed, assign them…
I guess to progress from here we'd need to laboriously compare actual example pieces of code. For example a URL shortener is going to be easier to write safely in Haskell, where I am guaranteed by the type system not to have 404 errors in routes I advertise, or XSS attacks.
Also, in my experience, computer software is buggy, unreliable, crashing, and generally terrible. I think people who view software differently have simply grown accustomed to the terribleness that they can't see it anymore.
Also, reliability is interchangable with development speed. That is, you can trade one for the other. So if you start with a higher point, you can trade more for speed and still be reliable. In unreliable language, typically reliability is achieved by spending more time maintaining test code, doing QA, etc. In a reliable language more resources can be spent doing quicker development, and less on testing and QA.
When you see a reliable project implemented using unreliable technology, you know it's going to scale poorly and require a lot of testing.
Re: Frameworks Round 6
#135Earlier quoted context omitted.
Because it's completely factually wrong. Go is not AT ALL dynamically typed.
Go is more dynamically typed than Haskell. That is, it leaves nullability to runtime. It leaves parameteric polymorphism to runtime. Whenever there's a static type that Go cannot express (and there are plenty of those!) it is effectively dynamically typed about that property.
Right, Go doesn't have sum types for example. (Or at least, it didn't. Does it now?)