skysight-inc/HackerNews huggingface dataset:
I mean, they can be, they just aren't now. For it to be common, it has to fit more people's use cases. Clearly, that's more likely to happen in somewhere like NYC than in Memphis, but I would think that most people, even people inclined to use bikes like that, would use it only on shopping days, and a more traditional two-wheeler for their commute.

As for other hypothetical reasons they are not normal now (hypothetical because I know very little about NL / BE / wherever):

* Are people in those places using them for work or leisure? I suspect that if they're that common, people are using them for work in jobs like delivering market goods (e.g., similarly to how we use bike messengers, but for larger 'messages')

* I've seen them used in Netherlands for carrying children and such, while it seems that predominately, more Americans are dual income families, with children being cared for in daycare / school during the days.

As for all things that aren't "normal", there's the chicken and the egg problem. There's nothing wrong with being anormative, but right or wrong, if you're deviating from the norm, you should expect people to ask questions. If you'd like to help normalize what you're doing, then answering their questions (where possible) seems like a fine way to start. Without getting into a meta-debate about vaping, I was an early vaper because I liked the idea of saving money, and they seemed healthier than cigarettes. If your first experience to vaping is by a guy who sneers at your questions, acts better than you, and then blows huge clouds in small rooms, you're probably going to be put off to it. If your first experience is with me, who vapes outside, is usually happy to answer any questions, etc., you're less likely to be.

Obviously, no one's beholden to take time out of their day to answer other people's questions, but the vibe I got from the author was that they were stupid for asking them, that he couldn't be bothered, and that overall, he didn't seem like a pretty good ambassador to the cause.
9 mph is super fast in NYC. Here is the Mobility Report from 2016:

http://www.nyc.gov/html/dot/downloads/pdf/mobility-report-20...

A bus will be 4-6 mph, a taxi at great expense averages 8-9 mph. Sure, if you're not doing all 15 miles in city center but come in from outside, you can do moderately better than that, but for connections inside the city taking a bike is already the fastest transportation, even if you can only do 9 mph (and most people, in a flat city like NY, can do a lot more).
You don't need to visit a gym to get a workout, a set of free weights is a good (and inexpensive) way to tone up at home -- you really don't need machines. Take the money you would have spent on a gym and spend it on a periodic visit from a personal trainer.
Yep, that makes sense... problem is when something doesn't match the patterns, they just shrug and give up.
I've found the opposite approach to be more useful: elimination, selectivity, and focus.

For example:

Read only the best books, take notes on them, and absorb them fully. Book lists are good, but they tend to grow unbounded and promote anxiety. It's not difficult to get to a book list of 300-500. Once you're there, there's little reason to update it often. The focus should instead become chewing through the list you've created and periodically retreading some of the best ground you've already covered. Most people who are reading are not truly learning, and even fewer are applying. When you find a book that's valuable, expending the additional time and effort to fully incorporate its content and lessons pays tremendous dividends. The best books should be given a chance to fundamentally change how you think. That doesn't happen on a first-pass read.

Aggressively cultivating a frontier of possibilities (I would call this "metaknowledge") is easy, often addictive, generally not useful, and usually detrimental to your emotional health. Most people are not short of possibilities. They're short of the focus, willpower, and grit needed to convert those possibilities into hard-won experience.
2018 IT Industry Outlook
Title should have: (2007).
Oh yes, I agree. In fact, I’m taking a close look at the architecture, organizational efficiency and results to form an opinion of the bigger picture. Indeed, I haven’t, scratch that, can’t, even assert an opinion on the article as a whole without doing so.

Then how is this productive you ask? Because for now I’m only drawing much smaller conclusions, which also generalize to most actively developed software. Rich, well maintained APIs tend to be useful. As of yet I see no real explanation of why that doesn’t apply to OSM.

To start, not sure why you mention a central server vs. “separate servers”. SaaS users shouldn’t care, or ideally even need to know whether something runs on 10 or 100 servers.

Maybe instead of separate servers, you meant different companies? Knowing which organization is the provider of each service is paramount. For each provider it’s also important to know something about their business model, reputation, roadmap, and the pros/cons of using multiple providers vs. one stop shopping. It’s important enough that companies like Gartner are paid a truckload of money by SaaS users to analyze these details.

So back to my original point: Most significant and active projects benefit from investing in rich and well maintained APIs.

Take that fact, and add in a domain expert taking the time to write an article asserting it’s indeed a problem relevant to OSM. One person’s opinion is not always a smoking gun. But combined with the fact a 10 year old stale API is so unusual, and the fact that what other companies do is a red herring argument being made, at minimum it sure seems like a bright red flag that warrants better understanding of what’s going on over there.
I'm not sure what the downvoting is for. There are verifiably a bunch of people on HN, granted probably a vocal minority, who slag Google off for a variety of reasons (plenty valid, no doubt).

The author of the article doesn't mention Google, but that's not what my comment was about: it was a (very mild) observation that there are some people, and I'm sure by no means the majority nor anywhere close, who will neg on Google and their tech, because they don't like Google.
[Thank you for reading the post! I am glad you enjoyed it]

All optimizations in the post can mostly be divided into three large groups:

1) algorithmic improvements;
2) workarounds for implementation independent, but potentially language dependent issues;
3) workarounds for V8 specific issues;

You need to think about algorithms no matter which language you write in, so we don't need to talk much about the first group. In the post it is represented by sorting improvements (sorting subsequences rather than the whole array) and by discussions of caching benefits (or lack of them there-off).

The second group is represented by a monomorphisation trick: the fact that the performance suffers due to polymorphism is not really a V8 specific issue and it is not even JS specific issue. You can apply this approach across implementations and even languages. Some languages apply it in some form for you under the hood.

The last group is represented by argument adaptation stuff.

Finally an optimization I did to mappings representation (using typed array instead of an object) is an optimization that spans all three groups. It's about understanding limitations and costs of a GCed system as whole.

Now... Why did I choose the title? That's because I think group #3 represents the issue that should and would be mostly fixed over time. While groups 1 and 2 represent universal knowledge that spans across implementations and languages.

Obviously it is up to each developer and each team to choose between spending N rigorous hours profiling and reading and thinking about their JavaScript code, or to spend N hours rewriting their stuff in a language X. What I want is:

a) that everybody was fully aware that the choice even exists;
b) language designers and implementors worked together on making this choice less and less obvious - which means working on language features and tools and reducing the need in group #3 optimizations.
That comment (which I made) explains why probably the best we can expect for wasm accessing normal JS objects is the same level of speed as a modern JS engine's "tier 1"/"baseline" JIT. But the Rust code discussed in the OP wasn't accessing JS objects, it was accessing Rust memory which lives in wasm's "linear memory", so I don't see how my comment really disagrees with what jandem or dikaiosune are saying.
Developing SaaS? Forget Scrum, Check Out Kanban and Similar Approaches
> Why is Apple submitting to all the demands of the Chinese government?

Money, and continued market dominance.
That was a really fun watch. Thanks for sharing!
So is literally every tech company working in China.

> The Chinese state relies upon private enterprise to implement social credit and extend its tentacular reach. Top-tier concerns like Alibaba’s Alipay, Tencent, Baidu, the mobility-on-demand service Didi Chuxing, and the massively popular dating site Baihe either contribute significant elements of the system’s architecture or incorporate its rulings into their services.

https://www.theatlantic.com/technology/archive/2018/02/china...

I'm not at all arguing Apple is right to do this (in a moral sense. Certainly it's right in a purely financial sense); just that it's one small part of a much broader issue.

(EDIT: removed gratuitous complaint about clickbait headline; you guys have convinced me I was wrong. As long as I'm here, though, I really do recommend reading the Atlantic link above; it does a good job showing the context in which this is happening)
Where does that specialization stop, reasonably? Isn't this the same with JavaScript? If you have worked with any Algol-derived language you can learn them all.
This is a "smart" speaker. It's going to be obsolete long before any of its components reach EOL. I'd guess it's designed for a lifespan of 2-3 years at most.
Terracotta theft: Chinese anger over stolen warrior thumb
Adderall sure does help a ton. You might not have adhd, but instead add. I can empathize with you for sure.
> it's too expensive for many people to live near where their office is

On the contrary, a major recommendation from early retirement folks is to ditch your car and instead ride a bike to save money on net:

http://www.mrmoneymustache.com/2012/05/07/what-do-you-mean-y...

You might need to change where you live to make a bike commute possible, but at least where I live (Austin, TX) I find that living close to my work and riding a bike seems isn't any more expensive than living farther away and driving. Some of my work friends complain about the cost of parking, gas, car repairs, etc., yet I make the same amount they do and I have no money problems. I don't know their precise expenses, but I get the impression that I put a lot more money into savings than they do.

I can't find it right now, but I recall a journalist once crunched the numbers for several US cities and found that living downtown without a car was about as expensive as driving in from the suburbs. You don't need to live downtown, too, saving more money. Living in a reasonably cheap area that's also close works too.

Admittedly, living close and cycling in won't work in every case. Particularly given that many if not most places in the US are very car dependent. But most people pick where they live based on their driving commute, so if one prioritizes cycling they should at least give the same consideration to a cycling commute. It's not uncommon for people to avoid particular cities because the driving commute would be bad, so when choosing where to live it should not be unusual to pick a city based on a hypothetical cycling commute. So far in my life I've been able to pick jobs and where to live such that cycling is not just possible, but desirable.

> People want to reclaim as much time as they can for living. Cars give them the ability to do that.

You can find a lot of discussion among transportation cyclists about the concept of "effective speed". Cars might high absolute speeds, but that doesn't mean you save time from using them. The effective speed is defined as the distance traveled divided by the marginal time needed to travel that distance. Most obviously you need to factor in time spent parking (usually much longer for driving than cycling). Less obvious is the amount of time you need to work to pay for the vehicle and its use. Depending on the price of gas the effective speed of driving could be a lot lower. I've seen people argue that it's slower than cycling when gas prices are high.

I've had people tell me that they'll work the same amount of time either way, so the gas price isn't really a factor. This is fair, but not relevant for me. The money I save allows me to retire earlier.
Indeed, as pointed out by the Accidental Tech podcast and others, even if the speakers hold up, what is going to kill it for longevity is the lack of a line-in. It is very unlikely that HomePod's version of AirPlay is going to be supported for more that 10 years. If the device had a line-in, it would still serve as a fine speaker beyond that. But now it is practically useless, even when you are in the Apple ecosystem, once Apple deprecates AirPlay 2.

In the meanwhile, I enjoyed the Altec Lansing speakers that my parents bought in the 70ies for quite some years.

(We were interested in the HomePod, but the lack of a line-in, and low-reparability has made the choice difficult. Added to that, I don't really like that it has so many Mics. 2025's Apple could be 2015's Lenovo, there is no guarantee that they will keep focusing on security & privacy, nor that they will resist government surveillance.)
I want them to bring one of the rovers back first. How cool would it be to see Opportunity or Curiosity at the Smithsonian.
I honestly don't know how far I am from "normal," but why do you believe there is a kind of implied sacredness even in the "normal" human condition?

Even if, for the sake of argument, we accepted all humans have trouble concentrating to the same degree, why is struggling with that a desirable goal? A lot of us get wisdom teeth, too. Am I missing out on important parts of the human experience by having them removed?
But are language enthusiasts really better hires in general? I've known many of them who loved the theory and toying with a language but were not any better at producing actual value than the average joe.
Sure! Email me at hn <at> myusername <dot> me and let's keep in touch! There are very cheap flights from Berlin to here if you're flexible. :) Cheers!
They probably call out their employer internally, know who to call directly when they find something, and so on. For stuff that isn't their own, the rules are probably very different.

At least that is how I would run something like this.
> "Hey Rust and WASM is a thing! You can make webpages with it". Ok, fine.

It is very early days. More to come...

> However, I don't see a lot of the things that are in libraries like Vue and React

Yes. There's not too many of these yet; there are some though. For example, https://github.com/DenisKolodin/yew

There's also the inverse: can we re-write parts of libraries like Vue or React in something that compiles to wasm, so that you get better performance as the user? I know of at least one major SPA framework that's doing this. Don't want to spill the beans too much, even though it is technically public knowledge.

That said, that's how I think wasm will impact the lives of most JS programmers: as technology that underpins the libraries they use to make them better. Unless you want to, or unless you want to write a high-performance library, I wouldn't expect wasm to really change the way most JS programmers operate. It's abut augmenting JS, not replacing it.

> if I want to animate a div to fly across the page, am I going to have to write lots of low level code to do that?

That depends entirely on the library!

> I'd love it if somebody would point me at some resources that I could burn a weekend on

They're sorta scattered all over the place right now. Such is life for early adopters. More will come as stuff matures. Don't under-estimate how much this will change as the tooling gets built out, for example.
Write code to have an impressive features list in the product, even if half of them have 3 bugs per line of code.

It's not a strategy I approve, but it can be effective from a commercial stand-point, specially if the half that doesn't work is the half barely used in real life.

It was specially true in the past, with on premise software where clients were in a kind of lock-down with the software provider. Today, as we move more and more towards SaaS, this approach is far more risky because your client could easily switch to another service provider.
I guess traffic will always elicit emotional reactions in people. I bike through a tourist-laden, relatively narrow, street on my way to and from work and, my god, the amount of people just wandering around aimlessly seemingly having no sense of their surroundings is astonishing.
My theorie is that while we as humanity accepted the differences in human pretty far so far we still expect a pretty standardised human in terms of work environments.

However I think the trick is essentially to give up trying to act normal and finding your own way. Something that fits your style of life.

Edit:// I am certain any doctor would agree its ADHD. However you'd still have to question if amphetamines really present a final answer then.
You mean C99 ? What I really miss from C , with some of the things of this article, is constexpr, compile time checked enums, ...
> Someone has a great new design they want to implement which is leagues better than what exists, and the existing design is just so awful. Only, it’s going to require some duct tape here and there, but that’s totally acceptable because overall it’s better. Until it becomes apparent that it’s mostly duct tape, but you’ve gone all-in on this and you can’t go back.

> Solution: Start over. The sunken cost fallacy is real. You’ve made a mistake, and that’s ok, you can take those learnings and build something better. Don’t settle for chaos.

Seems like a smart solution, and yet I almost never hear “throw it out and start over” as an option for dealing with unforeseen problems.

Perhaps as programmers we should take some lessons from writers, who will often throw out all their work from the past day/week/month, because once it goes into production (a published book), you can’t change it. In software, you can change it, yes. But if it doesn’t add anything useful, complicates existing things, or will slow development in the future, there is a clear reason to just drop it and move onto the next approach.

One way to make “just drop it” a more palatable option is to give yourself a grace period from the outset. Something like “if we can’t get this to work in a week, we’ll drop it and reevaluate.” This is when it helps to have at least two people (engineer + manager, or engineer x2) because it eliminates “developer pride” as a variable in decision making and holds someone accountable for making that decision after a week. As a manager, often the most important decisions are not what to build, but what not to build.
With Love and Data – Discussing Impact of AI on Marketing and Content Creation
But I don't agree that programing SHOULD be a creative task. The primary reason being that A creative tasks' output depends quite a bit on the person performing the task. Whereas for an engineering task, less so - as long as the engineer is trained, knowledgeable etc, etc (usual caveats for pedants..)

>But that won't happen just by standardizing structure. The structure still holds content which has to adapt to those business goals etc.

I agree, but i'm thinking along the lines of - more LEGO, less literature. I.e. A move towards a more standardized problem specification process that itself becomes the solution, or at the very least through minimal effort.
That is why I long for iOS Time Capsule. The cloud is increasing a single point of area for government intervention. Especially for certain places in the world.
> Yes.

I am not sure how you can know that. I am actually sure Apple would have lost some market but not much and there could have been stuff they could do to let it happen rather than now just giving up everything to any authoritarian government.

Maybe Apple could have gained some respect and then market share if they would have stood firm. With this new management, Apple has become just focused on business (income) not what they were known to be passionate about.
I'd say Mars. Having it already in Earth orbit would make it more cost effective to hook it to a Mars mission. Also, being 100% electric I'm sure they would find a way to make it useable on Mars. Just imagine watching some pilot doing stunts in a reduced gravity.
From tech to bio. Primarily diving into the processes involved with DNA, RNA, and proteins (i.e. following CRISPR hype).
F# is a bit surprising, since it’s already on top of a mainstream platform. If all else fails you can glue in C# if you ever find that you really can’t do something with F#.
I agree with this, it's especially hard in a place like Wisconsin where everywhere is "two bars and a church". I personally drink and don't have any problems with it but I also don't enjoy when every meet-up or company sponsored event is in a bar (not the company I work for but this is a common thing). Have the event at a hotel or establishment with a bar in a separate area if people want to drink. Or have the event and after the main event is concluded say, "As an after event from hours 3 to 6 we'll be doing cocktails at location XYZ if anyone is interested."
> and requires introducing another stack frame for no good reason

With a given implementation or is there something in the Go specification that prevents this from being compiled away? If I were to write something similar in, say, C++ with a good compiler I would expect the generated code to be equivalent to using a ternary operator.
I totally agree - what I should have said is that we struggled to make hires for a React job opening.

We've always been happy to hire good people who don't happen to be familiar with our stack already.
Yup, I'm on trustroots as well. Indeed, it looks like a nicer alternative, now that CS is becoming more and more commercial. Not that many people on trustroots yet though.
There is also Erlang and Elixir which while functional aren't typed. There are some static analysis tools though.
Yeah that's a power law. It would have been pretty easy to see had you used a log-log plot.
If traffic constrains you to 9 mph, you car isn't going to be much faster than 20 - 25mph. Though where I live, a 15 mile car commute is going to be at least 2 hours/day, unless you have enough flexibility to drive outside of typical commute hours.

When I had a city commute (in SF), I was doing around 12mph average to get downtown, and biking was faster than the train (driving wasn't an option due to parking availability, both at home and work).

When I had a longer bike commute mostly on bike trails, I averaged 15mph at a moderate pace - I could go faster if I pushed harder.

Hills used to be an issue for a bike commute, they could really kill your average speed, but with the advent of electric bikes, hills are much less of an issue - electric assist can get you over the hill quickly and without much effort.
I was going to cite Nix in response to this article, but I see you have already mentioned Guix. I hope that both GuixSD and NixOS strike happy balances between the two opposing philosophies described in this article.