Live data from Hacker News

Cold Showers

github.com

311–320 of 363 posts

Re: Cold Showers

#311

> 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…

The problem is everyone thinks they're good at naming when they're the one writing the names, but it turns out everyone is terrible at naming when you're the one reading the names.

Names evoke ideas, and this is very subjective. So "self-documenting names" can turn into "misleading names" in a hurry. The name "x" never misleads because it evokes nothing.

Re: Cold Showers

#312

> Static Typing reduces bugs. This matches my experience. People say otherwise might need to put more effort on writing better tests. That said static typing usually catch minor problems like typo faster. But for dynamic typing it's going to catch by tests a bit later. But usually tests run faster with dynamic languages, so it's a tradeoff. My favorite approach is the mixed approach like TypeScript: 1. Faster feedbac…

Why not have static typing and an IDE catch the issue before you run the test?

Re: Cold Showers

#313
post #296

Earlier quoted context omitted.

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 a…

Now we are just talking about using a sane naming convention for your types. Depending on the paradigm you are working in your instance of IBlaha has a consistent definition - in a trait or a class or whatever else you like. It also likely makes simple work for your IDE during refactoring as others have observed. You don’t get this from dynamic typing.

Of course you could say the same thing about sane naming dynamic naming conventions for your declarations in a dynamically typed language - and you wouldn’t be wrong, but a compiler won’t help you in the case of human error. All I’m interested in is offloading as much complexity onto the tools at my disposal, so I can focus on what’s important.

On my citation … that was tongue in cheek and I thought it was obvious. I don’t have a citation, this is all my own experience. For the third time, if you can work your way around this you have my respect.

Re: Cold Showers

#314
post #84

For me the biggest advantage of static typing is that it allows to safely refactor code. Without it even with extensive unit test coverage refactoring often is just not an option.

So many people in the thread saying this. But in my experience refactoring large code bases in both Java and Javascript, it's roughly the same. Ultimately the real answer will have to come from a peer reviewed study, because as the post suggests, these sorts of things are not as intuitive as people think

Anecdotes don't really count for much, of course, but the balance is against you, here. It is clearly and evidently true that when you refactor, static typing systems find a lot of errors that you would discover at runtime in dynamically-typed systems. It's true almost by definition.

It can still be fine if you're being meticulous and know the codebase well enough, but otherwise, you'll miss corner cases in parts of the code with less test coverage or typical interaction. When you accidentally occasionally have a string in place of a number deep in some data structure, you might not notice for a long time.

Re: Cold Showers

#315
post #313

Earlier quoted context omitted.

> 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 a…

Now we are just talking about using a sane naming convention for your types. Depending on the paradigm you are working in your instance of IBlaha has a consistent definition - in a trait or a class or whatever else you like. It also likely makes simple work for your IDE during refactoring as others have observed. You don’t get this from dynamic typing. Of course you could say the same thing about sane naming dynamic…

Sure, the type IBlaha is defined somewhere just as the object(s) passed to add_item_to_cart are also defined somewhere. Again: "That it has type "Item" doesn't help you unless you have contextual information." It has nothing to do with naming conventions. Whatever simplistic tools does is irrelevant since this sub thread was about the meaning of two declarations in HN comment.

Dynamically typed languages are very popular so it seems that many developers can work their way around dynamic typing.

Re: Cold Showers

#316

Earlier quoted context omitted.

So you saved, $28,400 a month. Did that make a material difference to the company? I often tell people above me I could save us $10k a month at AWS and generally the response is, "Yeaaaaaaah that's great, could you do XYZ instead to help us land an additional $1M in ARR?"

$340,800/year. If that doesn't make a material difference to your company or department you've never worked where cash is tight. More bluntly: you've been spoilt with excess resources. That's a lot of cash to waste.

I know how to multiply by 12, thanks. I asked the previous commenter if the $340,800 actually made a difference and he hasn't replied.

Re: Cold Showers

#317

Earlier quoted context omitted.

So you saved, $28,400 a month. Did that make a material difference to the company? I often tell people above me I could save us $10k a month at AWS and generally the response is, "Yeaaaaaaah that's great, could you do XYZ instead to help us land an additional $1M in ARR?"

The people above you suck. That's a terrible attitude. Signalling that saving money or just generally improving systems doesn't matter will not build a culture of technical excellence and ambition. Also, it's not peanuts. How many extra developers are $28400 per month?

> The people above you suck.

No, actually they don't. In the time I've been there they've 10x the size of the company. Maintained majority control through multiple rounds of funding. Significantly increased salaries. Provided a great work life balance. Etc.

Why are developers obsessed with how many additional developers they could hire with hypothetical savings?

Re: Cold Showers

#318

Earlier quoted context omitted.

So you saved, $28,400 a month. Did that make a material difference to the company? I often tell people above me I could save us $10k a month at AWS and generally the response is, "Yeaaaaaaah that's great, could you do XYZ instead to help us land an additional $1M in ARR?"

$340,800/year. If that doesn't make a material difference to your company or department you've never worked where cash is tight. More bluntly: you've been spoilt with excess resources. That's a lot of cash to waste.

There's now an entire generation of programmers, all the way up through senior/staff level, that's known nothing but the free-money era.

It will be an interesting next few years.

Re: Cold Showers

#319

> 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…

I built this decision tree (LightGBM) compiler last summer: https://github.com/siboehm/lleaves It get's you ~10x speedups for batch predictions, more if your model is big. It's not complicated, it ended up being <1K lines of Python code. I heard a couple of stories like yours, where people had multi-node spark clusters running LightGBM, and it always amused me because by if you compiled the trees instead you could ge…

Wow, very interesting, thanks for this. Daily batch predictions is all we do. I’m the maintainer of miceforest[1], do you think this would integrate well into the package at a brief glance? I’m always looking for ways to make this package faster.

[1] https://github.com/AnotherSamWilson/miceforest

Re: Cold Showers

#320

Earlier quoted context omitted.

$340,800/year. If that doesn't make a material difference to your company or department you've never worked where cash is tight. More bluntly: you've been spoilt with excess resources. That's a lot of cash to waste.

I know how to multiply by 12, thanks. I asked the previous commenter if the $340,800 actually made a difference and he hasn't replied.

I can't speak for him, so for myself: some years ago I had to almost beg for a new disk for a server. A disk. I didn't even bother to ask if we could have a bigger server, no point trying.
Post reply on HN