How to survive a ransomware attack without paying the ransom - <AUTHOR> https://www.bloomberg.com/news/features/2020-07-23/how-to-survive-ransomware-attack-without-paying-ransom <comment><USER2> Garmin CEO at al must be reading this impatiently, looking for some clever- magic clue, which is not gonna arrive, I am afraid.

Meanwhile Garmin watches users (like me) are wondering how it is that syncing my watch that I have bought with an application on my smartphone that I have bought requires presence of some distant online service.

I can understand that some parts like "social" stuff might depend on some central service but, hey, something simple like syncing ones excercise achievements between phone and watch? Really? Who has designed that?

<comment><USER3> It is surprisingly difficult to make synchronisation work between two devices that might run different hard- and firmware and even potentially software versions. Cloud based APIs as middleware is soo much easier in comparison.

I am completely with you conceptually, but from experience I can tell you that even if there is a commercial incentive to allow for local communication it takes a few days to get it working with the cloud and months to do it locally only. And you really need to know what you are doing to make it safe and reliable in all eventualities.

<comment><USER4> What makes it so difficult? What are some concrete problems you encountered?

<comment><USER5> It is not intrinsically difficult, it's made difficult by the fact that the companies themselves specifically want to have their infrastructure in the mix to have access to valuable user data. There's no particularly difficult challenge to sync the phone and watch directly, offline. A good chunk of revenue comes from services which rely on the data being in the cloud.

<comment><USER6> I worked on a competitor.

It was 100% about user expectations, the data was never mined for anything.

People use multiple phones, replace their phone, delete apps to free up space, and still expect their data to be there.

Running a cloud infrastructure for PII isn't exactly low cost, and bundling a life time subscription with a one time device purchase is horrible economics. It isn't done for no reason.

<comment><USER5> > the data was never mined for anything

Oh I wasn't implying what's generally seen as "data mining". But for such a company to offer many of the features in the paid services they need that data. They don't have to sell it to others, they only have to sell it back to the users as added services even included in the price of the hardware itself. Those added services can be as simple as sync between multiple phones or sharing on social media, or premium features like advanced analytics.

On the other hand this kind of data can be also sold entirely anonymized. Strava does this and many cities' urban planners buy the data to understand better how the city infrastructure is used by the people (running, cycling, etc.) and how to develop it.

I'm not saying there's no value in it, just that without it the value of the product decreases significantly. So it's in the manufacturer's best interest to have it as part of the basis of their offering.

</comment></comment></comment></comment></comment></comment><comment><USER7> _It is always a temptation for a rich and lazy nation,

To puff and look important and to say: –

"Though we know we should defeat you,

we have not the time to meet you.

We will therefore pay you cash to go away."

And that is called paying the Dane-geld;

But we've proved it again and again,

That if once you have paid him the Dane-geld

You never get rid of the Dane._

[http://www.kiplingsociety.co.uk/poems_danegeld.htm](http://www.kiplingsociety.co.uk/poems_danegeld.htm)

parenthetically, this is equally true of toddler-geld.

</comment><comment><USER8> > _In other words, it's less a question of how to stop hackers from breaking > in than how to best survive the inevitable damage._

There doesn't seem to be conventional wisdom about how to build systems that are easy to restore. How do you optimize for recovery after an attack? How do you ensure that you've eliminated all the backdoors?

My guess is a combination of "continuous restoration", version controlled code, and a complete separation of code from data.

I want to read books about this but they don't seem to exist.

<comment><USER9> Just having a decent and reasonable way to nuke and pave machines goes a long way. Most organizations don't have a good way to shoot a machine in the face and have it back up and serving in 2 minutes. Most organizations are absolutely married to "stateful services" like SQL databases with local storage, that are hard to kill, hard to restore, and give attackers a place to hang out.

If you can take all your hosts down and bring them all back up quickly, that gives you at least one tool for disrupting the attackers.

<comment> em-bee which company was it that randomly shot down machines in production to make sure the system would be resilient enough?

<comment><USER10> Sounds like the Netflix chaos engineering team

</comment></comment></comment></comment><comment><USER11> How is ransomware able to spread to all the PCs in a company? (Especially PCs at different locations around the globe)

The malware needs to execute itself on each computer. But I would think this would be thwarted by hardware firewalls as well as apps like Windows Firewall.

If my PC at work gets infected, somehow it can magically infect the guy down the hall's PC too? I thought that was made impossible years ago.

<comment><USER12> The common components in the ransomware attacks is Windows and AD.

Some leverage known exploits against elements like LSASS, so if the person infected has credentials for another computer, why not slurp up all the credential tokens on remote computers that you can log into too.

If you use Linux/Unix on the other hand, you can do descent things to contain access. Firstly, elevated management accounts can restrict login sources, either by ssh authorized_keys or deny rules in sshd_config. Secondly, and very importantly, you can contain what applications can access through SELinux.

Running Windows these days is like walking around with "Kick me" hung around your neck.

<comment><USER13> None of what you mentioned requires a lot of effort on Windows. Exploits in LSASS are no different from exploits in Linux kernel, and if you stay up to date and configure everything correctly you should be fine.

<comment><USER14> LSASS is a system process, need SE_DEBUG_PRIVILEGES to read its memory (full system administrator).

As far as I am aware, the last time there was an actual exploit in LSASS was in Windows XP.

</comment></comment></comment></comment><comment><USER15> I know this is always contentious but are there any of these ransomware attacks on non Windows machine? I mean prominent ones? I understand everyone is running Windows on the desktop, but why are Linux servers not targetted by the same thing as they are prominent? I know they get hacked all the time, but I never read stories like this about them. I read that mongo was hacked (and yeah, using mongo, sorry but...) which probably ran on Linux; however pure ransomware attacks I cannot find outside Windows. People keep saying that if other devices would be as popular, they would attack them; but for instance my mother has an ipad, android phone and a windows laptop, and the only (penis enlarger.....) malware is in windows which has an up to date AV. Android is more popular than Windows, Linux on servers is as well, iOS is as well. And yet all the crap is always Windows. I do not get it.

<comment><USER16> Ransomware attacks absolutely _do_ target Linux servers because one needs to take down all the servers to have a proper business disruption for which someone will pay a million dollar ransom; in all the recent prominent attacks Linux servers were taken down as well.

Perhaps there's some issue with what you mean by "pure ransomware" \- if you mean automatically spreading worms, then those aren't that relevant, prominent examples like Petya was four years ago; NotPetya was not ransomware but a destructive weapon, etc. In the current environment, and also in the attack described in this article, a "ransomware attack" means a takeover of your systems by a ransomware crew of hackers manually working on your specific network. They generally start with a spearphishing which targets Windows desktop machines because usually the easiest way to target Linux servers is through client-side attacks, obtaining user credentials and a foothold inside the network that helps with firewall restrictions.

<comment><USER15> > obtaining user credentials and a foothold inside the network that helps with > firewall restrictions.

Yes but those are somewhat human errors; my point is more along the lines that linux might be the primary target for the entire attack, but it always starts with attacks on Windows. I was looking for a case, specifically with ransomware, that started with Linux/Mac OS X instead of Windows.

In my opinion (and to be honest, PCI DSS actually enforces this some extend) it should not be possible to gather linux credentials from singular hacked machines. If you hack my system, you will not be able to login to our prod linux machines; you will need my hardware device to generate OTPs. This is what we actually do for a living, but it is rather weird that people don't just have google-authenticator as standard for lack of a hardware token; then your private key would still not get the hackers anywhere. Use hardware tokens + non-windows then basically none of these attacks would work.

</comment></comment></comment><comment><USER17> I consider the modal on the bloomberg site a ransomware. Can't close till you pay. Joking :)

<comment><USER18> Yeah screw that paywall. Paste this into the console

        document.querySelector('.paywall-inline-tout').remove();
        document.querySelectorAll('p').forEach(e => e.style.display='');

<comment><USER19> I prefer control-W

<comment><USER20> One of my extension appear to be blocking it because I didn't know it existed

</comment></comment></comment></comment><comment><USER21> Given there's been a recent trend about ransomware not only encrypting, but also exfiltrating data, backups won't save you from the bad PR of the leak.

</comment><comment><USER22> [https://archive.is/Rfcha](https://archive.is/Rfcha)

</comment><comment><USER23> The unfortunate thing is that the ransom probably is priced such that it's cheaper than the company resolving the problem on their own. Or the company would just resolve it without paying the ransom. On the other hand, it's bad on many fronts if the company just decides it is the cost of doing business, and doesn't do a great job of securing their systems in the future...

Many companies just get by, rather than doing serious security design. How do you change that culture in a company? Will paying the ransom do that? Probably if it only costs $1M to do. If it costs them $100M to do, would they do it?

</comment><comment><USER24> This is not really surviving. What do you need to do is prepare and to have off line backups

<comment><USER25> Offline backups have been a thing for decades. Why is this not standard practice? Especially for a technology company like Garmin. It can't be about cost savings, businesses still pay for insurance and security systems. For that matter, offsite backups should also be saved in case of fires, floods, tornadoes, theft, etc...

<comment><USER26> Offline backups are not a complete solution. What if your backups are infected with the virus? Even if the backups are uninfected, your IT department has to manually scrap and rebuild all your computers from data centers to the warehouse to the receptionist. And in the meantime, like the article described, you have to pay your employees and suppliers and continue to ship products to customers.

<comment><USER25> An important part of any backup strategy is testing your backups on a regular basis. Perhaps it could even be automated...

<comment><USER27> I think the point here is that it's not as trivial as having an offline copy of your SQL DB or whatever. If the ransomware has encrypted a huge chunk of your infra the chances are that you no longer have anything to restore the backup to — maybe your configurations are encrypted, your DB hosts aren't up, user accounts etc are missing. Assuming that only user data is affected and can be easily restored likely falls very short of the full picture. I expect the folks at Garmin are faced with an infrastructure that looks like a grenade fell into it.

</comment></comment></comment></comment></comment><comment><USER28> Good story, bad title. There is no real lesson on how to survive ransomware except that company called Hydro was able to use employees to rebuild some of its data needed for running plants. Most companies deal with databases that cannot be similarly rebuilt in just days like that.

</comment><comment><USER29> I wonder how many of such attacks can be prevented / starved in a zero-trust network.

</comment><comment><USER30> This quote left me dumbfounded, marveling at sheer level of incompetence (or bureaucracy) some places have:

"Three weeks after the attack, Hydro had a total of four functioning PCs in all of the U.S."

</comment><comment><USER31> Judging by comments hackers aren't commenting on hacker news anymore.

</comment><comment><USER32> Isn't a ransomware attack no different from a catastrophic disk drive failure? You reformat and restore from backup. Of course, the companies profiled in that article had all their computers infected, so it could take some time. Still a recovery boot disk could be distributed and a clean image restored over the network.

<comment><USER16> No, because you can't consider your backups as a "known good state". A malicious attack is fundamentally different from a disaster or accident.

You should expect that any backup of systems (instead of backups of 100% pure data) will contain backdoors, that any weird systems (routers, printers, phone centrals) may be compromised even if they seem fine, and that the credentials of all the employees and any private keys/certificates have been exfiltrated, so they need to be changed.

<comment><USER33> Even "100% pure data" isn't necessarily safe. Word documents, Excel sheets, PowerPoint decks, _etc._ (and their Google Docs counterparts) are all suspect, because they can contain embedded code. Some "data" formats are really not data formats at all, but _code_ which produces the data you use ( _e.g._ PDF, Postscript, or any Excel sheet with formulas). It's even possible to corrupt certain otherwise inert data files in such a way as to cause malicious behavior by exploiting bugs in the software that reads them.

So, yes, while you're technically correct that 100% inert and uncorrupted data files are safe, you have to _prove_ that those files are not corrupted. And, so many data formats either are code or contain embedded code, so these need to be treated as suspect until proven otherwise, as well.

<comment><USER16> Well, yes, I would not consider arbitrary documents as "pure data" \- for that I was thinking as something like a dump of a particular database table contents only, separate from all the database structure/metadata/triggers/functions/etc.

You could restore a dump of pure structured data to a known clean system and that would be safe - but once you include arbitrary files as you describe, no way. Embedding malware in some periodically-accessed document on a public file share is a reasonable persistance mechanism for an attacker.

<comment><USER33> I would expect a SQL dump of a database to be safe, as long as the schema only contains standard data types and no BLOBs. Once you start throwing BLOBs in there, anything goes.

</comment></comment></comment></comment></comment><comment><USER34> I find it very interesting the Volume Shadow Copies and VLANs are basic tools that have been around forever, cost very little and can mitigate a lot of ransomware attempts.

There's no reason for the secretary's computer to be able to connect to the onsite SQL server... unless she uses an application that uses that SQL server.

<comment><USER35> The complicated part isn't figuring out that you should segment access or finding technology that lets you do it it's actually knowing what to segment in a way that balances risk with speed and cost.

The same is true for most things. Problems are often well known, solutions are often understood, but doing things is where the actual work is.

</comment></comment><comment> Tiltowait-- Easy: restore from backups.

<comment><USER36> What if they hacked you months before pulling the trigger? The article mentions they were hacked in December and the attack launched in March. Restoring a backup would then still leave the hackers inside.

And even if most data were backed up, most computers still have to be wiped and reinstalled. I don't think most companies backup the entire disks off all employees, it's normally just a dedicated file area. So while the data can be restored, the IT department still have to set up hundreds of computers for all kinds of different workers or machines on the spot.

Nothing is ever easy, don't be so dismissive about things you haven't thought through.

<comment><USER37> Companies of non-trivial size often have (and should have) a system allowing for remote device management. Which means:

\- It should be easy to reinstall to a known good image with all the relevant software, settings, drivers, etc. then restore the backed up data. This is relatively common in corps.

\- Once you observe the malware and know how it reaches the C&C server, you can push rules blocking that host or block the bad binary network-wide.

Of course there will be companies that didn't have good enough system in place and once exploited are doomed.

<comment><USER38> The attackers likely compromised the computers using the remote device management system which means it's either disabled or unsafe to use.

<comment><USER37> Sure, you need to make sure your AD and device management is clean before starting the process. My point was that once you're bootstraped you shouldn't need a fully manual recovery process.

<comment><USER38> And I'm pointing out that when your attacker has control of device management they can also disable device management on all the devices after their attack is deployed.

</comment></comment></comment></comment></comment></comment><comment><USER39> some of these companies, need to start suing microsoft. since it's usually windows affected by these malware attacks. if microsoft wants to keep serving the majority of the corp world, they need to have an os, based on user space system. i.e each program runs in it's own sandbox. and any data passed is via message passing.

<comment><USER14> Microsoft has pretty good security nowadays.

It's the fault of companies for never upgrading their machines, giving full administrators access to every employee and using Admin123 as the domain administrator password account.

If we believe the article, the virus came from an attachment in an email to a random employee. Why are executable attachments not blocked? Why is an executable running as an unprivileged user able to storm through every computer in the company?

<comment><USER40> But did they? Were their machines updated? Did they have some "corporate AV" solution that was useless?

> Why are executable attachments not blocked?

Because there are dozens of weird Windows extension types that execute automatically on Windows, though yeah the attachment should have been blocked and a customer service machine should have a whitelist of programs that need to run (or only run signed ones)

</comment></comment></comment><comment><USER41> You can't because of bitcoin. Bitcoin is what criminals dream of.</comment>


Ask HN: Becoming employee #1 - <AUTHOR>

For those of you who have experience becoming employee #1, what are the most important things to look out for when deciding to join? I'm particularly worried about delays in compensation and insolvency but are these things I should be worried about? <comment><USER2> I've had experience hiring employee #1 and my wife's had experience being employee #1 at other companies.

At that stage the founders should be comfortable talking about cash on hand and burn rate with you, so while insolvency is a risk, you'll at least see it coming. Confirm that they're open about this before joining. I wouldn't join any startup as employee #1 unless they were totally open with me about cash on hand, burn, and equity.

In my opinion, the biggest risks at a company that small are a) the founders not getting along and you feeling like a kid caught in a messy divorce, b) pivots transforming your job or your product into something you're not interested in, and c) soul-crushing workload transforming you into a burnout case. But those are hard to detect in advance.

The one thing you can detect in advance is whether, administratively, they've got their act together - formal offer letter, assignment of intellectual property paperwork, copy of the options plan, etc. Don't ever enter an employment situation where you're starting now but formalizing the paperwork later, when they can afford to spend money on a proper lawyer. That's amateur hour and you'll get burnt.

<comment><AUTHOR> Thanks! At this stage of the game, I've heard great things from the founders and they have had a successful exit before. I was planning on meeting up with them anyway even I've decided not to be employee #1 for now. Is it fair to ask about their exit strategy and their plans for growth?

Also, is it fair to make the assumption that employee #1 would be required to put in long hours (soul-crushing or otherwise)?

<comment><USER2> It's fair to ask about their exit strategy and plans for growth, to get a sense of how they're thinking about their company. At this stage I wouldn't expect their plans to have much more than a tenuous connection with what will actually happen, of course. You're learning more about them than you are about the future of your company.

It's a really good sign that the founders have successfully done this before, as long as they're continuing to build on and play to their strengths. If the founders' first startup was in a field they knew intimately (accountants building accounting software, say), but now they want to get into something completely unrelated (say, 3D printing), in my opinion that's a bit of warning sign. Previously successful people are susceptible to hubris - 'I did _x_ , so I can do _anything_!' Often false. Still better than completely inexperienced founders, I think, but by choosing something they know nothing about they're canceling out a lot of their advantage.

Yes, people at startups generally work long hours - that's a fair assumption. But there's a dividing line between long and soul-crushing that varies from person to person.

</comment></comment></comment><comment><USER3> I moved from a start-up in the pre-IPO phase to a start-up in the pre-we-have- checks-with-our-names-on-them phase, and it didn't work out. I took a small pay cut and the increased risk, and a learned a _ton_ on the job, but in the end the mismanagement and inability to accept feedback, I think, led to their demise. At the high point, there were about eight of us working there.

I should have started looking for a way out when the paychecks started coming late and I didn't find out until payday that I wasn't going to be paid. I got laid off three months later. My salary has never recovered.

Would I do it again? Apart from the fact that my wife would probably leave me, for sure. The long hours and tough projects were really challenging, but both in a good and bad way, and I worked with some pretty passionate people there. You just have to make sure that the founders are someone who deserves your absolute faith.

Finally, if you're employee #1, you probably deserve some equity (if you want it - you might not). I don't know what phase this company is at, but it should be anywhere from 5 to 10 percent (closer to 5 than 10). If a company offers you anything more than 10% equity, that's probably a warning sign.

<comment><AUTHOR> Thanks! I do have a fear that the paychecks might be coming late and I have several dependents as well as student loans to repay which I think would be too risky for me at this stage of my life.

I do appreciate your comments though. How can you tell apart a start-up from the pre-IPO phase to a start-up in the pre-we-have-checks-with-our-names-on- them phase?

Are there any tips on evaluating founders in general? I've only ever worked with established companies and have limited experience in evaluating founders.

</comment></comment><comment><USER4> The most important thing to look for is your own willingness to be employee #1 and not a founder.

Your role is different, often radically.</comment>


Is this the new iPhone 6? - <AUTHOR> https://www.youtube.com/watch?v=34T80iLYojk&feature=youtu.be

<comment><USER2> Heads up, about 20-30 seconds in, NSFW.</comment>


Sweden records highest death tally in 150 years in first half of 2020 - <AUTHOR> https://edition.cnn.com/2020/08/20/europe/sweden-deaths-highest-coronavirus-lockdown-intl/index.html <comment><USER2> Another absolutely childish article from the media.

"Despite the more relaxed approach, only 7.3% of people in Stockholm had developed the antibodies needed to fight the disease by late April -- well below the 70-90% needed for herd immunity."

They both condemn Sweden's approach but then seem proud hahahaha not enough people caught it.

As a society we need to stop supporting this media. I get people are dumb in general. But there needs to be someway to stop this.</comment>


Which BoD or E-book publisher would you recommend? - nils-m-holm I currently have about 15 book titles at Lulu.com, but I am looking for alternatives. In particular, I am looking for a publisher who lets me keep the copyright and distributes PDF and EPUB files as provided by me without and tampering. <comment><AUTHOR> I use leanpub [1] and gumroad [2]. Based on my testing, what we upload is retained exactly as it is. Unless you use options like make each copy unique (by adding some marker, etc). And as far as I understood the terms and conditions, the author retains the copyright.

[1] [https://leanpub.com/](https://leanpub.com/)

[2] [https://gumroad.com/](https://gumroad.com/)

<comment> nils-m-holm Excellent! Will have a look at both! Thanks!</comment></comment>


Any hackers in Phoenix, AZ? - <AUTHOR>

Any hackers in AZ? I am interested in sharing thoughts and networking all in the name of entrepreneurship. <comment><USER2> I'm from Tucson. There are a number of programming and DBA jobs in Phoenix. I constantly get contacted to do contract work in the area. I don't know how many startups are based in the area. I'd look into attending a Refresh Phoenix meeting or goto a startupdrinks. Though it looks the the startupdrinks site just sends you to other local groups.

<http://www.refreshphoenix.org/>

<http://phoenix.startupdrinks.com/>

</comment><comment><USER3> There seems to be a limited number of really good hackers in town and of the ones I associate with they all seem to be extremely busy at the moment.

The real issue is that Phoenix still isn't the tech hot bed everyone thought we might become, so attracting and keeping talent in town is extremely difficult.

I know I have left town twice for opportunities I just couldn't locate in town, though I always seem to come back.

</comment><comment><USER4> There are four or five of us in Phoenix I think.</comment>


On a caravan, with one of the Sahara's last European explorers - <AUTHOR> https://phys.org/news/2020-06-caravan-sahara-european-explorers.html <comment><USER2> This story reminded me of a documentation I saw some years ago, about also a french guy in the sahara dessert. But more extreme, he was basically living in the dessert and moving around with his camels nomad style. Would be curious if he is still there. Possible.

Deserts are a special place. I can agree to the statement from the article. It is never boring. At least not, when you choose to do the real dessert experience. Then you discover joys you did not imagine before, like finding fresh, drinking water, when you are dehydrated since a while, because the last 2 water springs had dried out and you really had to find water. It can be orgastic, when your body literaly starts to be flowing again, as the body shuts down function after function if there is water shortage. And then it is a rush, if finally the blood can flow again ... (and that can actually kill you, if you drink too much too quick, after being dehydrated, start with some sips)

I experienced that not in a dessert, but on a long hike in a dry area, where fresh-water spots on my map did not had running water in reality and no civilisation around. So I was rationing water. But then the next day, I found a spring. And so much water coming out! I could not believe it, all this fresh water just flowing and flowing and flowing ...

<comment><USER3> Getting the "real desert experience" in terms of migrating with camels or whatever must be hard in recent years.

In Moroccan-occupied Western Sahara there is a heavy police presence that doesn't want foreigners straying off the main highways, because foreigners might make contact with representatives of the oppressed indigenous Saharawi people. Sure, hundreds or thousands of elderly Europeans go down there every winter in their camping cars, Senegalese immigrants in Europe driving home to visit etc., but all they see is the tarmac running alongside the coast or the occasional towns.

In Mauritania, police tend to discourage you from wandering for different reasons, they don't want their tourism industry to suffer again from incidents of foreign tourists being attacked by militants. For similar reasons, southern Algeria is said to be difficult to move around in freely, and Libya is completely off-limits to tourists due to unrest.

<comment><USER4> Do you have any references?

Morocco is hugely popular with French / European 4x4 drivers and motorcyclists because of the terrain. It has everything, green mountains in the high atlas then sand, desert and mars like terrain as you go south and it's extremely quick and easy to get to jumping on a ferry from Spain.

I know they have army checkpoints at specific places but when I've been I've been extremely remote, way off the highway surrounded by nothing but sand dunes or baron landscapes. We drove through a checkpoint at one point which was essentially a small shed at the side of a track close to the Algerian border. Guard mustn't of heard us coming asleep in the office or something, came out waving after a few of us past, went back inside when we disappeared in to the distance.

<comment><USER3> Most people exploring Morocco overland are in Morocco proper, where there isn't the same strict control of foreigners as in Western Sahara. The checkpoints start at Guelmim and are spaced about every 100 km apart. One has to present one's ID or a printed page known as a _fiche_ with these details (a web search for Western Sahara + fiche will probably give plenty of travel blogs with details on the police scrutiny). Plainclothes police are also present at the major intersections to report on what direction a foreign-owned vehicle takes.

Although Morocco proper has some sand dunes in the east which are popular with tourists, these are not the "real Sahara", which is traditionally considered to start at Guelmim.

<comment><USER2> Yeah, there is a great difference between morocco and occupied western sahara. My morocco experience started in western sahara - and it was interesting to watch, but no fun, to be bothered by secret police all the time. I had intentions of traveling around there and meeting local population and getting into the sahara, but this was not really possible in a way I wanted. I played the naive tourist quite well, so I was not too much pestered, as being a european tourist, because the king himself has ordered to all police to be nice to tourists. But they really do not want journalist, I had to convince many slimy assholes where I felt dirty to shake hands with them, that I was not a journalist, nver were and no intentions of becoming one. And since I really was not a journalist I decided to be it not worth it. But I have friends who drove around with a bycicle there and camping overnight, so that is possible, but not peaceful. And dangerous if you come too close to the border.

Morocco then again was really different, full of hippies and other tourists. It surely has dangerous spots as well, but I felt quite safe hitchhiking there and I even met young women, who did hitchhiking there, without being kidnapped or raped, but that can happen.

And the real dessert experience, well, I was south-east of Zagora, wich was quite touristic - but to me it seemed the "real Sahara" did also start there. I met local beduins who felt that way too, but yeah. The border to algeria was too close and too guarded. And in the real dessert there are no nation borders, who pester the nomad.

</comment></comment></comment></comment></comment><comment><USER5> If you find the Sahara interesting, check out an older documentary by Pailin for the BBC.

[https://m.youtube.com/watch?v=O0A3JyK_N34](https://m.youtube.com/watch?v=O0A3JyK_N34)

Note that these were done in 2001

</comment><comment><USER6> Wish I was brave enough to explore some of these places. Unfortunately I feel I would almost certainly be killed, if not by man, then by the elements.</comment>


Alan Kay and Missing Messages - <AUTHOR> https://ovid.github.io/articles/alan-kay-and-missing-messages-a-follow-up.html <comment><USER2> This blog post proposes a "data" sanity solution (alternative external oracles, or "scoring" on probabilities, etc) but that's not really what the comment by Samuel Falvo II was about.

His problem was _syntax getting broken_ and not about "questionable data". In the context of dynamic vs static compile, he's worried about scenarios like this:

      x = customer.last_name  // worked on Friday and x=="Smith"
      - remove field customer.last_name // Saturday refactor
      + add field customer.full_name  // Saturday refactor
      x = customer.last_name  // broken on Monday with a runtime error

With a static type system, the changes on Saturday would have told them _immediately_ at compile time that the last_name field access by other client code was broken. (And yes, one typical answer for handling errors like that in dynamic type systems is _unit tests_ \-- but that's veering off into a different conversation.)

This essay is a "solution" to a different problem.

<comment><USER3> > ...would have told them immediately at compile time that the last_name field > access by other client code was broken.

What's the proposed fix in this case? Should all clients accessing that field switch to `customer.full_name`? Do you control all of the call-sites? If so, that change is pretty easy to automate in dynamic languages by marking the field as deprecated, adding the new field, and forwarding `customer.last_name` to `customer.full_name`. That way, running systems don't break but you get the new behavior. You can automate logs to track when the deprecated field is accessed and, if necessary, fix call-sites after a reasonable period of monitoring, reducing risk (assuming there's not "once-in-a-century" paths in the code that invoke the call site).

It seems reasonably likely that this is _not_ the desired behavior - you may have external clients, and some callers may be relying on this field to actually return only a last name. In that case, deprecation is _still_ the correct path, I think, since it's unreasonable to expect external clients to immediately fix systems relying on that field being available.

Static typing can tell clients _where_ they need to make changes, but it's not realistic demand that they immediately update every call site, every method depending on that behavior, and every integration with _their_ external dependencies that relied on the interaction between your code and another system. This is why we have (semantic) versioning, deprecation warnings, and support agreements for larger systems. API's should evolve slowly and gracefully over time, not shift suddenly overnight.

<comment><USER4> The proposed fix is that you don't deploy code that the type system can prove is broken, and the person performing the refactoring needs to do additional work rather than pushing out something that will fail in production.

My reading of jsode's example is in a shared codebase, where it would be reasonable for the person performing the refactoring to update all call sites, and where checking in a change that does not update all call sites to whatever branch is released to production should be unacceptable, as it will provably cause problems in production.

If the change was made in a standalone library that other teams depend on, the type-checker error would be produced when they update the library to the new refactored version, and it's the same story: prohibit deploying known-invalid code to production until you've updated all call-sites to match the changes in the library API.

If updating all call-sites immediately is implausible for whatever reason, leaving the old field in place with a deprecated annotation would be quite reasonable, but the purpose of a type checker in this context is to prevent you from failing to handle this in at least some way. As you say, responsible maintainership of an API should facilitate gradual transition; the use of a type-checker here is to prevent deploying code that will fail at runtime when someone has made a mistake, and can help facilitate responsible maintainership.

<comment><USER3> I don't disagree that static type checkers and analysis software can be useful for catching many kinds of errors. In fact, at the end of my comment I emphasize exactly their strength: in automatically detecting when and where clients need to make changes. My intent in making the comment was to highlight that static analysis is only one part of a larger solution to the problem of keeping call sites in sync with the code they depend on, and to discuss other techniques that don't rely on static analysis. I think articles and comments online focus too much on the debate between static and dynamic typing, instead of the engineering principles that apply to both camps, which can help mitigate the risks associated with change.

</comment></comment></comment></comment><comment><USER5> I think there's a big difference between not understanding the message, and not understanding the data (a message parameter).

When they get an unrecognized message, Objective C objects call their doesNotRecognizeSelector method, and Smalltalk objects call their doesNotUnderstand method.

And the object sending the message can first check with respondsToSelector in Objective C or respondsTo in Smalltalk, before sending the message.

But validating and sanitizing input parameters is a totally different thing than handling unknown messages, orthogonal to object oriented programming.

<comment><USER6> Hm, I don't see how they are totally different and orthogonal.

Objects and messages are kinds of types. Types can have constraints and conditions and there is all sorts of nuance.

Difference, yes. But completely different? No... when designing a system there is a lot of freedom in where to draw the shapes of the system, how much information do we contain in the objects themselves, a hierarchy or inside parameters.

"Stringy interfaces" is one extreme. There are many others.

<comment><USER5> I think you're barking up the wrong class hierarchy, trying to reformulate objects, messages and parameters as abstract data types. Alan Kay has been quite clear about his opinion that "Abstract Data Types" is not OOP.

[http://userpage.fu- berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...](http://userpage.fu- berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en)

>One of the things I should have mentioned is that there were two main paths that were catalysed by Simula. The early one (just by accident) was the bio/net non-data-procedure route that I took. The other one, which came a little later as an object of study was abstract data types, and this got much more play.

>If we look at the whole history, we see that the proto-OOP stuff started with ADT, had a little fork towards what I called "objects" \-- that led to Smalltalk, etc.,-- but after the little fork, the CS establishment pretty much did ADT and wanted to stick with the data-procedure paradigm. [...]

>(I'm not against types, but I don't know of any type systems that aren't a complete pain, so I still like dynamic typing.)

>OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them.

[https://computinged.wordpress.com/2010/09/15/alan-kay-on- mot...](https://computinged.wordpress.com/2010/09/15/alan-kay-on-motis- objects-ever-cacm-article/)

>If you are "setting" values from the outside of an object, you are doing "simulated data structure programming" rather than object oriented programming. One of my original motivations for trying to invent OOP was to eliminate imperative assignment (at least as a global unprotected action). "Real OOP" is much more about "requests", and the more the requests invoke goals the object knows how to accomplish, the better. "Abstract Data Types" is not OOP!

[https://news.ycombinator.com/item?id=10967103](https://news.ycombinator.com/item?id=10967103)

>An interesting historical note is that the two inventors of Simula had completely different views of what they were doing and how it should be used for programming. Dahl was brilliant and conservative, and later wrote papers about using class definitions to make Abstract Data Types (and that is how a lot of so-called OOP programming is done today). Nygaard on the other hand was quite a wonderful wild man and visionary -- beyond brilliant -- and was into the abstract "simulate the meaningful structures" idea. Dahl was trying to fix the past and Nygaard was trying to invent the future.

[http://worrydream.com/EarlyHistoryOfSmalltalk/](http://worrydream.com/EarlyHistoryOfSmalltalk/)

>"Object-oriented" Style

>This is probably a good place to comment on the difference between what we thought of as OOP-style and the superficial encapsulation called "abstract data types" that was just starting to be investigated in academic circles. Our early "LISP-pair" definition is an example of an abstract data type because it preserves the "field access" and "field rebinding" that is the hallmark of a data structure. Considerable work in the 60s was concerned with generalizing such structures [DSP *]. The "official" computer science world started to regard Simula as a possible vehicle for defining abstract data types (even by one of its inventors [Dahl 1970]), and it formed much of the later backbone of ADA. This led to the ubiquitous stack data-type example in hundreds of papers. To put it mildly, we were quite amazed at this, since to us, what Simula had whispered was something much stronger than simply reimplementing a weak and ad hoc idea. What I got from Simula was that you could now replace bindings and assignment with goals. The last thing you wanted any programmer to do is mess with internal state even if presented figuratively. Instead, the objects should be presented as sites of higher level behaviors more appropriate for use as dynamic components.

[https://medium.com/@richardeng/goos-is-looking-at-it-from- th...](https://medium.com/@richardeng/goos-is-looking-at-it-from-the- perspective-of-abstract-data-types-56c6d98108d3)

>GOOS is looking at it from the perspective of Abstract Data Types. In Alan Kay's conception of OOP, instead of static structures that are easy to reason, aliasing gives you dynamic systems of collaborating objects that are endlessly flexible and scalable, just like in nature's biological systems of cells or the Internet of web servers. Proponents of ADT-style thinking, who use languages like C++ and Java, can't imagine such complex systems, or they're afraid of them.

[http://mythz.servicestack.net/blog/2013/02/27/the-deep- insig...](http://mythz.servicestack.net/blog/2013/02/27/the-deep-insights-of- alan-kay/)

>Where the big missing piece lacking in mainstream typed OO languages today is:

>The big idea is "messaging"

>He advocates focus should instead be on messaging and the loose-coupling and interactions of modules rather than their internal object composition:

>The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be.

>And finds static type systems too crippling:

>I'm not against types, but I don't know of any type systems that aren't a complete pain, so I still like dynamic typing.

>Other popular languages embracing Smalltalk's message-passing and late- binding and having implemented its message-based doesNotUnderstand construct include: forwardInvocation in Objective-C, method_missing in Ruby and more recently noSuchMethod in Google's Dart.

[https://queue.acm.org/detail.cfm?id=1039523](https://queue.acm.org/detail.cfm?id=1039523)

>Some people are completely religious about type systems and as a mathematician I love the idea of type systems, but nobody has ever come up with one that has enough scope. If you combine Simula and Lisp—Lisp didn't have data structures, it had instances of objects—you would have a dynamic type system that would give you the range of expression you need.

>It would allow you to think the kinds of thoughts you need to think without worrying about what type something is, because you have a much, much wider range of things. What you're paying for is some of the checks that can be done at runtime, and, especially in the old days, you paid for it in some efficiencies. Now we get around the efficiency stuff the same way Barton did on the B5000: by just saying, "Screw it, we're going to execute this important stuff as directly as we possibly can." We're not going to worry about whether we can compile it into a von Neumann computer or not, and we will make the microcode do whatever we need to get around these inefficiencies because a lot of the inefficiencies are just putting stuff on obsolete hardware architectures.

[https://news.ycombinator.com/item?id=19416424](https://news.ycombinator.com/item?id=19416424)

>"I'm not against types, but I don't know of any type systems that aren't a complete pain, so I still like dynamic typing.)"

>That's probably more controversial here than his views on OO.

</comment></comment></comment><comment><USER7> > This is the software equivalent of "Not My Problem." ... This is how you > deal with unanswered messages. You _think_ about your response instead of > just letting your software crash.

A terrific 2014 paper, _Simple Testing Can Prevent Most Critical Failures: An Analysis of Production Failures in Distributed Data-Intensive Systems_ [1] found that most catastrophic crashes in distributed systems are a result of catching exceptions and not paying thought to how to handle them.

[1]: [https://www.usenix.org/system/files/conference/osdi14/osdi14...](https://www.usenix.org/system/files/conference/osdi14/osdi14-paper- yuan.pdf) (talk: [https://www.usenix.org/conference/osdi14/technical- sessions/...](https://www.usenix.org/conference/osdi14/technical- sessions/presentation/yuan))

<comment><USER8> I have c programming experience but not java. I would greatly appreciate if you can tell me the where to catch an exception. When there are nested method calls I can't tell where to handle it correctly - should I handle it in the top most function or the one where the current method was called from? Can you point me to some resources so that I can understand the correct way of handling exceptions.

<comment><USER9> You should handle it in the most immediate context which can do something productive with it- if there's nothing you can do but swallow it, you should probably let it continue to pass up the stack. If you can handle it and log a warning and return something else, you should handle it there.

For example, if you're writing an HTTP handler for an API, you should catch any exceptions at that point in your handler and return a 500 with an appropriate response to the client, since returning 500 is something productive we can do (vs letting it pass and crashing the server).

<comment><USER8> Thank you for offering pointers to effective usage of exceptions.

</comment></comment></comment></comment><comment><USER10> I can't shake the feeling that we're talking about different classes of problems here.

Data importers and sanitizers are de-rigueur when dealing with real world data, of course. You have to expect to find crazy things inside, and be expected to just cope with it. That's not a problem.

But when you're dealing with purely internal systems, the calculus is different. If you had to keep chasing down fopen(), printf(), and malloc() calls, you'd spend more time in administration than you would getting actual work done.

So if I'm understanding this correctly, we're talking about purely internal code vs code that traverses domains (much like in DDD), which require different styles of solutions.

Or am I still missing the point?

<comment><AUTHOR> You're not missing the point. I apparently didn't do a good job of making it clear.

I'm primarily talking about _external_ data/services. Anything which you would ordinarily consider "suspect", such as "reading from a third-party API", is the target here.

The odds of printf() failing are so ridiculously low that I am not going to write tons of code to handle this case. It's not worth the money.

The odds of putMoneyInCustomerAccount() failing are much higher, and the consequences are much graver, so that's a perfect candidate for saying "maybe just throwing an exception ain't the best solution here."

In the case of OOP, particularly in Kay's vision, these objects might be written by someone else, using code we don't see, and thanks to isolation, might be connecting to third-party services which do all sorts of interesting things we don't know about or need to care about. Thus, they're not trusted.

If _I_ wrote the object or I can read its code, and I know what it's doing, I'm not going to sweat it.

I'm also not arguing that we should always make the code that robust. Some things you can recover from or your budget might not allow you to make the system more robust.

<comment><USER11> I think some of the confusion here is that code you can't see or change is typically running on a different server, while ordinary method calls are typically about in-process communication. Compile-time checking makes sense for avoiding problems within code that's all going to be compiled together. Runtime error recovery makes sense for remote procedure calls. And there are also situations where you have untrusted code loaded dynamically (JavaScript in a browser).

It seems pretty important to be clear about static assumptions you can trust (because it's compiled in) versus things that can change.

<comment><USER5> Alan Kay doesn't consider "remote procedure calls" to be "object oriented programming".

[http://mythz.servicestack.net/blog/2013/02/27/the-deep- insig...](http://mythz.servicestack.net/blog/2013/02/27/the-deep-insights-of- alan-kay/)

mythz> On RPC, and how it distorts developers mindsets in architecting and building systems:

Kay> The people who liked objects as non-data were smaller in number, and included myself, Carl Hewitt, Dave Reed and a few others – pretty much all of this group were from the ARPA community and were involved in one way or another with the design of ARPAnet->Internet in which the basic unit of computation was a whole computer. But just to show how stubbornly an idea can hang on, all through the seventies and eighties, there were many people who tried to get by with "Remote Procedure Call" instead of thinking about objects and messages. Sic transit gloria mundi.

mythz> Carl Hewitt being the inventor of the Actor Model and Dave Reed who was involved in the early development of TCP/IP and the designer of UDP.

mythz> The last latin phrase translates to "Thus passes the glory of the world" - expressing his dismay on what might have been.

He also doesn't consider accessing a data field called "entire_name" to be "object oriented programming". He calls that "simulated data structure programming".

[https://computinged.wordpress.com/2010/09/15/alan-kay-on- mot...](https://computinged.wordpress.com/2010/09/15/alan-kay-on-motis- objects-ever-cacm-article/)

Kay> If you are "setting" values from the outside of an object, you are doing "simulated data structure programming" rather than object oriented programming. One of my original motivations for trying to invent OOP was to eliminate imperative assignment (at least as a global unprotected action). "Real OOP" is much more about "requests", and the more the requests invoke goals the object knows how to accomplish, the better. "Abstract Data Types" is not OOP!

<comment><USER11> For RPC, substitute "sending a message to a remote machine" if that's what you prefer. Network requests and responses are pretty universal and can be represented in different ways at the language level, but they are pretty different from local requests.

I'm wondering if this stuff could be better explained without going back to what Alan Kay supposedly wanted? If a software architecture idea is good then it should live on its own and others should have elaborations on it.

</comment></comment></comment></comment></comment><comment><USER12> I was asked to do something very similar at a film post production facility for credits. Essentially I was given a day and a half to reconcile spreadsheets of crew member names (compiled by department HODs) with their "credit name" on our employee database in order to create a master for the production company.

I had all kinds of issues - variations of names, mispelled names, nicknames, names with the middle name used as a surname (and vice versa) and a few lacking even that. I recall leaning heavily on tables of common names, various Python string normalisation methods as well as soundex. In the end I was left with a dozen or so names which needed follow up but it was pretty good for the ~1000 I had started with initially.

The most harrowing part of it all was attending the crew screening - it is actually possible to address issues on an end crawl (provided you catch it early enough) but I really didn't want to be the guy who screwed up the credit of someone who had just spent the previous three months in crunch to get the picture out the door.

</comment><comment><USER13> I've watched one of Rich Hickey's talk and at some point he brings that issue on the table, what happens when the receiver is not responding to the message.

He is advocating Queues and one of his arguments is that Queues decoupling the requester from the receiver. So you don't really have to worry about things like this by using a queue.

[1] [https://youtu.be/ROor6_NGIWU?t=1955](https://youtu.be/ROor6_NGIWU?t=1955)

<comment><USER14> That's abstracting in time more than in implementation; and it's primarily useful with stateful objects that are best reasoned about as a single, synchronous timeline (which most objects are). You'll see this pattern used in, say, Actor systems, as a queue-backed inbox.

</comment></comment><comment><USER15> Note that "...how you might handle objects that don't respond to messages" refers specifically to what happens when you send a message (or call a method, in the parlance of most non-Smalltalk languages)

        thingy.spamford()

and the thingy doesn't implement a handler (or a method) for spamford. It has to do with this paragraph from the original, original post:

" _Kay argues (correctly, IMHO), that the computer revolution hasn 't happened yet because while our bodies are massively scalable meat computers, our silicon computers generally don't scale in the slightest. This isn't just because silicon is slow; it's because of things like print customers.fetch(customer_id).last_name not actually having a last_name method, throwing an exception (assuming it compiled in the first place) and programmers getting frantic late-night calls to bring the batch system back up. The only real upside is that it offers job security._"

This has nothing to do with network protocols.

</comment><comment><USER16> Having worked in healthcare IT, I'm less astonished than I should be about approximate matches and score thresholds being used to confirm "same entity" for pharma data. What could go wrong?

(Not knocking the author...the practice is unfortunately needed because providers won't provide good data)

<comment><AUTHOR> Sorry, I wasn't clear.

It wasn't quite like that. It was to help the pharmaceuticals work together to "pool" talented researchers who had the required training to proceed in the clinical trials. If a bunch of companies don't share this data, they drive up their costs tremendously in trying to find and recruit qualified doctors for their trials, pay to train them, and then have them conduct studies, only to find out that the doctor in question doesn't recruit any candidates themselves, or fails to report results.

If, however, they pool their resources, they can find qualified doctors who have already taken the training and are known to participate well in trials. They can then correlate that with populations who might benefit from the drugs in question and save a fortune (and possibly many lives), by reducing the cost-to-market.

The matching algorithm was actually very strong, but there was still a human step, from the pharmaceutical companies, to verify that these were the researchers they were seeking.

<comment><USER16> That's helpful, though I can confirm the same sort of process is used in areas where it matters more.

</comment></comment></comment><comment><AUTHOR> This is the original discussion: [https://news.ycombinator.com/item?id=19968496](https://news.ycombinator.com/item?id=19968496)

</comment><comment><USER17> There's something I don't understand about the "messaging" metaphor as opposed to the more pedestrian method calling system that most people are used to...

What about private methods? Decently written objects in the wild tend to have some private methods that they call on _themselves_. The highfalutin metaphor of a _message_ goes out the window there, because it's an individual object doing something to itself, not a communication.

<comment><USER18> That's true if there is no composition going on within the object. But, once you have a class hierarchy, some mixins, some dependency injection, or some such... you are "privately" talking to parts of yourself that come from elsewhere.

<comment><USER17> But when it's the exact same syntax to call a statically-dispatched method on the current object as it is to send a message to something else, it breaks the illusion of messaging being meaningfully different while writing code.

Whether some actual bonafide communication ends up being done one level removed (e.g. inside such a private method, or chained off of a field access) is immaterial because when appraising the conceptual integrity we cannot continue after seeing a fail.

(edited)

</comment></comment></comment><comment><USER19> The article is making essentially the same argument as this one: [https://dave.cheney.net/2019/01/27/eliminate-error- handling-...](https://dave.cheney.net/2019/01/27/eliminate-error-handling-by- eliminating-errors)

</comment><comment><USER20> am I crazy about this? You should have (at least two) type of message guarantees - "don't care" and "must respond", kind of like "udp" and "tcp". Obviously other messaging systems have other types of guarantees, but these seem like they are a reasonable basic.

If your agent that send a "must respond" message doesn't get a response within some customizable time, then it itself fails loudly.

</comment><comment><USER21> Repeat ... coupling and strict error processing kill token ring and let Ethernet win. So is sna and internet.

Cross system require much flexibility and to allow for error.

</comment><comment><USER22> I personally did not understand the solution proposed here, I would like to see an actual solution to the problem that was raised.

<comment><USER23> The idea is that rather than try/catch (which tries to do something and can report low-level failures but cannot resume them) one uses something more like Lisp's condition system. In a condition system, signalling an error preserves the stack, and it means for example that a low-level loop can detect an error (say, a poorly-formatted CSV cell), signal that to higher-level code, the high-level code can make a decision (e.g. to replace the contents of the cell or skip the cell or send an email to the CEO with the contents of the cell and wait for his reply) and the low-level loop can continue processing as if there had never been a problem at all. There's a really great explanation in Practical Common Lisp:

[http://gigamonkeys.com/book/beyond-exception-handling- condit...](http://gigamonkeys.com/book/beyond-exception-handling-conditions- and-restarts.html)

In the context of the example, I can easily imagine how the system might have processed most rows without issue, called out to a scoring system for most exceptional rows, and raised a few rows to human attention when even the scoring system couldn't figure it out.

<comment><USER22> Is this lie instead of throwin errors/exceptions you raise Error events ?

<comment><USER23> Here's a stupidly-simple example in Python. So very not ready for production use:

        def with_handler(ctx, h):
            return {'handler': h, 'next': ctx}

        def with_restart(ctx, name, r):
            return {'restart': (name, r), 'next': ctx}

        def find_handler(ctx, err):
            if 'handler' in ctx:
                return ctx['handler']
            elif 'next' in ctx:
                return find_handler(ctx['next'], err)
            else:
                raise Exception('Unhandled error %s' % err)

        def find_restart(ctx, name):
            if 'restart' in ctx and ctx['restart'][0] == name:
                return ctx['restart'][1]
            elif 'next' in ctx:
                return find_restart(ctx['next'], name)
            else:
                return error(ctx, 'No restart named %s' % name)

        def error(ctx, err):
            find_handler(ctx, err)(ctx, err)
            raise Exception('No handler found for %s in %s', err, ctx)

        def do_stuff(ctx):
            results = []
            for i in range(100):
                results.append(do_little_stuff(ctx, i))
            return results

        class alpha(Exception):
            def __init__(self, text):
                self.text = text

        def do_little_stuff(ctx, i):
            def restart(ctx):
                raise alpha('text: %d' % i)
            ctx = with_restart(ctx, 'use-alpha', restart)
            try:
                if i % 3 == 0:
                    error(ctx, '%d %% 3 == 0' % i)
                return i
            except alpha as e:
                return e.text

        def handler(ctx, err):
            find_restart(ctx, 'use-alpha')(ctx)
        ctx = with_handler({}, handler)
        print do_stuff(ctx)

Note how the top level provides a contextual handler which chooses to use the alpha restart, while the restart itself is provided by the mid-level do_stuff, while the low-level do_little_stuff both provides the restart & signals the condition.

Add in some type detection &c. and this could start to be useful. But it'd still be hellaciously verbose compared to the Lisp:

        (defun do-stuff ()
          (loop for i below 100 collect (do-little-stuff i)))

        (define-condition mod-three () ())

        (defun do-little-stuff (i)
          (restart-case
              (progn
                (when (zerop (mod i 3)) (error 'mod-three))
                i)
            (use-alpha () (format nil "text: ~d" i))))

        (handler-bind ((mod-three #'(lambda (c) (invoke-restart 'use-alpha))))
          (do-stuff))

<comment><USER22> To have this used by libraries and libraries users won't you need some standardization though in the language? Otherwise you get various implementation.

<comment><USER23> Yup, that's another reason I love Lisp — it's been standardised since 1994, and everyone supports it (and since it's standardised and provided by the implementation, there are efficiency hacks possible which you wouldn't want in normal library code).

Lisp has been doing things newer languages _still_ don't do since before a lot of modern programmers were even born. And there are relatively few warts for that age (upcasing and the pathname functions are the warts which leap to mind)!

</comment></comment></comment></comment></comment></comment><comment><USER24> Right, so this is basically the Go approach: explicit error checking on everything. No exceptions, because exceptions are a weird sort of non-local control flow, and can escape and take down your program as a whole.

The "if you don't know the answer, find an approximation from another route" is .. situational. In this case it's exactly what the customer wants. In other cases (finance, security, aerospace) it could be a disaster waiting to happen.

I worked on a point-of-sale system where it was a matter of design philosophy that any inconsistency should be an immediate crash-and-reboot; since it also operated as a save-everywhere and audit-everywhere system, if you did manage to crash it then within 30 seconds you'd be back at the screen just before the last button press with no data loss other than the button press that caused the crash. I believe this crash-and-recover approach is very Erlang: [https://ninenines.eu/articles/dont-let-it- crash/](https://ninenines.eu/articles/dont-let-it-crash/)

Thinking of exceptions and message validation also makes me think of "in band" versus "out of band" signalling and errors. Exceptions are "out of band" \- outside the normal function return process. Internet communication is all "in band" and the whole approach of separate control and data planes has almost entirely gone away, apart from SIP and (nearly dead) FTP.

<comment><USER25> Sum types arguably permit a form of out-of-band return value. A function that returns a sum type has the choice of returning the usual type (an integer value, say) or an error value of some other type.

IMO this counts as a kind of out-of-band arrangement because it doesn't involve using one of the normal return values to signal error.

[https://en.wikipedia.org/wiki/Semipredicate_problem](https://en.wikipedia.org/wiki/Semipredicate_problem)

<comment><USER26> But are you actually returning either an int or an error? You're always returning a Result type which may contain either an int or an error.

<comment><USER25> In Haskell one applicable type is actually called "Either a b".

I'm not sure what your point is. If a function has a "unitary" return type (not, say, a list of possible return types out of which one is selected) then obviously it always returns a value of that type.

You could probably invent a kind of function that had a list of possible return types. Then anyone who called it would have to deal with those possibilities.

It all comes to the same thing in the end. Sum types and pattern matching are a very good system for expressing this functionality.

It's conceivable that a compiler would throw away the Either type information and just generate separate code for the different ways the function might return. Ultimately, though, I suppose it would end up calling a continuation, since the function has to "return" somehow.

<comment><USER26> I was replying to this:

> IMO this counts as a kind of out-of-band arrangement because it doesn't > involve using one of the normal return values to signal error.

My point is that if you're returning an algebraic data type Result that encodes Ok(val) or NotOk(_), you _are_ using one of the normal return values, because the function always returns a Result. The whole purpose of the construct seems to me to be bringing the error case handling into band.

<comment><USER25> The way I see it, each of the data types in a sum type is analogous to a channel. The type of the 'message' conveyed by a value is effectively "Either Control Data".

In-band signalling is messier than out-of-band signalling, so I see out-of- band as the goal. If you look at the various approaches to the semipredicate problem on that Wikipedia page, it looks like, historically, we started out with awkward in-band solutions and the evolution is towards the clarity offered by expanding the return type to send errors out-of-band.

I mentioned this previously on HN, and maybe that earlier comment will clarify what I'm talking about: [https://news.ycombinator.com/item?id=18766478](https://news.ycombinator.com/item?id=18766478)

pjc50's way of applying the terms to flow of control is a somewhat different thing.</comment></comment></comment></comment></comment></comment>


US government considers charging for popular Earth-observing data - <AUTHOR> https://www.nature.com/articles/d41586-018-04874-y <comment><USER2> I always find this a little disturbing as a citizen. I know my taxes pay for it already, but then I have to pay again for it, and have no say in anything for it even though my taxes still pay for it.

</comment><comment><USER3> Ah, just what I paid for as a taxpayer! Instead of having something freely available as a public good, the government can use it to generate a paltry amount of revenue....woo?</comment>


Ask HN: Should I work at a startup? - <AUTHOR>

Throwaway acct...
I'm a well-rounded developer. I'm good with people and I've managed to snag a ton of well-paying work for myself in the freelance world. This is highly convenient for freeing up time to spend with new young family.
And then I get a call about an opportunity to work at this awesome company. They're new, but doing really well. Lots of funding, growth, and revenue. The role suits my skills well. The company's offering is killer, and I could stand to become very rich as they become very rich.
We've really hit it off and I'm meeting again with the company's brass soon. I'm expecting an offer shortly thereafter.
I've never worked at a startup. I'm a little concerned about work hours (40-50 hours sounds less appetizing compared to lazy 25-30 very well paid freelance hours). But the truth is, I'm young (20's) and I don't feel like I've been super intellectually stimulated yet in the workplace. I'm thinking this gig could deliver it, along with other outlined pros.
This all happens on the same day Jeff Atwood chucks the deuce, like "I'm leaving to go hang with my kids more."
With these things in mind:
1. Broadly, should I take it? 2. What specific questions should I ask in order to flesh this out better? <comment><USER2> It's possible to balance personal life and startup life. It takes focus, but it's definitely feasible.

It sounds like you're very excited by the prospect of joining the startup. Do it.

Make it clear to the founders that you won't miss your kids' bedtime day after day just to meet deadlines- good engineers are fulfilled and well rested engineers, and good founders will understand that. In the startup I work at, we actually tell each other to go home and get some rest/downtime if we notice others staying late too many days in a row.

Sure, some nights you might have to stay a bit late because you just launched a product and have urgent bugs to fix- this is startup life after all (but you can always do that remotely when the kids are in bed). But conversely, it should give you the flexibility to leave early to spend extra time with your family when times are a bit less hectic.

Make sure you're clear on the terms with the founders, and you should be fine :)

<comment><AUTHOR> I think you nailed it. Client work (my familiar stomping grounds) lives and breathes by managing expectations and clear communication. And this holds true for just about every aspect of life. If we're both clear on what to expect from eachother, and it's a good fit, then it's going to work out awesome.

I am excited, thank you for the encouragement. :)

</comment></comment><comment><USER3> I think you need to know things about both yourself and the company before you can make a decision like this.

Questions about yourself: * Are you willing to sacrifice your free time and family time for your job?

* Can you get things done, even if it's not so clean?

* When crunch mode hits, how will you keep yourself centered? (e.g. exercise)

Questions about the company:

* What is the expected work schedule, and does it fit your life?

* How are they funded, do they have a revenue stream?

* What is the 1, 3, and 5 year plan for the company?

* Does your compensation include equity?

Hope this helps,

Matthew

<comment><AUTHOR> All very good questions. My responses to a few:

\- The higher-up technical roles are pretty well fleshed out, so unless somebody dips out, it seems difficult for me to move 'up' (which isn't to say I can't advance diagonally, so to speak). This ties directly into the longer term company plan, and how I fit in, and I have heard a few intriguing ideas here in talking to employees.

\- Revenue is definitely coming in... curious to find out what the funding/revenue split looks like. Equity is up for grabs, subject to negotiation.

Excellent comments, I'm taking notes now. Thank you Matthew.

</comment></comment><comment><USER4> 1\. It depends on the startup. If it's the kind where the founders are busting hump developing next to you, then you should have no problem. If it's the kind where the "founders" are always busy expensing their lifestyles and spending weeks worrying about what the logo and corporate color scheme will be, then maybe look elsewhere.

2\. How did you come up with the logo? (super expensive agency?) Are any/all the founders developers. How do you feel about X? If you hear stuff like (X is shit, we only use Apple here) you're maybe looking at a Entertainment 720! type place.

<comment><AUTHOR> The founders have dev chops. I saw equal hump busting taking place when I visited their office. That gives me a lot of confidence.

</comment></comment><comment><USER5> Take it!

<comment><AUTHOR> I'm leaning toward yes. :) Thanks for your input.</comment></comment>


The rise of Angela Merkel - <AUTHOR> http://www.newyorker.com/magazine/2014/12/01/quiet-german?mbid=social_twitter <comment><USER2> It is full of interesting tidbits and quotations, but this one stands out:

Later, Merkel interpreted Putin's behavior. "I understand why he has to do this—to prove he's a man," she told a group of reporters. "He's afraid of his own weakness. Russia has nothing, no successful politics or economy. All they have is this."

Savage.</comment>


How Much Income You Need to Afford the Average Home in Every State in 2018 - <AUTHOR> https://howmuch.net/articles/salary-to-afford-the-average-home-in-your-state <comment><USER2> This information is not that meaningful. Using the median rather than the average would have been useful.</comment>


Google: How can I use spreadsheets to answer some of my many questions about the world? - <AUTHOR> http://documents.google.com/support/spreadsheets/bin/answer.py?answer=54199 <comment><USER2> Hahaha... I was going to submit this here but I didn't remember my login password, and to my surprise, discovered there was no way to get a password reminder from the site. So I posted it to reddit instead. Now I found my password, but it was late: the link was posted here too, already :)

I think Hacker News needs: password reminders, and an option for changing passwords.

</comment><comment><USER3> Is it possible to do a google lookup outside of a spreadsheet? Now that would be very useful for outside apps. :)

</comment><comment><USER4> The greatest thing since =GoogleLookup("bread"; "sliced")</comment>


Functional programming and OCaml koans - <AUTHOR> http://eigenclass.org/hiki/fp-ocaml-koans

<comment><USER2> These are really good :-)

</comment><comment><USER3> The last one is an excellent jab at devotees of dynamically typed languages.

Neat submission. Copied and saved!

<comment><USER4> Uh, it was a jab at Haskell & lazy evaluation:

> He plunged into deep meditation in the middle of conversations

...forcing a large complicated thunk in the middle of a simple function definition

> could not help waking up late in the morning

...all expressions are suspended by default

> and failed to do his chores in a timely manner.

...evaluation is delayed.

> "You must go back to your strict ways."

...the opposite of "strict" being "lazy", in FP terms.

The comments confirm it, the "H___ temple" being the Haskell community.</comment></comment>


Microsoft is killing legendary Paint after 32 years - <AUTHOR> http://www.telegraph.co.uk/technology/2017/07/24/microsoft-killing-legendary-paint-32-years/ <comment><USER2> >"It marked Paint as 'deprecated' in a list of apps and features that may be removed from the software, meaning the app is 'not in active development and might be removed in future releases'."

Not quite "killing" just yet. I imagine that either Paint3D or a similar program will be phased in to replace it, though. Microsoft is pushing the creator angle on their in-house PC designs, and I wouldn't be surprised if they have a more serious "prosumer" application in the works.

</comment><comment><USER3> previously: [https://news.ycombinator.com/item?id=14835878](https://news.ycombinator.com/item?id=14835878)

[https://news.ycombinator.com/item?id=14837260](https://news.ycombinator.com/item?id=14837260)

</comment><comment><USER4> Didn't they kill it back in Windows 7 (or maybe Vista)?

The whole attraction of Paint was that it was a KISS pixel-level editor, and it ceased to be so in the latter versions of Windows.</comment>


EngineYard releases Solo: Inexpensive, web-based platform for Rails - <AUTHOR> http://www.engineyard.com/solo

<comment><USER2> My first reaction was also that the $129 price tag seems steep, but then I started doing the math: My guess is that if you want to go with EC2 on your own that it's approximately $50 per month cheaper than Solo (see <http://tinyurl.com/2q4e3t> for the AWS EC2 cost calculator).

However, my guess is that there is a significant number of of Rails hackers who would be better off spending those extra $50 to get going right away instead of messing around themselves trying to configure their EC2 instance.

Ezra mentions a lot of details in his introduction video on the EY site, such as a hardened and and pre-compiled _nix packages (_ cough* rmagick), optimizing MySQL memory usage etc, knowledge they have built-up over the years within EY. Their knowledge is worth money.

The only problem I foresee for EY's Solo is that the 'end result' of an EC instance deployed by Solo is easily copied. All the knowledge poured into the configs are accessible by anyone with root access to the instance, and nothing prevents you from deploying the next instance completely yourself. But if the configuration management tools of Solo (and upcoming Flex) seriously rock than I doubt that this will be an attractive option.

</comment><comment><USER3> Heroku is free. It's also easier and available right now. I uploaded the code for <http://fuel.dustincurtis.com> and it was working within 10 minutes.

For most of my little fun projects, I don't need an entire instance, and Solo is extremely expensive for that.

Also, I have a question for Engine Yard: why did you make the EC2 stuff transparent? One of the downsides of EC2 is that it has a very complicated pricing structure. The people Solo is targeting probably don't want to deal with a 20 row table of different prices.

<comment><USER4> The ec2 stuff is transparent because we aren't trying to hide the underlying platform. You can still utilize the full power of AWS form our system, you just don't have to unless you really want to. Sane defaults but major flexibility is one of the goals of this platform. That being said you may be right and we may need a tiered pricing system tha includes certain amounts of bandwidth and storage for a known monthly price. Time will tell as people start top use the platform.

Also you can run multiple applications on one solo instance. Since you have 1.7 gigs of ram you can run 3-6 little apps pretty easily if you use the apache + passenger stack.

</comment></comment><comment><USER5> Who else is saying, "YES YES YES YES YES YES YES"? haha

I am.

I think the beauty of Engine Yard and Heroku is that at some point in time, one of these two companies (or perhaps Google), will figure out a way to "just scale." At that point, web developers will just simply follow some basic guidelines and never worry about system administration again. I think that will be an extremely happy day for me.

<comment><USER6> I got excited. Even though I don't have a need for this at the moment, I know I will in the future.

</comment></comment><comment><USER7> $129 minimum isn't _that_ inexpensive. Otherwise, it looks quite clever.

<comment><USER8> $129 per month with engine yard appears to whoop Joyents equivalent Accelerator.

1 GiB RAM, 15 GiB Storage 1/4 CPU core guaranteed, Burstable to 8

vs

~1.2Ghz 1 ECU, 1.7GB RAM 160 GB Non-persistent storage

<comment><USER7> Agreed, but I think it's significant that Joyent offers a lower spec starter plan under that for $199 _per year_.

<comment><USER8> good point. I wonder what size apps you could run on that, though.

</comment></comment></comment></comment><comment><USER9> As a long time Engine Yard customer I can say $129 is a very good deal considering the level of support that brings you. We've run PMOG (<http://pmog.com>) on EngineYard from a small starting slice right up to a real application and I've found them to consistently be responsive, knowledgable and scale-able, if you see what I mean :)

I'd strongly recommend anyone checkout EY solo. Hearing about their plans flex, the ability to run with passenger and soon rack, should make you realise that they know how to handle Ruby.

</comment><comment><USER10> It's great to see the EY folks offering support for Passenger.

</comment><comment><USER8> whats the differnece between this and normal EC2?

<comment><USER4> The main difference is that ec2 and aws in general just gives you very low level building blocks. It gives you an api for 'give me a new server', 'attach an ip address', 'create a new volume', 'attach volume' etc. So you have to learn this stuff just to get your basic hardware in place. once you have that done you will still be faced with all the sysadmin tasks involved with configuring everything to mount and format these volumes and configure every service you need to run. Of course you need to know what the proper setup for a ruby app in production is and learn all the different webservers and monitoring tools.

The idea behind ey-solo(and the soon coming ey-flex) is that you don't want to have to learn all that stuff. We have been running and managing high volume ruby apps in production for 2.5 years now and we have taken our whole battle tested stack and are now offering it as SaaS.

So the goal is to save you time and hassle. We will maintain the whole stack with constant feature and security updates as well as bug fixes and all you need to do is write your app and leave the deployment and scaling hassles to us.

AWS is only the beginning, this platform will soon be available on other clouds as well as be downloadable so it can be run on any hosting provider if you run our linux and install our agent.

This means that eventually you will be able to host _anywhere_ and still use our automated stack to manage the servers.

<comment><USER11> Is there a way I can use this instead of a multi-slice conventional EngineYard setup? Or do you have a RightScale-type thing in the works?

<comment><USER4> We have ey-flex coming in a few months. Flex is the multi slice clustered version of engineyard on AWS, replicated db's autoscaling app servers and load balancing, message queueing plus logging and monitoring aggregation services.

So the answer is yes you will be able to replicate a traditional EY cluster setup on AWS in a few months.

</comment></comment></comment></comment><comment><USER11> I can't believe so many folks are talking about how expensive it is. It's $129 per month people!!

If you're gonna launch anything that people will use you ought to be able to monetize. If you can't, what the hell are you doing in the first place?!

</comment><comment><USER12> I'm looking forward to the generic Rack deployment option.</comment>


ISON Update for 22:00 UTC Nov. 28. - <AUTHOR> http://www.slate.com/blogs/bad_astronomy/2013/11/28/ison_update_for_22_00_utc_nov_28.html <comment><USER2> I found this article useful for finding out what ISON actually is: [http://www.abc.net.au/science/articles/2013/11/29/3901668.ht...](http://www.abc.net.au/science/articles/2013/11/29/3901668.htm)

Here is the youtube video of it fizzling: [http://www.youtube.com/watch?v=6j6nkLnHyG0](http://www.youtube.com/watch?v=6j6nkLnHyG0)</comment>


Maths on a plane - <AUTHOR> http://plus.maths.org/issue47/features/trinh/index.html

<comment><USER2> Nice story, but a shame her handwriting is perfectly regular...</comment>


5 Shocking Truths about CO2 Emissions - <AUTHOR> https://medium.com/@KODIAKRating/co2-little-too-late-2d4f39b1703#.454g7wp3k <comment><USER2> According to a NASA page I read, we are roughly 300 years away from cataclysmic climate change - in 50 years - science will have capabilities we cannot even begin to imagine today.

Everyone is already aware of the issues involved - so alarmism isn't needed.

Electric cars and fusion power are already visible on the horizon.

Lastly there are at least two guys claiming to be about to get their papers past peer review that replaces current climate models with warming estimates 4 times lower than current models - regarsless - current facts do not indicate reason for hysteria - merely awareness.</comment>