Live data from Hacker News

Cold Showers: For when people get too hyped up about things

github.com

161–170 of 243 posts

Re: Cold Showers: For when people get too hyped up about things

#161
post #77

Earlier quoted context omitted.

The study IMHO is reality. Every large, actively maintained system I've ever heard of uses a strongly typed language, or was written in a dynamically typed language but has converted to a gradually typed language. You can't safely refactor without compile time type checking, and you can't maintain a non-trivial system over the long-term if you can't refactor it.

Just write tests and suddenly refactoring is possible without static typing. Those tests will also cover type checking concerns implicitly.

Yeah, except your tests can never prove that your code is fully sound, whereas a good type system can (for some definition of soundness)

Re: Cold Showers: For when people get too hyped up about things

#162
post #66

Earlier quoted context omitted.

It helps a lot with refactoring and many other things even early in the project. For example I‘m using TypeScript with a GraphQL code generator. Now let‘s assume I add a new value to a GraphQL enum. I run codegen, then fix everything until the compiler is happy. Afterwards, all places where this enum was ever touched will take it into account correctly, including mappings, translations, all switch statements, conditi…

You could do the same process if you used dynamic typing and good test coverage. Just make your change and keep fixing tests until everything is green.

Then you essentially are implementing a type checker in your tests, but worse

Re: Cold Showers: For when people get too hyped up about things

#163

"Scalability! but at what COST?" Is a very good example on how frustrating it can be. We are throwing a lot of resources against a problem because we are not able to educate people good enough to understand basic performance optimizations. You are a Data Scientist/anyone else and you don't understand your tooling? You are doing your job wrong.

Maybe the available tooling for extracting good performance is not friendly to people that aren’t already familiar with it?

Re: Cold Showers: For when people get too hyped up about things

#164

It's really hard to point at studies to evaluate these types of hyped development paradigms. Some thoughts, as someone who loves static typing and microservices: My favorite thing about static typing is that it makes code more self-documenting. The reason I love Go specifically is because if you have 10 people write the same thing in Go, it's all going to come out relatively similar and use mostly built-in packages.…

You certainly can throw errors away in Go -- in various ways. It's one of the notable flaws in a largely cohesive, sensible language. (Which I use daily.)

    success, err := fail()
    do(success)

    success, _ := fail()

    fail()

Re: Cold Showers: For when people get too hyped up about things

#165

Earlier quoted context omitted.

Just write tests and suddenly refactoring is possible without static typing. Those tests will also cover type checking concerns implicitly.

Tests can't replace types, just like types can't replace tests. You need both. Types can't check the correctness of everything, but they do prove that certain classes of errors don't exist in your program. Tests, on the other hand, can test for many more types of bugs, but they can only look for errors, they can't prove correctness (except in very small, closed environments where you can literally test every possible…

> they do prove that certain classes of errors don't exist in your program

That's particularly important when refactoring because you want to assert that you haven't introduced new bugs, and the type system will often let you prove that with almost zero effort on your part.

Re: Cold Showers: For when people get too hyped up about things

#166
post #127

Earlier quoted context omitted.

> I am not aware of any hosted SQL technology which is capable of magically interleaving large aggregate queries with live transactions and not having one or both impacted in some way. At the end of the day, you still have to go to disk on writes, and this must be serialized against reads for basic consistency reasons. I do sometimes wonder if dirty reads are what the business folks actually want. Not necessarily unc…

My experience is that customers/executives will accept latency but not inaccuracy. In practice this may be the same thing, it just depends how you position it. “Reports are accurate but may be up to 5 minutes out of date” is a very easy sell to a corporate worker who logs in to check a dashboard once a month. Primary/replica is probably the correct way to solve this. In some places, I have also shunted writes through…

You're absolutely right. But I also find that what customers/executives actually want, and what they say they want, turn out to be different things once you start unpacking them.

And sometimes it's just a matter of framing. Don't say accurate, say, "Accurate to within x%" or "Rounded to the nearest $x" type of thing. But I certainly would never actually pick an argument over it. Sometimes they do know what they want. Other times they really don't, but you still don't get to decide for yourself how the problem is going to be solved.

Re: Cold Showers: For when people get too hyped up about things

#167

It's really hard to point at studies to evaluate these types of hyped development paradigms. Some thoughts, as someone who loves static typing and microservices: My favorite thing about static typing is that it makes code more self-documenting. The reason I love Go specifically is because if you have 10 people write the same thing in Go, it's all going to come out relatively similar and use mostly built-in packages.…

You certainly can throw errors away in Go -- in various ways. It's one of the notable flaws in a largely cohesive, sensible language. (Which I use daily.) success, err := fail() do(success) success, _ := fail() fail()

The second one is pretty intentional - it'd be annoying it were downright impossible.

The first and third one fails on go vet. The first one also fails to compile if you never read from err in the entire function.

Re: Cold Showers: For when people get too hyped up about things

#169
post #79

Earlier quoted context omitted.

I can assure you that I live on the same planet as everyone else posting here. Whether or not I could perform this miracle depends entirely on your specific use cases. Many people who have this sort of reaction are coming from a place where there is heavy use of the vendor lock-in features such as SSIS and stored procedures. If you are ultimately just trying to get structured business data to/from disk in a consisten…

Is SQLite likely to be faster than postgres? In terms of ease of use / admin overhead I consider them mostly equivalent. I thought the main problem with SQLite was it was slow tih concurrent writers. Whereas the "bigger" SQL databases have code that allows concurrent writes.

WAL mode is how you address this problem with SQLite.

See: https://www.sqlite.org/wal.html

"Write transactions are very fast since they only involve writing the content once (versus twice for rollback-journal transactions) and because the writes are all sequential. Further, syncing the content to the disk is not required, as long as the application is willing to sacrifice durability following a power loss or hard reboot."

Re: Cold Showers: For when people get too hyped up about things

#170

It's really hard to point at studies to evaluate these types of hyped development paradigms. Some thoughts, as someone who loves static typing and microservices: My favorite thing about static typing is that it makes code more self-documenting. The reason I love Go specifically is because if you have 10 people write the same thing in Go, it's all going to come out relatively similar and use mostly built-in packages.…

You certainly can throw errors away in Go -- in various ways. It's one of the notable flaws in a largely cohesive, sensible language. (Which I use daily.) success, err := fail() do(success) success, _ := fail() fail()

I suppose my point, more specifically, is that functions return errors instead of opaquely throwing them. Most languages expect you to know where they're going to occur and catch them as close to their occurrence as possible, in Go you are explicitly carrying them along the whole way. Some people don't like this, I prefer it.

True, if you completely ignore the function's return values, you can throw errors away, but then you wouldn't be using the language in the way that makes it powerful to me; that there are simple and clear interfaces that you interact with.

Post reply on HN