Live data from Hacker News

Cold Showers

github.com

201–210 of 363 posts

Re: Cold Showers

#201

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

I don't use AWS for a damn thing because of exorbitant costs. I just don't get why people think that it's necessary other than that they're the types to get drawn into marketing hype.

There's just so many better things for your company to be spending the money on.

Re: Cold Showers

#202
post #123

Earlier quoted context omitted.

I've never found static typing to aid in my understanding of a program. For example: def add_item_to_cart(item) vs void add_item_to_cart(IItem item) They are equally easy to understand. The first is easier to read.

What is an item in the first declaration? Is it an id? Is it an object (if so, what type of object? Id and qty or some other data)? I guess you now need to read through the implementation or docs. The first is much easier to read incorrectly .

What is an item in the second declaration? That it has type "Item" doesn't help you unless you have contextual information. And if you have contextual information you can probably figure out what an item is in the first declaration too.

Re: Cold Showers

#203

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

https://adamdrake.com/command-line-tools-can-be-235x-faster-...

Oh yeah I love simply avoiding memory allocation at all costs and keeping things to the processor cache and streaming APIs. awk/sed is fantastic for this if you're just working with CSV data, but I've done it in my own custom code processing hundreds of gigabytes of JSON in seconds as well.

I think data scientists just aren't really hugely concerned with programming optimizations or bottlnecks or whatever. Most of them are just intermediate-level python programmers, and that's completely fine until they think they need a hadoop cluster for whatever they're doing and the costs start piling up.

Re: Cold Showers

#204

Earlier quoted context omitted.

I always notate my functions with JSDocs and my DTOs as jsdoc types which in any modern IDE gives you the same advantages that you would get out of the explicit typescript interface/type. And Unlike typescript my code doesn't need to be transpiled at all since it is already vanilla JS.

Discipline doesn't scale. https://www.sicpers.info/2020/10/discipline-doesnt-scale/ Add 10 people to your project and start forgetting some docs or failing to update them.

> Discipline doesn't scale.

I want a shirt with this on it.

Re: Cold Showers

#205
post #77

Earlier quoted context omitted.

One could argue that dynamically typed code is often shorter, and therefore both easier to reason about, and possessed of fewer bugs on a bugs-per-line basis. Not really keen to push that line of reasoning myself, just helping picture one possible argument.

As a Haskell programmer, this argument does not resonate with me. I find most dynamically typed languages (e.g., JavaScript) verbose compared to what I'm used to. Of course, plenty of statically typed languages are verbose too. But static typing is not a sufficient condition for a language to be verbose. I associate verbosity with object-oriented programming, whether statically typed or not.

As a clojure programmer, I'd say the same of Haskell. Oop is less expressive than FP, and static typing is less expressive than dynamic typing. These are usually just tradeoffs people choose for their problem domain

Re: Cold Showers

#206

Earlier quoted context omitted.

> A type system can keep you from having to write those tests. Because with a proper static lang (hint: not Java, not C#), nil doesn't exist? Right.

They all have nulls but a static lang will warn you that the value can be null.

This is false. There are plenty of languages without pervasive implicit nullability. Check out Haskell and Rust and Ocaml.

Re: Cold Showers

#207

>Hype: "Static Typing reduces bugs." Oof, that one is a huge can of worms.

Refactor any js code to typescript. You’ll see how many bugs are discovered and how many wtfs!

Re: Cold Showers

#208

Earlier quoted context omitted.

As a Haskell programmer, this argument does not resonate with me. I find most dynamically typed languages (e.g., JavaScript) verbose compared to what I'm used to. Of course, plenty of statically typed languages are verbose too. But static typing is not a sufficient condition for a language to be verbose. I associate verbosity with object-oriented programming, whether statically typed or not.

As a clojure programmer, I'd say the same of Haskell. Oop is less expressive than FP, and static typing is less expressive than dynamic typing. These are usually just tradeoffs people choose for their problem domain

> static typing is less expressive than dynamic typing

Here's something I can express with static typing that I can't express with dynamic typing: "this function returns a function which returns an integer for every input". There's no test you could write to verify this property. So I'm inclined to say that static typing is more expressive, since it gives me a way to express and verify properties like this.

Re: Cold Showers

#209

Earlier quoted context omitted.

I can't speak for all Ruby developers but I found that I could read a pull request from just about anyone I worked with a and find a spot where they hadn't covered a possible nil with a test. And yes, we had coverage checks. A type system can keep you from having to write those tests.

> A type system can keep you from having to write those tests. Because with a proper static lang (hint: not Java, not C#), nil doesn't exist? Right.

Doesn't C# support this by enabling Nullable?

Re: Cold Showers

#210
post #187

Earlier quoted context omitted.

CPU RAM is generally much slower. 8 channels of DDR4-3200 only provide 200GB/s bandwidth. RTX 3090 has 936GB/s. So even 4 socket Xeon won't catch up.

That would only be an advantage if you had to do multiple passes over the data, otherwise the data would still go through the CPU RAM before getting loaded onto the GPU, no?

Definitely the case in the state of the art stuff like neural networks.

Many if not most other algorithms are iterative. Hell, even sorting is.

Post reply on HN