Ask HN: Bad situation – how long of a notice should a consultant give a client? - <AUTHOR>

What is the opinion in the United States for how much notice you have to give a client if you want to cut the work short? We've been working together for two months (350 hours). The contract allows me to just walk away, but just like with employment, you don't want to do that except in extreme cases.
It's my first time consulting and things have gone about as bad as could be. What was initially estimated to be 150 hours for $6000 (well below my market rate to begin with) currently stands at 350 hours and $6700 in the bank so far. I got sweet-talked into extending twice. This time I told the client I am done and will not continue beyond finishing one last item and writing the docs for business continuity. He's trying to sweet talk into doing several of the important and urgent items, which of course are going to play out like everything else so far and take much longer than he thinks.
So, if for full-time employment two weeks notice is customary, what is it for consulting?
I'd also like to hear from other folks just how bad things went for them to justify quitting suddenly? How did the client take it? <comment><USER2> "Customary"? For a consultant, you'd normally down-tools as soon as the first invoice is overdue.

Depending on how you packaged up that "estimated 150hrs" originally, you might not (yet?) have an overdue invoice.

Just how bad is "the contract"? Could the client plausibly claim you've failed to deliver on what he's already paid $6700 for? If so, you might need to finish off whatever needs doing to meet your end of the contractual obligation (or be prepared to give some/all of that money back). If the contract was "150hours work, estimated to be sufficient to complete the project", you're fully entitled to stop and ask for more money before continuing (although if it was _your_ estimate, you'll have some questions to ask about why it was so badly out).

</comment><comment><USER3> How important is the relationship and other interests?

Are you working based on the idea that the relationship is important, and the other side is hard-balling you?

Is walking away that risky that you don't want to do it?

I focus on 'relationship' as you mention being sweet-talked. Are there other interests that this client thinks they have you owing to you, or you owing in them, that make them (or you) behave like this?

If not complex with multiple vested interests, wait until Monday (Mondays are good for breaking news, as people can stew over things on weekends and it gives you weekend planning time), create some really specific criteria for both what you do that is billable and what you think is OK for continuing the contract. If it is far longer than he thinks, then tell him how long it will really take, or do something even more simple and bill on product specification, not hours, and ensure re-billing is done on any change of product specification (which should include testing checklists).

If they decline, then walk away. Don't be sweet talked by someone with no sweets in their pocket.

</comment><comment><USER4> I wrote about my own experience with this sort of situation here:

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

You need to firmly end the scope creep, _now_. Explain that:

* the project has blown way out, that the engagement is no longer benefiting you

* if they want to continue working with you they're going to have to negotiate a new deal

</comment><comment><USER5> Sorry to hear about the stressful situation. I rarely cut an engagement short, but there's nothing wrong with doing it. Just decide how many more hours you're willing to put in to do a decent job wrapping things up, and then tell the client you're not available past X date and what you're doing to leave them in a good place. In my experience, professional people have no trouble understanding that. How you communicate is more important than the actual details. No matter how stressed you are, you can be courteous but firm.

One last thing: consulting is NOT "just like [with] employment." The "walk away at any time" bit is there for a reason.

</comment><comment><USER6> It depends on what you want out of the situation.

If you genuinely just want to be rid of the client, then just walk away. You've done more than enough already.

If you want to see if you can turn this problem-client into a good one, then maybe you can talk with them (firmly) about setting up a payment plan or some- other-way for them to pay off the extra work you've been doing.

If you want a good reference from the client in the future (semi-important if you're still building-out your portfolio) then maaaaaaybe I'd transition away over 2 weeks or so. But that's only if their reputation is fantastic and they'd make a great reference in the future.

</comment><comment><USER7> If you haven't been paid all that you are owed, stop work immediately.

The customary notice is exactly in the contract.

The problem with providing services at below the market rate is that you've told the client that your time isn't very valuable. Cheap clients are not worth having. Part of the reason is that they prevent you from getting better work.

Good luck.

</comment><comment><USER8> Sounds like the client has you trained. Everything the client asks for, you give in. What do you think the client is going to keep doing?

<comment><USER9> Or looking at it another way, OP has trained the _client_ to continue to act this way by rewarding his undesirable behaviour.

Its like giving a dog a biscuit every time it pisses on the rug.

Still, I feel that the fair solution to both parties is to explain to the client _why_ the important and urgent items are going to take much longer than he thinks.

OP could look on this gig as an opportunity to train himself in managing clients, and therefore walk away with some benefit.

</comment></comment><comment><USER10> 1) Stop working right now. Fuck the business continuity documents. You're more than double over your budgeted hours.

2) Take 40 minutes of your invaluable time and listen to Mike Monterio's talk, "Fuck you, Pay Me". [https://vimeo.com/22053820](https://vimeo.com/22053820)

How the client will take it is relative to how it impacts you. The worse it is for you, the less it matters how it impacts a client. Ultimately, you are responsible for the position you're in, but the client is complicit. There's a good chance that you won't be able to use this client as a reference, and do not kid yourself by believing that you can "explain the situation" to future clients. It's time to cut your losses and move on.

You are currently working for job rate of $17/hr ($6000/350). As a consultant, you are underwater. It _will_ take time to find more work, which must be factored in to your hourly rate. I used to compute average hourly working rate on an quarterly basis: total billings for the quarter divided by gross hours worked. The gross hours worked number included admin time, which I billed to my own company. You're cruising toward McDonald's wage if you don't turn this around.

I'm going to assume that this was a fixed-price contract, and that you included a budgeted number of hours in your contract. You need to draft a communication explaining that you've more than doubled the number of budgeted hours for the project, and that you cannot continue working unless the customer is willing to enter in to a new contract with additional billing.

If your original contract did not include a budgeted number of hours, then you're really in a bad spot. The best you can hope for is that you can walk away and not have the customer come after you for failure to deliver, and demanding a refund.

The key to all of this is communicating early, and communicating often.

Do not worry that the customer will be annoyed.

Do not worry that they won't like you.

Do not worry that you're asking for too much.

Tell the client that you've worked over twice the number of budgeted hours, and that you're not willing to go any further.

Tell them what your time is worth, and that you'll be happy to provide them with an estimate to complete the project.

When you deliver that estimate, make sure your rate is solid, and that the estimate includes a budgeted number of hours. Deliver a weekly report of the hours consumed and the work completed. Book the time required to track this information to an "admin" task. Include that item on your billing, but bill it at a $0 rate. Explain to the customer that this line item is the time required to track the progress of the project, and that you're such a nice guy, you're not going to bill them for it.

I wish you the best of luck, but I've been in this situation before as well. I've been worse. I've had a developer flake out, and I had to write a check back to a customer. This is consulting. You win some; you lose some. That's why consulting rates are $250/hr when wages are $50/hr. There are costs external to the customer's job that must be priced in. The customer's alternative is to hire someone (muy expensive), or to find some other schmuck to do the job on the cheap. The trick is not to be the schmuck.

EDIT: After submitting this, I realized that I didn't address your $60/hr billing rate. That number is insanely low for a consultant. If you're a rock star and you've got work lined up for months you can optimistically expect to hit 80% billable time. That is 80% of your 40 hour work week will be billable. Do the math:

80% of 40 hours is 32 hours a week of actual billable time.

On an annual basis, how many weeks of work do you think you can line up? My experience was around 3 out of every 4 weeks. That's 39 billable weeks a year.

With those numbers, you're on track to make around $75k a year. That's if you have a mature business with a good client book and return work. It took me three years to get there.

The other problem with a $60/hr billing rate is that you'll attract $60/hr customers. Otherwise known as people who will run you double-over your budgeted hours and demand that you keep going. Fuck those people. Double your billing rate and start selling solutions, not technology.

See also: [https://news.ycombinator.com/item?id=6717875](https://news.ycombinator.com/item?id=6717875)

</comment><comment><USER11> Stop doing anything for the client until he pays. For your purposes, "pays" might just mean the money is in escrow until the work is done. But the client needs to demonstrate that the money exists and will be given to you.

</comment><comment><USER12> I've dropped a couple of clients, usually over some kind of billing issue or abuse. I don't regret losing the relationships, but I would handle it a lot differently now (they happened earlier on in my business, and I was partly at fault too).

"Hi, we really need to talk about how your project has been progressing. I've put a lot of effort in to it, with a lot more hours than we originally discussed. I want to see it finished to your satisfaction, but I'm also not making enough money right now to cover my expenses. I have to start looking for more income immediately.

I'll finish a few more items [..., ..., ...], but if you want [..., ..., ...] done, I have to bill you at a normal professional rate. Since we've worked so hard together on this, I'll charge a little less than my next client. Let's say $400/day. I'll do my best to give you an estimate for new features."

And negotiate from there. Put the ball back in his court; let it be his decision to either pay you or discontinue the project.

 _Most_ folks understand that they can get any 2 of cheap, fast, or good; if he can't afford the budget for the project, he'll either drop it or negotiate with you and you can offer to wind down the project at a rate that you're happier with, spending far less time on it. Or, he'll come up with the money; I've had a few clients suddenly show up with a nice check once I say, "I can't keep working on this for you at your original budget."

I started doing the "straightforward & honest" thing with clients a little over a year ago. I dropped all pretenses about money and how great business is (it's not bad, but it could be better). I thought everyone would stop working with me. What happened instead is almost everyone really appreciated it. So, in my experience, there's no harm at all in just telling someone you can't afford to keep working for them. Sometimes they'll offer you more money.

A few folks will flip out or come unglued or say rude things. That's the beauty of being a consultant, you really don't have to put up with that if you don't feel like it. You can walk away from people like them and not look back or regret it.

But, almost all of my work has come from word-of-mouth, so I try to keep clients pretty happy as much as possible.

> _I got sweet-talked... trying to sweet talk..._

It sounds like you're just struggling with negotiating, like pretty much everyone does when they're just starting out. He begs or pleads or convinces you that it won't be that hard and you wear down and say OK and then try to do it and resent it. So now you want to run away because you don't feel like you can handle negotiating with him.

Try it anyway, and keep trying. Even if you end up walking away from the project, you'll learn _a lot_ by trying to renegotiate. If you have to, write a number down on a piece of paper before talking to him. Don't start higher with the hopes of negotiating down to it, don't accept anything less than that, just stick to it. Write "don't do it you idiot" on the back of the paper. Every time you start to consider taking a lower number, flip the paper over.</comment>


Wikipedia Asking PAN Number for Donation Process (India) - <AUTHOR> As you may have seen/noticed, Wikipedia is asking for a donations. I've seen the similar messages on Wiki pages before, not highlighted in such manner (red box with large font)<p>I was proceeding with the donation but stopped when it asked for PAN number. Any idea why they are asking for PAN number? <comment><USER2> [http://wiki.wikimedia.in/FAQ-Donations](http://wiki.wikimedia.in/FAQ- Donations) "For large value donations, PAN number is mandatory to enable the Chapter to comply with the regulatory requirements."

</comment><comment><USER3> Can you use Bitcoin and a VPN to bypass this arbitrary rule?</comment>


YouTube is changing its algorithms to stop recommending conspiracies - <AUTHOR> https://www.washingtonpost.com/technology/2019/01/25/youtube-is-changing-its-algorithms-stop-recommending-conspiracies/ <comment><USER2> Comments moved to [https://news.ycombinator.com/item?id=18999326](https://news.ycombinator.com/item?id=18999326).

</comment><comment><USER3> Unfortunately things are converging on the Chinese model. Young people in the US have been so brainwashed against anything really critical of the government that they are literally earnestly requesting political censorship.

<comment><USER4> There's a big difference between criticizing of the government and believing that the government is poisoning us with chemtrails. Hardcore conspiracy theorists are severally mentally ill and these conspiracy channels on Youtube only serve as an echo chamber for crazy people to validate each other.</comment></comment>


Ask HN: Is there a bubble in software work? What's the 5/10 year forecast? - <AUTHOR> I'm reading The Click Moment, where the author writes, "Ten years ago, if you wanted to guarantee yourself a life of financial security, one of the surest paths was to become a lawyer." So law programs and students blew up, and the result was companies like LegalZoom offering routine legal work for $25, and it's no longer deemed a "hot" field. I'm wondering what you guys think about this. With AWS releasing CodeGuru, (which aims to reduce hours spent debugging and testing) I suspect a similar thing could happen. I'm in ${BIG_TECH_CITY} where there are bootcamp ads plastered on buses and in my YouTube ads. I just doubt there will be work for new bootcamp grads, say, 5 or 10 years from now. <comment><USER2> Law is not really comparable.

Software continues to eat the world. There are so many new sectors and the demand for software is insatiable. Mobile apps, drones, robots, ai, self driving, medical devices, blockchain... so much more... there are so many fields and applications for software still...

And new sectors... an example: If I were starting in college today. I would major in cs and genetic engineering. Programming living cells...

For context: Andreessen, why software is eating the world. [http://online.wsj.com/article/SB1000142405311190348090457651...](http://online.wsj.com/article/SB10001424053111903480904576512250915629460.html?emailToken=e7b7167e3d50c060558d98b1b3d56fa3ikaF9de4vuvRCiOGccQSv0KFEircJUzE0BcBA5rMF9Uzx/ENT3FPbn0NVXWeqJQ0GviBealZXN9Ucj6JsN9Chi/gxQyQ63w9qA7X5HZSM+o%3D&reflink=article_copyURL_share)

<comment><USER3> Not to mention the maintenance and replacement of software in fields where it's already extremely dominant.

The valley may explode/implode but the rest of the world has had a pretty solid demand for developers since I was a teenager in the 90's, it's just less dramatic and less well paid with fewer hours.

</comment></comment><comment><USER4> Computer Science is still hard, and the vast majority of those who think they want to write software simply aren't effective at it.

There will always be work for people who are good at writing software.

As to your last comment? Maybe but I doubt it. I think that things will morph a bit to the point where there will be better "bootcamps", maybe not called that exactly, that offer more of the real CS education that's necessary for a good software engineer. But we'll see.

<comment><USER5> Writing software isn't really "bootcampable" if there is such a word. You need a significant amount of time to gradually absorb knowledge and skills.

<comment><USER4> I covered that in my comment.

</comment></comment></comment><comment><USER6> The bootcamp student no longer needs to learn garbage collection, how memory works, hash maps va arrays vs linked lists and all that.

They really just learn to tell the app what to do. They tell it to open a camera, save the photo, what format to save it in, submit it it which server, how to store it, when to resize, a balance between quality and size, how to inform another user when the photo has been submitted, how to politely inform the user that it's not going to abuse camera permissions, how to gather user data while staying within legal restrictions, and so on.

A good developer with the best tools might do this in half an hour. A newbie developer could take half a week. The good developer can easily demand more money.

Sure there are things that will simplified to a $25 action. When I started programming, we were building our own push notification services and chat servers. A lot of this is now $25 or less, but a developer can still get paid $1000 to assemble it - the code is there but you still need to pay someone to read documentation.

And maybe through some miracle, AI can do all this work in the future. Then you still need people to manage AI, to communicate with clients/customers, understand what they want, and tell the AI to build it. AI will likely be as smart as some cheap foreign labor who can barely speak English, so someone needs to slowly explain to them what they mean, possibly in their own language... which is a lot like programming.

So let's fast forward 1000 years, where we can reach 90% project estimation accuracy and all this assembly is just blue collar work. We'll get something very similar to the construction industry now, which still hires engineers with a degree, to build complex megaprojects like getting a skyscraper done in a couple years. Maybe a CS certification and the word "engineer" might actually mean something then.

</comment><comment><USER7> I think the upper echelon of computer programmers will be paid more than ever. I think the lower levels will see compensation decreases. So if you want to make tons of money, get really really good at computer science and algorithms, ignore the frameworks

</comment><comment><USER8> The premise is flawed. Law has been a problematic field for a long time now — anyone looking at being attorney as a stable path a decade ago was delusional.

Technology is eating the world, but it's not a high security field at the same time. Whatever you do today is legacy is 5-10 years, and you can be easily rendered redundant if you're not in the right place/skillset.

</comment><comment><USER5> 5 to 10 years is a lifetime in this business. That's like asking what cars or aircraft will look like in 50 or 100 years.</comment>


World's First Patented Unhackable Computer Ever - <AUTHOR> https://www.kickstarter.com/projects/microsafex/worlds-first-patented-unhackable-computer-ever <comment><USER2> It looks fake. The highest reward is 150 and it's already gone (with one backer claiming it). The other two rewards are 5 bucks for updates and 20 for a T-shirt. I'm not sure how they will get 870,000 dollars from that. Also it says it can protect data being transmitted. I guess that works if you mail your laptop to your friends so they can see a picture?</comment>


Ask HN: Are you getting my same bad experience with Windows codesigning? - <AUTHOR> I'm the Co-Founder of Snapp (http://getsnapp.com), a tiny filesharing utility for Mac and Windows. Our app is of course getting issues with Windows Anti-Viruses because its code is not signed. This is representing a huge first-use barreer to some users so I started the procedure to get a valid codesigning certificate.
Since we are currently bootstrapping, we are trying to save as much money as possible, so I opted for K-Software which is re-selling Comodo certificates for cheeper prices. Unfortunately the whole procedure looks insane to me: I've had to validate a few documents through an attorney, I've had to FAX everything from the attorney's office to the Comodo offices and I've had to send the same docs via ordinary mail to the Comodo offices. The thing is taking long especially for the mailing part since we are based in Italy and we are still waiting for the docs to hit the offices.
As a side note, I'm a little concerned regarding opening our private beta. We feel ready for making the beta public due to the apps performing well now, but I'm concerned regarding the codesigning stuff on Windows, because this would surely mean a bad experience for most of Windows users.
Also, is it just me or the Windows codesigning experience is the worst? I mean, I had codesigning experiences with Apple and despite them being a convoluted process, they ended up taking just a day or two.
I just wanted to share my experience and gather a few information from you. You may have had a better experience than mine. <comment><USER2> Looks like a Comodo, other CAs have a less terrible process: [https://www.digicert.com/ssl-validation- process.htm](https://www.digicert.com/ssl-validation-process.htm)

<comment><AUTHOR> Yeah, I imagine with digicert I'd get a smoother process but unfortunately they have way higher costs which currently we can't afford.

<comment><USER3> Hi there,

We're actually launching a program where we offer free EV certificates to Y Combinator startups. Email flavio.martins (at) digicert (dot) com for more information. We'd be happy to help you out.

</comment></comment></comment><comment><USER4> Unfortunately, I think code signing requires organization validation, unlike SSL certificates. Though I agree that resellers being involved makes the process more complex.</comment>


How to De-Risk Your Startup and Become 'Definitely Fundable' - <AUTHOR> https://blog.foundersuite.com/how-to-de-risk-your-startup-and-become-definitely-fundable/ <comment><USER2> Just don't de-risk too much. You might discover that you do not need VC money...</comment>


Show HN: Stock Bubbles app, advices? - <AUTHOR>

A few weeks ago I got an idea for a more interesting interface to check the stock market. The huge list of symbols in a table view that are either green or red (the same red and green whatever the gain is 0.1% or 10%) is not really cool for fast scanning, nor fun to use.
Since I happen to be involved with an iPhone and iPad devleopment company here in Sicily since a few years, as share holder and "advisor", I suggested the idea to this friends of mine. As there was no really development bandwidth to do things like this, as they mostly work for other companies creating applications for the editorial market, I suggested to do this in the spare time, and check how this could work as an alternative to just providing
services to other companies.
So one of the developers, and my girlfriend that is the graphic designer in the company, started working at this, and after just a few days the app was ready.
http://itunes.apple.com/us/app/stock-bubbles/id417945202?mt=8&ls=1
This guys read hacker news every day (this was one of my first advices), but never participate with actual comments. I think it's a shame that they don'ttry to directly sell things on the app store most of the times, so please can you provide some suggestion to this guys? What's ok and what's wrong with Stock Bubbles, is it too much a small market to create a viable business model? Does it makes sense to create such side projects with just a few days of work of a few poeple, or it's better to invest months developing an application even if it could not be a success at all? (while doing work for customers will pay less but will pay for sure).
Thanks for any feedback, the developer of the app is 'artix' here and will reply to all your questions. The app is free, but with an optional in-app purcahse to unblock the configuration screen, but there is no need to buy it to check how it works and to provide useful suggestions of course. <comment><USER2> It is interesting, but (at least to me) it does not seem to add any benefit. It basically is a list of stocks (I assume a watch list) sorted by % change which happens to be shown in colored bubbles. At first I thought that the size of the bubbles will play in help showing the data, allowing the trader to analyze the watch list or holdings, but it doesn't. Sorry man. It's interesting, but not beneficial to the average traders. Keep going at it though.

<comment><AUTHOR> Since I'm the one proposing this visualization, this is the reasoning: basically the idea is that you can check how the market is going in very little time. I guess the value is much more for casual users interested in the stock market then for traders that will study every single stock with greater detail.

So indeed there is no real added value, but just a faster to read UI I hope. Btw I also concur that the developers should invest more time in providing also some added value that is not just an UI, but I guess this will hardly be a metter of a few days of efforts. Btw I must admit my "benchmark" was the iPhone built-in app that was what I used before.

Thanks for the feedback!

</comment></comment><comment><USER3> Here's something similiar I did a couple years back in Raphael:

<http://80concepts.com/graph>

<comment><USER4> Cool! We could have done something similar for our website as a marketing idea!

</comment></comment><comment><USER5> Here is our tech(presented at nVidia's ECS): <http://www.youtube.com/watch?v=wGrXPTShuqM>

Getting it to work on iPad/iPhone is tough due to the limited memory. We're hoping that some of the newer tablets give developers more memory to work with.

More at: <http://www.aqumin.com></comment>


How to survive and thrive in a down market - <AUTHOR> http://calacanis.com/2018/07/25/this-is-your-captain-speaking-im-turning-on-the-fasten-seat-belt-sign/ <comment><USER2> Student loan debt usually can't be discharged through bankruptcy so it's unlikely to cause some kind of panic sell-off even if the loans being made are low quality. The debt will continue to be a noose around the neck of consumer spending power. Indentured servitude 2.0.

<comment><USER3> Today's businesses rely, directly or indirectly, on consumer spending power. If its decline hasn't been correctly worked into the present-value-of-future- dividends (aka price) and the market corrects, the magnitude would have no difficulty rivaling or exceeding previous recessions.

<comment><USER4> As long as the people getting richer keep consuming enough to offset the reduced consumption of those getting poorer, it could work out. We just have to ignore the part where 20% of the population enjoys life while 80% go through the grind to provide for the 20%.

</comment></comment></comment><comment><USER5> Investors frequently say things like this:

"Am I at, or can I get to, profitability on the money I have?...(If so) Go raise "opportunistic money" from your existing investors at a good or great price."

If you're profitable and believe that your customers will continue investing in you, you should think long and hard about raising more capital as "the answer."

Raising more capital is _sometimes_ the answer, and it's an investor's job to convince you that raising capital is _always_ the answer.

<comment><USER6> That statement made me feel uncomfortable. Isn't it exactly this type of attitude that creates financial bubbles in the first place?

Without a plan, or even a good reason, for that money how does it contribute to making your business more profitable or resilient to the vagaries of your market? In the short term it'll keep you afloat but that isn't going to be a big consolation when the money does run out. Stock piling cash in exchange for huge amounts of equity seems totally irresponsible.

<comment><USER7> > Bottom line: In almost all of the cases above, my advice is to build a war > chest of capital so that you can deploy it in the down market.

What I think he is saying is that in a downturn things can get tough if you don't have enough cash to get through it, and it will be harder to raise more money if you need it. But, in a down turn everything also gets a lot cheaper so if you do have the cash then then you can really capitalize on this and emerge from it as the leader in your sector.

<comment><USER6> Yeah, I can definitely see the argument for having a war chest. Building it by exchanging a chunk of your equity for it in the hope that on the other side of the storm (what is that old fable about economists correctly predicting 11 of the last 7 down turns?) you can make that back and then some feels a little too much of a gamble. You'd have to be incredibly lucky to get the timing right.

Building a war chest by maximising profitability and minimising costs I could definitely understand.

Perhaps I just don't have the guts for it though.

<comment><USER7> Perhaps you are a programmer and not an investor so you are going to have a different perspective. (I tend to agree your view btw...)

</comment></comment></comment></comment></comment><comment><USER8> This has been always a question I always asks myself on a personal level. I was still in school during the recession and graduated when the economy was picking up so I did not experience the impact of the recession first hand. Now that I am older, I am always worried how I can survive with my family through the next dep/recession. Is saving up the best way to protect myself? Are there things I can do now to increase the chances of having income during a downturn?

<comment><USER9> I'm asking the exact same question. If we expect to find ourselves in a long financial winter, what can we do?

Specifically, I'm considering buying a house and renting out my current house right now...to buy or not to buy. Leveraging up is great until house prices drop by 30%. Then again, the previous recession was specifically a housing crunch, so perhaps the next recession won't create the same housing drop.

No one on this thread knows the future, but it's hard having lived through a very long bull market to anticipate the results of what looks to be a pretty severe bear market.

Hussman Funds is calling for negative total returns on the S&P500 for the next 10 years, which feels like a very long time.

<comment><USER10> As far as the house you live in, if you don't plan on moving, why do you care about the value of your house? For me, getting a house with a fix rate loan was a no brainer. Rent where I was staying from 2012-2016 went up by $500 and it's gone up another $300 since then - and I'm neither on the west coast or live in NYC.

Owning a house as a primary residence is a great inflation hedge. Besides, apartments can kick you out within a matter of weeks if you don't pay. Banks really don't want to foreclose on a house - especially during a downturn. You have a lot more leeway on not paying your mortgage than your rent.

</comment></comment></comment><comment><USER11> "In the Black Swan, non-financial event category we could list Russia, North Korea, China, Pakistan, Iran, domestic political unrest and the Mueller investigation as market busters."

Instead of Black Swans aren't these more like grey swans? Their shade can be discussed of course, some might be lighter than others.

<comment><USER12> I think blackness here is because they are rare, not because they are bad.

<comment><USER13> I suspect that jnurmine meant that they are not _that_ unlikely.

<comment><USER14> Suspect so. The fact that we can name them in advance implies they aren't that _black_.

</comment></comment></comment></comment><comment><USER15> I've been hearing about an incoming correction since 2013. As always, no one has any clue when it is coming and the age old tenet holds true:

Time in the market beats timing the market.

<comment><USER16> > I've been hearing about an incoming correction since 2013

We've have 2 corrections the past 5 years. We even had one in the beginning of this year.

[https://www.investopedia.com/terms/c/correction.asp](https://www.investopedia.com/terms/c/correction.asp)

What you may be referring to is a recession, which is different from a correction.

</comment></comment><comment><USER17> I find it interesting that much of this advice can be somewhat applied to safeguarding personal assets (including skillset and personal skill marketability) in preparing for a down market.

Many of these safeguards are recommended for individual investors. Diversity of portfolio is always important, but even more-so when a bull market has been on a sustained tear. Being at least somewhat invested in the well-funded can help offset. (YMMV but that's been my experience)

Overall it's prudent for Jason to send this to his folks. At the very least it makes them _aware_ of the possibility, if they aren't already, of a down market and puts that thought in the forefront.

</comment><comment><USER18> The bubble that is going to pop is Ad Tech

<comment><USER19> I hope this is true.

</comment></comment><comment><USER20> Duplicate: [https://news.ycombinator.com/item?id=17618431](https://news.ycombinator.com/item?id=17618431)

</comment><comment><USER21> _> After a crash, the stock market tends to recover in a couple of quarters (think three to six)._

Based on recent crashes yes, but has that always been true?

<comment><USER22> No, the Great Depression lasted 10 years, from 1929 to 1939 officially (and, for instance, the djia took until the 1950s to recover to the bull market levels that preceded the Great Depression).

<comment><USER16> Or the japanese crash of the early 90s, from which japan still hasn't recovered.

The nikkei is about 1/3 of what it used to be almost 30 years on.

</comment></comment></comment><comment><USER23> That is NOT the Captain speaking.

It's someone who wants to extract money from your wallet. Run away!

<comment><USER24> What part of the article gave you this impression?

</comment></comment><comment><USER25> "Buy into a company because you want to own it, not because you want the stock to go up; Sooner or later the market mirrors the business" \--Buffet

<comment><USER26> "The market can remain irrational longer than you can remain solvent."

<comment><USER27> right, which is why you never short a stock no matter how obviously overpriced it is.

</comment></comment></comment><comment><USER28> Kind of apropos, this struck me.

 _" Venture Capitalists decide not to make capital calls to their Limited Partners, sometimes as a courtesy, other times the result of a directive. They know their LPs have been heavily impacted by the market collapse and don't want to stress them more."_

It's interesting that when it comes to financing insiders, obligations seem to be a lot softer and more negotiable. Margin calls and capital calls. Interbank trading, where long term loans to customers are funded by daily loans to banks.

</comment><comment><USER29> tl;dr have money ready

<comment><USER30> 1.5 years+ of money</comment></comment>


Ask HN: Building a SaaS by connecting services instead of custom-dev everything? - <AUTHOR> I've been reading a lot on Indie Hackers lately about SaaS businesses, typically smaller "micro-saas" which serve some hyper-specific features/business model until there are opportunities to expand. Is it possible to piece a SaaS together by combining a website framework such as Wordpress with payment processing from Stripe, and maybe a few other services, without having to re-invent the wheel or learn full-on development?<p>To be honest I haven't even come up with an idea yet, so I'm not ready to start, but I'm doing a weekend of research to determine feasibility of getting the barebones of a SaaS started while leaving me with an opportunity to seek contracted/outsourced help for small tasks as opposed to developing everything myself.  Any experience in this area?  I'll also be digging through IndieHackers interviews to see if I can find others who have shared similar experiences with little custom development work (until it was needed). <comment><USER2> I've actually done something similar before - using stripe and Sendgrid to make a small (and unremarkable) email service.

I had a very basic management app in rails but nothing else. In the end, I spent maybe 40 hours of dev and less than $100 to make it (domain name and ssl cert). It was a proof of concept for myself.

The drawback was assembling the elements to make it resulted in little to no unique value in the product itself. It had no compelling value prop and as such I never released it.

So, you can do this but you'll probably have to do some dev work and make sure the end product is both compelling, solves a real need and can deliver continuous value.

As an aside, a product that I did enjoy a while ago (the name escapes me) was really just a single person sending a newsletter with a curated list of web dev/design contracts. He used gum road to charge $40/month for it. While I used it, it was totally a valuable offering - and involved zero dev work.

Value can be created in other ways too :)

<comment><AUTHOR> Thanks for the feedback and for sharing your personal experiences. I think your comment about value being created in other ways (and in sometimes incredibly simple, non-techy ways) is something important to not lose sight of. Also, just in that example alone, future enhancement of a service like that could be automating the newsletter into multiple formats, for viewing on the go (such as a kindle format, PDF, etc.), instead of leaving it email only.

But yea, like I said in my OP, I don't even have a business idea yet. Whatever it is, it will need to have a real value prop to be worth doing.

</comment></comment><comment><USER3> Here's a link to an article for something like that:

[https://www.process.st/mvp-app/](https://www.process.st/mvp-app/)</comment>


Ask HN: Do you like modern, Squarespace-style websites? - <AUTHOR> <comment><USER2> Not trying to be smarty pants but I like websites that meet the following criteria:

1\. Homepage loads in a second or less

2\. Clean design and no clutter. Don't give me too many buttons or Call to Actions. Don't make me think too much

3\. Please be gentle with your choice of colors and contrast unless you are specifically catering to an audience like say kids.

4\. No pop-ups asking for my email. Instead, have a subscribe form somewhere and if I am interested, you bet I will subscribe.

5\. Don't hijack scrolling and back button.

</comment><comment><USER3> Yes. Though I prefer more minimalist versions. I wish there was a SquareSpace for typography driven (i.e. minimal graphics and styling other than nice typography) simple/minimalist websites.

<comment><AUTHOR> If Instapaper had a rogue sibling that allowed one to make websites out of specified content, and have it look like Instapaper, I'd be first in line.

</comment></comment><comment><USER4> have a look [http://www.goodui.org/](http://www.goodui.org/)</comment>


Query Language (List of Query Languages) - <AUTHOR> https://en.wikipedia.org/wiki/Query_language <comment><USER2>
      SELECT * FROM QueryLanguages;</comment>


How natural is numeracy? - <AUTHOR> https://aeon.co/essays/why-do-humans-have-numbers-are-they-cultural-or-innate <comment><USER2> >Scientists have long claimed that our ability with numbers is indeed biologically evolved – that we can count because counting was a useful thing for our brains to be able to do.

I would like some citations for this. This is the first I've heard of this, and I previously have assumed that it was universally accepted that this was _not_ the case.

This article makes similar claims at multiple points, without corroboration. "researchers have concluded", "researchers often assume", "researchers have argued", for arguments that I have never heard made.

<comment><USER3> The book "Where Mathematics Comes From"[1] by Lakoff and Núñez makes a lengthy, detailed argument that numeracy is evolved, not universal. I didn't find myself agreeing with everything in it, but I no longer take it for granted that math is a universal concept.

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

<comment><USER4> Can you explain what you mean by evolved as opposed to universal?

Because from my perspective, they mean the same thing when applied to this context. That is, if numeracy is evolved, everyone is fundamentally numerate at some level. And if numeracy is universal, then everybody is fundamentally numerate. They're both nature, not nurture.

What do you mean by those words?

(Personally, I think that numbers are mostly learned, but that the brain has an evolved aptitude for symbolic systems, mathematics being just one of many. I don't think any innate concept of number goes much beyond order of magnitude (i.e. logarithmic) relative differences.)

<comment><USER3> I mean, universal across the universe. There is a common assumption that mathematics is a common language that we could use to communicate with aliens. The notion is that, for example, the concept of prime numbers would be discovered everywhere in the universe just as an intelligence would discover that hydrogen is the simplest atom.

To go further, the Mathematical Universe Hypothesis formalizes the notion that the universe itself is math, and that we are just discovering the math of the universe as we develop mathematics.

I'm personally agnostic on the universality of mathematics. Math is a tremendous tool for describing the universe, but I am willing to consider that a different intelligence might invent some accurate and non-mathematical predictive model.

<comment><USER5> > The notion is that, for example, the concept of prime numbers would be > discovered everywhere in the universe just as an intelligence would discover > that hydrogen is the simplest atom.

The concept of prime numbers is a lot more fundamental than hydrogen being the simplest atom. You could conceivably have a universe where every element is an elementary particle, but you couldn't have a universe where you can put two and two together and get five. Nor could you possibly have a universe where you can take five of something, and divide it into equal sized groups, unless each group has one item or you only have one group.

</comment></comment></comment></comment></comment><comment><USER6> "'The brain, a biological organ with a genetically defined wiring scheme, is predisposed to acquire a number system,' said the neurobiologist Andreas Nieder of the University of Tübingen in Germany. 'Culture can only shape our number faculty within the limits of the capacities of the brain. Without this predisposition, number symbols would lie [forever] beyond our grasp.'"

Well that seems like absolute nonsense. How do we understand computers then? Or almost literally any art form?

<comment><USER7> Because computers are just logic combined with numbers. (The 32gb RAM is attached to the motherboard, which has 32gb.) And for art, we _also_ have other brain systems that understand how to judge beauty in people and landscapes.

I think a more interesting example is quantum physics. Humans have a difficult time understanding it, because it doesn't jive with our normative understanding of the world. But we are still able to understand it, because it is just very messy logic.

<comment><USER6> Right, which seems sort of exactly the argument in the article. "Numbers" are just us extrapolating from "quantity".

</comment></comment></comment><comment><USER8> I'm surprised there was no mention of the Pirahã, a tribe made famous by their apparent innumeracy:

[http://science.sciencemag.org/content/306/5695/496.full](http://science.sciencemag.org/content/306/5695/496.full)

[http://langcog.stanford.edu/papers/FEFG- cognition.pdf](http://langcog.stanford.edu/papers/FEFG-cognition.pdf)

</comment><comment><USER9> Núñez is not a mathematician and claims an anti-Platonic view of maths which is totally inconsistent with the reality of practicing mathematicians over the past century. In particular, I doubt that they grok the extent to which maths and physics have collaborated, and all of the predictions in particle colliders which started out as quirks of equations on blackboards.

<comment><USER10> Nothing about the practice of mathematics over the last century requires (or is even advantaged by) a platonic view.

<comment><USER5> A Platonic view of mathematics, not a Platonic view of the physical universe.

That is, when we say '1', we mean the abstract concept of unity, not one of any particular physical thing.</comment></comment></comment>


Eltanin impact - <AUTHOR> https://en.wikipedia.org/wiki/Eltanin_impact <comment><USER2> It's interesting to see how they estimate all the different quantities involved here: first the fact that there was an impact at all, then the size of the impactor and its speed, then the size of the crater and the ensuing environmental effects like the height of the resulting tsunami, ozone depletion, etc. But there is apparently no evidence of a major extinction event at the same time.

How carefully do researchers in this field crosscheck these numbers? Do they build their next model assuming that the previous model got it right? Or did someone run through some kind of conservation-of-energy calculations and say "yep it all fits together"? I assume these kinds of things are researched all at once soon after the discovery, but are those results ever revisited?

I'm not trying to cast specific doubts on this study or any other particular one, just wondering in general how confident these kinds of ancient geological results are.

<comment><USER3> > apparently no evidence of a major extinction event at the same time

Not a scientist, but I did notice Wiki has a sidebox that gives some very rough indicator of the confidence about this _hypothetical_ impactor. It also lists its estimated size as 1-4km compared to the 11-81 it lists for the _confirmed_ impactor at Chicxulub ([https://en.wikipedia.org/wiki/Chicxulub_crater](https://en.wikipedia.org/wiki/Chicxulub_crater)), or around 1/3-1/20th of the size.

I don't know the impact (sigh) of these factors, but it's probably worth noting that this is also a deep ocean (5km) impact 1500km offshore near the antarctic circle with continents in roughly contemporary locations, versus a continental shelf impact (perhaps sloping from 100m to 1.2km) near the tropics when the landmasses that comprise Africa, the Americas, Europe and Asia are thought to have been much closer together than they are today.

> How carefully do researchers in this field crosscheck these numbers? Do they > build their next model assuming that the previous model got it right? Or did > someone run through some kind of conservation-of-energy calculations and say > "yep it all fits together"? I assume these kinds of things are researched > all at once soon after the discovery, but are those results ever revisited?

Again shooting from the hip, but I don't think it usually works out like this. AFAIK it's rare to have a proposed significant impact that doesn't attempt to marshal/explain existing observations of various sorts locally, regionally, and globally. Likewise, the proposal is likely to get refuted or revised as others point out, publish, and discover something that seems to refute or support the proposed impact. Part of demonstrating the validity of a new model (or improvements to an old one) is going to be showing that it can better- explain some observations without creating large inconsistencies.

I went looking for papers on the associated tsunami to see how they change over time, but you may want to go straight to this one ([https://onlinelibrary.wiley.com/doi/full/10.1111/maps.12326](https://onlinelibrary.wiley.com/doi/full/10.1111/maps.12326)) from 2014. I think it's really well written, and does a decent job of unpacking the various factors that go into how they are projecting some of the various quantities involved.

Here are a few of the others: [http://www.geosci.usyd.edu.au/users/prey/Teaching/Geos-2111G...](http://www.geosci.usyd.edu.au/users/prey/Teaching/Geos-2111GIS/Ref/Ward- TsunamicImpact.pdf) (2002)

[https://link.springer.com/article/10.1134/S0038094607010066](https://link.springer.com/article/10.1134/S0038094607010066) (2007)

[https://onlinelibrary.wiley.com/doi/abs/10.1002/jqs.2571](https://onlinelibrary.wiley.com/doi/abs/10.1002/jqs.2571) (2012)

[https://www.sciencedirect.com/science/article/pii/S0012821X1...](https://www.sciencedirect.com/science/article/pii/S0012821X14006773) (2015)

</comment></comment><comment><USER4> Tangential: Anyone know how to fix the {{Location map}} template on this page? It doesn't have the proper border around it, and the text runs too close to the image.

When I look at the template page, this problem doesn't appear, but I don't know why: [https://en.wikipedia.org/wiki/Template:Location_map](https://en.wikipedia.org/wiki/Template:Location_map)</comment>


Show HN: Mine output simulator - <AUTHOR> https://gist.github.com/CodingNinja/86d84cec11bae0f4ec66

<comment><AUTHOR> I wrote this little simulator to help a friend in college who was stuck with his thesis. It simulates the output of a mine based on the distances required for trucks to travel and each location and trucks capacity.</comment>


iOS 10 release - <AUTHOR> http://www.apple.com/ios/ios-10/?afid=p238%7CsEZIm5H3q-dc_mtid_20925e1t39169_pcrid_137646155470_&cid=wwa-us-kwgo-features-slid- <comment><USER2> some reports of bricking of devices with the OTA update [http://www.macrumors.com/2016/09/13/ios-10-update- bricking-i...](http://www.macrumors.com/2016/09/13/ios-10-update-bricking- iphones-and-ipads/)

</comment><comment><USER3> Really looking forward to 3D Touch use picking up, now that every notification is 3D Touch-able.</comment>


Web SQL Database: In Memoriam - <AUTHOR> http://nolanlawson.com/2014/04/26/web-sql-database-in-memoriam/ <comment><USER2> The great thing is that we're on the verge of not needing Web SQL anymore. sql.js ([https://github.com/kripken/sql.js](https://github.com/kripken/sql.js)) is SQLite compiled to JS (via Emscripten). It can do everything you'd normally do with SQLite. You can take the db and serialize it down into a format that can be stored in local storage, and rehydrate the DB from that when a user returns to your site.

The only thing preventing this from being practical is that sql.js weighs in at around 2MB. Still, there are caching mechanisms that could get around that issue.

I think it's fantastic that we've reached the point where we don't need databases baked into our browsers. All we need is fast JS engines (which we have) and a dumb data store (which we have), and we can provide our own client side databases.

<comment><USER3> I've used both sql.js and WebSQL. Sql.js will get the job done in a lot of cases, but it is not a perfect substitute. Sql.js's performance is an order of a magnitude worse than WebSQL when put under heavy load (this likely has more to do with ASM vs true native code than Sql.js in particular). Particularly, sql.js starts to stutter at a far lower query load than WebSQL for a given machine. Furthermore, Sql.js uses sqlite3_exec() under the hood, which means that all results get converted to strings, _regardless of the underlying type of the column_. And finally, effective memory capacities are not the same.

<comment><USER4> Yes, I just wrote a small app around sql.js, and I was surprised at how poorly it performed. I was expecting to be within a factor of three of native, but I'm seeing performance down by an order of magnitude or so. The sql.js page alludes to bugs open in Firefox and Chrome for these issues; I imagine they'll shake out over time, but it's certainly not a buttery smooth experience just yet. Even still, it certainly works better than the alternatives!

</comment></comment></comment><comment><USER5> It's unfortunate most of this was debated at the beginning of all the hype around NoSQL data stores.

It would be some work, but still be relatively trivial to build a query spec, probably based off of SQL 92, and a basic type system spec (Strings, numbers, and dates are the bulk of it), and then an implementation of everything else.

Facebook did it with Presto, although they haven't finished the DML part of it.

Reading the emails, I get the feeling most of the people involved didn't have as much experience with databases as they probably should have in order to make a truly informed decision.

<comment><USER6> The problem is that all pages aren't written to the spec, they're written to work with implementations.

When there's only one implementation (that authors care about), then every quirk, bug and accidental misfeature can be depended upon, and SQLite has plenty of those ("FLOATING POINT" parsed as "INT", magic of ROWID, the lax type system even more forgiving than PHP, etc.)

If there was another implementation then lack of overlap in quirks/bugs would prevent authors from depending on them (e.g. if you wrote something stupid then it'd work in one browser, but not the other).

ASCII venn diagram of 2 implementations:

       { bugs1 ( usable standard } bugs2 )

ASCII venn diagram of all browsers just shipping same Sqlite:

       {( usable: standard and all bugs })

<comment><USER7> That's a good point, and one I could have added to the post. There are bugs in Web SQL, but they're largely the same on both Chrome and Safari. IndexedDB is trickier, because the bugs are all different between Firefox, IE, and Chrome. Again, another situation where libraries can help out.

Although in general, it's sad that the "independent implementations" mantra basically guarantees a lack of consistency across browsers. It's like we only have a choice between "pointing to a pile of C code" or ending up with a pile of browser bugs. Maybe the W3C could write acceptance tests to go alongside the specs.

<comment><USER8> > Maybe the W3C could write acceptance tests to go alongside the specs.

Like these? :) [https://github.com/w3c/web-platform- tests](https://github.com/w3c/web-platform-tests)

<comment><USER7> Heh, I learned a thing about a thing! :) Curious to know how so many quirks slipped through, though. Maybe I should do a PR on the tests for bugs that the browser vendors might not know about, e.g. [https://gist.github.com/nolanlawson/8330172](https://gist.github.com/nolanlawson/8330172).

</comment></comment></comment></comment></comment><comment><USER9> WebSQL is remarkably simple to use, works on the most popular browsers on mobile and desktop, and gives you the power of SQL. In contrast, IME indexed db felt like pulling teeth. The discussions seem to suggest that institutional intransigence by Mozilla pushed the internet back a step. (And yes, SQLite + Emscripten is significantly slower than websql on chrome and iOS Safari)

<comment><USER10> From a personal perspective I stopped building HTML web apps after I started to transition my WebSQL apps to IndexedDB. I really really disliked the experience (messy code/overhead) and haven't had any desire to write another with a client side DB again. The bright side for is however it drove me to learn iOS and Android development... not such a great day for the web though as I suspect my experience isn't unique.

</comment></comment><comment><USER11> As always, there are some problems IndexedDB document stores solve well, and others that SQL is really well suited for, and I think it's great to have both options. What sucks is when people say "Sure, we'll support that there is more than one way to do this (TMTOWTDI), as long as you recognize that my way is the right way in almost all foreseeable cases, so we'll build the tool this way". That statement is rarely correct, especially when making a browser capability. (Yes, I know, trying to disprove a generalization with a generalization isn't very persuasive. Oh well.)

I read all the concerns (it's a standard built around sqllite, and who wants that?!?!, etc.) and I still sigh a sigh of disappointment that it's come to this. I know, Web SQL isn't going away, as the author points out, but it will be a 2nd class citizen for the foreseeable future, and that's just a missed opportunity, imho.

<comment><USER12> Exactly they both have scenarios that they work very well for just like you have with the server-side SQL RDBMS and the NoSQL ones. IndexedDB is fine for simpler apps or apps where there isn't a real need for joining, grouping and ordering the records in a very flexible way.

Web SQL is definitely dead in native Chrome apps. It was never born actually given IndexedDB was the only solution that was pushed.

</comment></comment><comment><USER13> WebSQL yet another web spec that the Mozilla Foundation won't implement because of "problems". There are a few bits of CSS that I would love to use all over the web, like "display: run-in", but Gecko is the only holdout.

<comment><USER14> It sounds like Blink and WebKit are actually removing display:run-in, according to the Gecko bug:

[https://bugzilla.mozilla.org/show_bug.cgi?id=2056](https://bugzilla.mozilla.org/show_bug.cgi?id=2056)

</comment></comment><comment><USER15> Shamless plug: My (now quite old) library Gazel puts a Redis-like API on top of IndexedDB making it pleasant to use: [http://gazeljs.org/](http://gazeljs.org/)

</comment><comment><USER15> The flip-side is that IndexedDB being an independent spec means they are able to extend it in ways that wouldn't be possible with WebSQL. For example, in IndexedDB you can store arbitrary Blobs as values. This means you could store an HD movie if you wanted. With WebSQL you had to base64 encode blobs to store them.

I think this articles kicks on one key thing that explains the lack of enthusiasm around IndexedDB... people primarily want a database on mobile. And iPhone doesn't support IndexedDB yet, that is enough to kill it.

</comment><comment><USER16> > Often in the tech industry we're too quick to eviscerate some recently- > obsoleted technology (Flash, SVN, Perl)

Perl is obsolete? LOLz.</comment>


What's New in ES2019 - <AUTHOR> https://blog.tildeloop.com/posts/javascript-what%E2%80%99s-new-in-es2019 <comment><USER3> Honest question, not meant to be inflammatory.

If we still need to target es5 4 years later, and transpilation is standard practice, why bother? Is the evolution of JS not directed in practice by the authors of Babel and Typescript? If no one can confidently ship this stuff for years after, what's the incentive to even bother thinking about what is official vs a Babel supported proposal.

I like the idea of idiomatic JS with powerful modern features, but in practice every project I've seen seems to use a pretty arbitrary subset of the language, with different ideas about best practices and what the good parts are.

<comment><USER4> That's not unique to JS. Some compilers took over a decade to implement C99 features. Most of us C coders were still defaulting to C89 for portability well into the late 00's. But now C99 is mainstream enough that you can (mostly) safely target it.

If you never release new standards you'll never be able to use them. I realize that in JS world 4 years is basically an eternity so it's hard to project that far but I'm sure that if you still have to write javascript code 10 years from now you'll be happy to be able to use the features of ES2019.

Regarding transpilation surely it's not as standard as you make it out to be? It's popular to be sure but handwritten javascript is not that rare nowadays, is it?

<comment><USER5> > It's popular to be sure but handwritten javascript is not that rare > nowadays, is it?

Long time front end developer here. In the last couple of years I can't recall seeing even a single project without a build pipeline (not that they don't exist, I just haven't encountered them at my day job, first or third party).

<comment><USER6> I don't understand what is so appealing about not having a build pipeline for JavaScript, other than the ability to very quickly test and learn things directly in the browser, which of course anyone can still do.

For anything remotely important, you're almost certainly going to already want a build pipeline to do things like concatenating/minifying code, running tests, and deploying. Adding a transpilation step to extend support to older browsers comes with almost no cost to time or maintainability, assuming you're using well-supported things like Babel and its official plugins.

<comment><USER7> The appealing thing about not having a build pipeline is not having it. Not having another thing to maintain and update/upgrade/debug. I've gone through grunt, gulp, webpack and parcel. Somewhere along the way I realized that with es6 imports and css variables I don't really need it.

I've talked with frontend devs who only worked on projects with build steps about this and they often seem perplexed and surprised by just how simple it can be if you don't make it complex.

<comment><USER8> Can you imagine a modern SoundCloud, Spotify, Facebook, Airbnb or Slack without a build pipeline? There's nothing appealing about that.

It's nice and simple for small projects but let's not act like putting a script tag in HTML is some divine wisdom that newbies don't understand.

<comment><USER7> Yes I can. All of those except for facebook (because facebook is a sprawling platform) seem reasonable to be able to build without a build system. And with using es6 modules it's not "putting a script tag in HTML", you have a proper module loading system without needing any builds or libs.

I'm not saying it's some sort of lost knowledge like Damascus steel, I'm just saying that many people these days are so caught up into the current dogma of JS that they never consider a simpler but still modern path.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> Now if we could just get pattern matching[1] and optional chaining[2], that would really elevate things.

[1] [https://github.com/tc39/proposal-pattern- matching](https://github.com/tc39/proposal-pattern-matching)

[2] [https://github.com/tc39/proposal-optional- chaining](https://github.com/tc39/proposal-optional-chaining)

<comment><USER10> Optional chaining recently reached stage 3, the babel plugin is available and TS is going to adopt it for 3.7.0.

<comment><USER11> Oh I didnt know about TS being so close to have it, that's great news

EDIT: here is the confirmation TS 3.7.0 got tagged: [https://github.com/microsoft/TypeScript/issues/16#issuecomme...](https://github.com/microsoft/TypeScript/issues/16#issuecomment-515160784)

EDIT 2: wow just noticed, that the issue ID is "16" and it has been open since Jul 15, 2014 (I guess: good things take time ... ;) )

</comment></comment></comment><comment><USER12> A year back I dropped a proposal idea at the EcmaScript discussion list, I hope it get's picked up sometime.

My idea is that `let`, `var` and `const` return the value(s) being assigned. Basically I miss being able to declare variables in the assertion part of `if` blocks that are scoped only during the `if()` block existence (including `else` blocks).

Something along these lines:

        if( let row = await db.findOne() ) {
             // row available here
        }

        // row does not exist here

The current alternative is to declare the variable outside the `if()` block, but I believe that is inelegant and harder to read, and also requires you to start renaming variables (ie. row1, row2...) due them going over their intended scope.

As previous art, Golang's:

          if x:=foo(); x>50 {
            // x is here
          }
          else {
            // x is here too
          }

          // x is not scoped here

And Perl's

          if( ( my $x = foo() ) > 50 ) {
               print $x
          }

<comment><USER13> I know this doesn't match up entirely with what you want syntax wise, but the following works and I consider it quite elegant.

      {
        let row;
        if (row = await db.findOne()) {
          //
        }
        else {
          //
        }
      }

<comment><USER12> It's not the same. For instance, you could not use a `const` variable.

Also having "phantom" scope blocks get very nasty to read once you have more involved logic, as the block itself has no implied meaning and the programmer has to walk a few lines into it to get what's going on.

<comment><USER14> You could always make it a labelled block statement !

</comment></comment></comment></comment><comment><USER15> It's great to see JS getting some of the features of better planned languages.

But I'm still very nervous about some of the stuff mentioned here with regard to mutation. Taking Rust and Clojure as references, you always know for sure whether or not a call to e.g. `flat` will result in a mutation.

In JS, because of past experience, I'd never be completely confident that I wasn't mutating something by mistake. I don't know if you could retrofit features like const or mut. But, speaking personally, it might create enough safety-net to consider JS again.

(Maybe I'm missing an obvious feature?)

<comment><USER16> I still don't understand why neither JSs var or let allow you to redefine the variable with the same name.

I makes chaining things while debugging so much harder:

      let a = a.project();
      let a = debug(a);
      let a = a.eject();

vs

      let a1 = a.project();
      let a1d = debug(a1);
      let a2 = a1d.eject();

<comment><USER17> Without getting into the merits of allowing redefines in a loosely typed language, the simple reason why JS can't support this is hoisting.

Any var/let statement of the form var a = 1; is interpreted as 2 statements. (1) The declaration of the variable which is hoisted to the beginning of the variable scope, and the (2) setting of the value, which is done at the location the var statement is at.

Having multiple let statements would mean the same variable is declared and hoisted to the same location multiple times. So it's basically unnecessary and breaks hoisting semantics.

In addition, the downside risk of accidentally redefining a variable is probably far greater than the semantic benefits of making the redefinition clear to a reader (esp since I think that benefit is extremely limited in a loosely typed language like JS anyways).

<comment><USER18> That's not quite accurate. It's actually the reverse.

Think of the closure as an object. It contains variables like `this`, `arguments`, a pointer to the parent closure, all your variables, etc.

The interpreter needs to create this closure object BEFORE it runs the function. Before the function can run, it has to be parsed. It looks for any parameters, `var` statements, and function statements. These are all added to the list of properties in the object with a value of `undefined`. If you have `var foo` twice, it only creates one property with that name.

Now when it runs, it just ignores any `var` statements and instead, it looks up the value in the object. If it's not there, then it looks in the parent closure and throws an error if it reaches the top closure and doesn't find a property with that name. Since all the variables were assigned `undefined` beforehand, a lookup always returns the correct value.

`let` wrecks this simple strategy. When you're creating the closure, you have to specify if a variable belongs in the `var` group or in the `let` group. If it is in the `let` group, it isn't given a default value of `undefined`. Because of the TDZ (temporal dead zone), it is instead give a pseudo "really undefined" placeholder value.

When your function runs and comes across a variable in the let group, it must do a couple checks.

Case 1: we have a `let` statement. Re-assign all the given variables to their assigned value or to `undefined` if no value is given.

Case 2: we have an assignment statement. Check if we are "really undefined" or if we have an actual value. If "really undefined", then we must throw an error that we used before assignment. Otherwise, assign the variable the given value;

Case 3: We are accessing a variable. Check if we are "really undefined" and throw if we are. Otherwise, return the value.

To my knowledge, there's no technical reason for implementing the rule of only one declaration aside from forcing some idea of purity. The biggest general downside of `let` IMO is that you must do extra checks and branches every time you access a variable else have the JIT generate another code path (both of which are less efficient).

<comment><USER17> We are on the same page.

My point is having 2 let or var statements doesn't actually do anything on the interpreter side.

If JS allowed 2 var/lets without complaining, it would be entirely a social convention as to what that meant, since it would have no effect on the actual code that was run.

And the social convention benefit (which could more easily be achieved with just putting a comment at the end) is probably far outweighed by the many, real examples I've seen where someone has accidentally created a new variable without realizing that variable already exists in scope.

Disallowing multiple vars helps linters identify these situations (which are far more common with var's function level scoping than let's block level scoping).

</comment></comment></comment></comment></comment><comment><USER19> That array.flat() and array.flatMap() stuff is great to see. Always having to rely on lodash and friends to do that type of work. Exciting to see how JS is evolving.

<comment><USER20> I dig it too, but you could previously flatten an array with concat, and the spread operator. [].concat(...array)

Lodash wasn't necessary.

<comment><USER21> No this is not an alternative, it will fail if the array is too large, as you will exceed the maximum number of arguments a function will accept (which is implementation defined).

In general the spread operator should only be used for forwarding arguments not for array operations.

<comment><USER22> > In general the spread operator should only be used for forwarding arguments > not for array operations.

Not quite. You should also use the spread operator when you are spreading an iterable into an array:

        const unique = [...new Set(arr)];

<comment><USER23> Seems like a needlessly unreadable alternative to Array.from unless you're combining multiple iterables or values an iterables e.g.

        const unique = [...a, ...b];

You might expect that concat would work, but it doesn't handle arbitrary iterables:

        > [].concat([1][Symbol.iterator](), [2][Symbol.iterator]())
        [Array Iterator, Array Iterator]
        > [...[1][Symbol.iterator](), ...[2][Symbol.iterator]()]
        [1, 2]

</comment></comment></comment></comment></comment><comment><USER11> A read a similar article few days ago (might be interesting too) (not mine): [https://medium.com/@selvaganesh93/javascript-whats-new-in- ec...](https://medium.com/@selvaganesh93/javascript-whats-new-in- ecmascript-2019-es2019-es10-35210c6e7f4b)

And also here is a good recap of ES 6/7/8/9 (just in case you missed something) (also not mine): [https://medium.com/@madasamy/javascript-brief- history-and-ec...](https://medium.com/@madasamy/javascript-brief-history-and- ecmascript-es6-es7-es8-features-673973394df4)

</comment><comment><USER24> Object.fromEntries will be super useful, surprised it's taken this long to become a native feature.

<comment><USER25> What would some common/helpful use cases be?

<comment><USER26> I often use Object.entries so that I can use Array.filter/map/foreach on an object, but then I need to use Array.reduce to hack it back into an object. Object.fromEntries solves this.

<comment><USER27> Yeah this is what I'm most excited for. filter and map and my preferred array traversal methods. reduce can be awkward though, and people abuse it by using it to replace or combine filter and map. fromEntries almost makes reduce unnecessary when working with objects.

</comment></comment></comment></comment><comment><USER28> Why did they create a flatMap method? What is wrong with .map(...).flat()? Can they improve the performance by combining it that much?

<comment><USER29> They could have also implemented flat in terms of flatMap: flatMap(x => x)

I personally feel flatMap is a much more used method than flat, so if you want to remove one, I would remove flat.

<comment><USER23> > They could have also implemented flat in terms of flatMap: flatMap(x => x)

Flat can flatten any level of nesting (it just defaults to 1), so would be difficult to implement in terms of flatMap.

<comment><USER30> You _could_ reproduce that behaviour of 'flat' by doing something like:

        function flatten(x, n=1) {
            return n > 0 ? x.flatmap(y => flatten(y, n-1))
                         : x;
        }

<comment><USER23> You could also blow up your stack as there is no requirement whatsoever that javascript implementations be tail-recursive.

</comment></comment></comment></comment></comment><comment><USER31> arr.flat(Infinity) seems like a strange decision for flattening the entire array - wouldn't the most common number of levels to flatten an array be all levels, in which case I'd expect arr.flat() to flatten the whole array but in this case it's just 1 level.

<comment><USER32> Infinity was originally the default (which feels intuitive), but here's the argument for changing it [0]:

"I think Array#flatten should be shallow by default because it makes sense to do less work by default, it aligns with existing APIs like the DOM Node#cloneNode which is shallow by default, and it would align with the existing ES3 pattern of using Array#concat for a shallow flatten. Shallow by default would also align with flatMap too."

[0] [https://github.com/tc39/proposal- flatMap/issues/9](https://github.com/tc39/proposal-flatMap/issues/9)

<comment><USER31> I'm trying to think of a single use case where I'd want to flatten exactly one level of an array and can't.

</comment></comment></comment><comment><USER33> Finally, flatMap is here.

I really hope there could be syntactic sugar like do expression in Haskell, for in Scala, and LinQ in C# for flatMap instead of type limited version like async await.

Another thing is pipe operator seems to be very welcome among the proposals. There will be no awkward .pipe(map(f), tap(g)) in RxJS since then.

</comment><comment><USER34> Some half decent stuff in here, but I heavily disagree with changing the output of toString. That might cause problems if someone is expecting one output, but the new version creates something new. I don't see a reason why they couldn't have just added a new function functionCode() or something similar. It would give people the functionality they want, without destroying backwards compatibility.

<comment><USER35> It's already been deployed in the wild for about a year.

</comment></comment><comment><USER36> Can someone please point me to the rationale behind the new toString() function?

<comment><USER23> Rather than how complete it is, the real improvements of the proposal are:

1\. it all but requires that ES-defined functions stringify to their source code. Pre-ES2019 that's implementation-defined

2\. it standardises the placeholder for the case where toString can't or won't create ECMAScript code (e.g. host functions), this could otherwise be an issue as with implementation-defined placeholders subsequent updates to the standard _might_ make the placeholder unexpectedly syntactically valid, by having the placeholder standard future proposals can easily avoid making it valid

3\. the stringification should be cross-platform as the algorithm is standardised

<comment><USER37> Ok that makes sense... I was really confused because that's already more or less toString()'s behavior on modern browsers, though the whitespace discrepancy is important to define.

<comment><USER23> That's in part because it was fed back through browsers during the specification process.

</comment></comment></comment></comment><comment><USER38> That's a surprisingly small amount of change. I'll leave it to others to determine if that's a good or bad thing.

<comment><USER39> Clojure too didn't change a lot. In these years of 'disruption' it feels odd. But it may just be that we forgot stability and maturity.

<comment><USER38> Existing Clojure APIs don't change, but Clojure adds a lot more than this each year. Look at spec, reducers, transducers &c

<comment><USER39> Well reducers and transducers were big announcements. IIRC clojure 1.10 didn't add any feature of that scale, and few people mentioned that it was quite a "smaller", without criticizing. spec seems important but is still alpha status.

</comment></comment></comment></comment><comment><USER40> Isn't the new function string representation backwards incompatible? Having struggled with javascript's lame error tooling I could see people actually using it in production too.

</comment><comment><USER41> Why are empty elements in an array allowed? oO

[1,2,,3]

<comment><USER42> They need to ensure that any combination of characters will produce some result.

</comment></comment><comment><USER43> The part about parameter less catch reveals a lot about the philosophy of the language. For me, silencing error like this is a bad practice. You may still produce a sane error in the catch, but the design goes toward silencing things.

I really love languages that force you to handle errors up to the top level.

<comment><USER44> It does, though I wouldn't go to the same conclusion. It gives more freedom to the developer. They are lot of cases where errors are in fact, expected. Parsing a user inputted JSON. Making a request to check internet connection availability. Any promise that is going to be consumed by an async - <USER2> pattern. In those cases (and many more), you may want to try something just simply to see if it works. It's completely different say to being on the backend, trying to write to a database which may or may not fail.

In those cases, forcing the extra parameter in the catch, even though you are not using it, is slightly annoying. I mean it's literally 3 characters, but in this age of linters encouraging to not specify arguments you don't use, it just feels unnatural.

<comment><USER45> The problem is that the catch block will catch all errors, so if a different type of error to the one you expected occurs then it gets silently swallowed. This is the equivalent of catching the generic Exception class in python. Horrendous terrible practice in anything but the hackiest scripts.

</comment></comment></comment><comment><USER46> It's very exciting to see how JavaScript is evolving!

<comment><USER47> Honest question, not playing. What is exactly exciting about it? 2020 is around the corner and the language created back in 1995 is only now getting features that have been standard in many other languages, either as part of the core language or the standard library for decades.

<comment><USER48> Well, I'd think that was pretty obvious, right? It's exciting because if you spend the day writing JavaScript I don't give a hoot that another language has had that feature for decades because I don't get to use that other language.

Are you implying that no other languages ever add features that other languages have? All languages except JS are feature complete? Come on..

<comment><USER47> Well now, having an option to use other languages to script web pages, that would be exciting.

<comment><USER49> The better JS gets, the more I want to use it. JS with Promises + async/await is now one of my favorite languages.

<comment><USER47> How do you cancel promises?

</comment></comment></comment></comment></comment></comment><comment><USER50> I feel after ES6 and async/await in ES7 we're getting pretty meager upgrades.

IMO the three features that would make a much more significant impact in front end work are:

\- optional static types

\- reactivity

\- some way to solve data binding with the DOM at the native level

<comment><USER51> Yep, waiting for private methods (Stage 3) and private-fields.

</comment></comment><comment><USER52> Ummm... 25^2 is 625. 15^2 is 225 (see the Object.fromEntries example). I mean, I knew JavaScript math was a bit sloppy due to the use of floating point everywhere, but I hope it's not THAT bad...

<comment><USER53> I think it's been changed after you posted this comment. It now shows that 15^2 is 225.

</comment></comment><comment><USER54> That Function.prototype.toString change is probably going to break some Angular.js code who relies on scanning function argument names for dependency injection.

<comment><USER55> It also requires that comments get stored and waste memory: previously just enough of the AST needed to be stored to be able to regenerate the JavaScript. You can't throw away the comments because you can't predict where code might do someVarHoldingAFunc.toString()

It seems like an unnecessary change - if the source needs to be accessed then get the source file.

<comment><USER56> Agreed. I guess the argument for it is it's more accurately reflected but... who cares? Maybe I'm not understanding what people do with [function].toString() in the real world.

<comment><USER55> What's even worse is that now frameworks (and viruses) will store data in comments.

I know this because I have wanted to use fn.toString() as part of some meta- programming many years ago (but couldn't because comments were not stored).

I am sure a lot of effort went in to making a good decision, aiming for a good outcome, but this smells like a bad one.

</comment></comment></comment></comment><comment><USER57> So, what coffeescript features are we still missing after this round?

</comment><comment><USER58> I think the flatMap method is pretty solid evidence for my contention the language is really getting bloated now.

</comment><comment><USER59> Is that all there is that's new? Maybe it's a good thing that JavaScript is finally slowing down.

</comment><comment><USER60> Under symbol.description:

const test = Symbol("Desc");

testSymbol.description; // "Desc"

\</comment><comment>---

Should testSymbol be replaced with test?

<comment><USER61> Fixed the typo, thanks for the heads up!

</comment></comment><comment><USER62> Why does flatmap exist? What's against `sentence.map().flat()`

</comment><comment> john-foley Hard to believe that const arr4 = [1, 2, , 4, 5]; is valid.

<comment><USER63> Seems perfectly logical to me: an array of length 5 with four populated elements and one empty one (3). Though I did double-check my understanding that the length property would report 5 rather than 4 (it does).

What looks out of place to you in that example?

Would it make more sense to you with a very slightly less arbitrary example, perhaps arr = ['Value for 0', 'Value for 1', , 'Value for 3', 'Value for 4']; instead of simple mapping ints to ints?

Because array contents are mutable [even if the array variable itself is declared const] that third index may be populated at a later point in the code.

<comment><USER23> > What looks out of place to you in that example?

Most languages don't have sparse arrays so it's really weird.

> Would it make more sense to you with a very slightly less arbitrary example, > perhaps arr = ['Value for 0', 'Value for 1', , 'Value for 3', 'Value for > 4']; instead of simple mapping ints to ints?

You'd usually put an explicit `null` there, especially as HOFs skip "empty" array cells so

        ['Value for 0', 'Value for 1', , 'Value for 3', 'Value for 4'].map(_=>1)

returns

        [1, 1, , 1, 1]

which is rarely expected or desirable.

</comment></comment></comment><comment><USER64> .

<comment><USER65> Doesn't the fact that flatten by default only flattens one level mean you can still create nested output by emitted nested outputs?

<comment><USER66> Yes, it appears so. From MDN:

> The flatMap() method first maps each element using a mapping function, then > flattens the result into a new array. It is identical to a map() followed by > a flat() of depth 1, but flatMap() is often quite useful, as merging both > into one method is slightly more efficient.

[https://developer.mozilla.org/en- US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en- US/docs/Web/JavaScript/Reference/Global_Objects/Array/flatMap)

<comment><USER67> FlatMap is often most useful when recursing, in my experience.

</comment></comment></comment></comment><comment><USER68> seems like a real missed opportunity to add string.leftPad()

<comment><USER69> Seems like a real missed opportunity to look at the Python stdlib and add a bunch of missing functionality to JS so that people don't have to import a metric ton of third party libraries (or worse, write it themselves) to add something you get for free in most other scripting languages.

Even the trim operations they added fall short of the target. In Python (and tcl, by the way) you can specify which characters to trim.

So close, yet, so far.

<comment><USER35> You can use regex for other characters, the point of the trim functions is that they match the somewhat complex unicode whitespace.

</comment></comment></comment><comment><USER70> At this point, I'm convinced that Javascript is basically a jobs creation program.

We go on adding fancy new syntax for little or no gain. The whole arrow function notation, for example, buys nothing new compared to the old notation of writing "function(....){}" other than appearing to keep up with functional fashion of the times.

Similarly, python which was resistant to the idea of 20 ways to do the same thing, also seems to be going in the direction of crazy things like the "walrus" operator which seems to be increasing the cognitive load by being a little more terse while not solving any fundamental issues.

Nothing wrong with functional paradigm, but extra syntax should only be added when it brings something substantial valuable to the table.

Also, features should be removed just as aggressively as they are added, otherwise you end up with C++ where you need less of a programmer to be able to tell what a given expression will do and more of a compiler grammar lawyer who can unmangle the legalese.

<comment><USER71> >The whole arrow function notation, for example, buys nothing new compared to the old notation of writing "function(....){}" other than appearing to keep up with functional fashion of the times.

Incorrect - The main advantage is fat arrow syntax can keep lexical scope of this current context. Hence you dontneed to implement that=this antipattern

<comment><USER70> In that case, they should have deprecated the "function(){}" notation or at least made it such that arrow function doesn't overlap it.

The current scene is that most people don't know what the real difference between arrow and function notations and this leads to a lot more number of bugs than if they weren't this overlapping. Overall, my point is, this just leads to poor ergonomics and you'll have a larger number of avoidable bugs.

<comment><USER49> > The current scene is that most people don't know what the real difference > between arrow and function notations

That's hard to believe unless you're working on the most amateur of teams.

There's a point where you have to expect people to understand the most basic concepts of the language/tools they're hired to use. This shouldn't require more than a simple 5min pull-aside of the junior developer.

Also, you can't change function(){}'s dynamic scope without breaking the web, which is a major downside for your suggested upside of developers not having to learn the distinction. function(){} was _always_ confusing from day one. ()=>{} is a move back toward intuitiveness.

</comment></comment></comment></comment><comment><USER72> Can we get some additions that replace the garbage one-liner `is-even`/`is- odd` npm libraries that are a scourge?

<comment><USER73> You mean something like x % 2 === 1?

I'm a JS fan but had to admit I chuckled at the implementation of is-even: [https://github.com/jonschlinkert/is- even/blob/master/index.j...](https://github.com/jonschlinkert/is- even/blob/master/index.js)

<comment><USER37> That's hilarious.

What's not hilarious is that, after removing the essentially useless error- checking, is-even is literally just `(n % 2) === 1`. On one hand, JS desperately needs a standard library, on the other hand, JS devs can be so infuriatingly lazy and obtuse.

<comment><USER74> > is-even is literally just `(n % 2) === 1`

Pretty sure that tells you if a number is odd. I guess maybe there is a reason these libraries exist.

<comment><USER37> That was just a typo, I meant the source for is-odd. I copy-pasted it. I use that exact syntax all the time in code, you don't need to be patronizing.

</comment></comment></comment></comment></comment><comment><USER75> Most of this is sugar, e.g. flat() and flatMap(), out of scope for a language spec.

Function.toString being more accurate is helpful.

But real progress would be removing dangerous backtracking regular expressions in favor of RE2: [https://github.com/google/re2/wiki/Syntax](https://github.com/google/re2/wiki/Syntax)</comment>


Leaving Microsoft - <AUTHOR> http://www.haskell.org/pipermail/haskell/2012-November/023566.html <comment><USER2> FYI, Simon Marlow is incredibly big in the Haskell community and is the leading expert in Multi core parallelism via STMs in Haskell. Some of the work he has done for the GHC compiler is frankly fantastic.

This is incredibly big news in the Haskell world. The FP community is starting to break boundaries with the industry in the last 5 years with Clojure (and Scala's functional support).

Currently, FB seems to use haskell only for basic lexing and parsing[1]. It would be tremendous to see them using it at FB scale. I think there's going to be gain for both parties - For FB, the publicity and hacker outreach, and Haskell - industrial reliability.

[1]: <http://www.haskell.org/haskellwiki/Haskell_in_industry>

<comment><USER3> > The FP community is starting to break boundaries with the industry in the > last 5 years with Clojure (and Scala's functional support).

There is very little evidence of that. Do a search for Scala, Clojure or Haskell on the main indicator web sites (job boards, StackOverflow, TIOBE, indeed.com, etc...) and you'll find they are as insignificant today as they were five years ago compared to the mainstream languages.

<comment><USER2> Anecdotally (n=1, of course) I have seen and heard tremendous resistance to clisp in the industry I work in 5 years ago. Now, clojure and Scala are being adopted and recommended by even conservative PMs and architects.

The choices are way more today (Almost a tautology given old choices don't really vanish into thin air) and on more reliable platforms with tried and tested libraries.

anyway the spirit with which i meant that statement was that it is far easier to convince "senior management" and others with power to let stuff be done in clojure / Scala than it was to convince them about ml or clisp five years ago.

And I am not even talking about "ivory tower Haskell" (which i love using).

(Don't know enough about erlang / f# to comment).

<comment><USER4> My new recent project is in .NET and I happily using all functional like features C# 4.0 offers.

</comment></comment></comment></comment><comment><USER5> It should be made clear in the title that Haskell isn't leaving MS, rather it is one of the lead developers of GHC, Simon Marlow.

<comment><USER6> Agreed. It should be "GHC Developer Leaving Microsoft".

<comment><USER7> It's the subject of the mailing list message (the [Haskell] being the mailing list subject prefix). I was able to piece together what it meant, but I know that a couple of key people for ghc work for Microsoft Research. I agree in general that it's confusing, but it's not like this is the subject of blog post that was poorly chosen. The 'real' subject is just "Leaving Microsoft".

<comment><USER8> And how would we know that before we click on the link bait?

<comment><USER9> Complain to the policy or machinery against editorializing titles that makes every submission title converge towards the <title> on the linked page.

</comment></comment></comment></comment></comment><comment><USER10> Wow, talk about a shock. I hope that this is good news for functional programming and the programming language community, rather than just good news for Facebook.

</comment><comment><USER11> Does this mean that Facebook is using Haskell more these days?

<comment><USER12> Nah, it means that Simon Marlow harbored a latent desire to go code in PHP.

<comment><USER13> Facebook is about equally PHP and C++ these days.

<comment><USER14> This really boggles my mind. Facebook's stack is intriguing.

</comment></comment></comment></comment><comment><USER15> This may be either disastrous or magnificent. I think it may end up being the latter.

</comment><comment><USER16> This email was sent yesterday, how come it's in Courier New?

</comment><comment><USER17> GHC? Great Haskell Collider?

<comment><USER18> Well the strong type system ensures that no collisions are possible. GHC is quite the software gem. I love haskell more and more. Everything that is so simple to write, has no right of being so fast.

<comment><USER8> I agree. The type inference is a beautiful thing. I had started a project in Scala and I'm finding it hard to stay interested when Haskell is so much more interesting to me. But Scala is a LOT more practical for my project. :(

<comment><USER19> i dunno i've seen type inference create horrible to debug situations - although mainly where it has been shoehorned into to C++11 and used with templates and auto to create code that fails silently doing nothing when a parameter has the wrong type

<comment><USER20> C++ "type inference" has nothing to do with actual type inference. Types in functional programming languages have a proper academic mathematical foundation, specifically in formal logic. This is in sharp contrast to C++, where it was added as a convenience to avoid specifying certain template parameters. And with so many C++ "features", this one adds yet more ambiguity to the language.

</comment></comment></comment></comment></comment><comment><USER19> i'm assuming this guy has done real world work before? the idea of a compiler/language lead programmer effectively having lived in academia is terrifying on many levels.

best of luck to him at any rate. haskell and ghc are a cool language and compiler combo, one i have enjoyed for recreational programming time and time again.

<comment><USER21> err... do you know that (since 1.4 IIRC) the java compiler is the one written by Martin Odersky?

<comment><USER4> Wasn't 1.5?

Martin's work was related to generics, which got introduced in 1.5.

<comment><USER22> It was 1.3, but the interesting features were disabled in production builds until 1.5, [http://docs.oracle.com/javase/specs/jls/se7/html/jls-0-prefa...](http://docs.oracle.com/javase/specs/jls/se7/html/jls-0-preface3.html)

<comment><USER4> Thanks for the clarification.</comment></comment></comment></comment></comment>


Facebook at War: 6 Key Takeaways from the Times's Investigation - <AUTHOR> https://www.nytimes.com/2018/11/14/technology/facebook-crisis-mark-zuckerberg-sheryl-sandberg.html <comment><USER2> The part about Chuck Schumer protecting Facebook from the inside while they raise money for him and employ his daughter are new to me.</comment>