Comment Re:Less ad money? (Score 1) 124
And in the not too distant future, some DRM inside you will disable your movements so you have to watch the ads
And in the not too distant future, some DRM inside you will disable your movements so you have to watch the ads
if( a )
do_a();
Well, in Go you'd have to do:
if( a ) {
do_a()
}
if( a ) do_a();
if( b ) do_b();
You'd probably write it this way then in Go:
if( a ) { do_a() }
if( b ) { do_b() }
case A: do_a(); break;
case B: do_b(); break;
In Go (no real change except it automatically breaks, not sure if I like that yet or not to be totally honest...)
case A: do_a()
case B: do_b()
if( a )
{
do_a();
}
Again, the first example in Go is what you'd write here again because it forces the use of braces.
I can't stand some language dictating how or where I mark-up my code/comments with extra whitespace or terminators.
To an extent I agree, but I've also seen some people who also believe that and their code not only looks like garbage, and/or there's subtle bugs because they did something like this (in C):
if( a )
if( b )
do_something();
else
not_a();
For example, putting the comma in front, makes it dead easy to extend enums, etc. instead of having to dick around add/removing the last comma.
enum Color { __DUMMY_COLOR
, Red = 0
, Green
, Blue
};
I personally don't care for this style. I've also never really heard a compelling argument to make me consider using that style. Back to Go, you're in luck with this example because Go doesn't have a dedicated enum. Instead, you use const.
const (
Red = iota
Green
Blue
)
Maybe worse than ever because it's not just the API they control, but the language.
Sure, they control the language, but it's typically not the language (or even a few of the standard libraries) that is of concern since it's an open specification. Where the, "we might have cause for concern" comes in is all the libraries/API that Mono implements that is not part of the standard (the
Anyways, just thoughts on the issue. See also: http://www.mono-project.com/ECMA
1) The games themselves will more or less not care about Cocoa because they'll use the least that they can to get an OpenGL window open and usable.
2) Non-issue, if it's closed source and the person who buys it complains about the driver being closed but the game not, there are bigger issues that person needs to work on. The 100% FOSS users obviously aren't going to want either. So again, they're not going to complain that a closed source game needs a closed source driver to work. As for the closed drivers themselves, AMD/ATI are descent (if you have hardware that they support) & nVIdia's Linux drivers are quite good. The OpenGL renderer for the games will likely need little to no changes to run on these drivers.
3) Short answer: yes http://www.wolfire.com/humble http://2dboy.com/2009/10/26/pay-what-you-want-birthday-sale-wrap-up/ Long answer: more than likely. The most common complaint I've heard over the years from Linux users is the lack of commercial/popular games that are only available on Windows (or Windows and OS X)
In fact, what happens is that the formal language uses semicolons, much as in C or Java, but they are inserted automatically at the end of every line that looks like the end of a statement. You don't need to type them yourself.
Javascript programs/scripts often has subtle and often hard to find bugs for this very same reason. Douglas Crockford even calls this feature a design mistake for Javascript, and I see absolutely no reason why the same claim couldn't be applied here as well.
One of the big misconceptions by GPL people is they think that if the license is GPL, the potential contributor will be "forced" to contribute back. No, he won't. Anyone that does not wish to contribute will not, regardless of license. He'll either use GPL code, but not distribute, use another project, or roll his own. The GPL did not force anyone to contribute in those cases.
That's just how things go. The not distributing and rolling their own can be hard in situations such as compilers or development tools. Using a different project is always an option, but the same is true in the commercial world. It's the same as choosing a library to use based on the license price, features, whatever. You're going to choose what works best for the project. If not contributing back and keeping the source closed is a deal breaker for the project, GPL isn't going to be an option if you have to release/distribute the program. So you're right, yet, there are still plenty of companies that try to use GPL code without releasing the source till legal action is finally threatened.
By the way, GPL folks, stop being offended for BSD projects when some commercial entity uses their code. It's allowed in the license and the BSD people aren't stupid. They are okay with the use of the code so you should be too. Stop using the Microsoft TCP/IP example. Nobody cared
It's typically not used as an example of them doing anything legally wrong, just more ethically (in their eyes.) GPL advocates at least want the option of being able to incorporate the changes back into the main line, or being able to make further changes to the code that was forked. Someone in another thread said it quite well: BSD gives more freedom to the developers, and GPL gives more freedom to the users. And you're right, the BSD devs didn't/don't care if their code is used commercially without releasing their changes. It's a non-issue to them because they're developers and care more about making developers' lives easier.
I don't really disagree with that, but I did watch the development blogs as KDE 4 was being developed and they painted a different picture of what the KDE 4.0 release meant (at least to them.) I believe the logic behind it was for a couple of reasons. (These are in relation to KDE 4, and not Amarok or Koffice)
Release early release often. This was a cited reason. They didn't want the development life cycle to drag on for another few years just till a perceived stability of a dot release could be achieved. The libraries were at a fairly stable point. The main Plasma was still basically at a tech preview state when 4.0 was released.
Now, I'm not sure how well KDE would have faired if they would have waited till it was at a stable point before releasing. Because it would have been at least a year more. Some devs said KDE 4.2 was the stable release of KDE. I personally feel it was closer to 4.3. In the time from 4.0 to 4.2-4.3, they received a huge number of bug reports and feature requests. I think at least some of these were fixed otherwise the current versions would still be as bad as early versions.
So, it may have been almost a necessary evil for them to release KDE 4.0 when they did and as they did in order to get the large scale feedback they (IMO) desperately needed. There is also the fact that most distributions didn't even begin to pick up KDE 4 as the default until 4.1 or 4.2.
While not entirely proper, namespaces can pretty much be emulated trivially with objects. So I don't really see the issue here, unless you're one of those people who think that the programming language has to include everything for you to be able to use it.
ECHMAscript has had exceptions since 1999 with the release of version 3. Javascript quite possibly had them even before that. What's the issue here?
If static typing is one of your requirements, then you're correct, Javascript doesn't fit your needs.
What's wrong with how Javascript does prototyped-based OO?
Javascript is actually a pretty interesting language once you learn how to use it correctly. There are just a lot of ways to use it incorrectly (which is how it's used 70-90% of the time.) Anyways, feel free to actually look these features that Javascript has had for at least the last 10 years yourself if you don't believe me (or want to further try to justify your statements.)
Kleeneness is next to Godelness.
