Since this is Slashdot, you might as well just refer to Larry Niven's "Known Space" series, where the punishment for large-scale pollution (e.g. using nuclear rocket engine in the atmosphere) was exactly that.

You don't have to provide all the intermediate sizes in an .ico file - you can have one that only has 16x16 and 256x256, for example.

Also, aren't OS X icons bitmap-only as well? My impression was that only Linux DEs have embraced vector graphics for everything.

It is strictly application-dependent. If app declares itself as high-DPI-aware (which they have to do explicitly in the app manifest), then it's expected to properly handle DPI by scaling everything appropriately. Some frameworks do it automatically - for example, WPF. Others do not, but people declare their apps as high-DPI-aware anyway because they don't understand what it actually implies.

It should be noted that this is a strict subset of fractional scaling that Windows has. If you set scaling to 200% in the latter, then you'll get the same integer scaling for non-DPI-aware apps.

Well three problems there:

1) Not really a Rogue kind of guy. It isn't my sort of game. I like more story in my RPGs which does, of course, preclude random generation. It is a tradeoff.

2) When you play a game made for a PC, it doesn't translate well to touch. Touch dictates some things be done rather differently to work well, and these do not have the UI to deal with that.

3) As you said, they are old, I've already played them. I like new games, not playing the same ones over and over for a quarter century.

It still quite supports my and the GP's point about the lack of good games for mobile.

Note that this is not a part of the language itself (a comment is a comment). You can use Doxygen with C# if you really want.

Though I agree that the "standard" syntax for doc comments could be thought out better. On the other hand, the nice thing about XML is that it's an "Extensible" Markup Language. Which is to say, you can use any custom elements that you want in your comments, and the compiler will extract them into the .xml file when it compiles your source code, alongside with other stuff that it does understand. Then you can write custom tools that post-process the binaries, or do various other things, based on that XML.

This comment might explain what exactly C# async/await does that Java futures do not (and why it is a language feature, and not just a library thing).

Some were, some weren't. E.g., how did delegates make it easier to "write code that only ran on Windows"?

The thread, the comments specifically, are actually pretty educational, informative, and potentially valuable. To me that is one of the main reasons that I frequent this site and this thread isn't, to me at least, anywhere near worth complaining about as compared to some of the others that have been approved.

So, having said that, this thread is much better than it could be - which is an excellent thing. The subject, headline, article content, summary, and the likes aren't really that bad. I guess that it is, of course, subjective and all that but it seems like a perfectly acceptable topic for Slashdot and is fitting for this site. I don't think the source of content is of great importance so long as the information imparted is appropriate, contextually related to the general interests of the site at large, and informative.

In this case it appears to have raised legitimate questions which people are interested in. The evidence for this is in the number of replies and in the number of dialogues being had because of this posting.

I'm not trying to talk you out of leaving Slashdot, not at all - I thing you should as pessimism isn't really helpful no matter what, but I'm trying to point out that it your post is illogical in a variety of ways. I think that I should point out that the most important error in reasoning your post includes is that it assumes that people have any regard for your opinion on the subject and that you are assuming we value your presence enough to be concerned with your continued participation. It is, shall we say, unlikely that your opinion(s) are going to influence the content of the site.

But, well, I digress. I think it would have been more simple (and effective) for me to have simply posted, "Well... Bye."

JNI is a platform-independent framework to access platform-specific native APIs. So same end result.

If AWT was "nothing more than a wrapper around Windows API", then how exactly did it work on Solaris and Linux.

Thing is, AWT was a wrapper over the lowest common denominator of Win32 and Motif. That it sucked was inevitable by design.

If you look at Windows Forms, it's essentially WFC (the Win32-specific UI framework offered in J++ as a better alternative to AWT) developed further and rewritten in C#.

And Swing? It still sucks today, but back then, in 1997 and even in 2001, it was a horribly bloated framework that had visible UI lag on all platforms. To add insult to injury, it also looked like crap on all those platforms.

Apparently it is, since this is exactly what GP said happened. The "can't call it Java" thingy that ended up being released is .NET.

I just wrote two comments that try to get into more detail on both LINQ and async.They might come in handy if you don't want to re-word all that yourself over and over again ~

Async in the context of C# usually refers to async/await. If you're familiar with PL concepts, the concise way to describe it is that it takes a sequential algorithm, and rewrites it in continuation-passing style for you, with continuation boundaries explicitly determined by where you put 'await" in your code. E.g. consider this:

s = file.ReadLine();
Console.WriteLine(s);
s = file.ReadLine();
Console.WriteLine(s);

This code is just reading two lines synchronously, blocking the thread between two reads waiting on I/O to complete. If you wanted to avoid blocking the thread, you can write that with a chain of callbacks, much like what you see in Node.js etc:

file.ReadLineAsync().ContinueWith(t1 =>
  Console.WriteLine(t1.Result)
).ContinueWith(t2 =>
  Console.WriteLine(t2.Result)
);

This works, but it gets tedious when you have long chains, and even more tedious when you have nested chains. Worse yet, rewriting loops in this manner is not trivial. For example, simple synchronous code like this:

while ((s = file.ReadLine()) != null) {
  Console.WriteLine(s);
}

becomes this mess if redone async callback style:

Action<Task<string>> body = t => {
  string s = t.Result;
  if (s != null) {
    Console.WriteLine(t.Result);
    file.ReadLineAsync().ContinueWith(body);
  }
};
file.ReadLineAsync().ContinueWith(body);

On the other hand, with async/await, the first example becomes:

s = await file.ReadLineAsync();
Console.WriteLine(s);
s = await file.ReadLineAsync();
Console.WriteLine(s);

and the second one is:

while ((s = await file.ReadLineAsync()) != null) {
  Console.WriteLine(s);
}

Note how the only difference between async and sync code here is the addition of "await", and the use of ReadLineAsync instead of ReadLine. Compiler transforms all that to code with callbacks, automatically inserting one in every place where "await" is used (and rewriting loops etc as needed).

Really, all of this is just coroutines married to futures. In some other languages, you can take existing coroutine support and implement futures as a library (e.g. in Python, where "yield" becomes the equivalent of "await").

LINQ is a lot of different things that combine together. Let me try to go point by point.

The first piece is what other languages call list or sequence comprehensions. If you ever wrote something like:

[x*2 for x in range(10) if x % 2 == 0]

in Python, you've used that. LINQ uses a less concise syntax that is more reminiscent to SQL for the same thing - e.g. the example above would be:

from x in Enumerable.Range(0, 10) where x % 2 == 0 select x*2

in C#, but semantics are the same. That syntax is actually just syntactic sugar for a bunch of method calls with lambdas, with keywords mapped to methods with the same name - the expression above, for example, is translated to:

Enumerable.Range(0, 10).Where(x => x % 2 == 0).Select(x => x*2)

And Where and Select can be pretty much anything - e.g. the return type of Where doesn't matter, so long as it has a method called Select on it. Standard collection types provide implementations that do what you'd expect them to do (not directly, but rather via a mechanism called "extension methods", which allows you to add members to existing types - but this doesn't really matter to the developer using this API).

The second part are lambdas themselves. When you see x => x % 2 == 0, this has pretty much the same meaning as arrow-based lambda syntax in other languages using it (like Scala), with type of x inferred from the context in which it is used. However, there's a twist: instead of compiling this to a function and passing a reference to that, there's also an option of implicitly "quoting" lambda expressions as ASTs. Simply put, if the function you are passing the lambda to as a parameter declares the type of that parameter as Expression, then that function gets the AST for the lambda body, instead of compiled code.

This allows the function to interpret that AST in different ways at runtime instead of just compiling and running it (though that remains an option). For example, in LINQ to SQL and Entity Framework, the AST is converted to SQL, and passed on to the server. In general, the idea is that you have various LINQ providers (i.e. implementations of Where, Select etc) accepting ASTs and converting them to whatever query language is used by the backend that you're extracting the data from. Thus, you have a single uniform syntax for queries, that is also strongly typed (can also be weakly typed since "dynamic" was introduced in C# 4.0), but which can be handled in different ways depending on what data you're querying.

It has amazed me how hard it is to find good games for mobile devices. I'm a big-time gamer, I'd much rather play a game than watch TV for entertainment. It is my primary goof-off activity. So I have a nice powerful smartphone (Android in this case), and it would be nice to have some portable games for it.

Some I want just for quick things, like waiting in the doctor's office or the like. Those are reasonably easy to find, I have a small collection of simplistic titles that do the trick for that. Still though it took a good bit of wading through crap to find them, and there were some things that initially looked promising but turned out to be "pay-2-win" that wanted to suck tons of money out of your pocket.

However I also wanted some with more substance, for if I'm traveling or something like that. Those... Well results haven't been great. I've bought some of the highest rated and reviewed stuff and so far it has been at best ok, either than Plants vs Zombies (which I already had on my PC). These are games that would be 5 or 6 of 10, maybe 7 in rare cases on the PC or a console, but are the "best" you find. Symphony of Eternity, NFS Most Wanted, etc are ok to play, but they really aren't up to what I'm used to.

Then some games that used to be good go to shit. Like Zenoia. Not a wonderful game, but at least a reasonably competent Zelda type. I have the first two. There are more... but again they are all pay-2-win crap.

Now compare that to the PC. I have more games then I can play. I have games on Steam I literally haven't installed yet, because I don't have time to play them yet, and I have another list of games I'd like to buy, if I have time. My problem isn't finding games I want, it is finding the free time to play them all.

I'll believe iOS or Android can compete with Sony and Nintendo if I start to see some serious amount of high quality titles out. Not a small handful, many of which are ports, but a real library that regularly sees new releases.

X-Com is a great example: That launched a year ago for consoles and PCs. I played it and loved it. So now had I waited I could get it, with lesser graphics, and a rather cramped UI to be touch enabled... No thanks. I'll stick with it on the first-flight systems, thanks.