Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cold Showers

github.com

Post reply on HN
Print view View original

301–310 of 363 posts

Re: Cold Showers

#301

Post by yen223 »

ReactiveJelly wrote: post #180
moffkalast wrote: post #147

Earlier quoted context omitted.

> bugs that would have been caught by a type checker Type checking also introduces its own set of additional bugs by the virtue of object incompatibility, that do not exist at all in dynamically typed languages (or are handled correctly every time by the compiler/interpreter automatically). Take as an example exchanging objects over sockets, rest, files, etc. Whenever the object definition changes in another piece of…

> exchanging objects over sockets, rest, files, etc. Whenever the object definition changes in another piece of the software stack the statically typed parts will crash upon receiving the updated objects, even if it's just one new param added that would've been fine otherwise if dynamically typed Anecdotally, this is not true for C++ using JSON or msgpack, since those are self-describing formats where extra fields ar…

The protocol buffers approach is quite interesting. With proto3, there's basically no such thing as a "required" field anymore. All fields are now optional.

Now, being able to assert that a field is present in an object is a basic and valuable use-case for static typing. However, the developers felt that even this basic level of static type checking added too much friction whenever they had to update systems.

https://capnproto.org/faq.html#how-do-i-make-a-field-require...

Re: Cold Showers

#302

Post by arendtio »

roeles wrote: post #278

I am particularly surprised by the agile statements. I wonder if this flies in the face of the "state of DevOps" reports some people wave around.

I just watched the whole video and only agree with about 20% of the arguments. It feels a bit like Bertrand Meyer is missing the point of Agile. Yes, a bit of upfront understanding of the problem domain certainly is a good idea, but IMHO he is missing the point, that user stories are an instrument to support communication.

He treats them like an incomplete requirements document, but instead they should just contain the bullet points so that the people who talked about the issue still remember what they talked about. In a typical requirements document the communication form is written, whereas in case of user stories the communication form is verbal and the document is just there to help people to remember.

Re: Cold Showers

#303

Post by davnn »

VWWHFSfQ wrote: post #110
CapmCrackaWaka wrote: post #12

> Benchmarking cutting-edge graph-processing algorithms running on 128-core clusters against a single-threaded 2014 Macbook Pro. The laptop consistently wins, sometimes by an order of magnitude. LOL, this hits close to home. My company had a modeling specific VM set up to run our predictive modeling pipelines. Typical pipeline is about 50,000 to 5 million rows of training data. At best, using an expensive VM, we mana…

Haha! Back in ~2014 or so my company was spending nearly $30,000/month on an EC2 "compute-optimized" cluster to transcode live video streams to multiple renditions. One of our engineers said hey, why don't we try to colo some real hardware? We did a test with a single bare-metal 8-core Xeon server and it completely destroyed the performance of the EC2 "compute-optimized" cluster! After that we colo'd 4 big Xeon serve…

For some use cases though, the cloud is just amazingly cheap and fast. We are currently scaling our (computationally cheap) batch re-training jobs on AWS Lambda and it‘s quite incredible that you can train thousands of models in parallel with TBs of RAM. There is no on-premise alternative.

Re: Cold Showers

#304

Post by resonious »

fifticon wrote: post #241
cloogshicer wrote: post #14

> Static Typing reduces bugs. At least to me, the big advantage of static typing is not that it (allegedly) reduces bugs, but that it aids my understanding and helps in navigating the program. It's a tool for thinking and communicating.

I'm not against studies and research - I have a computer science degree myself - but I'm a little tired of being told my personal anecdotal evidence is not sufficient to conclude that water is wet. As a professional software developer of 30+ years, the doubts on static types puzzle me. 8 years ago, I started dabbling more in javascript, for one of my continuous pet projects. I had it running and grew it to a consider…

I have far less experience than you and I've definitely experienced drowning in runtime issues when working with a large project in a dynamic language.

On the other hand, though: have you worked with large, thoroughly tested projects in a dynamic language? Personally, I find that good tests catch 99% of the bugs that static types do, plus quite a lot of other bugs as well. Arguably, you ought to write tests anyway to find those other bugs. Since they also find your typos etc, you get to enjoy the ergonomics boost of dynamic typing almost for free.

That's my (also anecdotal) argument for doubting static types.

Re: Cold Showers

#305

Post by wkrsz »

blindmute wrote: post #225

Hype: Your friend says, "Good morning!" Shower: Unfortunately, there is no conclusive peer-reviewed evidence that it is, in fact, a good morning. A randomized trial found that many mornings are bad. Caveats: Only applies to mornings. No rigorous paper exists for evenings, so this remains an unknown.

Caveat: It's unspecified whether the friend wishes reader a good morning, or means that it is a good morning whether reader wants it or not; or that they feel good this morning; or that it is a morning to be good on?

Re: Cold Showers

#306

Post by ncmncm »

tharkun__ wrote: post #226
ncmncm wrote: post #216

Earlier quoted context omitted.

Yes. Shorter means less to compare against for consistency.

My point is exactly the opposite. Shorter does not always equals easier, less to do etc. Let's say we compare Javascript and Typescript (as they're so close but one has static typing. const myFunc = (param) => { doSomethingWith(param?.property); } Easy, right? Well, does param actually have `property`? No idea. What type is `property`? Does the function `doSomethingWith` take that kind of input? No idea. Now I have t…

It would be hard for me to agree more.

But Java, Kotlin, and Typescript types are very weak sauce. When types can do more, we can do more with them.

Re: Cold Showers

#307

Post by ehnto »

edanm wrote: post #248
fifticon wrote: post #241

Earlier quoted context omitted.

I'm not against studies and research - I have a computer science degree myself - but I'm a little tired of being told my personal anecdotal evidence is not sufficient to conclude that water is wet. As a professional software developer of 30+ years, the doubts on static types puzzle me. 8 years ago, I started dabbling more in javascript, for one of my continuous pet projects. I had it running and grew it to a consider…

> [...] I'm a little tired of being told my personal anecdotal evidence is not sufficient to conclude that water is wet. The problem is, other people with just as many credentials as you have the opposite experience. From an outsider's perspective, two people with equal authority say opposite things, what can they possibly do except an independent study? Also, note that there's a reason anecdotal evidence is not alwa…

I suppose what they can do is write some code and figure out where their specific situation lands them on the Static Typing is good/bad spectrum.

In this scenario, I honestly don't think it matters whose objectively right. Software is not a clean, normalized and organized set of use cases after all, maybe static typing works for person X and doesn't for person Y because of their background, or preferences, or codebase requirements, and so on.

Maybe one day we can conclusively prove that on aggregate static-typing/{insertThingHere} is overall less buggy, but even if we did, it'll still change depending on circumstances.

Re: Cold Showers

#308

Post by ehnto »

drujensen wrote: post #101
sumy23 wrote: post #62

Earlier quoted context omitted.

It’s basically self-evident that static analysis reduces bugs. It’s trivial to construct an example of where type information would catch a bug. Unless there is some reason that including type information increases bugs, the existence of a single example where type information catches a bug would prove that overall type information reduces total bug count.

This reminds me of the studies done related to traffic lights and stop signs. Removing traffic lights and stop signs actually reduces accidents because drivers are more careful when driving through intersections which reduces speeds and drivers become more alert. Developers will adapt to their toolset. If you have a statically typed language, you trust it will deal with type related issues and you become more lax wit…

That's a good analogy, because just like when an intersection gets enough throughput, relying on drivers to navigate their way through becomes unrealistic. Once a codebase reaches a certain size or complexity, it starts becoming really time consuming to follow untyped logic all over the place and you run the risk of a rockstar developer putting a scooter object into the side door of your minivan object.

Static typing gives you assurances and tools with which to test your assumptions in the code, for those times when reading the whole stack is cumbersome, and you need to defend against less careful developers. It also transfers a bit of knowledge between developers in a trivial way that would otherwise be a pain to communicate.

Re: Cold Showers

#309

Post by ehnto »

laserlight wrote: post #128

> Hype: "Identifiers should be self-documenting! Use full names, not abbreviations." > Shower: Researchers had programmers fix bugs in a codebase, either with all of the identifiers were abbreviated, or where all of the identifiers were full-words. They found no difference in time taken or quality of debugging. That's a very weird take on the statement. The downside of using abbreviations is probably dominated by the…

Maybe I could get it done in the same time, but I'd be really annoyed, and less certain what things are intended for. An IDE can really carry the burden figuring out what things are, but you're going to lack some context.

Usually it doesn't matter WHAT things are, I need to know WHY you have a variable, and what it's intended use is. That can be explained in the variable name a lot of the time.

I have the same argument against the no-comments evangelists, and wanting to squash all commits into one when they're merging. Yes you can read the code diff, but that only tells you what, not why, something was changed. Why did the API endpoint change? Why do we have to call the payment processor before this event rather than after all of a sudden? Why did the add to cart button move up one div? All very useful information when you have to come back to fix things.

For the no-comments evangelists, I understand the idea is to make the code as self-documenting as possible, and that's awesome, but you can still miss out on the why, and sometimes the Why is entrenched in external business requirements that aren't in the code.

Re: Cold Showers

#310

Post by bjourne »

kdtsh wrote: post #296
bjourne wrote: post #295

Earlier quoted context omitted.

That fact is useless without any context. An "item" could have been an "Ifdkjsj" and you'd be none the wiser. "incredible amount of mental overhead" needs a citation and, as shown in TFA, no citation exists.

Maybe I’m not understanding where you’re coming from because as far as I can tell a ‘lfdkjsj’ and a ‘skfjwb’ which are both an IItem, or both a IWhcjwp, is easier to work with than the dynamic alternative. Regardless of how poorly named a variable is, in a static ruling system what you see is what you get, where as in a dynamic typing system what you see could be anything at runtime. The only citation I have is the t…

> in a static ruling system what you see is what you get, where as in a dynamic typing system what you see could be anything at runtime.

What you see in a statically typed language: IBlaha blah. What could blah be? An IBlaha. What could IBlaha be? Anything! The type has not gained you anything.

> The only citation I have is the tenuous grip I have on my own sanity

That's an argument from authority where you are the authority. It doesn't work on HN since we are all skilled developers. I've also been a software developer for decades and I can count on one hand the times static types has provided a tangible benefits.

Post reply on HN