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

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

github.com

Post reply on HN
Print view View original

141–150 of 243 posts

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

#141

Post by zimpenfish »

mumblemumble wrote: post #114
zimpenfish wrote: post #92

Earlier quoted context omitted.

In some respects, I think the constraints of something like SQLite can focus people's attention on making things work properly rather than throwing hardware at the problem. I can think of a couple of places I've worked where they had simple problems that could have been solved by some thinking and coding but instead were solved* by more expensive hardware.

The last time I reduced database server load by 70% by just spending a week tuning indexing strategies and ill-performing queries, nobody thanked me. Sure, a new database server costs way more than a week of my time, but that is completely beside the point. The point is that I robbed someone of the chance to buy a shiny new computer.

> The last time I reduced database server load by 70% [...] nobody thanked me.

It's crazy. I could maybe understand if there's a time crunch where it's quicker and easier to get more hardware in order to make a sale that'll keep the company alive (which I have experienced once) but that's maybe 1% of the cases.

Anyway, in lieu of their gratitude, I offer my thanks because I appreciate the effort.

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

#142

Post by qznc »

mbrock wrote: post #41
pydry wrote: post #34

Earlier quoted context omitted.

My biggest issue with formal verification after doing it a couple of times was how absurdly complex the specification needed to be for it to work. If the spec is 5x more complicated than the code would be then I'm not sure I see much of a point coz you're just creating different spaces for bugs to hide in.

The aim is to have a spec that is much LESS complex than the code, written at a higher level, abstracting away details. If the spec is 5x more complex than the code then indeed there’s no point.

Here is a counter argument: http://www.pathsensitive.com/2018/10/book-review-philosophy-...

My summary would be: The spec must cover all possible implementations so it is usually larger than the most simple one.

An example from there:

> The authors of SibylFS tried to write down an exact description of the `open` interface. Their annotated version of the POSIX standard is over 3000 words. Not counting basic machinery, it took them over 200 lines to write down the properties of `open` in higher-order logic, and another 70 to give the interactions between open and close.

> For comparison, while it’s difficult to do the accounting for the size of a feature, their model implementation is a mere 40 lines.

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

#143

Post by teddyh »

nafey wrote: post #136
albntomat0 wrote: post #131

Earlier quoted context omitted.

They are not the same, at least according to the definitions I'm familiar with. Static/dynamic is whether type checking is done at compile time or run type. Strong/weak is how flexible the language is with type conversion. Another explanation: https://en.hexlet.io/courses/intro_to_programming/lessons/ty...

Are these dimensions orthogonal though? For example is there any Strongly typed dynamic language?

I think Python is mentioned as the usual example.

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

#144

Post by wtetzner »

archarios wrote: post #128
jdm2212 wrote: 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.

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 combination of inputs and outputs).

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

#145

Post by elric »

fmakunbound wrote: post #61
rwoerz wrote: post #28

We software engineers are still more like alchimists rather than chemists. That list reminds me of [1], which rants about this state of affairs and [2] that puts many beliefs to the test. [1] https://youtu.be/WELBnE33dpY [2] https://www.oreilly.com/library/view/making-software/9780596...

In addition to that, I also feel calling ourselves engineers is a stretch.

I've always considered "engineer" to be more of a personality trait than a formal qualification. Most engineers I've met (whether Software, Bio, Civil or whatever) have a similar mindset to my own, although that might be selection bias at play. There's a sense of curiosity and wanting to understand, not in an academic way, but by virtue of doing.

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

#146

Post by elbear »

nafey wrote: post #136
albntomat0 wrote: post #131

Earlier quoted context omitted.

They are not the same, at least according to the definitions I'm familiar with. Static/dynamic is whether type checking is done at compile time or run type. Strong/weak is how flexible the language is with type conversion. Another explanation: https://en.hexlet.io/courses/intro_to_programming/lessons/ty...

Are these dimensions orthogonal though? For example is there any Strongly typed dynamic language?

Python is considered strongly typed, but usually it's placed in opposition with PHP or JavaScript. That's why I don't understand why the previous poster used strongly typed. The conversation was about static and dynamic programming languages.

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

#147

Post by hodgesrm »

castorp wrote: post #86
bob1029 wrote: post #71

Earlier quoted context omitted.

We aren't running any reports on our databases like this. I would argue it is a bad practice in general to mix OLTP and OLAP workloads on a single database instance, regardless of the specific technology involved. If we wanted to run an aggregate that could potentially impact live transactions, we would just copy the SQLite db to another server and perform the analysis there. We have some telemetry services which ope…

> 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. No, absolutely not. That's why modern databases use a thing called multi version concurrency control. You can run (multiple) queries on the same table that is updated by multiple transactions at the same time without one blocking the others (assuming the write transactions don't bl…

OLTP databases are optimized for mutable data. OLAP databases are optimized for immutable data. There's a big difference between appropriate data structures for each use case that has little to do with hardware capabilities.

OLAP databases tend to write columns in large blocks and apply sort orders to improve compression. This type of structure works well if you write the data once and read it many times. It's horrendously inefficient for concurrent updates to things like user session contexts. (Or even reading them for that matter.) You are better off using a row store with ACID transactions and relatively small pages.

The dichotomy has been visible for decades and shows no sign of disappearing, because the difference is mostly how you arrange and access data, not so much the hardware used.

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

#148

Post by tome »

Tyr42 wrote: post #68
simiones wrote: post #49

Earlier quoted context omitted.

I think the general feeling is that there are some code patterns that are safe and easy to do with dynamic typing, but impossible with simple type systems or more complex with more advanced type system. An example would be Common Lisp's `map` function [0] (it takes a number of sequences and a function that has as many parameters as there are sequences). It would be hard to come up with a type for this in Java, and it…

Haskell's not too bad once you understand ZipList http://learnyouahaskell.com/functors-applicative-functors-an... max ZipList [1,2,3,4,5,3] ZipList [5,3,1,2] > [5,3,3,4]

Yeah it's not at all complicated in Haskell. I'm not sure what GP is talking about.

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

#149

Post by david-cako »

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. Any API requests are going to be self-documenting, because you have to write a struct to decode them into. Any function has clear inputs and outputs; I can hover a parameter in my IDE and know exactly what's going on. You can't just throw errors away; you always are aware of them, and any functions you write should bubble them up.

Typescript addresses this somewhat, but basically offsets that complexity with more configuration files. I like Typescript in use, but I can't stand the fact that Javascript requires configuration files, transpilers, a million dependencies. Same for Python and mypy.

Yes, I could just look at class members in a dynamic language, but there's nothing that formally verifies the shape of data. It's much more annoying to piece apart. I don't use static analyzers, but my guess is that languages like Go and Rust are the most compatible with them. Go programs are the closest thing to a declarative solution to a software problem, of any modern language IMO. As we continue experimenting with GPT-generated programs, I think we're going to see much more success with opinionated languages that have fewer features and more consistency in how finished programs look.

Microservices are also great at making large applications more maintainable, but add additional devops complexity. It's harder to keep track of what's running where and requires some sort of centralized logging for requests and runtime.

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

#150

Post by pragmatic »

I think functional reactive programming belongs on this list.

Rxjs, etc.

Angular uses typescript and rxjs excessively and, while I used to like typescript, the combo has made me reconsider.

Rxjs send like an overcomplex way to do common tasks. Has RRP caught on anywhere else? Is there a usage that doesn't suck?

Post reply on HN