__sr__

I think it’s iOS/Android only — which is a pity because a lot of people still prefer a laptop/desktop — although it works well enough for me.

https://get.google.com/trips/

https://itunes.apple.com/us/app/google-trips-plan-your-trip/...

https://play.google.com/store/apps/details?id=com.google.and...

Try Google Trips

Wow! I haven’t used regular Gmail in years! It will be a pain to switch back. The whole bundling, scheduling, snoozing, pinning, reminders etc are really useful.

But then it’s Google. The key people probably got bored and moved on and perhaps no one else is willing to take it up. At least they didn’t make 10 different email products like they did with IM.

Any suggestions for alternative email clients for iOS/Android (other than Gmail app) which works well with Gmail? The iOS client doesn’t work well with Gmail. I’m looking for something which has as many as possible features from Inbox and doesn’t mess up my inbox — i.e. no Mail Pilot.

It was Alan Kay, actually.

They probably don’t have a lot of users who install and use the Dropbox client on a server machine.

Err... I can’t imagine a scenario where one would want to use OneDrive/Dropbox to sync git repositories. It’s like having your local Dropbox folder inside your local OneDrive folder — only a lot worse.

> For any kind of app targeting westen world (meaning - it's not localised into Hindi, African and Chinese languages), the market share of Lollipop will be below 20%.

Where exactly are you getting this data from? Please do not put random numbers without citing sources.

> In my experience, the fact that I can navigate a file without taking my hands off the home row far outweighs any disadvantages hjkl might have.

In my experience, most (if not all) of the people who use Vim or Emacs are programmers — and I am including sysadmins etc. in the wide category of programmers — and a programmer typically spends far more time thinking about what to type than the actual typing[1]. So I don’t see how the speed of typing is synonymous with productivity.

[1] Unless it’s a Java programmer — they spend most of their time typing — just kidding.

Exactly — this.

There is a major difference between what Microsoft was doing back in 90s and what Apple is doing today.

Or 1996.

The horror! Fill gazillions of forms in triplicate and get them approved before we’d let you do anything useful.

And my point is — how do you, as a startup founder, judge whether .NET — or any other platform, for that matter — increases your developers’ productivity by N percent? You certainly don’t have the time or resources to build the MVP on every major platform and measure. More often than not, startups go with whatever their first few developers are comfortable with.

And, once you have started with Java/Python, why would you want to spend your money on licensing costs AND .NET developers who, from personal experience, often tend to be more expensive and harder to hire than Java/Python/Go developers?

Licensing costs don’t matter a lot if you already have a team that is proficient in .NET. It’s a Catch-22 situation. Why would want to spend money on building a team of .NET developers in the first place unless you have some hard evidence that using .NET is going to help your business significantly?

Do not forget — Microsoft licence costs also increase with the number of CPU cores in your server.

In addition to costs themselves, Microsoft licensing is a highly complex topic. One of my colleagues who deals with Microsoft jokes that someone well versed with MS licensing deserves a PhD. A lot of people simply don’t want to deal with all that when they have a thousand other things to worry about.

> If I can get my engineers 3% more efficient at the cost of making my hosting 30% more expensive I will do this in a heartbeat.

How do you quantify engineers’ productivity? A Java or a Python developer (much easier to find than a .NET developer) will be a lot more productive in Java or Python. And it is not a universal fact that .NET developers are more productive than others. Python developers would argue the other way round.

> Is that...bad?

For Microsoft and .NET community — yes.

A lot of organisations prohibit sharing internal practices — or at least make the process really hard by requiring multiple approvals.

Happy to help!

Disclaimer: I am not associated with Zulip in any way.

There is also Zulip (https://zulipchat.com)

Setup an old faishoned IRC server?

Wait, if Huawei Partner acquired the company, doesn’t it mean they got the rights to its IP? Isn’t that often the sole point of acquision?

Or did I misread something?

So how exactly were they doing their job? Didn’t their manager have anything to say about the non-delivery of the project?

> You can't create additional instances of module-level state. For example, if your app server uses a module-level global for the server listening socket, you can't run two app server instances in the same process.

So a global variable should not be used for such cases. That doesn’t mean it is inherently bad. People writing the code are supposed to think about what constructs to use for a given scenario.

Agreed, and module globals shouldn’t be used for such cases. But for simpler cases, it may, in some cases, be better to use globals than create a singleton or some other convoluted solution.

To be clear, I am not saying globals should be used everywhere. There are a programming construct just like any other. When used carefully, they can greatly simplify code — but also have the potential to horribly complicate the code when abused. And that is true about any programming construct.

One thing that irritates me is the tendency to paint things black and white — eg. goto, globals, multiple inheritance etc. are bad. So “modern” programming languages try to eliminate them in a misguided attempt to keep programmers safe from themselves. I agree that these things are often misused, but a bad programmer will figure out a way to misuse anything — or do you think it is impossible to write bad code in something like, say, Go? Dumbing things down doesn’t prevent bad programmers from messing up, instead it causes the rest to write horrible code because of the lost power.

> For most people H1B = cheap, which is grossly incorrect

>> In any case, treating the two categories as one is probably not a great idea.

That is exactly what I said.

> The H-1Bs however, in my experience, don't. Why might that be?

That is strange. In my experience, H1Bs are let go as quickly as natives if they are not competent. Of course, it could simply be a matter of the type of companies we have worked with. Again, see my (longer) response to the OP. I have mostly worked with Type 1 people I described there and have been fortunate enough to mostly avoid the Type 2. That said, I’ve worked with both extremes.

EDIT: When I say I’ve worked with both the extremes, I mean I have worked with both highly skilled and totally incompetent foreigners as well as natives.

EDIT 2: I’ve also worked with a third category — highly intelligent people (PhD level) who are more interested in spreading their intelligence (i.e. showing off) than getting actual work done. Unfortunately, I haven’t met the other extreme in this case. :-)

I am not saying that python globals are a great idea — just that they are not as horrible as they are in case of C and they they do have their uses — they just need to be used carefully. Of course, python makes it impossible to truly hide anything. In an ideal world, module level globals won’t be mutable outside the module.

> Mutable instance variables are much less bad because their scope is much more limited: you can much more easily scan all the code that mutates them and check that invariants are upheld etc.

Same can be done with module level globals.

That was meant as a joke.

While I agree that there are many incompetent people who have abused H1B and other such systems, I prefer to judge people on their individual merits and avoid stereotyping. I have worked with both the extremes.

See my longer response to the OP

Well, there have been cases where I was asked to get rid of them by people reviewing my code — for no reason other than that global variables are “considered harmful”.

Are they really? I agree that global variables are horrible in a language like C where they are truly “global” because of the lack of namespaces. But in a language like Python, they are tolerable because they are not truly global — they are restricted to the particular module. I am not saying they are great, but they are not as horrible as they are in, say, C. Of course, care must be taken to ensure that they are abused, but that is true of any programming construct.

If module global variables are considered truly horrible, the same can be said about instance variables inside classes. They are as good (or bad) as module globals in the sense that they represent shared state and can potentially be mutated by any method/member function in the class.

Of course the functional programmers among us will say that shared state of any kind is bad, and I agree. But we are not talking about that here, are we?