But you can't actually simulate a TM on any machine with a fixed amount of memory. And any "special purpose" computing hardware would have at least a little memory. So I don't think that distinction works. Unless it only applies to machines with expandable memory? Technically, if it were hot swappable, the memory would be unbounded. But nowadays, the SD slot on phones is often under the battery, if it exists at all.
Could you explain what you mean by "to a lesser extent Android"? Android lets apps add widgets to the home screen, replace the home screen, replace the browser, run arbitrary background tasks, and so forth. You can even sideload apps and create your own app store. None of this is possible on iOS.
I'm a little disappointed that Wirth doesn't mention one of the key reasons that financial institutions use decimal floating point: that binary floating point can't produce exact representations of powers of 10, such as 0.1, and you may want to produce exact results for these situations, because fractions of a cent can really add up over time (see e.g. http://en.wikipedia.org/wiki/Salami_slicing).
This is one of the best critiques so far of the decision.
There are two sides to this trial. On the one side is the emotional appeal: Samsung copied Apple, and documents detail the extent to which Samsung imitated the iPhone. On the other side are the various technical ways in which Apple claimed that Samsung copied them. But just as Apple engineers slaved for years over the technical details of the iPhone, it is incredibly important for the future of mobile innovation that all of the technical parts of the trial are correctly decided. If the jury finds no infringement but finds that infringement was induced, this indicates that technical mistakes were made. But in particular, I wonder if the jury was so swayed by the emotional appeal that sufficient attention was paid to the substantial prior art demonstrated regarding capacitive touch screen phones and multitouch displays.
It's a design patent granted in 2005 for an electronic device shaped like a rounded rectangle. But it cites several other patents for other devices shaped like rectangles. So is it the precise aspect ratio and thickness of their rectangle that makes it unique? But the Galaxy Tab is substantially thinner than the rectangle shown in this patent.
First, Apple has been designing its own "Ax" series of ARM chips with its purchase of PA Semi, currently with the A5/A5X. If Apple switched to an Intel chip, they would no longer have the flexibility of a custom design or marketing claim to a custom chip in their product.
Second, though Apple contracts with Samsung to fabricate their ARM chips, they could presumably go to other companies to do the same thing. There have been rumors of a future partnership with TSMC. If Apple switched iOS to Intel's architecture, Apple would have much less flexibility with fabrication.
Third, switching CPU architectures means that your old software doesn't work immediately (we used to say "out of the box"). When Apple previously switched CPU architectures on the Mac, they had an emulator to allow running old apps, but this has a huge performance penalty that wouldn't fly on iOS: apps wouldn't be silky smooth on the latest product. The situation here is a bit different than with the Mac because developers sell directly through the App Store, but Apple would have to take a temporary hit to their huge app selection while developers recompile their apps, and some developers may not have the resources to do so (because the work was done via contract, for example). Perhaps static recompilation to retarget the architecture could be done by Apple for each app, but reading the EFF's copy of the iPhone Developer Program License Agreement, I don't see where Apple granted themselves the right to do this (correct me if I'm wrong).
To me, it makes more sense that Apple would want Intel to manufacture Ax ARM chips for them. But given that Intel has shown huge resistance to ARM (probably due to the lack of manufacturer lock-in), it's unlikely that they would partner with Apple to do this. The key advantage for Apple would be the use of Intel's cutting edge fabs, which would make their ARM chips the undisputed champions.
I looked twice to verify that she needed the wheelchair.
I'm not quite sure why Pike wrote this. Was he afraid that the wheelchair concealed a weapon of some sort? But how can you visually verify that a person needs a wheelchair?
I also wonder what Pike thinks now that his employer is being sued over the violations of patents in their open source GUI software. The swipe-to-unlock patent strikes me as about as obvious as backing store.
I'm not quite sure what the issue is here. It turns out that the author modeled the domain incorrectly. At least that incorrect model is completely explicit in the code. If it weren't spelled out explicitly, the coupling that the author speaks of would be insidiously spread throughout the code. In order to make the change that the author wants, it's as easy as introducing a new abstract class. In fact, if all the existing code correctly assumes the existence of an Isin, we can create the following set of classes:
abstract class BaseSecurity {
public string Description { get; set; }
public Exchange Exchange { get; set; }
}
then modify Security to derive from BaseSecurity:
abstract class Security : BaseSecurity {
public string Isin { get; set; }
}
Then you are done, except for two issues: first is that any serialized data needs to be regenerated, and second is that you can't trade BaseSecurities. However, this trading functionality can be written separately without disturbing the existing ecosystem of software. This is what your type hierarchy buys you.
On the other hand, if we insist that this is not correct, and Security should have Isin removed, then we can add a new PhysicalSecurity between Security and the various implementations, and Stock/Bond/Trade can inherit from PhysicalSecurity.
In that case, the problem is that a lot of code was written with the incorrect assumption that an Isin exists in every security. Now we have to take a step back and ask how to fix that code on a case by case basis. No matter what language you use, it's always possible to write bad code with incorrect assumptions, and in that case you must pay the price. Hopefully you would be clear with your client on the delays required.
Now we can ask ourselves how a static language treats the situation differently than a dynamic language. The author seems to think a dynamic language would help, providing only praise in his description of them.
With a static language, we can simply remove Isin from the definition of Option. This will cause a lot of compilation failures. However, every place where there is a compilation failure is a place in the code which had an incorrect assumption. Each of these incorrect assumptions must be considered individually. After all, this represents the model for a trading system, and any bugs would likely result in severe financial consequences.
In a dynamic language, the definition could be changed, but there would not be any inherent mechanism to catch the now-incorrect calls. Instead, we would just get the NullPointerExceptions that the author complains about and which jeopardize the viability of the financial trading system. Perhaps the coders would have written beautiful unit tests that would help, but that could be the case in any static language as well. Of course, it's also possible that the coders would have created trivial unit tests or no tests at all.
In any case, I see this situation as a win for static type systems rather than a loss.
At runtime init, Go programs attempt to reserve 512mb of RAM. If they can’t do this, they crash. Go needs the space because it is garbage collected - presumably, all GC languages, or any program that takes a similar approach to memory management, will be susceptible to the same problem.
While it is true that most garbage collected environments will reserve some memory at startup, a hard minimum of 512 MB is not the norm. Do note that embedded Java has run on cell phones with minimal amounts of RAM for many years.
Facebook's testing practices and culture of developer accountability help to prevent serious bugs from being rolled out in production code. When a developer's code disrupts the website and necessitates a post-deployment fix, the incident is tracked and factored into Facebook's assessment of the developer's job performance.
[...]
Employees with low karma can regain their lost points over time by performing well—though some also try to help their odds by bringing Rossi goodies. Booze and cupcakes are Rossi's preferred currency of redemption; the release engineering team has an impressive supply of booze on hand, some of which was supplied by developers looking to restore their tarnished karma.
This sounds like Facebook strongly rewards developers who work on trivial, low-risk features rather than larger, more important features. Also, it sounds like bribery factors into your overall job performance rating.
I was interested in his response to the question, "What you dislike the most about Lisp?"
I must say that the lack of static typing really gets in the way on larger projects. Being able to confidently change datatypes and function signatures, knowing that the compiler will point out most inconsistencies that you introduce, is something that I've really come to appreciate after working with Rust and Haskell. Test coverage helps, of course, but I'm not a very diligent test writer, and tend to feel that type signatures are easier to maintain than an exhaustive test suite.
Also, I'd recommend taking a look at Magma: http://en.wikipedia.org/wiki/Magma_computer_algebra_system