I think your warnings about complexity in the type system are prudent, but your comment about casting is off. Casting (with the exception of primitive types) is a very blunt hammer to bash your way out of a type system. The MLs have a simple type system, yet you almost never need to cast. It's worthwhile from a language design perspective to try to eliminate the need to cast entirely, and I believe you don't have to complicate your type system to do so.
Also, you note that "many people prefer static typing", but then you suggest Clojure...
Well, avoiding casts AND supporting inheritance AND having a simple type system is pretty hard. You can usually just pick two of the three.
Many prefer static typing, and many don't. BTW, Clojure is indeed dynamically typed, but it has a "type philosophy" that keeps things nice and orderly, namely no encapsulation and uniform data access.
Java avoids casts in most cases with generics, it supports inheritance, and it has a simple type system. Ditto with C#. (I also haven't heard people complain about the complexity of F#'s type system, so I'd point to it, but I don't know F# enough to be able to say whether it's a good point or bad point in the space here.) OCaml also supports inheritance, although its object system is kinda weird (in that it doesn't really fit with the rest of the language; I wouldn't say it's overly complex though).
Basically I don't think that Scala's complexity should burn us on type safety in general. I think Go and Dart, for example, are an overreaction to the complexities of type systems like those of Scala (no generics and null pointers in the former, and unsound covariant generics and null pointers in the latter). There is room for a statically typed language that brings the benefits of type safety that make programming easier without the complexities that make programming harder; the fact that we haven't found that sweet spot yet doesn't mean that we should just throw up our hands. I'm not convinced that the sweet spot is either unsound or requires casts.
Java was designed as a reaction to the complexity of C++. Scala was, in turn, designed as a reaction to the simplistic nature of Java. It sounds like you prefer minimalism, and in that sense Java is a better choice for you. That's what it was designed for: simplicity.
Oracle's primary concern isn't to rewrite Java or to spend resources to make Java awesome enough to compete with the latest stuff that is coming.
Their fundamental concern is to milk Java as much and as long as they can to drive their sales for Oracle DB and associated business products. And that makes perfect sense too, they are in business to make money anything else and they won't be doing their job properly. Don't you see what has become of Sun Microsystems? They were making awesome stuff by the day for somebody else's profits. Oracle is not going to make the same mistake again.
Java is oracle's strategic investment in using that as a leverage to drive sales else where. And looking at their segment, its mean't mostly for large corporate programmers and not hacker, start ups and alike.
I bet IBM makes sufficient contribution to COBOL still just to keep their mainframe sales alive and not because they want COBOL to be awesome enough to rule the world.
Similarly Oracle's contributions and investments to Java are going to be for driving their sales not for sake of making Java awesome.
I basically agree with almost everything you wrote here and in the other long one you posted replying to me up thread.
But I downvoted you because this has almost nothing to do with ootachi's comment about the realities that the designers of generics had to cope with. You're just regurgitating the same criticisms that has been leveled against Java for years.
ootachi was was referring to the designers of Java generics, who were working sometime before Java 1.5 was released in 2004, long before Oracle bought Sun.
Why would you move from Haskell to Go? There's a night-and-day difference between them. I don't understand why you'd switch to a language because of the features it's lacking, unless you think those features are a bad thing (and I have yet to see a reason why generics and TCO are a bad thing).
Of course they are not a bad thing. It's just that Go has character. It doesn't have generics or C++-style classes just because every other language has them. I respect that.
Up until the point you want to return an object from your container, sure. Then you have to return a Comparable and the user has to downcast it into the right object.
I see a lot of very good reasons for Google not to lose time rewriting Chrome in Go, even without thinking about webkit, but do you have a reference to support this "200ms" assumption ? I never observed this in my programs (which doesn't have the kind of brutal allocations that a browser must have) so I'm curious.
ootachi does seem to like to pop into discussions about Go, throw around statements about Go's GC as if they were facts, despite never having used Go.
A 200ms GC pause is entirely possible for a busy, unoptimised server. The question you should be asking, though, is whether it's a problem. And if (and only if) it's a problem, whether the programmer has tried to reduce allocations. The easiest way to reduce GC time is to produce less garbage.
Now you've moved the goal posts. You can write free lists manually in Java as well. Doing so is incredibly awkward in Java or Go, compared to C++ where placement new makes it fairly straightforward (and moreover, you can use reference counting without too much trouble either). You can also use a real-time GC for Java, and you don't have that option in Go. This is perhaps uncharitable, but you're basically saying "our GC is bad, but you can work around it so it's okay".
Furthermore, you're implying that I'm saying something false ("as if they were facts"), but acknowledge that it is "possible". So I'm actually not seeing where I was wrong.
And I have used Go. I didn't like it. I realize I'm in the minority, but there are valid reasons for disliking Go.
You wrote "200ms GC pauses are completely unacceptable for a web browser." That's a bald unqualified statement. 200ms GC pauses are possible in some situations, but you say it as if it's inevitable and unfixable. It's not.
A garbage collected environment does not mean that generating garbage is harmless. Even in the presence of a (hypothetical) perfect GC, generating garbage would still be a major overhead. Go's GC is simpler than Java's GC, and has plenty of room for improvement, but you have much greater control over whether your code generates garbage in Go, which means that the suboptimality of Go's GC is much less significant.
I don't really care whether you like Go or not, or whether you use it. But you keep saying stuff about it that is either untrue or at least misleading. It's almost as if you have an axe to grind.
How do you have greater control over whether your code generates garbage in Go? The only difference between Java's memory model and Go's memory model is that, in Go, you can put structs inside other structs (and unsafe code I guess, and note that you can get some of the "structs inside other structs" benefit from inheritance in Java). That's it. The stack/heap distinction is no different between Go and Java.
The idea that "the suboptimality of Go's GC is much less significant" is just wrong -- Go has the exact same memory model as Java, only it's less well equipped to deal with it than Java is because its GC is so suboptimal. I'm just countering the oft-quoted statement that Go's memory model is somehow closer to the metal than that of Java -- it isn't.
To optimize allocations in Java, you use free lists and make fewer variables escape so they can be stack allocated. To optimize allocations in Go, you use free lists and make fewer variables escape so they can be stack allocated. Java has a wealth of allocation profiling tools available at its disposal. Go has some too. Go doesn't provide anything over Java here.
For me it's OK. I hadn't see this before and I feel that a discussion without those who don't like Go would be dangerously poor. Thanks for your contribution.
I bet most people get the "protected" one wrong, because it's actually strictly less restrictive than package access in Java. That is, protected members can be accessed by anyone within your same package. Do you reject people for not knowing that any class in the same package can access protected members?
If so, you probably just weeded out a huge percentage of Java programmers.
Is this about Java ? In C# that protected would be accessible from derived class but only trough the derived type, and what you described would be internal, ie. allow access from any class in the assembly. Terminology could be applied to C++ but it doesn't have syntax for interfaces and abstract classes.
Altough I like that answer you gave and this sort of "detailed" questions (I don't think the article had that in mind tough), primarily because if you can answer it I would guess that you know Java enough to be usefull without needing any furhter questions. Someone reading trough a textbook might read that but won't remember it unless he knows the implications, and if he knows that he knows Java. And if you don't know it that cool too, there are other questions like this that demonstrate actual expirience with the language/tools vs. shallow textbook trivia.
People don't use Web browsers for video chat. They use Skype. Getting people to change will be hard, especially since the browser offers no real benefits over Skype.
I'm not saying we shouldn't try to get people to change, only that it will be hard and Skype interoperability is a very legitimate thing to want to achieve.
That was before Google Voice+Video+Hangouts. A significant number of people I contact with has already switched to Google because it is much easier to use.
I can't really see how Skype can stay in the game after browsers support VOIP. At the moment if one party doesn't have Skype, it generally means either they end up installing it or (more likely) you abandon VOIP. At the point when you can say "no problem, just go to this URL...", Skype starts to seem pretty redundant. Of course that won't happen immediately, and always the possibility the plan might get derailed somehow, so I'd agree that Skype interop would be good.
They have nat-free servers and their own automatic nat-traversal methods. Even if every single browser supports VOIP, you won't be able to use it between 2 random people using standard home connection. Until we get out of the lack of IPv4 addresses situation there can be no true peer to peer network.
I assumed P2P, since Joeboy mentioned "no problem, just go to this URL...". If you're not doing this in a P2P way, then you need an account with third party and the third party sometimes needs to transfer both your signalling and your audio. That means they need to get money for that from somewhere...
In that case you're pretty much in the same position as with Skype - just without a download. Account, configuration, potential payments, etc. remain.
Edit: Actually now I see a solution - if only one person had an account, this would still be possible and he could start a call by sending some URL. So for the other person this is "just go to this URL". Unfortunately we still need a third party to handle the traffic unless you require the account holder to ensure their network is capable of acting as a server.
I don't understand why. I'm not a networking expert but I have some experience with networking... I mean, I've already tried a proof-of-concept out with a computer behind a NAT router and it worked fine.
Think about 2 devices (A,B) behind routers in different networks. Connections from A end up on B's router since there's no existing connection to match and connections from B end up on A's router. Unless you explicitly configure port forwarding B will never know that A is calling him.
Yeah - that will do, but the TURN operator is a third party. I commented about the situation assuming Joeboy meant P2P connection without Skype or anyone else Skype-like (the URL is the only thing needed). If you're ok with someone else providing TURN and making money on it in some way to pay for the bandwidth, then yeah - that's enough.
I'll be honest, I'm currently abusing the STUN servers that Google uses in their own WebRTC examples and will need to evaluate my own options. I was under the impression that STUN could be used to establish a connection that from then forward was able to be only peer to peer after the connection through the NAT had been established.
The browser offers no benefit? No installation, I can tweet, facebook, text, email a single link that opens an instant video chat with me, that's not a benefit? No user account registration, etc?
There's literally no effort needed to start using it. In fact, with oAuth you can even tie into existing user bases. Chat with all of your Facebook/Twitter friends by authing those accounts and the backend telling you which friends already have it. You get built in userbases for free almost.
There are lots of things that I could do in a web browser, but still don't, yet.
Old habits die hard; that's part of the problem. But also, we're still not there yet, AFAIK, turning browser apps into applications. Sure, I can tweet a link to everyone to video chat with me. But how well will that work if my browser isn't running when they call?
Skype is an always-on native application that doesn't steal a slot in the dock/taskbar when it's not in active use, and also just claims its reasonable slice of memory and doesn't generally go up from there. I keep it running, and people call me or IM occasionally.
My browsers... I generally have Chrome & Firefox and sometimes Opera up at varying times during the day (different browsers because I don't like mixing business with personal cookies, and because Facebook gets its own browser entirely), and they're all closed down sometimes. They suck up lots of memory (my tabs tend to accumulate rapidly until it gets out of hand and I do a cull), and it's pretty frequent that some site's JavaScript gets a bit wild and steals too much processor/bandwidth as well, so I shut them down whenever I can.
So how do I use some browser tab to be always available for calls and IM? If the right browser & tab are open, how will it even notify me when someone's IM'ing me? How annoying will it be to find the right tab, to respond?
The GMail interface is superior to Thunderbird for email, but I still pull two GMail accounts into Thunderbird (along with others hosted elsewhere) because it shows the little envelope in the tray when I have new mail, and I can mouse-over that to see what it is.
Well, and I can still search my entire message history (for 6 diversely-hosted accounts), write emails, etc., while offline, and don't have to provide Google access to my mail server. Etc..
Maybe there are good solutions to all of these problems? But I can't go changing all of my habits every time someone tells me "there's a new way!" -- I have work to do. Generally when I try, I get burned and have to change back.
Addendum -- I'm a technical user. I'm not completely ignorant of the possibilities. So take my reluctance to change, and multiply that by some large factor for everyone who finally got the hang of using Skype to keep in touch with their family overseas....
[immediate edit: I do know that some of these problems are solved; but I need all of them, or something so much better to my general workflow that it's worth the effort to switch and lose whatever I'm losing.]
I hadn't considered the limitations of "you have to have the browser open" as my browser is never closed.
You're right in that some of the problems are solved (I get native notifications of new email in Gmail via Web Notifications and a Chrome plugin that turns them in inotify (or whatever) notifications, and the indicator on my app'd tab in Chrome changes from zero -> one).
I do appreciate the feedback, these were conditions I hadn't even considered and need to account for.
That 'almost' is a lot bigger than you're making it out to be.
With a hypothetical "WebRTC video chat" service, in order to chat with "any of my facebook friends", I need to:
- Give all my data on my Facebook friends to the service in question. (Let's assume for the moment that it's a benevolent hypothetical chat service and I don't have to give up a lot)
- Invite one of my friends.
- Hope that my friend accepts the service accessing their information in the same way (A very big hurdle if it's a service they've never heard of)
Or I could just use Skype, that they're already on.
... It's still a wash in my opinion. There's no account required at all for a WebRTC application. I can send you a link on any service and you're a click away from video chatting with me. The Social Auth integration was just an example of how easy it would be to build off of existing user bases.
Grandparents probably don't note this difference. Skype is decidedly most popular by faraway folks keeping touch, particularly those that aren't terribly computer-savvy.
Grandparents have to be the most likely to understand or benefit from this difference.
Grandma, open the email I sent you and click the link [or] Grandma, Go to "tinyurl.com/5yp7q".
versus,
Grandma, download Skype, find it, run it, walk through the Installer, make an account, login, add my username, then call me. (and even then, this is glossing over a gross number of details that are hard for the unsavvy).
Even if it's already set up, there's no barrier to use of a simple WebRTC-based service assuming it's done correctly.
No; Grandma already has Skype installed & linked to your usernames, because you (or some other relative) did that for her. Probably at the same time you bought her a laptop.
So it's just ring ring "hello?"
Vs. sending an email to tell her to click this link so that you can call her....
If she knows to wake the computer up (or start it up) during your evening hours, that's enough -- Skype starts when the computer starts, unlike a browser.
Skype is easier than email, generally (and Grandma may not bother with email...). You don't even need typing skills. Just click the "answer" button when it rings, or if you want to call me, click my name then click "call".
That's how I set it up for my wife's parents, since 2006 - a not very cheap laptop back then, still works fine (had to be Windows XP). Works good 6 years later.
Then my father, became computer geek late in his years, and I can't even stop his mouth when comes to applications :) - He's bigger kid than me in that respect...
And even further...I bet many in this situation do some sort of Skype lesson during holiday visits.
Granted, I agree with the grandparent here: ultimately, browser-based software would be easier, but you have an entrenched user base who aren't likely to quickly change to new tech.
Everyone already has Skype. That hurdle was overcome a long, long time ago. Skype is an application that is just as ubiquitous as the web browser these days.
Also, you note that "many people prefer static typing", but then you suggest Clojure...