lake99

> as light as in the day

It's got nothing to do with intensity, which would be impossible to achieve, for all practical purposes. The article misused the word here. Rather, it's about color temperature.

I think this problem is overblown, because I've not heard similar complaints leveled against mercury-vapour lamps. I've grown up around them nearly all my life.

Not partirarchal, rather, it's about near-deification of elders, which includes the mother-in-law. Paternalistic attitudes pervade village life, and to some extent, the lives of most Indians. For example, among quite a few girls/women I know, menstrual restrictions are enforced by the grandmother, their grandfathers are dead, and the parents relax the restrictions a bit when the grandmother is out of town.

No, the US healthcare is in serious trouble. My point was about a line of approach for the problem. In fact, India can give a few good pointers here, which you can see from how little I pay for my own, rather excellent, healthcare.

Indian healthcare has its own can of worms, but since we are not talking about that, I won't open it.

Nah, this will go the way of Microsoft Tay and Facebook's automated curation. 4chan will run the system to generate jokes for themselves, until Google finally kills it.

I don't think we can generalize from Wikipedia lists for complex issues when the lists contain very diverse countries. I have spent some time in Europe and in India. I have a couple of chronic conditions that requires daily medications. One of those conditions have generics available worldwide, the other one does not. My medication costed 5 times my montly European insurance premium in Europe. In India, insurance providers don't cover much beyond hospitalization and cancer. In India, the same non-generic medicine used to cost me about half of my European insurance cost, but I had to foot the bill myself. Now, there are generics of that available here, and I pay about one fifth of my European insurance premium for a month's worth of medication. I have to pay for doctors' visits off-pocket too, and the specialists I visit charge me about 3€ per visit. If I visit a local GP, they'd charge me about 1.5€ per visit. I pay for tests out-of-pocket too, but most of them cost in the range of single-euro-digit per test. Sorry about being vague, I don't want to give away too much about myself.

Looking at per capita healthcare costs in India would be pointless, as the vast majority of people go without proper healthcare.

I probably am. I spent some time in northern Europe, where the temperature would go as low as -25°C, around the time I stayed. I was loath to deglove my barely warm hands, and used my nose instead, for some basic operations.

Actually, this is something that can get replaced overnight, were it not for the serious lack of manpower. Most people use Gnome or KDE. They will continue to do so when their distros quitely replace X11 with Wayland, overnight. Except that Gnome/Wayland has some features still unimplemented, and KDE/Wayland is awfully unstable.

I mean, this is more of a upstream-domain issue than a user-domain issue.

I agree with all you have written, but there is a way to zoom in or out without using your other hand: use your lips. "Muaa" zooms out, and "auum" zooms in. This will make public transport journeys more interesting (for the others).

Hit the directions button. You see two text fields, with the first one already filled out as "Your location". Change that. Enter the destination next.

This was on Android. Is your UX any different?

The phrase "middle class" is misleading here[1]. If you are talking about people with IT industry jobs, they certainly have enough disposable income to spend on flights or cars. Even lower income migrants travel home for major holidays, much like the author herself did when she was young.

[1] http://qz.com/578793/indias-middle-class-is-almost-impossibl...

> authoritatively declaring it to have 'vanished', has not vanished by a long shot.

I agree with you completely. Indians are quite guilty of giving really weird ideas of India to outsiders. I mean, the culture is vastly different from western culture, as it is, but adding a thick layer of nostalgia or romanticism will only make their expectations more fantastical.

> Being in a train without air conditioning...

I can almost guarantee that if you're traveling in a non-AC compartment in India, the windows stay open. People only close them before sleeping at night, because when trains invariably stop at its scheduled stations, the passengers don't want to run the risk of thieves grabbing valuables through windows.

There are some smells of certain cuisines that I absolutely detest (fish curry, garlic, etc.) but I can't recall ever being bothered by the smell of food in these compartments. I can recall being bothered by the smell of diesel fumes if the car happened to be close to the front. What drove me quite mad was this, "all culminating in a boisterous game of cards or round of antakshari". Ear plugs don't help much.

I lost track of this discussion!

> If you use an "int", you have specified that it must be at least 16-bits wide.

Few people write code for PCs with the assumption that an int could be 16-bits wide. They all assume that it's going to be 32-bits at least. A generic "int" encourages bad assumptions. Then come beasts like "long" or "long long", and people must pull out compiler manuals, talk on support forums, and so on. A developer is obliged to do that, but system integrators and cross-team reviewers are in for a world of pain if they have to keep reading across code bases across platforms like that. It's not an unrealistic scenario. A modern airplane or electric train is bound to have tens of processor families littered throughout the vehicle.

The original commenter also wrote about Swift going backwards, with its UInt8, Int32, etc. I'm not a Swift programer, but the documents gave me the impression that these are, again, syntactic widths, not physically allocated, i.e. semantic widths. All this shows that the original commenter had a problem with specifing any indication of the size of integers. His emphasis on "word-sized" clearly indicates that he wants to use "int" everywhere, and hopes the compiler will take care of the rest. This is what Swift does too with its "Int".

Some people extoll the virtues of long-form writing. But even a site like HN is far too information dense to spend so much time reading one article. It's a different matter when we're learning something of an academic nature, of course. That's why I love summaries such as yours.

Yeah, brushing teeth at night, with some caffeine may not be a bright idea.

Not to mention, they employ many stalwarts of CS, like Simon Peyton Jones and Leslie Lamport.

> As I've said - I don't really care what things are called.

I think this is where our disagreement lies. To me, this counts as "make a decision as to the width of an integer every time I declare a function". We are deciding the lower bound, but still, it's a decision on that matter.

> Semantically, there is very little that is different between "uint_least16_t" and "unsigned short".

But there could be a difference between "uint_least16_t" and "unsigned int" or "unsigned short". And there could be a difference between "uint_least32_t" and "unsigned int" or "unsigned long".

> But your solution also doesn't involve deciding on the width of an integer - your solution is to use integers that have a minimum width.

We declare the minimum width for all variables. We don't use "int" in for loops and hope for the best. I wouldn't go as far as to say "we don't care". We don't worry too much for code that's mean to be portable. We obviously care in non-portable code. But the important point here is that we use the same conventions whether we are writing portable code or not.

> So from this, it sounded like you were talking about fixed width types.

C99 conventions are too radically new to be used across our entire codebase. Uglyness has nothing to do with it. The only way to ensure fixed widths without int_leastX conventions is to be intimately familiar with the platform while we are declaring our typedefs, or creating makefiles for our projects. And to that extent, we use only fixed with types.

> If that is the case, then it sounds like this whole thread has been miscommunication :-)

I am not sure about that. The original poster wrote 'I have never once thought: "You know what, I'd like to make a decision as to the width of an integer every time I declare a function."' I disagreed with that, and that's where the whole discussion started off. And I still advocate using the smallest (explicitly sized) type you could get away with. Weren't you advocating using bare C types (unsigned char, short, long, etc.) for your variables all along?

These are good, but some of our codebases predate these conventions. We don't even use // for commenting, because the code could find its way to a compiler that can't handle C99. Secondly, the overriding principle here is that the massive company, despite dealing with a huge variety of architectures, has to speak one language.

If I were to start a company today in a similar domain, and not have a legacy to deal with, I would mandate uint_{least,fast}{8,16,32,64}_t and such.

This miscommunication was my fault. We don't use uint8_t or other such things, we use uint8, uint16, etc. These are typedefed to compiler-specific types that guarantee a required minimum size. This is also the reason we are not allowed to do arithmetic on chars. The types we use may eventually get typedefed to a char, but at least when I see someone else's function that requires a char as opposed to uint8, I know he's dealing with actual characters.

> then you have to do all the reasoning as if the type is of an unknown width

Well, no. If we are writing portable math routines for such types, it gives us nice ranges for which the code should behave with correct answers or should throw red flags during unit testing.

I did not expect you'd say "char", because it's a fixed size numeric type. Isn't that what you have been arguing against so far? Anyway, I'd get yelled at if I checked in code where I do math on char. It has to be on uint8 or int8 (or other widths). Not that I'd ever check in such code, after all, I agree with the company policy there. But "char" is just a part of the problem. We have the same issue with all kinds of bid-widths. When I read PC code with such names, I don't worry about their sizes, and just assume i386 conventions. When I read embedded C code with datatypes of undeclared widths, I get quite annoyed. Thankfully, I can't recall the last time I read such code.

> then uint_least32_t should make you happy

The thing is, I assume all uintX types to really mean at least X bits wide. I am aware that the compiler is free to use its discretion for allocating memory. I worry about finer details only when I need to.

> Take some correct code that works with int16_t, and replace the "int16_t" with plain "int". What breaks?

Memory. Defaulting to 16-bits when an 8-bit variable will do can be incredibly wasteful on an 8-bit µC. Keep in mind that we are not just talking about one variable in isolation. We are talking about all the integers we pass between functions. We are talking about code space, data space, and stack space. There are compilers that can optimize their arithmetic operations to 8-bit registers when they can be sure that that's all their operands need.

> Would you suggest a uint29_t?

If you are aware of a machine that provides that, yes! Otherwise, I'd suggest uint32_t. Yes, "long" is guranteed to be 32-bits wide, but it can also be 64-bits wide. I would not recommend defaulting to "long", as that could be wasteful. Here's an interesting discussion about the meaning of "long" and "long long" for their compiler: https://www.dsprelated.com/showthread/comp.dsp/42108-1.php. I see this discussion as a failure of the C standard.

I would much rather the compiler provided int64_t or int40_t or whatever else they can, that is not inefficient.

You can only check for overflows if you err in favour of larger architectures and declare all integers as "long int", and then check for overflows. Even the 8-bit compilers I have seen will allocate 32-bits for long int. And doing that will let the code remain compatible on smaller architectures, but it will hammer your CPU and memory usage. It's not a pleasant situation when you're struggling to save bytes.

> How do you port it to a machine without a 16-bit type?

The problem is made more severe when you use "int" and let the compiler decide the size of the variable. I guess I don't know what you're advocating.

> The stuff about communicating with the outside world is quite different.

I meant communicating as a throwaway example. It's a valid example, but really, everything gets affected. For example, a CAN identifier is 29 bits. What generic "int" would you use when you want to fill in this identifier? And no, I work at a level that's lower than an ABI. So, no OS, no file IO, etc.

Looks like you haven't worked on embedded systems. We need to be very careful with sizes of ints here. Not just because we run the risk of overflows, but also because when we create code that may have to be ported from one architecture to another, we want to minimize re-work.

> Notice how smooth the 32-bit to 64-bit transition went?

There are many reasons for that. For most PC work, a 32-bit int is more than large enough. Going to 64-bit should not have affected that at all. When you're working with embedded systems, you're often working at sizes that are the bare minimum that you can live with. You might also get to work on architectures where char, short, and int are all 32-bit wide. Assume something, and the communications protocol stops working. Moreover, the PC architecture itself supported coexistence of 32-bit and 64-bit executables.

No, I don't think you can fix the 'remember choice' feature. Practically all apps ask me for that when I click on a domain I haven't clicked on before. 'Remember' will only remember the choice for that domain.

I have five privacy tools on this browser: uBlock Origin, Privacy Badger, HTTPS Everywhere, NoScript, and a free VPN. It was quite tedious to go through each of them before I figured out it was an HTTPS issue.

For me, it was HTTPS Everywhere that was causing the problem. Disabling it showed me the pictures.

The mods can do it. I once left a comment about changing the link. They saw it and changed it on their own. I don't know how to notify them though.