ant5

I can only say that memorizing a large passage of shakespeare was demanding and interesting to me in ways I hadn't anticipated, yet still easier than I expected, and the passage and (positive) experience has stuck with me since junior high school (... and that's a long time).

Shakespeare is clever, bawdy, and often amusing, and you have to be even more clever to understand it. A lot his wordplay is based on idioms no longer in active use.

Take, for example, Act 1, Scene 1 (http://www.shakespeare-literature.com/Romeo_and_Juliet/2.htm...)

SAMPSON

  'Tis all one, I will show myself a tyrant: when I 
  have fought with the men, I will be cruel with the 
  maids, and cut off their heads. 

  The heads of the maids? 

  Ay, the heads of the maids, or their maidenheads; 
  take it in what sense thou wilt.

Or Act 1, Scene 3

NURSE

  And since that time it is eleven years; 
  For then she could stand alone; nay, by the rood, 
  She could have run and waddled all about; 
  For even the day before, she broke her brow: 
  And then my husband--God be with his soul! 
  A' was a merry man--took up the child: 
  'Yea,' quoth he, 'dost thou fall upon thy face? 
  Thou wilt fall backward when thou hast more wit; 
  Wilt thou not, Jule?' and, by my holidame, 
  The pretty wretch left crying and said 'Ay.' 
  To see, now, how a jest shall come about! 
  I warrant, an I should live a thousand years, 
  I never should forget it: 'Wilt thou not, Jule?' quoth he; 
  And, pretty fool, it stinted and said 'Ay.' 

It's crude, inappropriate, and -- at least to me -- pretty damn funny, in the story's context. It also has a hell of a lot to do with "words arranged in a particular order", and the nuances of the meanings of words. Memorizing it forces you to study the text more deeply than you likely have before.

I've never made use of Shakespeare as a programmer, but I still remember reading his works in school -- and the significant appreciation I had for the art and cleverness of it. I even memorized the entire Queen Mab Speech for extra credit (I'm glad I didn't refuse!). It did help that I went to a private school where the teacher was intelligent enough to explain the word-play to us, and didn't avoid the less appropriate aspects of it.

The number of people that will try to hack it is vanishingly small, but it only takes one.

Once that one person gets their hack working, the number of people that have no idea what they're doing but will still install a hack developed by someone else is surprisingly large.

... "Therefore bricking hacked phones is a good thing" at the end

Therefor, bricking hacked phones is their prerogative, it truly doesn't matter to me or 99.99% of the people buying their devices, and if someone does care, they should buy a device from someone interested in serving the tinkerer market, rather than trying to jury-rig a product from a company that clearly has no interested in supporting your endeavor.

Only if we assume your initial premise. How about this one? The average consumer is never going to try to hack their phone unless someone more knowledgable than them provides the instructions and resources necessary to do it. In other words, average consumer using the phone will never, ever, ever have a bricked phone because of some sort of anti-tampering device.

Motorola wishes to sell a device with a certain set of supported functionality. They do not wish to invest effort in dealing with hacked versions of their devices, and in fact they seem to have contracts with carriers that require them to protect the devices.

Motorola sells you a device that does exactly what they say it does. If you don't like the feature-set of this device, then don't buy it -- Motorola is not required to sell you an open platform and you't not required to buy their closed one.

That really doesn't make any sense.

Cars aren't phones. The cost of installing a new engine is very different than the cost of installing a phone hack, the set of people likely to do so (and the associated cost to the manufacturer and other vendors) isn't the same, and there's going to be a lot more consumer awareness about what they're doing by replacing the engine. And really -- modern cars are locked down.

As well as the intangible costs of what customers think and say after things go wrong. Look at how Mac application developers respond to things like Usanity's Haxies.

As a vendor, dealing with hacks, jailbreaks, and other such things is remarkably expensive. Consumers (not developers) wind up installing these things without understanding the implications of what they're doing. The OS breaks, the applications break, things go haywire, things go bad. The hardware vendor, the OS vendor, and the application vendor all take the blame and have to deal with the support costs. We get support e-mails all the time that can be traced to iOS jailbreak-induced issues.

It's a massive pain in the neck that, understandably, a vendor just doesn't want to deal with.

Moreover, as a consumer, it's incredibly wasteful to be spending so much time on trying to break into undocumented systems that the vendors just aren't interested in supporting.

Instead, I want to support vendors that provide more open platforms for a more premium price. It costs more to produce an open, supported platform, and I don't mind paying a little bit for an Android development phone that allows me to experiment with OS-level work, or something like the Ubiquity RouterStation Pro[0] as an alternative to consumer wireless routers. The advantage to me is that hacking the device is supported and I don't have to fight with a consumer manufacturer -- a company with very different priorities to my own -- to do it.

[0] http://www.ubnt.com/rspro

The primary advantage here is that you don't have to coordinate generation of new images just because someone, somewhere requires a specific size in some client of your image system.

Of course, just stick a CDN in front of your on-demand scaling implementation, potentially backed by S3, and you're done.

What's your name? What do you do? Would you like a dance?

What's your name? What do you do? Would you like to find out more about our F5 internet appliances?

Being sold something by an attractive woman with an ulterior motive raises my hackles and causes me to put up my guard. I'm certainly not going to be receptive to the sales pitch.

Thanks for replying. Congratulations on the investment, and I hope this works out for you and your company.

However, in my experience, nobody gives you $60 million (or $6 million) dollars and doesn't expect to have their finger in the pie. Everyone -- CEOs, the board, the investors themselves -- always says that they don't want to change a thing about a company, but how can you really avoid a shift in incentives when you hand over a board seat and start spending other people's money?

Whether or not that priority shift will be a good or bad thing is relative to who is asking. Often, there's surprisingly little alignment between what is good for the founders, the customers, the employees and the investors.

Regardless, I wish you all the best, hope you can keep doing things the way you want them to get done, and hope we can continue as Atlassian customers.

I can't speak to the financial implications for their company, but as a customer, the move was terrible. Their prices got jacked way up, they dropped all their offerings in favor of what they saw as the product likely to provide the highest return, invested a ton of that money in sales and marketing, and their service and quality plummeted.

They switched to a subscription software licensing model, stopped listing prices on their website, added a "Solutions" tab next to "Products", etc.

I never understood why they took the money, but I understood why those changes came with the money. As a customer, I hope Atlassian doesn't go down the same road, but given the amount of money and the actual scope of the products they work on, I can't help think that it's an inescapable path.

s/annoying/_expensive_/

but it's better for the language and the ecosystem to keep evolving.

Of course it's good for things to evolve. But you're painting a false dichotomy here.

Scala is taking the correct route here.

In the short-term? Just once? That may be true due to just how broken some things were.

In the long term? It's a very expensive thing to be breaking everyone's code and binaries.

Is that a real question or were you just setting up your false dichotomy via some well-placed rhetoric?

Where everything is shit because of backwards compatibility?

Oh, so that's why Java is so bad? Because it has some stagnant corners in which they're maintaining backwards compatibility? That's silly.

Backwards compatibility isn't holding back Java the language, or even Java the VM. Bad design decisions and an almost knee-jerk opposition to any forward progress holds Java back. You don't have to break compatibility to implement closures, you just have to herd cats until you can get people to agree on a proposal and implement it.

They've put a hell of a lot of work into making everything as compatible as possible with 2.7

But it's not actually compatible. And it may not be again in the future. And it's really easy to introduce binary incompatibility due to the implementation of traits.

If you look at other production programming environments, from C# to Objective-C, the maintainers bend over backwards to maintain binary and API compatibility across releases because it's bloody expensive to upgrade everything in lock-step, force all your customers to upgrade, wait for all your vendors to upgrade, and move the entire ecosystem to a new version in one gigantic step.

At some point you need to say, enough is enough, we're going to upgrade out and people will have to make minor changes to their source code to get the new features. They had 7 release candidates, so they've made a commitment to quality and given people time to upgrade leisurely.

Upgrade leisurely? To a release-candidate quality language release? Are you joking? Even if we wanted to upgrade to an RC release (and we didn't!), we'd had to wait for the libraries we depend on to be updated too (and wait for time to block development while we upgrade all internal components in lock-step).

I've only ever used maven for Scala projects, but I've come across this sentiment a few times -- it always strikes me as odd, given that I have very few significant maven complaints.

It has all sorts of great tools for automatically fetching dependencies, and doing "the right thing" via some fairly simple conventions. It's really easy to wire up something like tomcat:run to run a war in-place -- or your own custom self-contained code.

I also really like being able to have a local maven repository where we can store our own build products (and declare dependencies against them); server software like Artifactory makes this very nice: http://www.jfrog.org/products.php

Maven isn't wonderful, but build tools never are. I don't understand why you would hate it. Why do you hate it?

However, the lack of API and ABI compatibility is a really big failure. I can't believe that they're shipping what is supposed to be stable software and we can't rely on our code to continue running, much less building.

We had to do a fair bit of work to fix our projects' 2.8 compatibility issues, and it's causing us all sorts of grief in terms of having to do lock-step upgrades of all libraries from 2.7 to 2.8.

Zones and ESX are very different beasts, and de-duplication of memory is only part of the issue when you're talking about virtualization of user-space versus hardware virtualization.

Regardless of what they say, Apple is still claiming new two-character prefixes, including the one I've been using for years.

You work on LLVM? Props to you, if so. Thats an awesome project. However, if you work on gcc, I haven't used that in over a year :-)

I'm a big fan of LLVM, but no, I've done nothing with it. That said, if you're using clang for your production builds, you're a much braver soul than me.

There are still plenty of codegen issues, especially in the new iPhone/ARM support. There's a reason Apple is still using GCC.

http://www.mikeash.com/pyblog/performance-comparisons-of-com...

The long method names don't bother me.

If Apple developed a first-class alternative to ObjC I would switch in a heartbeat. In the meantime -- to write Mac/iPhone apps -- I will continue to use it.

You just wrote exactly the same thing I did, but in a style that triggers GCC warnings regarding using assignment as a truth value.

Huge advantage of this is that you can implement object pools, singletons, etc. transparently.

You might consider looking into Newspeak constructors to see how it can be (much) better done, with much less code.

In short, treat constructors as class methods, allow them to be used interchangeably, support self-types so that you can't get selector conflicts, enforce calling of the constructor so you don't have to rely on documenting the designated initializer.

Apple is now suggesting that you use three-character class name prefixes, since they claim all the two character ones. I had my two character prefix claimed by a new private framework Apple added to iOS, and now one of my class names conflict with one of theirs. Kaboom.

If you go the no-prefix route, your code isn't library-reusable since other people will do the same thing, and you will still get screwed -- Apple regularly claims non-prefixed classes in their code, too.

My assumption is that you simply don't grok it, that you haven't learned how to utilize dynamic dispatch, KVO, etc. to greatly simplify and streamline your application designs. Or you are one of those script kids that takes all the low level shit for granted. This isn't python. This isn't ruby. This isn't even smalltalk.

Seeing as you're writing ObjC using a compiler I've worked on, I think that probably understand the "low level shit" better than you do.

  + (NSString) stringWithFormat: (NSString *) format, ... {
      NSString *string;
      va_list ap;
  
      /* Fetch the arguments */
      va_start(ap, format);
      // Could iterate over the arguments yourself here, or just use:
      CFStringRef cfString = CFStringCreateWithFormatAndArguments(NULL, NULL, (CFStringRef)format, args);
      string = [NSMakeCollectable(cfString) autorelease];
      va_end(ap);
  
      return string;
  }

The memory management model for the iOS platform is not GC, and it's not manual management. Frankly I found manual management of memory simpler than retain/release. And the autorelease pool? That's just wrong.

retain/release + autorelease pools solve the ownership problem inherent in manual memory management system. You can return a heap allocated object from your function/method and neither you nor the caller have to be concerned about how it will be cleaned up.

Not sure what's wrong with that solution -- I've even implemented/used an equivalent implementation for pure C code.

Language research has progressed. Microsoft has invested heavily in C# and related technologies. Even Smalltalk research moved on -- strongtalk, newspeak. We have alternative, real-world usable languages running on the JVM, from Scala to Clojure.

Yet Objective-C moves forward one slow, stuttering step at a time. There are no namespaces. There are no self types (your init methods all have to return id so that they don't conflict with other init methods that have the same name). There are no private methods. Writing an initializer takes 3 lines of boilerplate, every time, plus the header declaration:

  if ((self = [super init]) == nil)
    return nil;

  return self;

Nuke it from orbit. It's the only way to be sure.

Anyone who thinks ObjC is a good language either hasn't actually spent significant time outside of C/C++/ObjC, or is still new to the wide, wonderful world of Mac/iPhone development.

Many programmers do love SQL. It's not a perfect solution, but it's better than most of the via alternatives.

Anyone that "hates" SQL should be forced to read C.J. Date's Database in Depth, after which, if they still hate SQL, it will at least be for the right reasons.

http://www.amazon.com/Database-Depth-Relational-Theory-Pract...

The problem here is that you stop thinking about your data as an independent thing that must be designed for long-term persistence.

Code itself should be mutable, easily changed and modified. The on-disk data is the opposite of this -- it must be iterated on carefully, and its requirements must be clearly defined as to be supported in the long-term.

I'm very wary of tools that do not make it easy to explicitly and rigorously define the data model entirely separately from the object model that will be used to represent it in a specific version of one application.

I think tools like LINQ are valuable because they make working with relational algebra and projections cleaner, but do not abstract the fact that you are working with a long-term persistent data store that is not the same thing as your comparatively short-lived object graph.