HN Theater @HNTheaterMonth

Do they care if a year down the road your maintenance costs increase fivefold? Have they seen the analysis which shows that initial development cost just makes a small fraction of the total cost and that fraction get smaller the longer software is in use?

Do they care if a year down the road your TTM times increase tenfold?

  We know that the bad code slows us down. Why do we write it?
  Why do we write the code that slows us down? How much does it
  slow us down? It slows us down a lot. And every time we touch
  the modules we get slowed down again. Every time we touch bad 
  code it slows us down, what do we write this stuff what slows 
  us down?
  And the answer to that is: well we have to go fast.
  I'll let you to deal with the logical inconsistency there, my 
  message to you today is—you don't go fast by writing crap.

https://www.youtube.com/watch?v=TMuno5RZNeE&feature=youtu.be...

⬐ wellboy

No. When they have seen all the bugs, they will tell you to fix them and when you make a new feature they will tell you the same thing, just make it work, just ship it.

The keywords were reserved in the latest spec for just this purpose.

I don't think the rationale for their inclusion is a good one. The inclusion of such keywords in languages like C++, Java, etc was well-meaning but a mistake in retrospect. In the presence of global variables and direct assignment these keywords are the PHB approach to information hiding. They require ceremony and diligence to achieve true encapsulation. It's a murky situation at best.

See Bob Martin https://www.youtube.com/watch?v=TMuno5RZNeE&t=2325 and Bertrand Meyer on Eiffel: http://se.inf.ethz.ch/old/teaching/ss2007/0050/slides/03_sof... (Bertrand Meyer coined the Open/Closed Principle and is the developer behind Eiffel).

At this point though I see their inclusion in JS being almost inevitable. Just another feature to ignore.

It'd be nicer if they would look to add syntax for higher-order operators like compose to the language instead of this.

> Except that languages which try to provide facilities for this principle have bolted it on in the wrong way and we as an industry have come to accept some other feature ("public/final/private" keyword languages) to mean we have, "encapsulation," in our language.

Actually, there's an interesting talk from Uncle Bob saying exactly that: https://www.youtube.com/watch?v=TMuno5RZNeE&t=2325

The idea is that public/private/protected is an attempt to restore some of the "perfect" encapsulation we had with C; and that we lost this encapsulation with OO langages.