12 ms·
Cold Showers: For when people get too hyped up about things
- timClicks 6y agoHillel (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 6y agoI 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).
- ahelwer 6y agoWell, 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 6y agoMy 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.
- mbrock 6y agoThe 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.
- szatkus 6y agoDo you have any rule of thumb for that? Like, I have 1000 LOCs, how many lines of spec I could except for that code?
- qznc 6y agoHere is a counter argument: http://www.pathsensitive.com/2018/10/book-review-philosophy-of-software.html 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.
- jacobr1 6y agoHow much of that is open/close being a poor abstraction, or overloading a bunch of semi-related functionality vs a more generalizable consideration systems designed with verification in mind.
- JabavuAdams 6y agoWe'll have AGI before we have usable formal verification. Just let the AGI write the code.
- dvfjsdhgfv 6y agoRegarding the bare metal issue, there are many more caveats, see for example: https://jan.rychter.com/enblog/cloud-server-cpu-performance-comparison-2019-12-12 https://jan.rychter.com/enblog/cloud-server-cpu-performance-...
- hansitomani 6y 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-Curunir 6y agoMaybe the available tooling for extracting good performance is not friendly to people that aren’t already familiar with it?
- moby_click 6y agoThere should be a section about the benefits of cold showers.
- gonzo41 6y agoIs taking cold showers like a machismo SV thing?
- ahelwer 6y agoYes. Like stoicism. You aren't emotionally insensitive/unintelligent, you're a masculine Roman general!
- jedimastert 6y agoHow is stoicism a SV thing? It's kinda been around for a while...
- ahelwer 6y agoEveryone I know who identifies as a stoic is an emotionally stunted software engineer who realistically isn't tasked with stoically shouldering very much of anything.
- jedimastert 6y agoAs a counterpoint, most of the people I know whom I would consider to follow a Stoic philosophy don't self-classify all that much. I would also say that there's a pretty big difference between "stiff upper lip/no emotions" that people imagine when using the the adjective "stoic" and the Stoic writings of Marcus Aurelius and the like.
- pantaloony 6y ago> I would also say that there's a pretty big difference between "stiff upper lip/no emotions" that people imagine when using the the adjective "stoic" and the Stoic writings of Marcus Aurelius and the like. A quick way to find out what sort of self-proclaimed lover of Meditations you’re dealing with is to ask what they think of its physics and metaphysics.
- Robin_f 6y agoThe first link to the PDF unfortunately doesn't work.
- esquire_900 6y agoThe 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 https://www.medicalnewstoday.com/articles/325725 [2] https://www.wimhofmethod.com/science https://www.wimhofmethod.com/science
- ahelwer 6y agoOnly on Hacker News could you find someone taking issue with the widely-used & understood phrase "cold shower".
- eitland 6y agoReminds me about one of my favorite HN comments of all time: https://news.ycombinator.com/item?id=8289007 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.
- quonn 6y agoI 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 ...
- GlennS 6y agoPeople 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.
- nafey 6y agoI 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.
- quonn 6y agoBut I rarely use classes in TypeScript. I do think of things as data transformations but the types certainly help a lot.
- protonfish 6y agoPlease don't use weak/strong to denote type systems. Those terms are highly subjective and even non-technical people would quickly form an opinion about which is better. (Strong is good, weak is bad.) Static/dynamic is more accurate and less opinionated terminology.
- Laakeri 6y agoI was expecting it to a have a section about deep learning hype.
- Multicomp 6y agoI 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 6y agoWhy choose sqlite over MySQL on a single server (e.g. small vm instance)?
- doublerabbit 6y agoOverhead. 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.
- acdha 6y agoMore 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.
- JAlexoid 6y agoLow maintenance overhead - SQLite, Firebird, Sybase are all like that.
- threeseed 6y agoMy 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. (c) used expensive, custom, non-ephemeral hardware. 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.
- babbledabbler 6y agoCold showers are awesome! Get outta here! https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5025014/ https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5025014/
- draw_down 6y ago> Static Typing reduces bugs. Imagine calling this “hype”. Good grief.
- api 6y agoThe 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 6y agoIt take hours to read a whole 10TiB hard drive. Depending on use cases, it can be unacceptable.
- rwoerz 6y agoWe 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 https://youtu.be/WELBnE33dpY [2] https://www.oreilly.com/library/view/making-software/9780596808310/ https://www.oreilly.com/library/view/making-software/9780596...
- fmakunbound 6y agoIn addition to that, I also feel calling ourselves engineers is a stretch.
- milquetoastaf 6y agoAgreed. If we were actually engineers we'd all be writing TLA+ and Coq to verify the correctness of what we do and there'd be a formal cert program codified by the state
- hwayne 6y agoI 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 https://www.youtube.com/watch?v=3018ABlET1Y I'm hoping to have a written version by the end of September.
- fmakunbound 6y agoFair enough! You make some great points there which changed my perspective.
- ozim 6y agoThis is great. People romanticize construction, mechanical and other engineering like there would be no failures in those disciplines. Buildings collapse, machines break down in unforeseen circumstances. My pet theory is that in software it is just a lot easier to create a lot of stuff, so it is also a lot easier to create issues. You can add that in eastern Europe you can get engineering degree which is "technical bachelor" from technical university, so I am software engineer as it is printed in my diploma.
- jdmoreira 6y 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.
- pantaloony 6y agoIt 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.
- archarios 6y agoIt seems to me that tests are equally good as a communication tool.
- pantaloony 6y agoThey don’t save me from having to go look at other files to learn things about the code I’m actually interested in; they can be misleading in ways that types aren’t—in particular, it’s very hard to know what sorts of things an all-green test suite guarantees versus a passing static type build, without a great deal more information; and they are, in practice, prone to rot and neglect in a way static types rarely are, and are harder to bring back into a useful state when that happens. They serve very different purposes and generally are not first and foremost good communication tools the way static types are, for a bunch of reasons. That doesn’t mean tests aren’t very useful and welcome things to have, however.
- wtetzner 6y agoMy experience is that tests tend to be much harder to read, and take more effort to understand, than types. Types are a higher-level approximation for your program.
- ravenstine 6y agoI 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.
- acdha 6y agoThat’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.
- mistermann 6y agoI 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 6y agoIt'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!
- Taikonerd 6y agoI read this and thought, "oh, the author is calling out formal verification as overhyped? Hillel Wayne (https://hillelwayne.com/ https://hillelwayne.com/) is going to be angry! Wait, who wrote this..."
- wenc 6y agoMe 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."
- mumblemumble 6y agoThings like this are exactly why I stop and pay attention whenever Hillel Wayne starts to speak.
- aidenn0 6y agoOverhyped 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 6y agoI 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.
- hwayne 6y agoI 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_af 6y agoA 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.
- hwayne 6y agoLaurent 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 https://leanpub.com/leprechauns
- the_af 6y agoThanks! 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 6y agoYet 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 6y agoFirst link (formal verification) currently gives a 404 for me. Someone not wanting the extra publicity?
- j1elo 6y agoI'm already thrilled waiting for an addition with "Kubernetes everywhere" ice shower.
- hwayne 6y agoI 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.
- j1elo 6y agoI 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.
- theptip 6y agoThis is probably a good place to start: https://github.com/hjacobs/kubernetes-failure-stories 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.)
- theptip 6y ago> Agile Methods: The Good, the Hype and the Ugly (Video) (https://www.youtube.com/watch?v=ffkIQrq-m34 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-4480fec7e8eb 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 6y agoI 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 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-cako 6y agoIt'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.
- networkimprov 6y agoYou 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()
- jchw 6y agoThe 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.
- pragmatic 6y agoI 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 6y agoReads 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 6y 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 6y agoHype: this document Shower: Out-of-date sources
- deleted 6y ago[deleted]
- ajbonkoski 6y agoThis 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.