14 ms·
So what’s wrong with 1975 programming? (2006)
- throwaway879 5y ago<< girls get disappointed if think they got hold of something else than the MP3 player you had in your pocket>> Sexist B.S.
- Yajirobe 5y agoHow is that sexist?
- geofft 5y agoHonest answer: because it treats "you," the potential reader of the article, as separate from the class of "girls."
- mattowen_uk 5y agoAdding my voice to this. I know that the article was written in 2006, but still. If one wants to be taken seriously as a writer, one shouldn't insert puerile jokes for 12 year olds into their prose. It made me wince when when I read it, and I was ready to comment here about it, but GP got here first.
- throwaway894345 5y agoTell that to Shakespeare and Chaucer.
- geofft 5y agoShakespeare and Chaucer were not writing technical documentation.
- throwaway894345 5y agoI was responding in jest to the narrow claim about not making puerile jokes if one wishes to be taken as a serious writer.
- deleted 5y ago[deleted]
- slver 5y agoI propose the article branches at this point as a set of selectable tabs, each labeled over a suitable set of properties describing the reader, and then offering a matching joke when you click the tab.
- geofft 5y agoDoesn't that still have the problem of categorizing the reader, being wildly off-topic from the technical content of the article and distracting the reader by making them wonder, at least a bit, if the technical content of the article is going to be different for them depending on who they are? The joke barely makes sense in context. Is the physical size of the memory relevant to the point about memory-mapped views of disk - and is it a problem that the physical size of memory is smaller? Should one program an MP3 player the way described in this article, or not? What about USB flash drives (which one is likely to have in one's pocket, and which are roughly the same form factor as the other object alluded to here) - they're much slower than main disk and more likely to fail. Is this an intended reference to such memory devices, and in either case, how does the advice from the article apply to such devices? The article would be better (more effective at communicating its point) without it.
- slver 5y agoOK, I propose then we replace the tabs with just a single link labeled "Please click here if you'd like a dick joke". Then have more detailed tabs on a dedicated page.
- pessimizer 5y agoYou can make a dick joke without assuming the listener is the owner of a dick.
- slver 5y agoThe conflict here is that a joke where you include the listener is automatically funnier, and a dick joke is also automatically funnier. Source: https://www.youtube.com/watch?v=xwGIHzR5r0Y https://www.youtube.com/watch?v=xwGIHzR5r0Y So the challenge lies in combining both, resulting in either the listener, or someone the listener is interacting with in the narrative having a dick. It's one of the big unsolved problems of telling jokes online.
- Hackbraten 5y agoYou shouldn’t get downvoted for that.
- mattowen_uk 5y agoWelcome to Hacker News, please enjoy your stay. /s
- wayoutthere 5y agoWhere people are either socialists or nazis, without a ton of middle ground so you’re likely to get downvoted no matter what you say.
- ttt0 5y agoAny article that assumes something about the reader is in some way discriminatory or is it just when it assumes that you're a man?
- geofft 5y agoGenerally, the accusation of "sexist" is used when someone is making unfair or irrelevant assumptions on the basis of sex. It is not generally leveled at technical documentation that assumes the reader has the technical background to read the documentation, for instance.
- ttt0 5y agoTechnical documentation sometimes does contain humor, it's not that uncommon for developers to include jokes and easter eggs. Furthermore, this is listed under category "Poul-Hennings random outbursts", described as "You may or may not want to know what Poul-Henning thinks.". So while technically included in it, it's not really a documentation of anything. It's basically a blog post. And just like I don't find anything wrong about a blog about cosmetics or fashion assuming that the reader is a woman, I don't find anything wrong in a blog post about technology assuming that the reader is a man.
- JI00912 5y agoNah.
- donkarma 5y agoNot really
- deleted 5y ago[deleted]
- anoncake 5y agoHeteronormative too.
- deleted 5y ago[deleted]
- antihero 5y agoAmazing until you need persistence.
- mrweasel 5y agoSure, but the point remains: If you fight the operating system you WILL lose. Varnish doesn’t solve the same problem as Squid does, the author have said as much in talks when Varnish was first released. Still that doesn’t excuse an outdated programming model in Squid.
- phkamp 5y agoWe actually do have a persistent `stevedore` in Varnish Cache, but we have marked it "deprecated" because it did not live up to expectations, but we keep it around to keep the internal API's honest. Redesigning that code has not bubbled up to the top of my TODO list yet, and shows now signs of doing so. But if you need persistence, there is a commercial version of Varnish which has it, but I have not been involved in that.
- flakiness 5y agoThe post should be marked as [2006]. A lot has changed since then. For example it doesn't talk about NUMA but it should, if it were written today. I would love to hear some opinions from the authors of more contemporary web servers like one of H2O or Envoy. (The latter may have slightly different use cases though.)
- markdog12 5y agoForgive my ignorance, but doesn't http://varnish-cache.org/docs/trunk/phk/notes.html#more-caches http://varnish-cache.org/docs/trunk/phk/notes.html#more-cach... talk about that, with an example?
- flakiness 5y agoIt's about cache vs memory. NUMA is about local memory vs remote memory. So similar but different IMO.
- tyingq 5y agoWhat's different about NUMA today vs 2006?
- wayoutthere 5y agoNUMA was not widely available / understood in 2006. I don’t recall seeing my first NUMA servers until probably 2008ish.
- tyingq 5y agoThat makes sense to me for the entire computing landscape, like if we're including windows, various 32-bit x86 unix like OS's, etc. But varnish was used on Solaris, IRIX, and HP/UX. All of which had cc-NUMA support fairly well established by 2006. I suppose, though, it was still new-ish.
- anonymfus 5y agoFirst Opterons were released in 2003
- mondoshawan 5y agoThis article is a bit strange and conflates disk storage with swap and RAM. Modern systems don't necessarily even have swap (looking at you, k8s), so the whole article falls on its face. > And then there were the secondary store, paper tape, magnetic tape, disk drives the size of houses, then the size of washing machines and these days so small that girls get disappointed if think they got hold of something else than the MP3 player you had in your pocket. This is also written terribly.
- slver 5y ago> This is also written terribly. I rewrote it for clarity: > Storage was large. Today it's small. Smaller than a dick.
- deleted 5y ago[deleted]
- weeboid 5y agoYeah, that is a really bad take. Remind me again why women drop out of engineering teams. To frame this triggering statement, imagine if he had somehow used breasts to make the same analogy. He’d be in a heap of trouble, prob LIFO’d out of his job
- slver 5y agoWait a minute, so... 1. If he makes a dick joke, women drop out of engineering teams. 2. If he makes a breasts joke, women drop out of engineering teams. So basically women in general prefer that human parts not be mentioned in jokes, but men like human parts. Interesting. I'm taking notes.
- jmull 5y agoNah. The point is, don't make your argument in obnoxious, off-putting, offensive terms.
- CrLf 5y agoVarnish seemed really popular a decade ago, but I wonder how it fits the modern web and who's using it today and for what purpose. The lack of built-in HTTPS seems killer to me. On the client-facing side it needs a separate daemon for TLS termination and on the upstream side there's no TLS support at all unless you're using the paid version.
- tyingq 5y ago"The lack of built-in HTTPS seems killer to me." I agree. I think varnish remained popular for 2 reasons: - It was, at one time, higher performing than an nginx proxy cache. That doesn't seem to be the case anymore. - VCL is very rich and flexible with primitives for reading/writing cookie contents, cache metadata, cache flushing, client and server state, and so on. So probably the only reason left if that you're doing something really complicated with your cache in VCL. Otherwise, as you say, the built in HTTPS of nginx, haproxy, nuster, or something else is a big advantage.
- acdha 5y agoAlso CDNs became cheaper and easily accessible. They don’t eat anywhere near 100% of your traffic for most sites but it’s likely enough to get a big chunk of the cacheable traffic at lower latency than your own Varnish server can unless you’re running them all over like Fastly. If a significant fraction of the traffic coming back isn’t cacheable the benefits of running Varnish might sink below the level where it’s worth dealing with another layer of production infrastructure.
- daper 5y agoThere are advantages of using HTTP cache on application side even if you use CDN: - Varnish can guarantee that a given resource will be fetched at most once every TTL expiration since you can set up one instance to do so (+ some HA solution like hot standby). This complements a large CDN that is highly scalable but at a cost that there is no hard "synchronization" between servers. You will see many requests for the same resource, even when the CDN uses cache hierarchy because they can't risk such bottleneck not knowing in advance your traffic pattern. You can intentionally do that with Varnish and benefit from that. - Complex caching rules, even including what to do if application is not available/slow. That includes serving stale content, how long to serve stale after TTL expires, guarantee that fetching a new version is performed in background. Example: https://varnish-cache.org/docs/trunk/users-guide/vcl-grace.html#misbehaving-servers https://varnish-cache.org/docs/trunk/users-guide/vcl-grace.h... We've used varnish + some other magic in addition to Cloudflare to withstand Black Friday when marketing insisted the promo has to start at specified time, anuonced much earlier to all customers. The landing page had up-to date info on available products updated almost instantly, thanks to serving stale (in practice < 1s) content and guaranteed prefresh in background. Cache key was properly set up to exclude tracking elements from URLs (from FB, adwords etc) and only include what is necessary.
- slver 5y agoTLDR; Varnish is very proud they use memory-mapped files for cache, instead of managing RAM and disk cache separately. That said, don't overestimate the OS ability to understand your usage of RAM. The entity with highest insight on that usage is the application. Maybe there's some fortunate overlap in the case of a caching service (Varnish) using a caching service (OS disk cache / virtual memory). Varnish itself has little clue how their entries will be used beyond what the OS sees. But in more complex applications that's decidedly not the case. Photoshop for example to this day uses a "scratch disk" separate from virtual memory. In fact you better hope you never use swap file with Photoshop, because it becomes unusable.
- hughw 5y agoThanks for making this point. If you access your memory sequentially, as Varnish does, great. But if you need to stride across a giant matrix in transposed order, you'll bring your spinning disk backed virtual memory to a halt, as it does a million seeks. To use virtual memory successfully you have to write in-memory algorithms that recognize the non-random-access nature of the memory. If you had simply acknowledged there's a storage system, you wouldn't put out much more effort, if any, to get the same performance. In fact, by pretending it's all RAM, you give up the opportunity to overlap your I/O and do something useful with the time the system would have to spend paging in your data. Edit: btw, happy and satisfied Varnish user for many years!
- zbentley 5y agoArenas are great for latency sensitive programming. But some of the advice in this piece is a bit limited in that it assumes the presence of swap (often disabled on server hardware) and programs whose important "hot" datasets are likely to fit in memory (i.e. the memory use is nice and predictable--an enviable but not always achievable property). When working with bursty memory demands and code/data you don't always fully control (think a big thick runtime with its own allocation decisions, some of them decidedly "1975") on a system whose swapping behavior you can't predict, hand managing on-disk versus in-memory data residency in userland (via manual memory mapping or something like sqlite/lmdb to take care of it for you) becomes necessary.
- kstenerud 5y agoThis is probably the thing that annoys me the most about golang: It abstracts everything as if you were on a 1975 computer, so there's allocations, allocations everywhere! And trying to keep them under control requires intimate knowledge about go's implementation details. Failure to do so dooms your program to run 3-4x slower since allocations are horribly slow to begin with, and now your data is spread all over the place. And even then, there are still some things (like []byte <-> string) that you simply can't get around (unless you want to delve into unsafe land and risk your code blowing up once the runtime implementation changes).
- masklinn 5y agoTo be fair to Go, it provides an escape analysis log and a memory profiler in the standard distribution, so while fixing the heap allocations can require good knowledge of implementation details, finding out that you have heap allocations is really easy.
- throwaway894345 5y agoGo is also not that clever, so you can often intuit fairly easily where the allocations are taking place and how to avoid them. As far as optimizing goes, it’s a lot easier to optimize away allocations in Go than in many other languages. I also think this is the right tradeoff—most code isn’t that sensitive to allocations so why make the programmer think about the 100% of the time, rather than opting into thinking about them in order to optimize the hot path?
- kgeist 5y ago>It abstracts everything as if you were on a 1975 computer, so there's allocations, allocations everywhere! Care to elaborate? Generally you don't care about memory management in Go at all, so I wouldn't call it 1975 programming where you certainly would. Sure, taking the address of a variable heap-allocates but that's an implementation detail and I don't see how it's related to the article at all. It's automatic and you don't even think about it. The article talks about userland software reinventing what's already implemented in a modern operating system. How is it the case with heap allocations in Go, escape analysis etc.? Operating systems don't have means to do escape analysis for userland variables. Or did you get the conclusion from the article that slow=1975 programming? I don't think that's what the author meant.
- wpietri 5y agoJust from the title, I would have expected the opposite approach: not treating RAM as a disk cache, but using RAM only and ignoring the disk. One of the biggest differences between now and then is that we've gone from RAM deficit to RAM surplus. (The VMs that contain so much of today's software can be seen as a way of cutting too-big physical RAM back down to slices that match problems.) This means that batch orientation makes sense for a much smaller slice of problems. Compilers, for example, come from a world of scarce RAM. When my dad started coding, one iteration of change-the-code-and-watch-it-run took days. Now that loop can be seconds: if I pause typing, my IDE starts running my unit tests automatically. It seems to me that things like compilers and runtimes should by default keep everything hot, incrementally updating as fast as possible.
- fao_ 5y ago> Now that loop can be seconds: if I pause typing, my IDE starts running my unit tests automatically. It seems to me that things like compilers and runtimes should by default keep everything hot, incrementally updating as fast as possible. Is it only me that finds this incredibly distracting? When I write code I pause often. It might be in the middle of a sentence, or a function definition, the most recent example I can think of is because I realised I needed another function, and this function's state is dependent on it, or I needed to look something up. Getting my mindstate trashed every time I pause because it's found a dozen irrelevant errors sounds horrifying.
- ufmace 5y agoAgreed, I hate that. I don't want to hear about test failures, syntax errors, compile errors, or anything like that until I ask for it.
- im3w1l 5y agoIt's a matter of UX. If the errors are displayed in a subtle way it's not an issue.
- namelosw 5y agoBecause there's latency. It wouldn't be distracting if there's no latency at all because it feels natural even if the code is in stale shapes. I use Wallaby[0] to run JavaScript tests, and it shows the result on the fly just near every line of test code. The latency is very small so it's hard to notice it. After I was used to this approach the idea of press the test button, and waiting for 1s to compile, another 3s to run tests is simply tormenting. It breaks the flow because I have to repeatedly wait for the computer to catch my thought. [0]: https://wallabyjs.com/ https://wallabyjs.com/
- geofft 5y agoSince the moderators seem to have collapsed the subthread about it (but not flagged it, so I can't vouch for it), I'd just like to say that the random puerile joke in this article detracts from its technical merit.
- kens 5y agoAs a historical note, I'll point out that 1975 computers weren't as primitive as the article implies. Virtual memory was introduced commercially in 1961 with the Burroughs B5000. Cache memory was introduced on the IBM System/360 Model 85 in 1969.
- phkamp 5y agoAbsolutely, but did you ever try to use any of that ? Back then /everything/ was a special case and everything needed to be programmed as such. This is literally why JCL is a nightmare. The genius of Ken & Dennis was to boil all the special cases down to one simple abstraction. (Look at the socket API to if you want an example what happens when people dont understand the importance of sticking with the dominant abstraction.)
- ithkuil 5y agoAny good examples of how the socket API could have been better if they did stick to the dominant abstraction?
- alexshendi 5y agohttps://9p.io/plan9/ https://9p.io/plan9/ SCNR
- graycat 5y agoOn what design features came to market when, two examples: (1) In 1972, I was at Georgetown U., and IBM was proposing that we buy a 370/135 with virtual memory. (2) In 1973 there was the IBM 360/67 with 31 bit addressing, virtual memory, and virtual machine.The virtual machine software was CP/67 (Control Program 67), and the user interface was from CMS (Conversational Monitor System). I programmed it in PL/I to schedule the fleet at FedEx.
- jleyank 5y agoRCA/Sperry Univac had reasonably large scale time sharing systems running basic, FORTRAN, apl, algol and 360-compatible assembly language. They had both physical and logical I/O APIs and supported vm to both disks and drums. Fill in the rest of the old time computer room as you’d like. Did a chess program and various other things in assembly, wrote the required Star Trek game in basic etc. As they provided the source code to the OS, even messed around with changing things like adding 2-step logins and other hacks. Basically, that decade saw the continuation and growth of the hacker culture that started in the early 60’s on trivially small machines (google spacewar). As there were no small machines, things were more social / collaborative than now out of necessity. And yeah, the hardware is bazillion times faster but the software less so as code bloat is real.
- eternalban 5y agoThis post elicited a response from antirez back in the day. Then he and "the varnish guy" /g had a meeting of geek minds. You'll learn quite a bit from both. http://oldblog.antirez.com/post/what-is-wrong-with-2006-programming.html http://oldblog.antirez.com/post/what-is-wrong-with-2006-prog...
- deleted 5y ago[deleted]
- dang 5y agoSome past threads: What's wrong with 1975 programming? - https://news.ycombinator.com/item?id=13435988 https://news.ycombinator.com/item?id=13435988 - Jan 2017 (3 comments) So what's wrong with 1975 programming? (2006) - https://news.ycombinator.com/item?id=9260169 https://news.ycombinator.com/item?id=9260169 - March 2015 (20 comments) So what's wrong with 1975 programming? (2008) - https://news.ycombinator.com/item?id=4874304 https://news.ycombinator.com/item?id=4874304 - Dec 2012 (128 comments) What's wrong with 1975 programming? - https://news.ycombinator.com/item?id=1760811 https://news.ycombinator.com/item?id=1760811 - Oct 2010 (12 comments) What's wrong with 1975 programming - https://news.ycombinator.com/item?id=1554656 https://news.ycombinator.com/item?id=1554656 - July 2010 (115 comments)
- ajarmst 5y agoI find this to be a bit of an oversimplification. It's certainly not the case that there's only one type of storage, at least from a hardware perspective: there will always be storage that is faster than other storage, and managing that will always be required to optimize performance. I agree with the author that you should program against the simplest abstraction you can, but that's not always clear. Just because your environment is one in which you don't have to doesn't mean you can't or shouldn't in the right circumstances. I'd argue that it's actually more complex now. I programmed in the early 1980s, and did have to worry about where my data physically resided inside the machine, but I never had to worry about whether it was in a different room on a different machine, or sitting on a hard drive in some Amazon Data Center a continent away. As others here note, the idea of using the same abstraction for all storage is at least as old as MMUs and Multics (mid 1960s). What is different is that programmers in the 60s and (early) 70s were usually coding pretty close to the bare metal. Nowadays, Moore's law has allowed us sufficient power to permit programming on top of a big pile of abstractions that try very hard to hide the actual hardware from us. That's a luxury afforded by the sheer power of what we're working with, but the people writing those abstraction layers still have to pay attention to the layer beneath them, and if you go down far enough, you'll find some code that needs to pay attention to what class of memory something is stored in and how to optimally move it around. It's just that work was probably done for you by someone else who wrote your operating system. Just because your programming language doesn't require you to use pointers doesn't meant that indirection isn't being used. You just don't have to deal with it (until it rears up and reminds you it's still there). Joel Spolsky's Law of Leaky abstractions (https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/ https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...) is relevant here.