skysight-inc/HackerNews huggingface dataset:
Google's lock in is more about Google Play than about what is coming in Android. Basically as a manufacturer, if you don't play nice, then you don't get Google Play (or YouTube, or Gmail, or GMaps), which then means that your smartphone is just an expensive brick with no apps on it. iOS is special because it is popular and was here first. But do you see Google giving a shit about Amazon's stuff or about the Windows phone?

You know, i'm an Android user because of its openness, because of its ability to be forked, but Google practices a kind of lock-in that is very hard to escape. Basically everything they do is technically excellent, plus they end up dominating the underlying platforms.
OP Here. Yes, now I agree with you that doing a “Replace All” on lifetime with another term does not really solve the problem. (I have replied you on the RFC discussion.) We need to distinguish some existing lifetime-related terms (concepts) clearly, including the two you just mentioned.

The issue is &'a is so common in Rust code. We simply call it lifetime 'a, which is misleading. It is not any object’s or pointer’s lifetime, but a set of lifetime requirements (or lifetime bound in your term) that every borrower imposes on the borrowed resources. It is the B I mentioned in the last section of my blog post:

When we talk about borrow, there are three different kinds of “lifetime” involved:

A: the lifetime of the resource owner (or the owned/borrowed resource)

B: the “lifetime” of the whole borrow, i.e. from the first borrow to the last return

C: the lifetime of an individual borrower or borrowed pointer

The required condition is A >= B, where B = C1 U C2 U ... U Cn.
This piqued my curiosity. Minor glitch--I attempted to subscribe to the RSS feed, http://contentmine.org/blog/feed, but it seems to not list any of the blog posts (?)
The cost to manufacture is still quite interesting.
There are many hard problems in computer science and software engineering. As it turns out, the solution to these problems is spider charts.

Finally, we'll be able to write distributed low-latency software that interacts with both legacy systems and browsers with complete end-to-end type safety, provable correctness and fault tolerance! In half the time, at half the cost!

With spider charts.
Starting Up in Africa – Calling on Africa's Futurists
tldr: civilization needs some goddamn refactoring.
Previously discussed here

`https://news.ycombinator.com/item?id=5872043'.

And links to the `greatest of the great' papers;

`https://news.ycombinator.com/item?id=5872310'.
Yes, I meant border-bottom in conjunction with line-height. It feels more connected to the idea of "underline" than adding a line-gradient.
Ember had a lot of growing pains, but it's starting to come out of it's cocoon and spread it's wings. When you combine it with the massive productivity boost of ember-cli, tooling that does all the tedious and hard shit that no one wants to deal with, it's a big win.

I recently made a simple app and decided to just write it in jquery and constantly found myself missing doing things "The Ember Way"™ Building an "ambitious" application in jquery alone would be complete madness and half-hearted frameworks don't really give you much benefit for all the wrestling you have to do.

I really like that the Ember team strives to find the right way and deprecates parts of the api that they find people using in bad ways. I've also seen a lot a pragmatism around preventing bloat like removing string inflections etc...

The best advice I have if you really want to try Ember is to read the guides, completely, word for word. Then try to write a simple app, using the guides/recipes/API for reference and then read the guides again, completely. Then do all that again. It won't take as long as you think and you'll be far ahead of where you would be reading some introductory blog posts.

Admittedly, I have been frustrated at points, but that's par for the course with any js framework at the moment and if I had chosen Angular 1.x for any of my previous clients, I would be VERY embarrassed right now.
> they can't make the code as easy to comprehend as it would be in a more expressive language.

It's a little hard to make a general statement using an vague term like "expressiveness".

Static typing can actually make things clearer. That's a kind of expressiveness. You can know with complete certainty what type of data the code works with, just by looking at it. No need to rely on a certain set of unit tests living somewhere else to confirm your assumptions. And if you say "well just read the function docs", how is that any less verbose in the end? It's the same verbosity, minus the compiler guarantees.

On the other hand, there are situations where DSLs can greatly cut down on route programming. Like Apache Pig vs. calling Java APIs. But that's a more extreme example, an actual speciality "domain" to make a specific language for.

I might help to use a more precise term like verbosity. Then we can ask, is this verbosity really helpful (like explicitly declaring types), or can we compact it without losing significant information. Fortunately Java 8 has made some progress with adopting features that cut down on unnecessary verbosity.
Win10 and it's (likely) XP/7 popularity level is a dark horse for native apps, and looming blow for the webapp movement. Which I believe has gotten a very long free-pass thanks to the most popular platform not having a cohesive appstore ready (on a popular OS).

Win8 IMO is almost irrelevant, the marketshare isn't there to add a MS Store option for me or many others. The corporations haven't and won't hop on. Everyone is (IMO rightly) focused on iOS/Android/web at the moment. Agreed on MSIs, but I'd add the customizable corporate frontend stores should be more powerful and slick than the current method (same appstore for MS desktop and mobile). It's possible once enterprise moves to the MS Store that MS mobile devices make major inroads.
For consumers, I think they'll rejoice at Win10, upgrade to it and by default go to the MS Store for security reasons alone. Not to mention auto-updates, same apps as on MS mobile etc.

I'm not pro-MS, I'm actually anti-all-for-profits and a Mozilla fanboy. I just disagree with Eich on a bytecode for the web, he blew it as far as the web being the prime delivery mechanism for apps is concerned. The webstack sucks, it had to go. Too late now.

I understand my view isn't popular at the moment. Especially among webdevs who are most likely to be reading this HN post. Those people have invested heavily in the webapp dream with their time, skills and careers. Anything to the contrary that it was a great idea is going to get downvoted. Regardless, I think this is an accurate reading of the foreseeable future.
Great post! I agree with your argument regarding libraries over frameworks, but I think the real problem is how we couple our software to third-party libraries. Frameworks tie you down more than a library, like you said. But if you're not careful a library can do just the same. Which is why I believe developers have to be more clever when architecting software.

Reading your post reminded me of Robert C. Martin (Uncle Bob) opinions on how coupling your code with anything that can screw you over obviously is a bad idea.

"Apparently the notion that it’s a good idea to hide the framework, UI, or database from the application code is not universally accepted."

"What happened to us? How did we forget these rules? When did the old rules of coupling and cohesion evaporate from our awareness? Are we really so naive as to think that the best way to write a complex system is to throw a bunch of components into a bag and shake it until it works?"

http://blog.8thlight.com/uncle-bob/2011/11/22/Clean-Architec...
If you want to base this on "good for society" or "ethical", i don't suspect you'll actually get anywhere in terms of coming to a conclusion. There are reasonable arguments on both sides.

My opinion on things related to competition/antitrust are based mainly on evolution of law and economic viewpoints.

Basically, over the past hundred years, courts have moved away from (and economists have strongly supported) declaring these kinds of things as "per-se" illegal precisely because evidence has not shown that you can simply point at them and say "yeah, this hurts competition" or "yeah, this hurts consumers", despite what one may think.

In some cases, this evolution of law/economy has pretty clearly turned out bad for consumers price-wise (with the return of folks requiring retailers to sell at certain minimum prices).

In some cases it hasn't.

This particular thing, hard to say.
This doesn't take resource exhaustion into account. Which is to say, that by maximizing first and then optimizing, you may be only ensuring the extinction of our species, and the fact that your civilization will still be around when the lights go out will be cold comfort.

I mean, this discussion is absurd, of course, since we seem to be operating under the assumption that the problem of how to do civilization can be solved with a half-dozen variables or so. But, even within that simplistic framework, the approach being laid out by you two is pretty daft IMO.

How about, an economy that achieves hegemony, and then continuously optimizes, increases resource consumption as appropriate and only to the extent that such consumption is sustainable (over some reasonable planning horizon anyway), and seeks out and destroys rival upstart economies that are a threat to it (especially when they have an unsustainable model of resource consumption), will tend to be successful and stay successful.
If you replace glibc, coreutils, bash, Xorg, and just about any other part that you as either a developer or user interact with, then no, it's not recognizably linux, any more than the BSDs are Linux. In fact, as far as I know, the BSDs will be easier to port to, because Bionic libc is really a stub, with lots of Posix bits left out.
The funny part of the 1979 paper is that its Fig 3 of NA codes just looks like QR code of 2014:

http://i.imgur.com/AR0OhAF.png
Fun Maths for All – Easy Way to Learn Maths
IRC is probably the best example of worse-is-better design, its not great, has some obvious problems, but its good enough that nothing to come after it has been able to fully unseat it.
> It could just as easily have used JSON or Protocol Buffers and it would still be SVG.

Definitely not protocol buffers. XML gives us some really nice bits of SVG, like the ability to put attributes and tags in namespaces, so you can use Inkscape to edit your SVG file, store a bunch of Inkscape-specific data in the SVG file, and not have other editors puke. SVG isn't just data interchange, it's a document edited by humans. JSON doesn't accommodate that very well.

> More like it seems easy to parse. Plenty of people think they are parsing XML but their ad hoc "parsers" know nothing about CDATA, DTDs, external entities, processing instructions, or comments.

I wouldn't use an ad-hoc parser for JSON either. The problem here isn't XML, the problem is thinking that you can solve your problem with regular expressions. Ignoring or throwing errors for DTDs, external entities, and PIs is reasonable behavior most of the time, and most parsers can be set to strip comments and erase the differences between entities/CDATA/text. This behavior is good enough for 99% of the use cases.

> ...except for gotchas like the fact that you need to entity-escape any ampersands in attributes (like "href").

Escape sequences in XML are better than JSON, at least. Try escaping a character from the astral plane in JSON, you have to encode it in UTF-16 and then encode each item in the surrogate pair as a separate escape sequence. This is insane. (Yes, sometimes you want to transmit JSON or XML in 7-bit).

Escape sequences are a natural part of any text format, other than plain text.

> Sure, but combined with the other specs which are assumed to be part of a modern XML stack

Most of the modern XML stack is a mistake, a symptom of the years when people thought XML was the coolest thing ever. XSLT is the worst mistake of all. That doesn't mean that you have to use it. Most people don't.

Let's not fall into the trap of thinking that we should use JSON for everything, just like so many fell into the trap of thinking that they should use XML for everything. Both have their use cases.
This behaviour - downvoting without explanation irritates me too when there is very lucid and concisely structured argument you can oppose.

As such, I do not find your argument for verbosity normalizing convincing :)

I fail to see how normalizing some risk metric against a verbosity of language will provide any valid data in the general context. For numerical algorithms, where a multiplication is just as verbose in any language then there is no difference.

But when manipulating collections, for example in C I need to write
int i;
for(i = 0; i < someSize; i++){...}

This has several places where the verbosity of language can make it easier to write bugs that slow down the progress a bit. If we add these tiny slowdowns throughout the lifecycle of the entire application the cost is not neglible if compared to a situation where these bugs would not appear at all. Some other language:

for i in collection do:...

Which does really have no place to shoot oneself in the foot unless the iteration logic itself does something funny.
Do you have any recommendations on articles or books about getting started with microservices? I'm an experienced Django dev - I began using Docker a few months ago and microservices seem like the natural next step. But most of the blog posts out there about the big picture reasons to switch to microservices, I haven't found much about implementation details.
> Fortunately we have JSON now.

Even JSON is really a sin. Using simple binary data formats like protocol buffers makes so much more sense.
The Science of Politely Ending a Conversation
Not until they support more than 2^31 elements in my array!
I'm not saying that I wish that it were true, or that I think it's a good thing. I agree that it's daft. But over the short term, pillaging societies appear to beat conserving ones. And it's a fact that we do seem to be (as a species) adopting a short-term-profitable long-term-suicidal approach.

(An interesting model is Norway's oil – they're maximising in the sense of getting all the oil out from under the sea, but they're stashing most of the profits away as a rainy-day fund, which puts the country on very secure footing for about the next hundred years or so. You might call that 'maximising without consuming', or 'camping'.)

I think the future of the human race depends on finding a better answer to this whole question, but I think accepting that pillagers beat conservers in a lot of cases is a necessary step to finding something better.

(I don't think we actually disagree; we seem to be arguing different points.)
"mine is one of them."

No, it isn't. Prove me otherwise. According to your definition, anyone who has sex other than in a long-term monogamous relationship is promiscuous. Quote where the WP page says something similar.

"What moralistic is that?"

According to the same Wikipedia page you mentioned "The term can carry a moral judgement if viewed in the context of a mainstream social ideal for sexual activity to occur only within exclusive committed relationships." That's exactly the way you used it.

You presume that everyone has specific end goals with sex. Not everyone who has sex with multiple partners is "experimenting". Not everyone wants to "settle down".

"is just an opinion"

There's no contradiction. Expressing opinions is one of the ways that morality reveals itself. The way you have expressed your opinions is judgmental and moralistic.

"promiscuous people have more risc in contracting a SDT ..."

The majority of people have an STD, even those who never have sex. Some STDs can be passed by kissing or sharing a toothbrush. Others require genital contact. I therefore observe that going within 100 meters of other people, or where other people have been, gives more risk in contracting an STD.

My observation is much more valid than yours, for reasons I highlighted earlier. Yours is mostly pointless, because having sex with multiple partners is only one risk factor, and not even the most significant risk factor. You can be completely monogamous and have only had sex with a single partner, and still get an STD from that partner; all the more so if that partner has frequent unsafe sex with a large number of partners.

"I'm not talking about abstinence"

Never said you were. I'm saying that sex positive safe sex education is more effective at improving social outcomes (reducing virus spread, reducing unplanned pregnancy, etc.) than anything which tries to reduce promiscuity. Therefore your observation is not only full of counter-cases but experience shows it can't be used for effective decision making - except by those wishing to enforce a certain morality.

"some how, you feel judged, I wonder why"

That's the second time you've tried to use that derailment tactic. It's an irrelevant ad hominem detail, and you should learn to not use it.
I wonder if we could use Magic eye as a replacement for captcha.
No, you can't. In particular -1 * Integer.MIN_VALUE == Integer.MIN_VALUE.
they don't work on a significant portion of the population.

edit: like myself.
If you look at surveys ,c++ ,as shitty as it may be, is used a lot around the industry.And the fact that ARM have chosen it for the mbed on which they plan to build an operating system around for IOT chips, shows it's value for mcu's, at least in some segments.

The other data point regarding rust is the huge excitement in the embedded community.
> Definitely not protocol buffers.

I fail to see why protocol buffers couldn't have worked for SVG. They are expressly defined so that you can have extensible types without breaking parsers...

> I wouldn't use an ad-hoc parser for JSON either. The problem here isn't XML

...but you can find plenty of "parsers" for both that don't actually parse either fully, correctly, or securely.

> Try escaping a character from the astral plane in JSON, you have to encode it in UTF-16 and then encode each item in the surrogate pair as a separate escape sequence.

One of many reasons to be annoyed by those who think JSON is a perfectly good data format.

> Escape sequences are a natural part of any text format, other than plain text.

Another reason to loathe them. ;-)

That said, you can avoid escape sequences in text formats, so long as your parse rules are length delimited, rather than based on reserved characters.

> Most of the modern XML stack is a mistake, a symptom of the years when people thought XML was the coolest thing ever. XSLT is the worst mistake of all. That doesn't mean that you have to use it. Most people don't.

Agreed, but generally if you aren't supporting it, you aren't using XML.

> Let's not fall into the trap of thinking that we should use JSON for everything, just like so many fell into the trap of thinking that they should use XML for everything. Both have their use cases.

Yes, though I'd argue they are primarily for causing problems.
"Improved" is a relative term and says nothing of the associated costs. Could we maybe reduce costs and still "improve" at a slower, more sustainable pace? It's worth exploring the notion without turning to the dogma of efficiency at any cost.
I maintain and develop a large code base written in (mainly) Python with some C thrown in here and there. It was maintained and developed by a number of people before me over several years, who have come and gone. And yes while there is rust and cobwebs, I don't attribute any maintenance issues to the fact it is Python or a dynamic language, but rather higher level design decisions about interfaces and boundaries and responsibilities. Often some module that wasn't supposed to know something all of a sudden needs to know due to some new/changed requirement, and redrawing data flows and structures to ensure the right information is where it needs to be can be challenging. But this situation can be applicable to a system developed in any language - if anything Python's flexible data structures makes it easy to accomplish such re-engineering.

The last time I tried to do anything in Java, I was instructed to "just run the maven build script". After watching that flaming train wreck I walked away and haven't looked back since.
Charging GST is ridiculous. They've made the right decision.
You'll get different responses on the value of the MBA. From what I understand, no one cares that you "have" an MBA, but the knowledge you learn by finishing it is invaluable. So that's a good start.

I'd be thinking of your next step. Is it Software Architect, Team Leader or Project Manager?

Very different skillset. I would say you don't "have" to master all of them, but you should have a good understanding of what all 3 do and how they add value to a project.

And last, something that will come out of your MBA is the importance of sales and the ability to sell (Sales cycle, sales funnel etc.) Whether you are selling a product, selling your ability or selling the benefits of a project. Sales knowledge is something I rarely see in developers.

If there's anything else I can help with, hit me up privately. My details are on my HN profile.

Good luck!
Moore's law eats the difference between first world prices and third world prices for breakfast. Changing how the hardware is manufactured wouldn't materially affect the choices programmers make even if it doubled the hardware cost, and it probably wouldn't even do that.
Software engineering was taken more seriously 20 years ago than it is now. There have been some notable successes of rigorous development, but they're not well known. Here are two in wide use.

The first is the operating system kernel in the air link processor of mobile phones. In most current phones, that's an L4 kernel with a full proof of correctness. Since any mobile phone can potentially knock out all phones for some distance around if it doesn't follow the sharing rules for the air link, this is important to carriers. They got it right. Nobody talks about this much, but if that layer had problems, there would be regular cellular blackouts.

The second is the Windows Static Driver Verifier. This has been used since Windows 7. It verifies that kernel drivers don't crash, clobber memory or call the driver APIs incorrectly. Before the Static Driver Verifier, drivers accounted for more than half of Windows crashes. Now, crashes from signed drivers are very rare, and usually involve getting the driven device itself to do bad DMA operations. (IOMMUs are coming along to stop that.)

This shows the right direction for software engineering. Some software really matters, and has to be engineered properly. Most software doesn't matter all that much. Engineered systems should separate the two, develop them in different ways, assume the low-grade stuff will crash, and architect systems so the low-grade stuff can only do limited damage. We're seeing architectures like that in the mobile world and in server-side systems. In the mobile world, "apps" run in relatively contained environments. In the server world, things seem to be moving towards containerized "apps" in systems like Docker, running on some minimal glue layer inside a container running on a secure microkernel such as Xen and talking via message passing.

That's software engineering.
True, v2->v3 was hard due to escaping-by-default, but that was a long time ago. v3 to v4 was trivial and v4 to v5 looks to be similarly easy.

Also, I find business logic sql libs written by typical devs tend to be unreadable and much buggier than AR code. They start clean, but once some other devs make some edits, they end up a jumble of sql concatenation nightmares (even if you use prepared statements, and especially if you've ever switched sql dialects). Given the choice, I think I'd rather see them written as stored procedures. At least that enforces decoupling.

I agree with your other points -- less code is more better.