r2dnb

You may disagree but saying that it doesn't make sense is quite a stretch. I will nonetheless address your points :

1) Throttling is addressed by decentralizing the web with technologies such as Web Torrent. If every user is a seeder, there is not much the ISP can do. At the same time, the reason tech giants may not be happy with this approach can be understood, but then it is their choice and ISPs should not be blamed. Once this category of heavy traffic is out of the way, with regards to FQDNs if the traffic is lightweight, then throttling wouldn't make anysense. My guess also is that discriminating based on FQDNs provided lightweight packets would be blatantly anti-competitive. It would be similar to denying access based on race. Also, keep in mind that the only thing ISPs are saying is that companies driving more traffic (namely streaming companies) should pay more. So the chinese-like firewall you described is highly unlikely.

2) Too slowly, you can't make a product based on any of the disruptive features as of today. Support is barely existing and not mature enough. If they really wanted it, it would already be done because while the modern web is progressing slowly, these companies manage to iterate much more complex features on their other products. For example, while we've been struggling with the shitty Internet Explorer, Microsoft managed to literally roll out their very complex enterprise cloud business and scale it from zero to a multi-billion dollars segment. This and the .NET Core stuff. Similar things can be said of Apple and Google. Let's be real. In 2017, we should be at the stage where all the backbones are long done and they are rolling out their implementations of the bluetooth spec.

3) Prices may go up on Netflix, but they'll go down on comcasttube.com (if the service is not outright included in the ISP subscription price). Then they'll go down again on Netflix. Regarding the point on the richness of the web, this is not the way I think it will pan out for the reasons I explained. And part of my point was that, with this regard, tech giants getting real with the modern web has much more to do with it than NN, despite the rational currently being pushed by the valley.

From my perspective, the positive to this is that it will incentivize tech giants to accelerate the development of the web platform (WebRTC, WebGL, Web Assembly, Web Torrent and the like) as stuffing everything in HTTP and using encryption will protect them from the dirty blocking of services, and will allow them to focus their efforts on fighting throttling. For this reason, I hope Comcast and others will scare the hell out of them and do some big time media-covered dirty throttling.

I can already see for-a-better-web.org where Apple, Microsoft, Google and others explain why they have finally decided to move their ass and get serious about implementing the modern web in their browsers. With their level of funding, the time all of this is taking is ridiculous. When Netflix and YouTube get their first bill from tier 1 providers, Web Torrent and libtorrent will receive a pull request within a week and chrome will be patched overnight.

I do not think that the small guy will be hit by these rules, mostly because I think that by the time it comes to that, politics will have changed. The end result will be that everybody will benefit. Implementing the modern web seriously is the one thing that web giants can do to protect themselves, as it would enable a fully decentralized web. The difference between that and NN is that the modern web would actually help the small guy by making it easy to for example start a decentralized YouTube. So it's easier to cry fool on NN, and look like you're concerned about the small guy when in reality you too are concerned about protecting your interests in the most convenient way possible.

Not saying all of this is a conspiracy, just saying tech companies are far from being disarmed, they also have their monopolies they want to protect. Keep it in mind before crying over this vote, or spending money and time on volunteering. Let Tier 1 dudes give them the hardest time of their life and watch. If it gets to hitting the average Joe, do something but my take is it won't have the time to get to that.

>Architectural offices that still use cad

Out of curiosity, what is the modern alternative to CAD used by architectural offices ?

> They force an idea in the mind to become concrete and logically digestible to other members of the party.

You make a very valid point, what I was highlighting is that good communication can be achieved without whiteboards too.

I understand your underlying argument that whiteboards may constitute the best technology, but I also think there is a tacit convention at play here. People tacitly agree to communicate in a way that make whiteboards work. For there are many effective and fluid ways to iterate on ideas that do not involve live drawings or complex tech.

I know it for a fact as drawing my thoughts on a whiteboard has always been counter-natural to me. I can do it but I wouldn't say that it is necessary for good communication. It is just a communication choice that people make.

Everything that can be drawn clearly can also be written clearly (analogies, bullet point lists for flows, etc...). Not to say that diagrams are never helpful, but it may be a stretch to assume that drawings and whiteboards have an almost essential role.

While I have nothing against MBAs, this is a typical example of what people call MBAish / corporate BS and why managerial profiles have gained a bad reputation here. It looks smart on the surface but scrutiny exposes non-sense.

>Conversations around whiteboards between stakeholders creates value.

Why ? Are whiteboards magic ?

>Pair programming makes for lower defects and more reliable scheduling

Putting aside the fact that the benefits of pair programming as less consensual than what you seem to suggest, it can be done much more conveniently in a remote setup with a screenshare and a headset than by sharing a desk.

>Software is a design delivery operation.

So ?

>There was recent article on MS office space redesign to create more value.

Here we have the business case reference, always good to include one. The substantial remark is that once again this doesn't prove anything, the first reason being that "value" is extremely vague.

>Productivity is not per-keystroke

The art of looking like you are siding with the people you want to control while it is actually the opposite. If we go the bottom of the reasoning : value is not per keystroke, we therefore need to put employees in a room because their true value must be monitored to be appreciated. "Please understand, I really want to be able to appreciate your true value". Sounds a bit hypocrite to me.

>Personal productivity is almost a misnomer

One more slogan.

>I have been paid extra to kill projects that never should have started.

While I am the first to advocate careful planning and writing code last, as an entrepreneur, I consider it a crime to sabotage projects, because anyone who has ever created something, or started a project or a venture understands that creativity is almost Holy. Beyond the technical deliverables, projects trigger group (and market) dynamics and institutional learning that may be hard to reproduce later in time. For this reason, doers do not sabotage or kill projects, they rectify them. Sure there can be pure follies that need to be stopped ASAP to stop diverting valuable resources of the company, but my overall impression is that you have a more liberal approach to assessing what must be killed.

I respect arguments from both sides, but this comment is really representative of the crap filling most companies.

Not taking side on the issue but this article sort of misses the point. The first half of it is focused on demonstrating that unlike packaged goods, producing electricity does not result in packages needing to be put in the trash which is a fact nobody ever challenged to the best of my knowledge. I never even heard of this interpretation of the waste criticism. But the author goes on and opens the Webster's dictionary at the "Wasteful" page to continue his argument.

The other half is an augmentation of the line that the electricity used for mining is actually used by the mining computer, and very little of it evaporates as heat. Moreover heat inefficiencies are not intended by miners. As a result mining is as legitimate as any other business activity and mining bitcoins should not be considered a waste of energy. While in this case an opponent may possibly exist, I am left unconvinced by this demonstration.

The real discussion is that as of today, the raw materials required to produce electricity are in limited supply and in decreasing amount. Provided this limited supply and this decreasing amount, a structural increase on the demand will result in a pressure on price which may have a negative impact on society and the economy. An other concern is that as of today, efforts are made to decrease energy consumption because energy production has a negative impact on environment with the current state of the art technologies. The waste discussion comes from the fact that the energy footprint of the bitcoin network may seem unnecessary to some since alternatives exist to transfer value.

The author fails to consider the issue from the other side of the table and does not even know who or what he argues against. He misunderstands what the opposing view is. Throughout the article a lot of energy is spent defending positions that nobody ever challenged and this for sure is a waste.

Just to represent the people who like me will not be able to invest time considering your tech until pricing is available.

The pricing of the infrastructure has the potential to literally poison a product.

Just adding this since nginx proponents seem to be over-represented in threads these days :

- I too find that the Apache documentation is much better than the nginx one

- I also prefer the Apache License over the open-core, pay-a-license-for-more-feature model of Nginx.

- Then the module system of Apache is simply stable, proven, and seamless.

I'd go with Apache any time of the day as far as HTTP servers are concerned. I have nothing against Nginx per se, but I think that the Apache is dying / Apache is obsolete rhetoric is so far away from truth and exaggerated that it is almost becoming some sort of propaganda.

Apache is doing just fine and is going nowhere anytime soon and its configuration file format is not that complicate. Just try it for yourself and read the (well-written) docs.

Many thanks jorgeleo ! I wasn't clear on how FP handles complexity management and the unknown. You've beautifully connected the dots and helped me shift my thinking, this is all clear now.

In particular your demonstration was very convincing from a DDD perspective. I can see that FP is not less natural than OOP for domain modelling while it approaches things from a very different angle. However FP brings to the table rich domain semantics, high correctness guarantees, and I feel productivity gains too. And with the mindset you've presented, it is also clear that the unknown seems to be accounted for in FP too. As an architect, this last point was the grey area and the deal breaker for me. However now I see no reason not to invest in heavily leveraging FP moving forward. Thanks again jorgeleo.

Many thanks for taking the time to explain this, I can see that you have a point.

>Or you can focus on the meaning of the words, then you need just a few types, see how those meanings compound, and go from there.

>I agree, FP is bad at extending things... but it is not FP fault that you see the world as things that need to be extended.

I should probably give another look to FP and continue to study the subject, I have likely been approaching it with a OOP mindset as you suggest. One last question though, what about code duplication ? If you focus on the meaning of words and compounding these meanings to create new things, wouldn't it most of the time create lot of duplicate code ? For example in the case of the local shop and the supermarket, wouldn't you have two functions (or a switch case) containing exactly the same code to calculate the quantity multiplied by the price of the groceries ? One would take a local shop as parameter, and the other one would take a supermarket.

Splitting the sale processing function in two parts - one summing up the groceries and the other one calculating the taxes - so that you can reuse the first function implies knowing in advance the existence of the supermarket structure (which you will only know many years after putting your product in production). Not doing it in advance either means duplicate code or refactoring every time you add an operation. The extension mindset initially comes from the need to avoid code duplication which is known to make maintenance difficult.

Now maybe the strongly-typed experience of FP and its compile-time checks are so convenient in practice that they make the maintenance of this kind of code easily manageable ? Maybe it's not even really duplicate code since what would be a basic number in OOP would be two different types here in FP ? Or maybe it's still thinking about FP from an OOP perspective ?

Thanks for the reference, this is indeed all about it. The solutions mentioned are unnatural patches to the respective shortcomings of FP and OOP. It's ok to patch corner cases to complete the last 15% of a job for which the tool was a perfect fit for the first 85%, however the first patch should be to use the right tool for the right job.

The functional and strongly typed value proposition of FP is very appealing on paper but only shines when you have a level of certainty and knowledge on requirements that you typically do not have in real world software development. OOP by design embraces this uncertainty (but as a trade off is less assertive on correctness than FP).

That being said, certain businesses do not have a high level of uncertainty in their developments while correctness is a big deal for them (banks, scientific researchers, etc...). It makes sense for them to reinvest this slack in correctness. However, for those iterating consumer facing products (which represents the majority of developments), OOP modelling usually is the way to go. Because of the expression problem (which should probably be called the expression dilemma to better highlight the fact that the assessment should be continuous and situational rather than ideological and/or philosophical)