Hacker Newsnew | past | comments | ask | show | jobs | submit | Sankozi's commentslogin

Almost nobody is using the word market as you are in your comment.

RC of course is inhibitor. It lowers value of the house, which lowers builder's profit, which lowers number of new investments.

Unless builders aren't building for profit.

Create an entity with a mandate to build and the funds to make it solvent. Basic and dignified shelter that enables all the other economic activity does not need to be a profit center.


This is possible but requires lots of money and oversight. I have never heard about scheme like that that replaced private investors. But as a way to offset some RC problems it could probably work.

A whisper on the wind, barely perceptible, it tickles your ear. "Singapore~ (also the UK before the Iron Lady messed things up)."

Of course demand is elastic.

Do you think, people will migrate to a city with an unaffordable housing (unaffordable for them)?

Unless you are living in North Korea, the competition is also there.


No, it is inelastic:

- inelastic means the demand is more or less independet of the price; you can't "just stop renting & living" if prices are going up, your options to bypass are highly limited -> therefore its called >inelastic<


You can "just stop renting" and move somewhere else.

Housing demand is less elastic than, let's say, potato demand, but it's not "absolutely inelastic" as you have said.


Good transit and road infrastructure also both make demand more elastic because the choice of where you can live without changing jobs expands.

In MBA101-bobos world this is true in theroy, in practice its not. (let me guess: You do not have children, yet, right?)

Thats always the biggest difference:

In theory, there is no difference between practive and theory - but in practice, there is ;-)


We are not talking about economic theory. We are talking about house prices. Time after time it has been seen that free-enough market can lower the prices to affordable levels.

Fair, but the thread has evolved into a discussion on the theory. We are definitely in the territory of theory when the invisible hand is mentioned.

I took "invisible hand" as a joke. The one with pattern : either (fairies/magic/invisible hand) or (sensible argument/observation here).

So such issues can appear in more products and more datatypes (int and bigint have same problem).

This is really bad rule for SQL's "equality" operator.

Still optimizer should be able to handle it - if the result is the same, optimizer should take faster path.


Emitting correct XHTML was not that hard. The biggest problem was that browsers supported plugins that could corrupt whole page. If you created XHTML webpage you had to handle bug reports caused by poorly written plugins.


I have opposite experience. Consistency is commonly enforced in bigger corporations while it's value is not that high (often negative). Lots of strategies/patterns promoted and blindly followed without a brief reflection that maybe this is a bad solution for certain problems. TDD, onion/hexagonal architecture, SPA, React, etc.


"In large codebases, consistency is more important than “good design”" - this is completely opposite from my experience. There is some value in consistency within single module but consistency in a large codebase is a big mistake (unless in extremely rare case that code base consists entirely of very similar modules).

Modules with different requirements should not have single consistent codebase. Testing strategy, application architecture, even naming should be different across different modules.


People using it wrong. It definitely should not be that popular. 95% of times when I see it I consider it a tech debt.

You should be using it in rare cases when you want to verify very complex code that needs to be working with strict requirements (like calling order is specified, or some calls cannot be made during execution of the method).

Usually it is used for pointless unit tests of simple intermediary layers to test if call is delegated correctly to deeper layer. Those tests usually have negative value (they test very little but make any modification much harder).


In the same post you are arguing for and against "slippery slope".

Either it is possible to easy change law to make it worse ("slippery slope" is valid objection) or changing law is "much harder than doing nothing"("slippery slope" is a fallacy).


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: