ColinDabritz

The demo form does seem to handle backspacing and pasting correctly.

I do know a LOT of places where this gets missed, and a typo goes to the next field, but reflexive backspace correction also fails.

On a brief look, it appears that all of these choices (Including Amazon's new one) only support Android devices and not iOS?

I believe Xamarin Test Cloud includes iOS, although I'm not certain if it integrates outside of the Xamarin framework. http://xamarin.com/test-cloud

Seems like a gap they should all be trying to fill.

Interesting, do you have a citation for this one? It reminds me of the "carrots help you see better" myth that began as WWII propaganda [1] as a cover for radar and has been very persistent since.

[1] http://www.washingtonpost.com/news/speaking-of-science/wp/20...

To clarify, the NuPRL project is like this in what way? They discuss cs topics and algorithms but no source code exists? or it exists but they don't provide it? Or (unlikely) they provide source code no one can compile?

I don't want to mix up the side issue of "should code-based research always provide source code" with the metaphors being discussed. I definitely think useful CS research can happen without source code needing to exist, which I hope is the NuPRL project's case.

I do feel code based research should provide source code that was created as part of the research when it is material to their claims, including 'we ran a simulation' and similar findings. If you already have that level of detail, you should include it. If you make claims based on data, you need to provide that data. If you make claims based on source code, you need to provide that source code.

That may be true, but one of the key ideals in science is that the findings are reproduceable. If I can't reproduce it, it's helpful for the science to be fairly specific, in case the findings depended on details that were thought to be unimportant, but we later find out were critical. The most interesting science comes in unexpected results.

I feel it's like a piece of closed source software releasing "the source code" and yet no one can make it compile. You don't have to have a clean codebase, it can be a bit tricky to build, but it has to be able to be compiled before anyone can have any confidence in your claims. If you don't provide that, it's much less useful.

The separate issues of for profit labs and what support they should expect in this context are tough issues, but we shouldn't undermine the science to thwart them.

I definitely like this approach in my own code. I think the main advantage of a different approach such as enums is enforcing the explicitness at the call site for all users, especially in library functions.

Another thing to consider: In some cases, it may make more sense to split the function into two versions, one for 'true' and one for 'false'. Then you gain the enforced explicitness. The function could call a private method to share code and pass the Boolean. Clearly that isn't ideal for all situations, but it might help in some situations today.

I think perhaps a better phrasing is 'write simpler code', code that expresses what it needs to as directly as possible, without unnecessary complexity.

This code does tend toward smaller more compact expression, but you're chasing the simplicity more than the literal absolute size.

I found the picture at the top to be a funny reflection of the problems of layout. The bird (I believe that's a cassowary as on the book cover) in a spacesuit is an interesting juxtaposition artistically, but the helmet face plate won't be able to rotate down over the birds beak and seal the helmet. A 'layout' case that the image didn't consider. Layout is hard.

What a wonderfully informative article. I really appreciated all the specific scenarios and cases.

It might be interesting to have a gate on publishing images that explicitly runs tests for major known vulnerabilities. You could at minimum flag images as "known vulnerable", or reject publishing attempts.

The flag might make sense on a new vulnerability, and it could be applied automatically. Imagine [Tag: Heartbleed - Untested] when the vulnerability happened, then as the automated process rolls through the images [Tag: Heartbleed - vulnerable] [Tag: Heartbleed - no vulnerability detected]. Future images are required to pass first.

We have to be careful with widely distributed images.

I think it's possible that some form of 'digital literacy' might make sense for all to learn in school, although I'm skeptical of our (US) school system's ability to execute it well.

I'm a software engineer, and I don't believe that "coding" is a necessary specific skill for all people to learn. I certainly believe that lots of people could learn it, love it, and benefit from it, but to declare it specifically as a skill that every last person must have seems like too broad of a position to take to me. I think we should present it positively as a choice for those interested and inclined, and let the students decide how interested they are.

When you let students decide for themselves, it's remarkably transformative. There is a lot of hand-wringing, but it appears they make reasonable decisions, and importantly they are suddenly hugely invested in learning and their future. They feel in control. It helps make learning fun, as it should be. Instead of dictating choices, perhaps we should let the 11 year old decide. Many of them may choose code, even at 11 or earlier. Others will choose what is right for them, and when.

Soon to be, it looks like: https://www.kickstarter.com/projects/theplanetarysociety/lig...

They are well along, this is a test flight for some of the systems I believe. The Kickstarer is for the rest of the funding for the main vehicle. It's not 100%, but a substantial chunk.

In the general case, we can't of course, as Turing proved. How we untangle special cases and categories of algorithms around this is part of the wonder of mathematics for me.

Sorry, I didn't mean to imply that strong AI isn't possible, I believe it is very possible. I was reacting strongly to the headline specifically, as it was invoking a "magic computers" image that I dislike.

I only meant that the computers of today are tools we use to explore math, but that the work today is very human. The "computer" that transcends that will look very different. What Alan Turing showed us was that you cannot turn all of "mathematics" into an algorithm. The beauty and elegance and human experience of the exploration of mathematics are important. Some day we will probably be able to teach a machine those traits.

The title reads more like someone wrote an app that solved math, which is silly. The article itself is fortunately much better.

Apologies, I didn't mean to make that implication. I was referring to the history of the original computability paper. There was an era in math where we believed it may be possible to determine the rest of mathematics via algorithm, that the game was up. Turing showed that this was not possible, and in doing so invented the general purpose computer.

Computers may be able to keep up, but the title was invoking "magic algorithm" suggestions to me. At the moment it may be unclear, but you are correct that it appears that computation can mimic the brain. For computers to be used as more than just tools in humans exploration of mathematics, to "redefine the rules" I think it would have to look quite different than the computers we have today.

The article is delightful, but regarding the title "Will Computers Redefine the Roots of Math?"

No.

Math is about human understanding, elegance and beauty.

Computers may be useful tools, and perhaps they will be of even greater assistance in mathematics moving forward, but Alan Turing and others have shown us they can't do it all. Math is a fundamentally human endeavor. We will have to transcend modern computers with something like strong AI before that can change.

It's impressive the chaos that one second can cause. I think in terms of hard problems, to naming and cache invalidation, I would add time or human notions thereof. Or perhaps time is a case of the first two intersecting...

It helped me to think of it this way: Alice is guessing that their coins are different (one possibility) and Bob is guessing that their coins are the same (the other possibility), so from either direction they are covered.

Interesting. You can, of course, work with actual executables in that environment too. Can you highlight some of the areas where it causes different behaviors or other design issues?

This is a specific critique about the usability of the Unix shell, and I think most of this is still valid. The inside jokes (less is more) and overloaded meanings of command names is still an issue today, for example. Some of the visibility has improved by various means, but overall there is still a fair amount of 'black box' that takes arcane knowledge to peek in to.

Naming is one area I appreciated Microsoft's approach in Powershell. They have command names with a Verb-Noun structure, and full clear words, sometimes quite long. Then, after establishing clear canonical forms for the commands, they add a few well chosen aliases for short invocation and memorization.

Of all the critiques though, the Cognitive Engineering objection, that the system is not well designed to be used by human capacities, is still true across many platforms, especially in esoteric areas like the command line.

Also interestingly, I am guessing that this is the same Donald A. Norman of 'The Design Of Everyday Things'. It's fascinating to see these ideas in flight in 1981.

How do we address these things? How does one "redesign Unix" today?

Thank you for sharing your perspective. I'm not sure that I agree. This is more than just some people estimating off the cuff, there are many studies in the US, and more instances and evidence world wide. Fortunately it's an experiment that is being run, so we will be able to see more hard data in the coming years.

http://www.endhomelessness.org/pages/cost_of_homelessness http://usich.gov/usich_resources/research_and_evaluation/cos... http://www.politifact.com/truth-o-meter/statements/2012/mar/...

The biggest costs are pretty concrete. They are 'after the fact' emergency services like emergency room hospital care (vs cheaper preventative care) and jail (instead of housing). It's clear that these costs are higher for the homeless than average, but that leaves the question of housing changing that for this specific group of people (e.g. maybe they are just inherently more likely to end up in an emergency room) which is a valid question.

The evidence is that people with housing are more able to get the help they need earlier (such as preventative care), and are less likely to commit crimes out of desperation, because they have housing. This leads to a much lower rate of using these expensive services, leading to a clearly lower cost to provide housing vs concrete cost of emergency services.

That's why I believe this approach is both humane and effective. This is why I believe housing first is better for everyone.

I don't see it. $100k per person costs drop to $20k per person costs, they should want to scale this as fast as they can. They may have had to invest a little up front, or redistribute some of the costs back to where the funding came from before, but it sounds like this scales spectacularly and is a huge win all around.

I don't think the metric 'any code that decreases agility as the project matures' is quite the same thing. I think most code lowers agility, as it is increasing complexity and the number of interactions and entanglements across your codebase. Adding features decreases agility. These are not 'technical debt'.

I always enjoy Ward Cunningham's discussion of this: http://c2.com/cgi/wiki?WardExplainsDebtMetaphor (Ward first used the metaphor)

Specifically, he is NOT talking about 'dirty code' or just badly written code, that's taking shortcuts and I believe it is never a good idea in software. We're talking about building good code but doing so before we fully understand the problem, often with the aim of learning more about the problem, especially from user feedback.

What I take Ward's discussion to mean is that "technical debt" is accrued when writing code for a problem you do not YET completely understand (e.g. almost all 'first pass' code). The debt occurs when your code's existing understanding is static (because it is in source control), and your teams understanding grows. The difference is your debt. You can continue building on the code's not-quite-right understanding for the moment which is carrying the debt forward and paying the costs of fighting a not-quite-right model, but at some point it becomes worth while to re-factor based on what your team has learned about your problem, and thus pay off the debt.

It would be neat if you could have it know nothing, and learn from you over a series of games.

These were interesting to me:

16. Take better care of your customers -- Apple support is pretty good, especially if you can get to a store

26. If you sell it, make it -- Their supply chain integration and control is impressive today

38. Make it easier for ISVs to make applications -- The app store and the development ecosystem is important for apple

50. Give Steve Jobs as much authority as he wants in new product development -- This paid off hugely

53. Recharge your strategy for Europe -- Apple is a very global company and is pushing into lots of markets

59. Invest heavily in Newton technology -- Apple parked that particular project, but the iPhone and iPad followed

Some clearly joke entries, and some misses and terrible ideas, but definitely some interesting insights as well.

PPA = Personal Package Archive

As someone who is unfamiliar with this term, can someone please summarize what it means? What makes it appealing?

Thank you in advance.

The comic itself does contain violence, so from that perspective I don't think it's an unreasonable choice for a filter to label it 'Violence', and that's my guess as to why it was filtered. Having the category of 'Violence' conflated with 'Terrorism' is ridiculous.

Not quite. PCIe is just the bus transport protocol. The PCIe SSDs still need a protocol to describe data operations to and from the OS to the Drive. Currently, they use the same protocols as those designed for HDDs, and those protocols make a lot of tradeoffs and assumptions about disk access time. The reason NVMe is exciting is that it is a brand new data protocol, designed with low latency SSD style storage in mind. We're already seeing speeds much higher than existing PCIe SSDs can manage (3+ GB/s!)

I think you're right! It's difficult to communicate tone and other 'out of band' stuff through text. This is what Wikipedia's "Assume good faith" guideline is to addresses.

http://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith

"all models are wrong but some are useful" - George E. P. Box

http://en.wikiquote.org/wiki/George_E._P._Box

I'm not certain if volume was lost or gained, but it looked possible at some points. Some of the other modeling seemed a bit 'off' but for so little code in ASCII it was pretty amazing.