Hacker Newsnew | comments | show | ask | jobs | submit | _frog's comments login

The problem here isn't with JavaScript in particular, but the complete lack of other options. When you're limited to a single language, what you end up with is a software engineering monoculture.

-----


>>When you're limited to a single language, what you end up with is a software engineering monoculture.

Really? There are a plethora of JavaScript frameworks out there, mostly client-side but also some server-side, each with its own distinct culture, and new ones are coming out all the time. And each framework imposes its own way of doing things, and that attracts different types of people and creates a different culture.

In fact, the JavaScript ecosystem is so vibrant and diverse right now that "monoculture" is the last word I'd use to describe it.

If you want monoculture, look at Ruby. (Don't get me wrong, I love Ruby and it's my favorite language, but it's basically dominated by the monoculture of Rails.)

-----


I think you guys are using the word monoculture to mean different things but you share a common worry.

_frog is worried by a language monoculture, having to develop for a platform in only one language: the platform mandates the language. Other examples: Java for Android, Objective-C for iOS (Swift now).

You are worried by a framework monoculture, Rails dominating Ruby. That has no parallel in the JavaScript world. Other examples: iOS development dominating Objective-C and Swift?

The common worry is that monocultures harm their environment (JavaScript harming the web and Rails harming Ruby).

Given the success of Rails and the JavaScript-based Web one wouldn't say any of those type of monocultures are bad for making money (and look at real monocultures in agriculture and animal farming) but farming teaches that if you don't have enough diversity you are exposed to problems.

Being able to program the web in many different languages would be both good (pick the tool you like most) and bad (example: "sorry, I can't take over this webapp because it's written in OCaml and I only do Ruby and Elixir, find somebody who knows OCaml") but not different from what we always did when developing for the desktop and the web server. Both did well. If we're heading there we'll cope with that (customers will stick with the "big" languages, as usual).

-----


Funny you should mention that. Quoting Apple's own docs:

> Objective-C lightweight generics are ignored by Swift. Any other types using lightweight generics are imported into Swift as if they were unparameterized.[1]

So it doesn't look like the goal here is Swift interop.

[1]: Excerpt from Using Swift with Cocoa and Objective-C (Swift 2 Prerelease) https://itunes.apple.com/us/book/using-swift-cocoa-objective...

-----


From the talks today it seems Swift interoperability was indeed the purpose.

-----


Are you talking about the thing where going fullscreen places the video in a new virtual desktop? Because if that's the case I vastly prefer that behaviour. It makes it much easier to jump back and forth between watching a fullscreen video and reading content in other browser tabs.

-----


No.

I am talking about thing that you zoom into YouTube video and it shrinks.

Virtual desktop feature is nice, although not related.

By the way, I was talking about YouTube being broken, not Safari. Haven't seen such behaviour with any other HTML5 player other than YouTube.

-----


I actually distinctly remember getting a copy of Metal Gear Solid 2 and being confused why I couldn't start the game. Hitting any button on the splash screen would take you to the menu, and then hitting X from there would take you back to the splash screen. Having primarily played western games up to that point, it didn't even occur to me that another button could be used for 'confirm'.

-----


It seems like Sony, being a Japanese company, originally intended for O to represent yes, and X to represent no. If you look at a lot of early PlayStation games, or most modern games released in Japan, that convention is apparent. The O and X buttons on the PlayStation controller even match the placement of A and B buttons on Nintendo's controllers, providing a clear analogue between the two.

I'd be curious to know what caused that convention to change in the west.

-----


> I'd be curious to know what caused that convention to change in the west.

The XBox controller has a swapped A/B pair and uses A confirm B cancel.

-----


The XBox controller is a clone of the Dreamcast controller. If you go back even further to the Megadrive, it had 6 buttons (on advanced controllers) with two rows of buttons - xyz and ABC arrayed from left to right.

When the Playstation 1 was released, the two consoles consumers could have been familiar with in the west were Super Nintendo and Sega Megadrive. SNES had the familiar ABXY, but mirrored with AX on the right. It used A for yes and B for no. The Megadrive had the aforementioned ABCxyz and also used A for yes and B for no. Meaning, one console used the bottom button for yes and the one on its right for no (Megadrive), while the other had the bottom button for no and the one on the right for yes (SNES).

So I doubt SONY copied the competition for their decision to swap the yes/no buttons.

-----


>SNES had the familiar ABXY, but mirrored with AX on the right.

Those of us that grew up with Nintendo consoles would say that B on the left of A is the natural order of things ;)

>Meaning, one console used the bottom button for yes and the one on its right for no (Megadrive)

Actually, almost every Megadrive game I've played lets you use both A and C for accept in menus, so you could use whichever orientation you were more comfortable with.

-----


I am just quoting another instance from around that time, besides this is all kind of moot since:

> I doubt SONY copied the competition

IIRC this wasn't decided by SONY, each game used its own variation until a standard was created organically.

-----


Makes sense to me. We have scan sheets and forms with empty bubbles and boxes meaning, "not this one," and we put a check mark, X, or other mark in them to indicate our selection.

-----


That may be the case, but there's many contexts where you'd use this button where you can't alter the page's CSS. Perhaps the prime example being GitHub READMEs.

-----


I'm not sure if there's been any changes regarding signing, but I can confirm that VirtualBox has been working fine through Vagrant for me.

-----


VMWare has an early access Fusion update that works, you can download it from their support site. Works okay for me so far.

-----


I've had luck installing most Ruby gems used by my projects. The only exception so far has been Nokogiri, and even in that case there were instructions on the project's web page that got it to install without a hitch.

-----


There seems to be a fundamental misunderstanding here about what Apple's HealthKit is. HealthKit is simply the name for the API framework Apple is making available to developers, following in the naming conventions of UIKit, WebKit, SpriteKit and so on.

HealthKit is not, however, a name that consumers will ever actually come across in using their device. Apple's own app on top of HealthKit is simply called "Health", and I highly doubt the string "HealthKit" appears anywhere in that app's UI.

-----


Apple is still using 'Healthkit' as a brand, even if that brand is only targeting developers rather than users.

Moreover it is a piece of software and falls within the same trade mark class (different people can trade mark the same word in different classes of business).

There is a clear conflict with the existing brand, that is likely to cause confusing and diminish the untility of the existing brand. Apple should change the name.

-----


True, but the HealthKit.com can't really establish any sort of claim to the IP - the name is both generic and descriptive and is therefore ridiculously hard to protect without huge traction.

-----


So is App Store, but Apple fought pretty hard to retain that one.

-----


This is a good qualification, but not all "products" need be consumer-facing products. That's just a play on words for "retail" sales vs business or professional sales.

Its a seperate point to say its a 'feature' not a product and thus is not actually sold to anyone (and thus distinct).

-----


It's a huge distinction if formal legal action happens because Apple can establish quite easily that they have relied on the Kit format for previous software, whereas HealthKit.com doesn't (AFAIK) have any major traction in the software space. Law student here, IANAL, so take this with a huge grain of salt.

Either way, in Australia, both parties would apply under Classes 9 and 44 which covers all computer software and medical services respectively. It's likely that Apple will win on class 9 as "Kit" is far better known in the software community than "HealthKit.com"; and arguably 44 too, depending on Healthkit.com's traction in the medical field.

It's unlikely that Apple's HealthKit and HealthKit's HealthKit would cause confusion in the market - but it makes a silly story to say that Apple's Health (which may have overlapping functionality with the preexisting HealthKit).

Gotta love the media.

-----


And regardless, there's unlikely to be overlap between the markets for these two products. HealthKit.com is somewhat hard to navigate, but the impression I get is that their product is aimed at medical practitioners. I doubt they overlap with the mobile developer demographic to any significant extent.

Though I'm curious to hear from someone with more legal knowledge than me: would the fact that there's very little chance of collision between these names protect either party from legal repercussions?

-----


What about the effect of search engines on brand value? Whereas, before, the existing HealthKit was probably the top result, after an invasion of Apple HealthKit development sites they may be kicked to the third page hellban.

Naturally, this same reasoning can be used to challenge the use of the same trademark in a different domain, something clearly accepted by law.

-----


The fact that has Apple has more money than they know what to do with is the real factor for legal repercussions.

It's one thing to have theoretically defensible IP, and other thing entirely to actually be able to.

Assuming equal resources backing the legal teams, it would probably be sufficient that they are both forms of software, as all software trademarks are lumped together in the single category. There might be some sort of passing off action one way or another but it would be more likely to come from Apple than HealthKit.

There seems to be overlap between the Health app and Healthkit.com which I suppose is the real issue. Hard to tell if Healthkit truly got sherlocked though, because I can't tell what they do from their website past management software.

-----


The second example how OS X has handled dropdown menus for some time now and it feels like a perfect compromise. Menus will pop in instantly, and fade away when they're dismissed.

-----


You're right! I hadn't realized http://i.imgur.com/83usTG1.gif

-----

More

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: