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

https://github.com/hwayne/awesome-cold-showers

by vthriller • 6 years ago

588 237 6 years ago

timClicks• 6 years ago

Hillel (the editor of this list) is one of the people in this industry that is going to make a tremendous difference to the world. His ability to make formal verification understandable, and therefore useful in practice, is unparalleled.

carlmr• 6 years ago

I think the biggest issue with formal verification, is that you need to rewrite the important parts of your code in (for example) TLA+. If it's integrated into the language, like ADA Spark, you don't need to learn so much additional syntax or rewrite parts of your codebase in a language you rarely use (given that you already work in ADA).

ahelwer4• 6 years ago

Well, you can't rewrite anything in TLA+. It's a formal specification language, not verification language. So you usually use it to catch spec- or algorithm-level logic & concurrency bugs then manually write the code to correspond to your TLA+ spec. People get really hung up on this last step, but I can tell you as a professional programmer that implementing code to follow a TLA+ spec is extremely easy - all the intellectual heavy lifting has already been done! - and avoids the extremely costly effort required to fully formally verify computer code. It's a great cost/benefit ratio.

pydry• 6 years ago

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.

JabavuAdams• 6 years ago

We'll have AGI before we have usable formal verification. Just let the AGI write the code.

dvfjsdhgfv• 6 years ago

Regarding the bare metal issue, there are many more caveats, see for example: https://jan.rychter.com/enblog/cloud-server-cpu-performance-...

hansitomani• 6 years ago

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

Ar-Curunir3• 6 years ago

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

moby_click• 6 years ago

There should be a section about the benefits of cold showers.

gonzo41• 6 years ago

Is taking cold showers like a machismo SV thing?

ahelwer4• 6 years ago

Yes. Like stoicism. You aren't emotionally insensitive/unintelligent, you're a masculine Roman general!

dTal• 6 years ago

Is thinking that everything is a Silicon Valley thing, a Silicon Valley thing? Is it really plausible that no one thought to feel manly about cold showers until a bunch of nerds came along?

Delk• 6 years ago

Possibly, but it doesn't have to be only that, or without any merit. Cold baths and even winter swimming [1] (in icy water) are a thing in many parts of the world.

[1] https://en.wikipedia.org/wiki/Winter_swimming

Noos2• 6 years ago

No, it is more of a euphemism for "sobering up." Existed for quite awhile, usually used for drunks though. Has minor connotations of being an oddball health nut-people extolling the benefits of being immersed into chilly water.

JAlexoid9• 6 years ago

Yeah... They're pointless, unless you're an athlete - where ice baths actually work.

Robin_f• 6 years ago

The first link to the PDF unfortunately doesn't work.

esquire_900• 6 years ago

The title doesn't really relate to its content very well; the concept of taking cold showers has some scientific backing ([1] & [2]), and is also slightly hyped. After taking cold showers and getting some (minor) benefits for some years, the term "cold shower" started to get a positive association in my mind.

This article isn't about showers, nor positive results, making the title quite confusing :)

[1] https://www.medicalnewstoday.com/articles/325725 [2] https://www.wimhofmethod.com/science

ahelwer4• 6 years ago

Only on Hacker News could you find someone taking issue with the widely-used & understood phrase "cold shower".

eitland• 6 years ago

Reminds me about one of my favorite HN comments of all time:

https://news.ycombinator.com/item?id=8289007

Topic: The curious case of the cyclist’s unshaven legs

From a comment (this part clearly intended to be witty I think): Really, I thought it was weird, and probably inappropriate, to mix in so much of an outsider's amateur and unsopported opinion about science into an otherwise interesting story about leg hair drag.

quonn3• 6 years ago

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 nice to have proper studies, but it‘s difficult to control the other variables ...

whatl3y• 6 years ago

I've recently learned and ported a few projects from Javascript to TypeScript and I'll vouch that, so far, it is much better and easier to reason about my code and what it's doing. I also feel I need less test cases to adequately test my code.

In saying that, I'm interested in if there is any accepted, peer reviewed literature with quantifiable data as to whether strongly typed languages are "better" (whatever the study might define as better such as being faster, more scalable, etc). From what I've heard and read, most of the better-ness that strong typing provides is related to people problems and being able to scale a team, not necessarily scaling a system or making the system better. When learning Go and TypeScript after primarily writing Ruby and Javascript, I'm convinced of the better-ness strong typing provides whether it's related to readability, better IDE intellisense, or speed (although Go for example is faster then Ruby and JS not just because it's strongly typed, but compiled), I'm just interested in if there's real data to support using them instead of anecdata.

j_m_b• 6 years ago

How much would you attribute that to the fact that you rewrote the code? I know my second pass is always better.

lioeters• 6 years ago

Here's the closest thing I could find:

The TypeScript Tax: A Cost vs. Benefit Analysis - https://medium.com/javascript-scene/the-typescript-tax-132ff...

The author leans against TypeScript, but does cite some relevant studies on the benefits.

---

One of the cited articles:

To Type or Not to Type: Quantifying Detectable Bugs in JavaScript - http://earlbarr.com/publications/typestudy.pdf (PDF)

GlennS3• 6 years ago

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.

nafey2• 6 years ago

I think it gives people a sense of satisfaction in modeling real world in the relations between classes. The assertion seems to be that if to solve a problem it has to be correctly modelled into the type system of the language. Once the modelling is done correctly solution will arise by itself.

On the other end people who prefer weakly typed languages see problems as primarily that of data transformation. For example from HTML Form to Http Request to SQL Db to CSV File and so on.

Both approaches are differentiated by the perspective on the problem.

pantaloony5• 6 years ago

I don’t get the cost claims. The time it takes to note which type I intend something to be is mostly either so low that I recover it via improved hints and such very quickly, or larger but only because I’m documenting something complex enough that I should have documented it anyway, whether or not I was using static types, because it’ll be hell for other people or future-me to figure out otherwise. It seems like a large time savings to me—throw in faster and more confident refactoring and stuff like that, and it’s not even close.

I just don’t get how people are working that it represents a time cost rather than a large time savings. I don’t mean that as a dig, I just mean I genuinely don’t know what that must look like. And I’ve written a lot more code in dynamic languages, and got my start there, so it’s not like I “grew up” writing Java or something like that.

wccrawford2• 6 years ago

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.

pixelrevision2• 6 years ago

Clojure spec seems like the way to go. I really like that it defines what should be going in and out while leaving it really easy to merge incoming data without having to write a bunch of extra code.

orangecat• 6 years ago

In my experience both the benefits and costs of static typing are overstated. It doesn't mean that your code works if it compiles, and it doesn't mean that you can get rid of half your tests. But it's great for refactoring, and it's a useful form of documentation that can't lie, unlike comments. And if you're using a reasonable language it's not much additional work to add types; often with type inference it's zero work.

nicoburns2• 6 years ago

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.

wolfadex2• 6 years ago

For me it depends on the style of static types. I do find Java or C#'s static types to be helpful, but also time consuming. Elm or Haskell on the other hand don't force me to write out the static types while still giving me the benefits of them.

There's also the case that I find the type systems of Rust, Elm, etc to be much more helpful than the type systems of C++ or Sorbet (type system for Ruby).

pixelrevision2• 6 years ago

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 type” greatly reduces the amount of paths you have to go down when you have to change something or understand what’s going wrong with it. Tradeoff is you end up with a lot more code to maintain...

quonn3• 6 years ago

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, conditions, lists where some of the other values are mentioned and so on.

This is something that‘s not possible in a dynamic language and it‘s not even possible in Java, really.

I rely on this daily.

pavel_lishin• 6 years ago

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

doctor_eval• 6 years ago

I much prefer static typing - but the metric used in the article is around bug reduction. Regardless of static (Go or Java), dynamic (JS), or a bit weird (plpgsql), I don’t generally get the type of a variable or object wrong - because when I’m using the object I necessarily must already have a mental map of what it represents. It’s pretty rare to try to call the “fill()” method on a “line” object, so to speak, because I know it’s a line when I access it.

So I’d guess that the number of type related bugs in dynamic languages is just a little bit greater than in static languages, simply because it is harder to make that kind of mistake in a typed language. But as a category, they aren’t common mistakes in the first place.

I can confidently say that I’m a bit of an expert at writing bugs :) and of all the kinds of bugs I write, type related bugs are probably no where near the top of the list.

That’s not to say that static typing isn’t better - I definitely think it is. But I can also believe that it doesn’t necessarily reduce the bug count by a huge margin. (For whatever it’s worth I think the main benefits are documentation and refactoring...)

the_af7• 6 years ago

On that note, I've heard many times dynamic typing advocates say (or write) "I've seldom wrote a bug that was a type error".

But a lot of the time, their language is simply unable to encode certain properties as types, so by definition they don't think of some classes of bugs they do write as "type errors". Maybe in a statically typed languages they would have been type errors indeed!

It's as if the tool you use sometimes reinforces your blind spots: "you don't know what you don't know".

PS: anecdote is probably irrelevant, but I've written plenty of dumb type errors with Python. Things that would have been caught by a test or an external tool, sure, or the type checker of a statically typed language could have caught for me for free, leaving the more relevant logic tests to me. I tend to write type errors left and right. Maybe I'm simply not a good Python programmer, of course!

jdm22125• 6 years ago

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.

zimpenfish3• 6 years ago

A contrary anecdata - I've worked at a bunch of places and know people who work at others that have large, actively maintained, decades-old systems using, e.g., Perl. The only one I know that was actively trying to migrate recently was looking at node instead.

archarios6• 6 years ago

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

therufa• 6 years ago

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 mistakes and failures. I strongly believe that I'm not the only one.

the_af7• 6 years ago

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

JAlexoid9• 6 years ago

And I feel that I'm wasting time on understanding the stuff that I need to pass and have to remember 100 times more things, than I need to.

I want my code to be clear and with certain expectations fulfilled, rather than a mystery in front of me. I'm not there to learn what could be passed into my functions - I'm there to create functionality.

catdog• 6 years ago

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, especially after it outscales what one person is able to (fully) overview. Static types are something a program can reason about so it allows so much more productivity boosting tooling to be created. This also goes way beyond simply catching type errors at compile time vs. runtime (a downside which can largely be mitigated by test coverage). Just look what an IDE for e.g. Java can do simply in helping you navigating a big codebase. Then throw in refactoring which is in many cases can even be a completely automated operation and in much more cases is at least greatly assisted by the tools. Tools for dynamic languages can often at most guess, making good guesses is hard so in practice you get mostly stuff which is pretty limited in its usefulness.

archarios6• 6 years ago

I've contributed to large codebases that have static typing (C++ and TypeScript) and dynamic typing (JavaScript) and I've come to the conclusion over the years that static typing isn't really worth it as long as you have the discipline to write tests for your code. The most basic unit tests cover type checking concerns. Refactoring might require a bit more search/replace but I don't see how that is a big deal. Tests make refactoring safer than with just types. Tests act as good documentation of how you expect your code to behave and what expected inputs/outputs there are. You just don't get autocomplete which is a pretty overrated feature imo.

wolfadex2• 6 years ago

I'd love for the study to include various types of static types. Testing against only C#/Java style type systems seems fairly narrow compared to the various kinda of static type systems available.

root_axis• 6 years ago

I just can't imagine how strong types can be viewed as anything other than an immense benefit. Maybe on some personal projects or a throwaway prototype or simple scripts it might not be worth the effort, but if you're working on any kind of software that needs to be maintained over a period of years, having strong types is always better than not having them. Strong types encode extremely valuable information about the composition of application data structures, omitting them can save time up front, but it's just a form of technical debt that every engineer on the project will have to pay back when they're tasked with debugging data errors in code they didn't write. So many engineering-hours wasted by developers stepping through a debugger trying to figure out why some complex object is arbitrarily missing certain properties or why the same property is sometimes a string but other times its an object with its own potential superposition of states. It's a nightmare.

Laakeri• 6 years ago

I was expecting it to a have a section about deep learning hype.

Multicomp2• 6 years ago

I love that sqlite article. It seems like "everyone" is certain that sqlite can only be used for up to a single query per second, anything more and you need to spin up a triple sharded postgres or Hadoop cluster because it 'needs to scale'.

I love being able to show that study, if you properly architect your sqlite system and am willing to purchase hardware, you can go a long long way, much further than almost all companies go, with your data access code needing nothing more than the equivalent of System.Data.Sqlite

tutfbhuf• 6 years ago

Why choose sqlite over MySQL on a single server (e.g. small vm instance)?

doublerabbit• 6 years ago

Overhead.

SQLite resources are a lot lower due to the database being a flatfile on the OS. It's only main resource is storage.

MySQL is a application that not only requires configuration, tweaking, turning and tender-loving-care but consumes constant resources utilising the processor, memory and storage.

acdha3• 6 years ago

More standard without all of the correctness foot-guns, less to configure and operate, and it’s usually faster. MySQL has to do a lot of work running as a separate process, handling connections, etc. whereas SQLite is just doing file I/O in your current process.

JAlexoid9• 6 years ago

Low maintenance overhead - SQLite, Firebird, Sybase are all like that.

threeseed• 6 years ago

My favourite part is how they:

(a) built their own transaction/caching/replication layer using Blockchain no less.

(b) paid SQLite team to add a number of custom modifications.

Now you could do all of this or just use an off the shelf database that you aren't having to write custom code to use and if you choose a distributed one e.g. Cassandra will be able to run on cheap, ephemeral hardware.

Spivak• 6 years ago

This really isn't a fair take on the situation.

(a) They implemented a very boring transaction/caching/replication layer that is like any other DB except they borrowed the idea that "longest chain" should be used for conflict resolution.

(b) They worked with upstream to get a few patches that were unique to their use-case. Once you're in deep with any DB this really isn't that uncommon.

(d) Bedrock isn't bound to the hardware. You could run it on EC2 and reap the benefits just the same except you'd pay more.

quickthrower2• 6 years ago

I don’t use SQLite on a server for the simple reason I’m to lazy to look after it. There are cloud managed sql server or psql databases. AWS backs me up by default. Why mess around with SQLite.

Not knocking SQLite - great for desktop apps or maybe local dev environments.

WrtCdEvrydy2• 6 years ago

It depends on whether your data is confidential as well... I have been known to send a full SQLite dump to a small app that needed a lot of local data.

You can store it in localStorage and read it making your reload be a lot smaller. If it's not in localStorage, you can just request a fresh copy of SQLite from us.

bob10297• 6 years ago

SQLite is incredible. If you are struggling to beat the "one query per second" meme, try the following 2 things:

1. Only use a single connection for all access. Open the database one time at startup. SQLite operates in serialized mode by default, so the only time you need to lock is when you are trying to obtain the LastInsertRowId or perform explicit transactions across multiple rows. Trying to use the one connection per query approach with SQLite is going to end very badly.

2. Execute one time against a fresh DB: PRAGMA journal_mode=WAL

If at this point you are still finding that SQLite is not as fast or faster than SQL Server, MySQL, et.al., then I would be very surprised.

I do not think you can persist a row to disk faster with any other traditional SQL technology. SQLite has the lowest access latency that I am aware of. Something about it living in the same process as your business application seems to help a lot.

We support hundreds of simultaneous users in production with 1-10 megs of business state tracked per user in a single SQLite database. It runs fantastically.

hans_castorp• 6 years ago

If at this point you are still finding that SQLite is not as fast or faster than SQL Server, MySQL, et.al., then I would be very surprised.

What about large aggregation queries, that are parallelized by modern DBMS?

Does it still scale that well if you have many concurrent read and write transactions (e.g. on the same table)?

saberience• 6 years ago

Are you living on another planet? Are you seriously suggesting people replace SqlServer or MySQL with SQLite?

If you can come to my company and replace our 96-core SqlServer boxes with SQLite I'll pay you any salary you ask for.

barrkel3• 6 years ago

You've just moved a bunch of problems to whatever is accessing SQLite. How do you scale out the application server compute if it needs to make transactionally conditional updates?

E.g.:

    transaction {
      if (expensiveFunction(query()))
        update();
    }

(My applications always get much faster when I plug them into Postgres after SQLite. But then I do do the odd sort and group by, not OLAP, but because they express the computation I want and Postgres is simply much better at that.)

neurostimulant• 6 years ago

How do you handle access from multiple worker processes? Some languages/frameworks handle have poor multi-threading performance and must be deployed in a multi-process setup (e.g. python webapps). Or is it not a good fit for sqlite?

itroot2• 6 years ago

Why single connection? Sqlite in WAL mode will allow to co-exist writer and readers.

lenkite• 6 years ago

Where are these databases persisted ? HA (multi-process)? Failover ? Backup ? How do you handle containerisation ?Some details would be seriously welcome.

thomascgalvin• 6 years ago

To me, this is the most important line in the article:

SQLite scales almost perfectly for parallel read performance (with a little work)

They aren't using stock SQLite, they're using SQLite wrapped in Bedrock[1], and their use case is primarily read-only.

SQLite is fantastic at read-only, or read-mostly, use cases. You start to run into trouble when you want to do concurrent writes, however. I tried to use SQLite as the backend of a service a couple of years ago, and it locked up at somewhere around tens of writes per second.

[1]: www.bedrockdb.com

Spooky23• 6 years ago

This is true of anything SQL.

I've been so many solutions that would be easily and reliably implemented on a single or small SQL database cluster of various types that turn into these complex systems to avoid the costs of scaling up the RDBMS.

smoe• 6 years ago

I'd certainly believe sqlite can be taken very far. Never done it so far.

But what does "properly architect your sqlite system" mean and how does this compare to just spinning up a postgres service (nothing sharded or fancy otherwise)?

therealdrag02• 6 years ago

In this case it seems to mean building an extra server layer on-top of it.

- https://blog.expensify.com/2018/01/08/scaling-sqlite-to-4m-q... - https://bedrockdb.com/

efreak• 6 years ago

As a casual user of random software that I test and then immediately forget: I really wish more applications supported sqlite databases. I've set up everything from IRC bots to server animation software to log analysis to forums and WordPress, to test it out, and the first thing that makes me drop something is a dependency on MySQL, pgsql, etc. If your software can work out of a single directory otherwise but can't work with a local database in the same directory, then I'm not going to use it.

babbledabbler• 6 years ago

Cold showers are awesome! Get outta here!

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5025014/

api• 6 years ago

The big data one is outstanding.

If you don't have more data than can fit on a reasonably large hard drive, you do not have big data and you are likely able to process it faster and cheaper on one system.

Today that threshold would be around 10TiB.

julienfr112• 6 years ago

It take hours to read a whole 10TiB hard drive. Depending on use cases, it can be unacceptable.

rwoerz2• 6 years ago

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

fmakunbound2• 6 years ago

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

hwayne5• 6 years ago

I used to think this, and then I interviewed people who did both traditional and software engineering professionally, and now I'm not so sure. I did a first draft of what I learned here: https://www.youtube.com/watch?v=3018ABlET1Y

I'm hoping to have a written version by the end of September.

rurp• 6 years ago

I don't know, my partner works at a civil engineering firm and the day to day work there sounds pretty similar to what I do as a software dev. Sometimes they have to do complicated calculations and research, but by far most of the work is copying templates and tweaking them as needed.

The hardest part of most projects is taking unrealistic and ever changing client demands and trying to turn them into something that will actually work in reality; a process which is probably all too familiar to many software developers.

dynamite-ready• 6 years ago

I think that's a very interesting point.

I think software 'engineering' is uniquely ambiguous in this regard, because software development as a discipline is in equal parts both design, and construction, and the design part bleeds into the 'construction' part, corrupting it (for want of a better word) in a way you would imagine that 'pure' engineering would not.

realtalk_sp• 6 years ago

I suspect many developers would find software a lot less appealing if it were closer to a traditional engineering discipline (slow, unforgiving, dramatically reduced expressive power and creative potential, etc).

I'm somewhat ADD and get bored easily, so not only do I need to do something more like software but I also have to stay as broad and high-level as possible within the discipline, to stave off ennui. NOTE: very much not arguing this is a good way to go through life.

elric• 6 years ago

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.

mistermann2• 6 years ago

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

JAlexoid9• 6 years ago

Because most of the issues arise from the bug that is present between the chain and the keyboard.

The issues are us - the developers. The machine code is mostly fine...

jdmoreira• 6 years ago

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.

pantaloony5• 6 years ago

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 on the dimensions measured.

archarios6• 6 years ago

It seems to me that tests are equally good as a communication tool.

acdha3• 6 years ago

My interpretation of that is both that we need more research and that this is a very hard problem to study. One of the big challenges is that the things which are easy to study aren't representative of real world conditions: if you have CS undergrads doing new development on toy problems, that isn't representative of what experienced developers at most businesses do. Having people pick less common languages can select for programmers who aren't representative of the general field[1] and are probably going to invest extra time making their favorite language look as good as possible. You can hire people, train them in various languages, and have them implement something generally applicable but that's now a really expensive study.

1. e.g. what percentage of the gains attributed to Lisp were more likely due to the candidate pool in the 90s/2000s skewing heavily towards people who learned it at elite CS programs, especially if you're doing a challenge competition which benefits from having studied various algorithms?

szatkus2• 6 years ago

Seems like modern Python or TypeScript are close to sweet spot for typed code. You don't need to set types for everything, but just enough to get checks from a compiler in most important places (at least for TS, tooling for Python is still lacking). Java is slowly going there too, but from another direction.

ravenstine• 6 years ago

I think the best takeaway from this is that the software industry makes lots of claims about development processes, but so little actual research is done in trying to validate those processes. It's all mostly based on opinion.

acdha3• 6 years ago

That’s the interesting take for me, too: we love to talk about it as engineering or science but there’s a fairly good argument that this is more aspirational than real in many cases.

mistermann2• 6 years ago

I reckon the same general phenomenon extends to most any human endeavor on the planet at the macro and micro level (and everything in between), and hardly anyone even notices they are doing it unless someone happens to point it out, which typically (in my experiences) then results in some form of rationalization. It's like (or actually is) humanity is living in a fantasy world at all times, but we're unable to realize it, or even consider it.

vii• 6 years ago

It's hard to do objective research. Some studies try A/B tests on student volunteers. But then this setting is clearly different to professional teams working on a project for a long time.

The value of new methodologies, languages, and techniques is partly that the enthusiastic proponents of them are given a chance to prove out that there is value, and so become motivated to go the extra distance to achieve the project specific outcome.

This value is destroyed if people are forced to use the technique, instead of championing its introduction. So measurement is made even harder!

Taikonerd2• 6 years ago

I read this and thought, "oh, the author is calling out formal verification as overhyped? Hillel Wayne (https://hillelwayne.com/) is going to be angry! Wait, who wrote this..."

wenc• 6 years ago

Me too.

I recall that F Scott Fitzgerald said "the test of a first-rate intelligence is the ability to hold two opposed ideas in mind at the same time and still retain the ability to function."

Taikonerd2• 6 years ago

In Hillel's defense, maybe they're not opposed ideas... this article talks about problems with formal verification, but I think his thing is more formal modeling (with TLA+).

mumblemumble4• 6 years ago

Things like this are exactly why I stop and pay attention whenever Hillel Wayne starts to speak.

aidenn0• 6 years ago

Overhyped is not the same thing as bad. I program in common lisp, it is by far my favorite environment for developing. I also think just about every blog post and reddit comment by someone who has just discovered lisp greatly overstates its advantages.

beh9540• 6 years ago

I was really surprised docker or kubernetes wasn't one of the items on here. While I use both, they definitely both could use cold showers to make sure they provide value.

hwayne5• 6 years ago

I seeded most of the list and know basically nothing about docker or kubernetes, so don't know of any cold showers myself. But I would be more than happy to edit a submission by someone who knows the space!

the_af7• 6 years ago

A Cold Shower for (early) testing of software, maybe:

There used to be an often cited paper by Boehm about the cost of catching bugs early vs late on production, usually mentioned by advocates of testing early, where the quoted conclusion was something like "studies show it's 10 times more costly to catch bugs late on production" or something like that. This is a very well known study, I'm likely misquoting it (the irony!) and readers here are probably familiar with it or its related mantra of early testing.

I haven't read the paper itself (I should!), but later someone claimed that a- Boehm doesn't state what people quoting him say he said, b- the relevant studies had serious methodological problems that call into question the conclusion he did say, c- there are plenty of examples where fixing bugs late on production wasn't particularly costly.

edit: I'm not arguing testing isn't necessary, in case that upset someone reading this post. I'm not really arguing anything, except that the study by Boehm that most people quote was called into question (and was probably misquoted to begin with). This doesn't prove/disprove anything, except maybe hinting at a possible Cold Shower. It does show that we as a field have a serious problem in software engineering with backing up claims with well designed studies and strong evidence, but this shouldn't come as a surprise to anyone reading this.

hwayne5• 6 years ago

Laurent Bossavit tears the Boehm paper apart in his book "Leprechauns of Software Engineering"[1]. It's a good read for anyone interested in the empirical side of software research.

[1] https://leanpub.com/leprechauns

the_af7• 6 years ago

Thanks! I think it might have been an extract from Bossavit's book what I'm struggling to remember now. The title definitely rings a bell.

sgt101• 6 years ago

Yet again the "we don't need big data" demoed on an example that fits on a disk. Big data is north of 30TB.

red_admiral• 6 years ago

First link (formal verification) currently gives a 404 for me. Someone not wanting the extra publicity?

j1elo2• 6 years ago

I'm already thrilled waiting for an addition with "Kubernetes everywhere" ice shower.

hwayne5• 6 years ago

I don't have the necessary background to find a good "Kubernetes everywhere" ice shower, but if someone else found one and submitted it I think I could evaluate it.

j1elo2• 6 years ago

I said it in a jokingly way, but it would really be a nice read.

The hype is huge in that train, but I'm sure there must be lots of professionals that have already learned about its shortcomings. Not sure if proper studies exist about Kubernetes yet, though. Hopefully you'll get a PR with some content.

theptip2• 6 years ago

This is probably a good place to start: https://github.com/hjacobs/kubernetes-failure-stories

(Not a balanced evaluation, just cherry-picking failures. But I suppose we're at the point in the hype cycle where it's easier to find success stories being talked about.)

theptip2• 6 years ago

Agile Methods: The Good, the Hype and the Ugly (Video) (https://www.youtube.com/watch?v=ffkIQrq-m34)

Thoughts on this one? I found the presentation to be somewhat mixed.

I found the initial comb through of the agile principles to be needlessly pedantic ("'Simplicity... is essential' isn't a principle, it's an assertion!"); anyone reading in good faith can extract the principle that's intended in each bullet of that manifesto.

The critique of user stories (~35 mins in) was more interesting; it's something we've been bumping up against recently. I think the agile response would be "if your features interact, you need a user story covering the interaction", i.e. you need to write user stories for the cross-product of your features, if they are not orthogonal.

I'm not really convinced that this is a fatal blow for user stories, and indeed in the telephony example it is pretty easy to see that you need a clarifying user story to say how the call group and DND features interact. But it does suggest that other approaches for specifying complex interactions might be better.

Maybe it would be simpler to show a chart of the relative priorities or abstract interactions? E.g. thinking about Slack's notorious "Should we send a notification" flowchart (https://slack.engineering/reducing-slacks-memory-footprint-4...), I think it's impossible (or at least unreasonably verbose) to describe this using solely user stories. I do wonder if that means it's impossible for users to understand how this set of features interact though?

Regarding the purported opposition in agile to creating artifacts like design docs, it's possible that I'm missing some conversation/context from the development of Agile, but I've never heard agile folks like Fowler, Martin, etc. argue against doing technical design; they just argue against doing too much of it too early (i.e. against waterfall design docs and for lean-manufacturing style just-in-time design) and that battle seems to have largely been won, considering what the standard best-practices were at the time the Agile manifesto was written vs. now.

andikleen3• 6 years ago

I can confirm the issues with formal methods.

I was working on a new type of locking mechanism and thought I would be smart by modelling it in spin [http://spinroot.com], which has been used for these kind of things before.

I ended up with a model that was proven in spin, but still failed in real code.

Given that's anecdata with a sample size of 1, but still was a valuable experience to me.

david-cako2• 6 years ago

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.

networkimprov2• 6 years ago

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()

jchw2• 6 years ago

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.

david-cako2• 6 years ago

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.

pragmatic• 6 years ago

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?

arendtio• 6 years ago

Reads like recipe for flame wars. Pick any of those topics and you can be sure to find someone with an opposite opinion of your own ;-)

vharuck• 6 years ago

Researchers had programmers fix bugs in a codebase, either with all of the identifiers were abbreviated, or where all of the identifiers were full-words. They found no difference in time taken or quality of debugging.

I would not have expected that. Still, I prefer to use full(er) identifiers. I don't like to guess how things were abbreviated, especially when consistency isn't guaranteed. If I were using a different language and IDE, this might be better.

touchpadder• 6 years ago

Hype: this document

Shower: Out-of-date sources

ajbonkoski• 6 years ago

This gets at the heart of one of my big gripes about how we talk about engineering and technology.

Often a fancy new thing is introduced with a very long list of pros: "fast, scalable, flexible, safe". Rarely, is a list of cons included: "brittle, tough learning curve, complicated, new failure modes".

This practice always strikes me as odd because the first law of engineering is "everything is a trade-off". So, if I am going to do my job as an engineer I really need to understand both the "pros" and "cons". I need to understand what trade-off I'm making to get the "pros". And only then can I reason about wether the cost is justified.

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

Related Stories