sivanmz

The Angular cross-compiling insanity and eventual switch to TypeScript is the likely catalyst. Still, I hope to see a technical discussion of why the VM had to go.

Looking forward to better interop with JS, but can't help feeling a bit sad.

I didn't really get oop until I learned Smalltalk, working through this book, and subsequently through the Seaside one, was a revelation.

It ruined things for me, most everyday tools and languages look messy and inelegant next to Smalltalk.

Why does it need to upload all my data and track my location on their server?

> Create other model objects to work with your entities instead of asking them to do things for you.

Regardless of persistence, using such "manager" objects to operate on data records is procedural rather than object oriented programming.

Agree that instanceof is wrong and discredits the article.

I'm not sure if this is what you meant, but here is how polymorphism along with the double dispatch pattern would work: NaiveActor#handleLifecycleMessage will need to delegate to the event subclass, which will in turn select the appropriate method on NaiveActor.

Example of subclass of LifecycleMessage:

        class ExitMessage implements LifecycleMessage {
            @Override
            void handle(BasicActor actor) {
               actor.handleExitMessage(this);  
            }
        }

In NaiveActor:

        @Override
        protected void handleLifecycleMessage(LifecycleMessage m) {
            m.handle(this);
        }

        @Override
        protected void handleExitMessage(ExitMessage m) {
            if (Objects.equals(m.getActor(), myBadActor) {
                System.out.println("My bad actor has just died of '" + m.getCause() + "'. Restarting.");
                spawnBadActor();
            }
            return super.handleExitMessage(m);
        }

It's been my experience that many developers resort to instanceof or enum type flags because they don't believe polymorphism actually works in real world situations such as this.

It's a cool gimmick that would be useful for Instagram photos of food. But selfies will still be distorted when taken up close with a wide angle lens.

It would be interesting to pair this with Nokia's high megapixel crop-zoom.

The fastest way to age is by working 80 hour weeks, living off of pizza, beer and Red Bull, and burning out.

At what point will early obsolescence distort the supply of willing workers and compensation demands?

Objects can substantially reduce and simplify testing, if you make guarantees about them during construction, keep them immutable and abide by Demeter's Law.

Have there been any reports on how iOS7 affects thefts?

He misstates the 1Password premise. It is actually that even if you have a complicated single password, repeating it throughout the day makes it easy to remember.

The rest of his argument is based on convenience alone and rather weak. A YubiKey, nice as it is, doesn't help with mobile devices, where transactions are increasingly taking place.

The pairwise recipe function in itertools demonstrates just that (using tee instead of multiplying the iterator):

http://docs.python.org/2/library/itertools.html

  def pairwise(iterable):
    "s -> (s0,s1), (s1,s2), (s2, s3), ..."
    a, b = tee(iterable)
    next(b, None)
    return izip(a, b)

If everyone in your tech-skewed job market is making comparable salaries, nominal values are far less important when competing for the same resources.

While the value of Motoblur has been questionable and the service is no longer a focus for Motorola, it makes sense to do this server side.

One connection that pushes aggregated social networking data saves the need for a multitude of apps constantly polling or keeping their own open commections to various services.

BlackBerry also provided similar services as part of their BIS plan. It would poll Gmail and Exchange servers from its own servers, and push compressed data to the device.

Also, remember that these services existed at a time of slow networks and devices and a lack of support for it from Google. At the present, it's becoming increasingly clear that only few companies have the expertise and trust to do this securely. Motorola is probably not one of them.

Java is just not made for quick prototyping. In production, the URL will come from somewhere, not written by hand, so it would need to be checked anyway. Sadly there's no quick-prototyping mode in Java where you can say, just call this URL string an don't bother checking. Another example is the inability to just read a local file into a string with a simple API call. It's this way, again, because in production the program has to reason about paths and file systems and can't make assumptions about the validity (or size) of the file you just want to load and play with.

In production code, no matter the language, you have to guard against these issues. The nice thing about typed objects (immutable, anyway), is that once constructed and validated, they do not require tedious validation at every method and client they are passed into. That actually results in less boilerplate, and less test writing.

So just remember, Java always assumes your code is production-bound and requires upfront planning and checking. That's why it's unpleasant to prototype with.

Java is just not made for quick prototyping. In production, the URL will come from somewhere, not written by hand, so it would need to be checked anyway. Sadly there's no quick-prototyping mode in Java where you can say, just call this URL string an don't bother checking.

Another example is the inability to just read a local file into a string with a simple API call. It's this way, again, because in production the program has to reason about paths and file systems and can't make assumptions about the validity (or size) of the file you just want to load and play with.

In production code, no matter the language, you have to guard against these issues. The nice thing about objects (immutable, anyway), is that once constructed and validated, they do not require tedious validation at every method and client they are passed into. That actually results in less boilerplate, and less test writing.

So just remember, Java always assumes your code is production-bound and requires upfront planning and checking. That's why it's unpleasant to prototype with.

It's interesting that the Eclipse devs were not aware until now that users actually don't like using it.

This is encouraging news. I hope the rest of the industry catches on to IntelliJ tooling.

Being offered Eclipse/Netbeans tools is the equivalent of getting a Dell laptop for work.

This is interesting, a lot to ponder. Will $7000 seem reasonable once hordes of graduates hit the market and commoditize the profession?

Or is CS a good fit for only a limited number of people, regardless of price?

It's fascinating that this field, which is difficult because it requires precision, lends itself so practically to automatic grading online.

As exciting as MOOCs are, will we be bound to use them in what's left of our free time just to keep up?

The entire casino business model relies on bugs in the human mind.

It makes sense to support IE 6 when you sell a product to an enterprise, the UI is task oriented and doesn't have to be pixel perfect to entice users.

The trick is to make supporting IE 6 cost effective. You can still use semantic markup and CSS layout, it would just be a simplified version of what you serve modern browsers. It's called graceful degradation, and with a well defined templating system, it's feasible without laborious adjustments and hacks.

Some enterprises really can't upgrade, and if you are willing to support that one troublesome browser, you can still sell the product behind it, which can be innovative and useful.

It would be more realistic to compare the iPhone with the Galaxy, which is also sold for profit.

The Nexus 4 is sold at a loss or barely break even, following the same model as Amazon's Kindle line. It's a class of devices sold using a different business model, regardless of Android.

It remains to be seen whether these can be manufactured at scale--it costs to commit to large scale production, which can be seen in LG's inability to deliver Nexus 4 devices at launch. And it is also doubtful that they can remain competitive over time. Other loss making devices such as game consoles don't see frequent hardware revisions.

Dave's long-time software, Radio Userland http://radio.userland.com uses a local server to serve the UI of a blog publishing tool. I surmise it published this site, and this is an artifact.

In the dev console you can see that this script actually failed to load.

Please have mercy on iPhone users' eyes and specify font-sizes in em

A couple of peculiarities in the study that place Java at a disadvantage:

1. Examples using outdated low level concurrency primitives such as wait and notify. Use of java.util.concurrent would have made the code much more terse and safe

2. Java performance affected by use of the outdated java.util.Stack class. It is well known that this class uses redundant synchronization. The docs recommend using a Deque implementation instead.