addicted44

India's is an extremely price conscious market.

Companies that raise prices by doing that will be beaten by companies that don't very quickly. Alternatively, combined with the much weaker law enforcement, "illegal" (I'm not sure about the legality of cracking copy protections here) copies will flourish if it's close to being feasible, which it could be.

India also has extremely high interest rates.

So there is a benefit in converting fixed upfront capital costs into rolling operational costs.

In most developed countries consumers can convert those upfront costs easily and cheaply through loans. In a country like India, loans are much more expensive.

Think of it like using cloud services instead of buying an upfront machine.

Uber/Lyft drivers don't badmouth it.

Would you if some random person, who for all you know could be an Uber/Lyft employee, and even if not, is someone who uses Uber/Lyft and therefore is likely happy with it, asks you a question about it?

What?

He's obviously talking about the person in different contexts.

The person is a friend to them, but they are also a someone, and for Apple they are a customer.

You're telling me Apple doesn't have a conflict of interest policy?

That sounds strange.

So the Geniuses at the Genius bar can basically openly tell people that they can go to the other shop they work at across the door and they will do the repair at half the price? And Apple will have no policy against that?

Servo wasn't even the main engine.

Considering their main revenue sources will likely be decimated, it makes sense to focus resources on the primary browser engine, and allow the open source community to build out the experimental features, moving temporary resources there as needed.

The thing with Open Source is that even if Mozilla Corp goes under, all of us can continue building out Firefox like a regular open source project. Or the Linux foundation could pick it up, etc.

That's literally how Firefox was created in the first place, as an open source continuation of the Netscape browser.

Using Firefox will lead to improvements that will persist even beyond Mozilla Corp. In the meanwhile, Mozilla Corp can be looked at as an experiment to commercially and profitably develop Firefox, which, if it fails, will require us to switch to the non commercial models that are driving several other open source projects.

:term is new with Vim 8 I believe.

The Vim author was against adding :term but their hand was forced by the success of neovim from what I understand.

If the article is worthless the issue isn't with the author who has written it and posted it.

The issue is with HNers who have promoted it and highlighted it.

Couldn't that also be because Firefox has a higher percentage of expert users than Chrome, which has pretty much become the default browser, would.

Hash maps also don't (usually) have external effects.

There arent many hash map methods that will actually modify the data.

Standard OOP, on the other hand, seems to encourage such behavior. So, for example, a Company object could contain a bunch of Department objects, each of which contained a bunch of Employee objects.

These people objects could also be referenced in areas outside of the company object.

If I called a company.giveFinanceDepartmentARaiseInDollars(10000) function on the Company object, it would have an unpredictable impact on the Department/Employee objects. It may also have cascading effects in other parts of the application that may not be clear.

On the other hand, if you represented this as a company hashmap, with the keys the department structs, you would have to do something like the following instead:

company["finance"].employees.forEach(x => x.salary = x.salary + 10000); company["finance"].base_salary = company["finance"].base_salary 10000

This contrived example shows some of the pros/cons. OOP allows us to hide a lot of behavior/changes, which may mean less repetitive code. OTOH, it hides a lot of behavior/changes.

Eventually data has to be bound to code. Otherwise you'd have apps where you either have functional code running and other apps that are displays of raw data.

The engineering question is what layer is it appropriate to do so. Under traditional OOP (your pre functional forward Java/C#/OOP C++), the answer was that code is almost always bound to data.

Haskell style functional programming binds code to data at the last moment possible.

The best answer is likely somewhere in the middle, depending on your application and usage. I find, for example, that UI controls work well with OOP, but most other stuff I tend to default to functional style programming.

I was fortunate in that I moved my team to Teams (I still find the name terrible) well before MS put a mandate out.

So our folks were comfortable once the MS EOL statement came out and the company started moving everyone over. Everyone else had quite a bit of a struggle for a week or so though.

On the plus side, I think there were very few complaints after a couple of weeks. Which probably had a lot more to do with how bad Skype for Business was (much worse than Lync) than how good Teams was (it was still fairly unpolished at the time...it's much better now...MS has been adding features and fixing issues rapidly).

I wasn't intending on disputing your statement but merely adding to it. Apologies if it came across that way.

Assuming the reporter is internal, you don't need them to go ahead and type out everything. A quick call with a screen share is all that's needed.

Not even reaching out (again, assuming they are internal...if they are external then there are many other considerations) is just not smart IMO.

If the reporter hasn't provided enough information to recreate the issue (it's obviously not a major deal breaking issue otherwise it would be obvious and easy to recreate) and they are internal to the company, tell them to provide more information before moving forward.

The author's approach is good for external bug reports, but they don't clarify that's indeed the case here.

I have to strongly appreciate the author for finding the root cause and tackling that instead of the symptom.

So often, especially in front end coding, you will see an exception being thrown because of a null value being passed in, and the "fix" checked in by the developer basically returns the default value if null is passed in, when they should be investigating and fixing why a null was passed into the function in the first place.

If your function has a contract that forbids nulls from You resolve the immediate bug, but this almost certainly leads to multiple bugs being created in the future (or worse, something that is quietly wrong, because 1 row in a 100 row table is missing and no one noticed) until the root issue is resolved.