Live data from Hacker News

Cold Showers

github.com

221–230 of 363 posts

Re: Cold Showers

#221

Earlier quoted context omitted.

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.

The argument is - engineers are expensive so why pay for the expertise to setup and run machines? There's just so many better things for your company to be spending the money on.

What if my company is pretty much all engineers?

We don't let pencil pushers with MBAs anywhere near what we're doing, and it's going great.

I know this isn't the most usual configuration but if undervaluing my skills and trying to bottom dollar on them is going to be their rules, then I'm just going to do my own thing, and they're just going to have to scrape the bottom of the barrel for talent.

I hope the zeitgeist changes any time soon. God knows how many unicorns have been sacrificed with that kind of paradigm which could be successful companies by now.

Re: Cold Showers

#222
post #198

Earlier quoted context omitted.

People nearly always gravitate towards abbreviations in natural language. The more a word is used, the more likely it gets shortened. LA for Los Angeles, Frisco for San Francisco, Vicki for Victoria, Jay for Jason, Dub for George W Bush, Doozy for Duesenberg, and on and on. Why should programming be different?

> Frisco for San Francisco wait what. I live in SF and everybody just says SF

I've heard SF, SanFran, Frisco, and Cisco.

Re: Cold Showers

#223
post #79

Earlier quoted context omitted.

Allegedly? Have you ever written code in a dynamically typed language? I'm forever fixing TypeErrors and AttributeErrors and the like. I suppose it's not even necessary to argue about experience fixing them or not, just the fact that those are runtime errors rather than compile-time (and so we presume not shipped) shows it reduces bugs doesn't it?

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.

The presence or absence of a compilation stage has nothing to do with static typing. Flow.js is static typing. MyPy is static typing. It sounds like your JSDoc comments are static typing, if your IDE ends up passing them through the TypeScript type checker in JS mode.

It may not be very comprehensive static typing but it is static typing none-the-less.

Re: Cold Showers

#224

Earlier quoted context omitted.

The argument is - engineers are expensive so why pay for the expertise to setup and run machines? There's just so many better things for your company to be spending the money on.

What if my company is pretty much all engineers? We don't let pencil pushers with MBAs anywhere near what we're doing, and it's going great. I know this isn't the most usual configuration but if undervaluing my skills and trying to bottom dollar on them is going to be their rules, then I'm just going to do my own thing, and they're just going to have to scrape the bottom of the barrel for talent. I hope the zeitgeist…

>What if my company is pretty much all engineers?

I don't know how that changes the equation. No one is undervaluing your skills; it's would you rather spend your time driving to a colo center to replace a RAID array or working on $product.

With AWS you are outsourcing an IT team, not just processors and how you approach pricing should reflect that.

Re: Cold Showers

#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.

Re: Cold Showers

#226
post #216

Earlier quoted context omitted.

I would even argue that shorter can do the opposite. You can squeeze an awful lot of information into a tight space in dynamically typed languages that allow functional programming and especially with terse syntax for often used constructs. This can make it much harder to actually reason about the code, while making it seem easier to reason about. Most people would agree w/ your reasoning on a short piece of logic, w…

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 to check that function, which might be coming from I don't know where, I might not even have an IDE that can reliably determine where `doSomethingWith` is coming from exactly. Even if I can navigate there now I have to check that piece of code and any other code it calls with `property`. Maybe `property` itself is an object and `doSomethingWith` assumes it has yet another property. This can easily go quite deep and I will not be able to easily reason about this at all. You can't tell me that someone can have all possible runtime combinations of this in his head for any reasonably sized program.

Now let's take something that is almost equal but slightly longer to read and write, same thing in Typescript. I've had to define the types of these things somewhere once. Big deal.

    const myFunc = (param: SomeType) => {
        doSomethingWith(param.property);
    }
Notice how this is really not much of a difference. Just a type declaration and it gives me a lot of safety. Let's assume SomeType defined `property` as non-null, so no `?` needed, I know my inputs have already been checked. `doSomethingWith` also defines its parameter type correctly and we know what `property` is or isn't. No need to know anything from the top of my head or spend time digging through code myself. The compiler knows that I am passing the correct type of object along and I won't get a runtime error (well, OK, it's Typescript, so let's also assume I'm not in a mixed TS/JS code base where I might very easily get `any` kind of object.

Now syntax will be a little bit different, but I would argue the exact same thing in say Java or Kotlin is equivalently short and readable (yes even in Java!) while benefiting from even more type safety:

    public myFunc(SomeType param) {
        doSomethingWith(param.getProperty());
    }
Didn't really hurt much, did it?

But these are super simple example. It get can arbitrarily complex.

Re: Cold Showers

#227
post #206

Earlier quoted context omitted.

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.

You are right. I should have said some. The point I wanted to make was that having type safety is better for checking null than having no type at all.

Re: Cold Showers

#228
> Compared to other languages, Go's concurrency system of goroutines and channels is easier to understand, easier to use ...

True and not a hype: Compared to other languages, Go has a runtime and built-in concurrency primitives that makes it easier to write concurrent code.

> and is less prone to bugs and memory leaks.

Who is actually claiming this? I've got a collection of good Go resources and nowhere something like this is stated. In contrast, some actually make it very clear to be very careful when sharing memory or actually better no sharing memory at all.

Concurrency is conceptually hard in Java, C#, Javascript, Python, C, C++ ... there's no reason to bully Go.

Rust makes the claim of "fearless concurrency" and the compiler indeed saves us from race conditions, but those are not the only concurrency related bugs, e.g. deadlocks are very well possible in Rust. Therefore Rust would be a proper candidate on this "Cold Showers" list.

Re: Cold Showers

#229

> Compared to other languages, Go's concurrency system of goroutines and channels is easier to understand, easier to use ... True and not a hype: Compared to other languages, Go has a runtime and built-in concurrency primitives that makes it easier to write concurrent code. > and is less prone to bugs and memory leaks. Who is actually claiming this? I've got a collection of good Go resources and nowhere something lik…

[deleted]

Re: Cold Showers

#230

> Hype: "Static Typing reduces bugs." It’s only hype because it’s imprecisely stated. Static type systems make entire classes of bugs impossible at runtime. The stronger (read less permissive) the type system, the more classes of bugs cannot occur.

On the other hand it increases development time and makes modifications and new features much harder to implement. If you took it to the extreme, you could also mathematically prove your code is correct for every input variable. Everything's a trade-off, the question is which approach is best for your application. Your average website doesn't warrant as much rigor as a Mars rover.

Okay please debug my py2 -> py3 migration bytes vs strings code with no type annotations.

Aaaahg it burns. I basically am going through and first annotating, then upgrading.

Post reply on HN