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

121–130 of 243 posts

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

#121

Post by wccrawford »

albntomat0 wrote: post #54
wccrawford wrote: post #31

Earlier quoted context omitted.

It depends on the situation. I've had code that absolutely benefited from static types and it helped me find bugs before they happened. But my current job has very, very little that would benefit from static typing. Adding it into the mix would slow us down, both literally and figuratively.

> But my current job has very, very little that would benefit from static typing Would you mind expanding on this? I'd be interested in what processes you have and if you use any additional tooling. Thanks!

Most of what we do is just data input and data display. And most of that is text. There aren't really any calculations or anything, beyond some simple sizing of UI stuff.

For database stuff, an ORM with some validation rules is generally enough, and couldn't be replaced with static typing anyhow.

For anything that absolutely has to be a certain kind of data, there are things built into dynamic languages to check the type of something, and you just call it as needed on a case-by-case basis.

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

#122

Post by the_af »

nicoburns wrote: post #109
GlennS wrote: post #23

Earlier quoted context omitted.

People who like static typing seem to really like static typing. I'm honestly not convinced it helps that much. And it seems to cost a lot to me. I like database and API schemas though. And I like clojure.spec and function preconditions a lot.

I hated statix typing until I used Rust. Rust has Sum types (super powered enums), which provide what I was missing from dynamically typed langauges in languages like Java, C#, etc: namely the ability to have an "or" type (e.g. this is an integer or a string, and I want to be able to branch on that at runtime). That, plus type inference makes the static typing pretty painless.

Agreed. Do note that many other languages before Rust do provide good static typing with the niceties you'd expect (and that are often missing from Java), such as type inference, sum types, etc. Some examples include, but are not limited to, Scala, Haskell, the ML family of languages, etc.

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

#123

Post by pavel_lishin »

pixelrevision wrote: post #27
quonn wrote: post #10

I wish it would be possible to have better studies for that. I believe that static typing has huge benefits as software scales. I also believe that the type system of TypeScript is actually stronger in practice than the Java or C# one (despite theoretical weaknesses). It has the right tradeoffs (e.g. structural equivalence, being able to type strings, being able to check that all cases are handled, etc.) It would be…

I think it’s the wrong metric to look at. Static typing still leaves plenty of room for bugs. The capability and discipline of the team would likely be more of a factor than the type system so the studies would be hard to get right. However I do think static typing provides an enormous benefit to picking up code that is 5 years old and written by someone else. The ability to see “this is a nonnullable int32 value typ…

I would change that "5 years" to "5 months" (or maybe even 5 weeks), and argue that you can just as easily be that "someone else" on a long enough time-scale (and I don't mean 5 years.)

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

#124

Post by mistermann »

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

> "...but I do want to underscore a really important point: almost everything in software is a belief - it is something we have experience about, it is something we have opinions on, but it's not something we have hard data on. In most cases, we just don't know. But we can find out. We find out through..."

This seems applicable to everything, almost, in this whole experiment humans have going on here on planet earth, it just doesn't seem like it. To see it, you have to have (at least) the ability and willingness to look.

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

#125

Post by ComputerGuru »

unilynx wrote: post #101
castorp wrote: post #86

Earlier quoted context omitted.

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

I think this is specifically because random reads are scaling much better than writes, even though you won't see it on standard "that many MB/s" benchmarks where read is 'just' a few multiples of the write performance. Persisting a transaction to the database is still (and especially in MVCC): "send data write". "wait for write to be flushed". "toggle metadata bit to mark write as completed". "wait for bit to be comp…

This is actually the opposite of current limitations. Stick a capacitor and some DRAM on the NVMe and you can "instantly" flush to disk, but there's no way to anticipate where the next read will come from and therefore no way to accelerate it.

You'll see modern NVMe disks with sustained writes greatly outpacing reads until the write cache is saturated, at which point what you say is true and reads will greatly outpace writes. But you don't want your disks to ever be in that threshold.

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

#126

Post by the_af »

therufa wrote: post #80
quonn wrote: post #10

I wish it would be possible to have better studies for that. I believe that static typing has huge benefits as software scales. I also believe that the type system of TypeScript is actually stronger in practice than the Java or C# one (despite theoretical weaknesses). It has the right tradeoffs (e.g. structural equivalence, being able to type strings, being able to check that all cases are handled, etc.) It would be…

In my personal opinion (based on personal observation) static typing helps to become more lazy and trusting since it enables features such as autocomplete, type hinting and so on where one basically gives away understanding of detail. Don't get me wrong! I love being lazy and trusting because it allows to leverage more code than I'd be able to produce on my own, but usually it's also the source of many of my own mist…

This is a surprising argument to me. In my opinion, the opposite is true: thinking about types makes you understand your building blocks better, whereas the danger of dynamic typing is that you can go a long way being "lazy" and not understanding/caring about the types involved, "it just works". Sometimes this speed is welcome, but (in my opinion) you end up crashing and burning sooner or later...

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

#127

Post by nthj »

mumblemumble wrote: post #113
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…

> 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 SQS queues, which in practice protects us from a locking operation in one place impacting other operations in a customer-facing way. I don’t think this is strictly necessary but it is a nice technical guard against the sociological problem of a contractor merging code like that. They don’t feel the pain of locks gone bad because they (per contract) can’t be on call.

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

#128

Post by archarios »

jdm2212 wrote: post #77
quonn wrote: post #10

I wish it would be possible to have better studies for that. I believe that static typing has huge benefits as software scales. I also believe that the type system of TypeScript is actually stronger in practice than the Java or C# one (despite theoretical weaknesses). It has the right tradeoffs (e.g. structural equivalence, being able to type strings, being able to check that all cases are handled, etc.) It would be…

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.

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

#129

Post by archarios »

quonn wrote: post #66
pixelrevision wrote: post #27

Earlier quoted context omitted.

I think it’s the wrong metric to look at. Static typing still leaves plenty of room for bugs. The capability and discipline of the team would likely be more of a factor than the type system so the studies would be hard to get right. However I do think static typing provides an enormous benefit to picking up code that is 5 years old and written by someone else. The ability to see “this is a nonnullable int32 value typ…

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.

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

#130

Post by archarios »

pantaloony wrote: post #37
jdmoreira wrote: post #32

> Static vs Dynamic Typing All research is inconclusive? Sure. I wonder what kind of type systems were in there? I guess Java and similars are accounted and yet I wouldn’t put any faith in them. ML, Swift, Haskell... now that’s something else.

It doesn’t account for the communication value of static types. Personally, I consider static types primarily a communication tool, so IMO the review’s interesting but not very useful per se . Also the main point of it seems to be “research on this topic is mostly bad, so far, so who the hell knows what’s true”. It could be that the research has sucked, not that there’s little discernible difference between the two o…

It seems to me that tests are equally good as a communication tool.
Post reply on HN