Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New iPhone Agreement Bans Flash-to-iPhone Compiler & Others

daringfireball.net

Post reply on HN
Print view View original

441–450 of 495 posts

Re: New iPhone Agreement Bans Flash-to-iPhone Compiler & Others

#441

Post by catch23 »

theBobMcCormick wrote: post #158
axod wrote: post #115

Earlier quoted context omitted.

Surely there's also the approval process? Checking an app isn't doing anything malicious may be easier if it's written with standard tools.

I don't see how. They don't ask for source when you submit your app, so it shouldn't matter at all what language you "originally" wrote the app in. This is just a bullshit control-freak move. Apple has stopped looking out for the interest of it's users and has started looking to punish it's competitors. Epic fail.

You mean Apple has stopped looking out for the interest of it's developers... If anything, Apple listens to their users better than any of their competitors. Try convincing an average 17 year old girl to buy an android/zune over an ipod touch for her music.

I think the situation will only improve when Google actually cares about their users and less about the cool tech that comes with every phone.

Re: New iPhone Agreement Bans Flash-to-iPhone Compiler & Others

#442

Post by tumult »

catch23 wrote: post #437
tumult wrote: post #317

Earlier quoted context omitted.

Easy is not always powerful or expressive.

ObjC is more expressive than you think. It has the same metaphors of duck typing that ruby/python/javascript have come to adopt. You can do mixins & monkey patching very easily with ObjC as well. I would say ObjC rates very well in terms of flexibility of development. ObjC is definitely more enjoyable than Java or C++ and just slightly less efficient than ruby/python. ObjC feels closer to ruby/smalltalk than it does…

I've written an Objective-C compiler and runtime myself, so I think I am familiar with its limitations. Monkey patching is a terrible idea and you should avoid ever seeing that stuff in production. Objective-C is 'flexible' but dangerous in that it does not offer much in the way of type safety, and relies on handling unrecognized messages at runtime to deal with both unexpected conditions (exceptions) and also errors made by the programmer (type errors, undefined behavior, null objects, etc).

Objective-C has only a small fraction of the potential performance of C++ so should not even be compared with it. They are in completely separate categories. Objective-C is used primarily as a higher-level glue for routines written in C. You cannot write all of your routines in Objective-C all the way down, because the performance is dynamic and often worse than languages with smart VMs. LuaJIT, MacRuby, and several others all have better performance (in terms of function dispatch, calling, etc) than Objective-C. If you want Objective-C code to perform well, you just start using C stuff instead of Objective-C classes and methods.

Re: New iPhone Agreement Bans Flash-to-iPhone Compiler & Others

#443

Post by strlen »

joubert wrote: post #211

I want to code in Objective-C, and I don't think Android allows that, so I'm stuck programming for iPhone/iPad. I wish Google will support Objectice-C calls against their APIs.

Afaik, Android has a Native SDK which means you can incorporate C code: http://developer.android.com/sdk/ndk/index.html -- I'd imagine, if you can get some cross compilation done with Obj-C it would work, as long as your output was a JNI library.

You could use a JVM-based "close substitute" (e.g., Objective J->JS->Rhino) for the UI portion, which makes JNI calls to an Obj-C backend.

Re: New iPhone Agreement Bans Flash-to-iPhone Compiler & Others

#444

Post by jrockway »

lispm wrote: post #381
jrockway wrote: post #287

Earlier quoted context omitted.

Android is completely Free Software. You can compile the git version and install it on pretty much any Android device. If there's spyware, delete it and recompile :) And your less paranoid users can just grab your software from your website, and run it on their "stock" devices.

true, but I don't want to support a company that does not respect privacy and collects data without any control - I also don't have the time to inspect their code

So what's your solution, "do nothing"? Typical lisp programmer...

Re: New iPhone Agreement Bans Flash-to-iPhone Compiler & Others

#445

Post by AlisdairO »

Silhouette wrote: post #421
AlisdairO wrote: post #365

Earlier quoted context omitted.

Because they don't have a monopoly on smartphones. They control their own platform, but as long as there's a reasonably competitive smartphone market out there, it's not illegal.

But aren't there really three markets here? First, we have the hardware, and as you say, Apple is certainly in a competitive market with its iPhone offering. Then, for each type of hardware, we have the software that runs on it. Anyone could write software to run on Apple's hardware, but because Apple lock down the phone and run the only app store in town, they have a de facto monopoly on the supply of software to iP…

'Software that runs on the iPhone' is, in the end, too narrow a window to consider for antitrust. If the iPhone were the only smartphone game in town, then the situation would be different, but as things stand, it's not.

Re: New iPhone Agreement Bans Flash-to-iPhone Compiler & Others

#446

Post by strlen »

Don't forget another possible explanation: Objective C, C and C++ are difficult languages, meaning there's a barrier to entry. Apple may also want to prevent application development from becoming a commodity: they don't want "widget shops" employing warm bodies to churn out low-value applications.

Of course, I disagree with this approach: there already are widget shops. It's possible to program in a language without knowing it, by writing it non-idiomatically resulting in buggier, slower code that takes longer to develop and is difficult to maintain. The fact that they write in languages that take longer to develop an app in would just mean they'll choose "low quality" while still maintaining the same quantity.

Re: New iPhone Agreement Bans Flash-to-iPhone Compiler & Others

#447

Post by pdubroy »

Bones wrote: post #321
wvenable wrote: post #278

Earlier quoted context omitted.

I can't stand the Mac UI. In every way that it's better than Windows, there's some way that it's worse. The dock is a terrible interface element and having a menu at top the of screen may have made sense when screens where 512×342 pixels but makes little sense with giant resolution screens and multiple monitors. I'd say the all user interfaces from all vendors suck, including Apple.

There’s a reason it’s at the top of the screen, and it has nothing to do with screen resolution. Try looking up Fitt’s Law ( http://en.wikipedia.org/wiki/Fittss_law ). Essentially, the menu items are infinitely tall hit targets… no matter how fast the mouse moves towards them, one can never overshoot them vertically. Menus in Windows and most *nix environments require both horizontal and vertical precision. Furthermo…

It's only true that you can't overshoot them if your trajectory is perfectly vertical. With a diagonal trajectory (which is usually the case), you can still overshoot the item you were aiming for.

Also, Fitts' Law says that the time to select a target is proportional to the distance and the size of the target. Putting the menu on the edge of the screen makes the effective size of the targets bigger, but in some cases it also means that they are much further away.

As I type this, the menu bar is about 4x further away than the top of my browser window.

Re: New iPhone Agreement Bans Flash-to-iPhone Compiler & Others

#448

Post by jrockway »

wisty wrote: post #330
jrockway wrote: post #288

Earlier quoted context omitted.

As an Emacs developer, I can tell you with 100% confidence that the C part of Emacs is utter crap. The good news is that there isn't very much of it. The rest of the software is buggier than it should be. My web browser has remotely-exploitable security holes. Random drivers in Linux randomly regress as the version number increases. OS X and Windows 7 crash for no reason, and don't support enough hardware. The only p…

Xmonad claims to be about 1000 lines of Haskell. I'd say that's equivalent to about 10-100k of C. It doesn't crash because it's simple, not because it's written in a good language. Well you'd probably have 100X as many bugs in a C program (it takes 10X as many LOC, and I bet bugs scale with N^2), so Haskell is a bit better, but language isn't as important as scope. Big programs have more bugs.

Actually, it doesn't crash because a theorem prover was run over the code to prove that it wouldn't crash. I believe some obscure stackset crashes were preemptively found this way.

http://neilmitchell.blogspot.com/2007/05/does-xmonad-crash.h...

Re: New iPhone Agreement Bans Flash-to-iPhone Compiler & Others

#449

Post by eru »

bdotdub wrote: post #439
eru wrote: post #434

Earlier quoted context omitted.

Sure. But it seems silly from Apple to restrict all iPhone developers to a (very) short whitelist of languages.

Howso? They've spent the money and the time to create a great platform. It seems well within their rights to dictate a lot of the rules around what goes on the platform they created. And as mentioned above, they dont have a monopoly in the market so, from Apple's perspective, 'if you don't like it, there are other opportunities' ... developing for the bberry :)

Oh, I never questioned their right to do so. My comment was meant literally: They look silly to me.

Re: New iPhone Agreement Bans Flash-to-iPhone Compiler & Others

#450

Post by jrockway »

eru wrote: post #392
l0stman wrote: post #351

Earlier quoted context omitted.

To be fair, the part of Emacs implemented in Lisp looks nothing like poetry. I wouldn't qualify it as ``utter crap'' but it's a lot messier than I thought. Some of the default packages looks like straight C code translated verbatim to Lisp. My take is that even if it's easier to screw things up in C, that doesn't mean that if you program in a higher level language, you'd automatically produce elegant code.

Emacs Lisp is a mess. It doesn't even have lexical scoping.

The development version does.

I can tell you, though, that this doesn't really matter in real life. The compiler warns you when you use a free variable, so it's pretty hard to accidentally misuse a dynamic variable. There are pathological cases that people point out, but these rarely matter in elisp that most people actually write.

Programming Emacs is a little different from programming other systems, but once you use its idioms instead of the ones you took from your favorite language, everything works quite nicely.

Post reply on HN