Which is the best reason to have a CLI. A CLI is usable interactively, but almost automatically, anything you do with a CLI, you can script. The same is not true of a GUI in any practical sense.
Maybe, but I've always been skeptical of those. CLIs are generally meant to be scripted -- they're both usable in realtime by a competent admin wanting to make a one-off change right now, and a serviceable API.
Of course, nothing's stopping you from having a GUI to supplement this situation, so long as everything is still possible with the CLI.
This hack in particular isn't a question of the design of anything. It's a bug in their website code, and a damned stupid bug at that -- one which, as MoNsTeR suggested, could've been avoided by adopting a slightly different coding style (bind variables) which is faster with many databases, and completely avoids SQL injection, which is what happened here.
The LIKE example I gave was just to show that bind variables don't automatically make you secure, but it's irrelevant to what actually happened here. But still, it's a lot easier to pay attention to whether you're doing stupid things with user input (like passing it unescaped into a LIKE query) when you don't also have to wonder if Bobby Tables will ruin your day.
First, Base64-encoding any input you receive from a user is going to be exactly as effective as quote-escaping any input you receive from a user -- that is, it works until you forget to do it. Except your method has the added bonus of increasing the amount of storage and making maintenance a headache.
Second, WTF does "rock the DB" mean? And even if you're building strings manually, why would you deliberately concatenate user data in there, instead of refactoring/debugging your strings into prepared queries? For that matter, are you aware that there are awesome APIs for SQL databases which don't require you to write SQL all the time, yet allow plenty of refactoring/debugging?
I mean, really, this is like avoiding email viruses by printing, then scanning, any email before you read it. Effective, but it makes my eyes bleed.
It's not strictly a SQL injection attack. Rather, the point is that you shouldn't assume that bind variables automatically make all user input safe, unless you also understand how that user input can be used in the query in question.
Most things are still perfectly safe. If all you're doing is select/insert/update with equality, you're probably fine.
The point here is that bind variables don't make you invincible, but they do make a certain class of vulnerabilities harder to create than to avoid, and they even make your code run faster.
I don't think this negates my argument at all, particularly because this is exactly the sort of thing I would put in a library and never look at again. The other responses suggest that this has been done, which doesn't really surprise me.
I have to agree with the AC here. And bind variables don't have to be inconvenient, either -- check out Rails (or, really, any Ruby ORM), and I think.NET has something similar, where an internal DSL is used to define the query you're going to execute.
Really, is this contrived example of checking whether a user is an admin:
Note that this doesn't mean you should assume you're safe just because you're using bind variables -- be aware of stuff like LIKE, for instance.
But yes, that is exactly the frustration I have when I hear about things like this. There's pretty much never a reason to build your own SQL string outside of a library.
the Samba team has moved active development of the project to the more strict GPLv3 license, which prevents Apple from using the software commercially.
I know nothing that GPLv3 does which prevents anyone from using it commercially, certainly nothing it does that GPLv2 doesn't. TFA doesn't say what Apple's actual problem is, but as evil as Apple has been, they aren't this stupid.
On the other hand, the version of Samba Apple had been using prevented Macs from seamlessly working with modern PCs running Windows 7, which include security changes in how encryptions protocols work. Apple's own software won't be constrained by the design limitation of Samba.
Wait, how is this lack of a feature a "design limitation" of Samba? They don't provide any source for this claim, and I very much doubt that it's a design limitation. I can believe it exists, but I find it hard to believe something in the design of Samba would prevent them from adding this feature.
There were a few things in TFA that seem plausible, but it really looks like they lose a lot in translation. I have to ask, what is the potential audience for such an article? I usually only see two types of Mac users, the Unix people who gave up on Linux, and the "It's easier, it Just Works" people who gave up on Windows. The "Just Works" people don't care about Samba, and if OS X won't play nice with Win7, they'll either blame Win7 or ask an Apple "Genius" to just fix it. The Unix people are going to be perfectly capable of using Samba if they want, and would probably like a lot more information about what's actually going on, including why GPLv3 is an issue.
Since Apple has chosen to actually enforce their own moral standards on their app store, every app they approve or reject on the basis of being "offensive" is effectively an opinion statement from Apple. This app in particular was a no-brainer: If Apple continued to allow it, they would be deliberately and knowingly profiting from the efforts of people who still believe homosexuality is a mental disorder. By disallowing it, they are making a statement that they don't want to be part of any such thing.
By having much less subjective standards -- things like "no spyware", but not really caring about content at all -- Android could carry as many ex-gay apps as the ex-gays can write, because Google has decided that it's not up to them. What's more, Google isn't going to stop you from installing apps from third-party sources. Nothing's stopping you from forming your own app store which filters what you care about, or applying filters to the official Google app store.
In other words, if an ex-gay app shows up on my Android phone, the very worst thing you could say about it is that you don't like the open-ness which allows that sort of thing to exist -- you certainly couldn't say Google approves of it. By contrast, when that app shows up in Apple's store, because of how it's set up, Apple is giving tacit approval.
Note that you are simply wrong. Your assumptions are flawed in terms of what is possible and they remain flawed in terms of it being "a royal pain in the ass".
Does not follow. Being subjective is not "simply wrong."
Well dude, mine will run in linear time and involves none of that executable data on a stack frame
Congratulations! You just proved that closures can run in linear time and do not require executable data on a stack frame.
It'd be nice if you actually admitted you were wrong, earlier, when these were exactly your complaints about closures, as a language feature.
(e.g. the number one vector for buffer over-runs and system smashing, one so pervasive that hardware manufacturers actually changed the way me make CPUs in order to defeat that hole that your language _requires_)
That code written in my language cannot ever cause.
It's kind of funny how backwards you have this. In C -- and, by extension, C++ -- hardware manufacturers actually changed the way we make CPUs in order to force you guys to not accidentally execute data, because fundamentally, pointers are all just integers, after you remove the "smoke and mirrors".
By contrast, it is impossible to write Ruby code which has a buffer overrun. It is possible for the interpreter to have an overrun, sure -- but it's also possible for CPUs to have security flaws. (And before you say it, by "interpreter" I really mean "VM", and by "VM" I really mean "Runtime".)
It's ironic, really. In Ruby, it's true, I could "eval" a string and thus turn user input into executable code right at that point. But until I actually call "eval" (which I generally don't), there is no way a user can enter a string which can make my program execute arbitrary code.
You can write C++ that is reasonably safe -- yes, I'm aware that C++ strings are. But then, there's always stuff like gets() lurking around the corner, and it isn't realistic to write C++ without using pointers at some point.
You want to get into a measuring contest? I can whip out boost::qi and write an entire recursive descent parser in overloaded operators like "source >> double_ % ','" to parse and store a list of one or more floating point numbers separated by commas.
Contrast to:
source.split(',').map(&:to_f)
Built into the language, and a bit more readable than your example, I think. But get back to me when you have something comparable to rspec.
But unlike your interpreted language it can be fully optimized at compile time,
So what? Was I ever once suggesting that Ruby is as fast as C?
What's more, I'm not convinced languages like Ruby can't be optimized, even at compile time. They just generally aren't. Ok, it's being compiled again and again every time I start my Rails server. In what world does it matter that it takes a few seconds for the app to start, if it's then going to be running continuously for months?
No language is the be-all or end-all of languages.
We're again in complete agreement!
And yes, I can be won over by elegant syntax. Your closure syntax isn't it. Ruby sure wasn't it.
Note that you are simply wrong.
Or are you willing to say that this is also subjective?
It's impossible, more or less, to write C++ that will fail to dispatch a method when a method is called.
"More or less."
It is, in fact, possible to write C++ that will dispatch to the wrong method when a method is called.
Suppose you cast a pointer to void, then back to another type which is compatible with the type you started with -- maybe a parent type, maybe a child type. This is how things work in C with void pointers, and it's how they work
Before we go any further, you need to demonstrate some reading comprehension:
Your language was written in my language dude, if my language couldn't do it yours wouldn't be able to do it either.
I addressed this argument, at length, and rather than refute any of my arguments, you're ignoring it and repeating your own. That strongly suggests you didn't read my comment at all.
Again: "Your language was written in my language" is as relevant to the topic at hand as the fact that all languages being discussed are Turing-complete, and that your language was written in assembly. The implication of your argument is that we should all use assembly, since it "by definition" has all features of all other languages. Do you really believe that?
Taking it a step further, as much as you talk like you understand how VMs are implemented, you still use an argument which suggests that Ruby code is compiled to C or C++ first, and then executed, and while there have been some interesting attempts, this was never the mainstream approach. Ruby closures are not implemented this way, and do not depend on any closure-like syntax you could build in C/C++.
God, you are so right... I wish I could do this in C++... Well its not possible in C though right?
I never once claimed these were impossible, and when people start strawmanning me, I generally stop listening.
In fact, I explicitly said that it was technically possible, thanks to Turing-completeness.
now I left off all sorts of syntatic and semantic sugar from a fully body of ready to use code,
Yes, you did, and that is exactly what counts. With your model here, my "each" example is now at a minimum:
mylist.each(Closure(cruft));
Contrast to:
mylist.each{|x|... }
Your example is already more needlessly verbose before you even get to the actual data. It looks as though you need at least some preprocessor hacks, probably built on top of something like nested functions -- ugly as hell, compared to what you'd be able to do with at least anonymous functions.
well doggie, you have it all with none of the waste.
If you really believe that, you understand far less about high-level languages than I do about C++. Please explain how smart_ptr prevents me from ever having a segfault, from my own stupidity or otherwise.
I don't know that this matters so much, since we could always ship Ruby code with a JRuby dependency. In fact, I'm fairly sure there are tools for packaging a JRuby app into a war file, so it shouldn't be too hard to make a JRuby jar.
It's more for the places where you need Java, and you can't use JRuby. I was first introduced to it with appengine-jruby, which lets you run Rack apps (including Rails apps!) on Google App Engine. Awesome, but App Engine has a quirk where unless you're paying for a reserved instance (and maybe sometimes even then), Google will automatically scale your app up and down by spinning up new instances of it on demand.
This means any given page load might boot your app, and JRuby adds seconds to that. Mirah, on the other hand, runs just like Java, but you can actually convert simple Rails controllers almost directly, and some templates even work -- so you can take the pages that you care the most about, or at least the ones that are going to be hit first, and convert those to Mirah as needed, while leaving the rest of your app in JRuby.
Another example might be something like Rawr. I'm not sure how it's done now -- I think they just have some Java code. It's not much, but getting rid of that and just using Ruby would be nice.
Still, I can't think of ever wanting to use Mirah instead of JRuby, only being forced to do so. After all, JRuby already gives me the part of this equation I want -- I can use pretty much any Java library in JRuby, and it pretty much works exactly the way I'd expect, I almost never have to look up how to do something. I just pretend it does what you'd think it would do -- I even sort of pretend it was written in Ruby -- and it just works.
It seems like people are using Mirah where they really need something that's effectively native Java, but they can't stand looking at the ugliness that is the Java language. I believe the original use case is making the JRuby code itself (most of which is written in Ruby) easier to work with, particularly for Rubyists.
Another good use case is for appengine-jruby -- Google App Engine may arbitrarily spin up or spin down instances of your app on demand, so startup time is essential -- basically, any given page load might boot your app. JRuby adds a few seconds to that start time. So you write your app in something like Rails or Sinatra, but maybe you port the homepage over to Mirah.
Besides, Rails already runs on JRuby. I'd guess most people who are using Rails don't really care about the JRuby overhead for their Rails apps, so they'd mainly be using Mirah, again, anywhere they would otherwise have to write raw Java -- maybe you want to optimize something by writing it in Java, but not C, since Java is easier (and doubly so with Mirah), and JRuby calling Java is probably better than JNI.
Oh, and whoosh, I know, but I can't resist answering a good question even if it was asked sarcastically.
It's not just the limit, it's that it impacts performance, and sometimes you really do want to make sure stuff gets flushed to disk.
In any case, the main problem isn't that you want to open 10k files at once. It's that you want to open maybe 10 files at once, and then a different 10 files, and so on. The only reason your finalizer will ever be called is if the GC cleans up that object. But it's not going to clean up that object because you're low on filehandles, only when you're low on memory.
It's also not just files, but, say, database handles, sockets, etc.
This is one of two main annoyances I have with GC'd languages, the other being that while I think I have seen languages shrink their heaps (I think?), they do it on their own sweet time. It'd be really nice if there was a way for garbage collectors and caches to register themselves with the OS, so that when the OS itself is low on memory, it can ask stuff to GC and/or purge caches.
Then again, 99% of the time, the block hack does what I want to do.
No more segfaults... instead, you get NullPointerExceptions.
Which throw a beautiful stacktrace, and generally take a few minutes to debug.
By contrast, a segfault may be caused by code that lives in an entirely different part of your program because you somehow screwed up how you're handling pointers.
What I don't like most about languages like Java and C# is that they lack the notion of const objects.
I really don't miss it, because it didn't really seem to have well-defined semantics in the first place. Java does have 'final', but it doesn't quite do the same thing.
However, when this is actually an issue, you can either use deliberately immutable classes, or you can copy it ahead of time. Not as nice as const, partly because it's not universally supported -- but neither is const.
There is a solution I've used from time to time which is kind of gross, but very workable -- since well-designed Java APIs use interfaces, if I need to return an object or pass it to another object and be absolutely sure it won't be modified, I can create an immutable wrapper object -- tedious, but not hard.
Incidentally, this is one reason I love Ruby -- such wrapper objects are relatively easy to create, and I can write libraries to make them easier. No need to implement every single method in the interface, I can just give it a list of methods to proxy and let it do the rest.
A closure is a snapshot of memory from a context so that you can peer back into that moment of time to the values in place at the time, to arbitrary depth.
That's the most obvious implementation, but it's not the only possible implementation. For one, unless the code in that closure has a call to "eval", you can pretty much read the symbols in it and figure out which variables it needs access to. In other words:
In C++ you have to return the information explicitly. That is you have to decide at the "moment of closure" what memory you are going to save
In a proper implementation of closures, it's still deciding what memory you're going to save, and it's doing it at compilation time -- so the net result is the same, you just have to do less work. What's more, in a language with a Java-like memory model (which Ruby kind of has), it's copying either primitives or references, not whole objects, so it's quite cheap.
Closures in your language of choice were implemented in C so by definition you can implement them in C.
First, not necessarily. I'm fairly sure there are Lisp compilers that were not written in C. Also, given the state of the best closure-enabled VMs or compilers, the C "implementation" is effectively a compiler written in C -- it's certainly not just translating the construct from that language into C.
Second, that's as irrelevant as saying, "Everything in language X was written in something which was written in something which eventually was written in assembly. By definition, you can implement anything in language X in assembly." Would you rather use assembly than C++?
The point of closures isn't that they enable you to do anything you can't do in any other language -- Turing-completeness means that anything you can do in one language, you can emulate in another.
The question is, how ugly is it going to be?
You answered this yourself. You went "eeeew" every time you suggested a way of getting at the functionality in C++. In Ruby, a closure is do...end, and it's quite efficient, considering that this is how most loops are implemented:
mylist.each {|x|... }
Figure most of your for loops would be replaced by that. Yeah, they're going to want to optimize the hell out of that.
Now, I have to ask:
I know the technologies quite well, and I know their implications.
If that's true, it is possible I'm missing something. Is there a reason my suggestion wouldn't work? That is, is there a reason a closure has to actually create a snapshot of memory, or is it enough for it to conceptually do so?
The fact that Ruby to C produces code "neck and neck" with ruby running inside the JVM is pretty much a universal indictment of Ruby,
On the grounds of... what? Performance comparable with... what?
See the plain truth is that the JVM is a least-common-denominator.
It is, but only in a certain context -- in particular, enterprise applications. It's certainly not a least-common denominator for desktop apps -- look how many people have to install Java just to get Minecraft running.
It is an interpreter for gawd's sake,
You pretty directly contradict this with:
and one that knows it is sufficiently crap that it has a "just in time compiler"
So, Java can be interpreted. It can also be compiled. The JVM includes both.
What about this implies the JVM "sucks"? That it has more features? Or that some of its features aren't a good idea all the time (interpreter), so it automatically chooses a more appropriate mode of operation (compiling)?
why not just JIT the entire code base?
To reduce startup time. You do understand the difference between just in time and ahead of time, right?
And if that, why not just compile the code base once to begin wiht?
You know what? gcj does just that.
But then you lose the runtime flexibility. Reflection can be useful, for one, and that pretty much demands that you keep some sort of intermediate representation around. And then there's the part where I can compile a program for one architecture on one OS, and copy the bytecode files to another architecture and OS, and expect it to work.
Why don't you ask the JavaScript developers why they don't just compile everything? They do compile quite a lot, and I think they might even be doing a better job than the JVM, but a language that dynamic just doesn't make sense as a binary blob.
And then there are the pathological cases where runtime-optimized code can perform better than ahead-of-time compiled code, because the runtime can take into account what is actually happening.
claiming it is new, novel, "a work of art" or any other damn thing is...
Something I see no one here doing. Strawman much?
Ask yourself why JINI had to be invented?
Because there's tons of stuff written in C.
Yes, you can occasionally get a speedup by translating chunks of your program from Java to C. Ask yourself why it's only isolated libraries that do this, and not large chunks of applications. Turns out Java is "fast enough" -- half the speed of C is still plenty fast for most applications, especially with the other advantages you get.
Ask yourself why JIT?
Again, why are you seeing JIT as a bad thing, and why are you seeing it as not part of the JVM?
The whole "compile once, run anywhere" thing is a _lie_ for two reasons.
I guess that program I wrote on my x64 Linux, then sent to someone else running a 32-bit Windows machine, was a figment of my imagination?
(1) the results "run anywhere" but only for _extremely_ constrained definitions of "anywhere"
Any desktop OS is still pretty damned good. The only reason it's not more relevant is that web browsers have gotten good enough that most of the original use cases of desktop Java don't matter anymore.
you "compile once" so the JVM can compile it again and again during runtime.
You mean, so it can compile it once per run, once it determines that it's worth compiling that chunk of code.
Releasing, e.g. _unlocking_ regions of files shared between applications (e.g. matching flock() calls between constructor and destructor to lock and release records at precise times).
Fair point, though I don't know that this saves you from the problem of locking in general. For a significantly parallel app, I'd be looking at either more granularity (Erlang) or less.
Unlocking and dismissing shared object libraries (e.g. undoing dlopen()) when, but not before, the last instance of any/every object dependent on the shared object file goes out of scope.
This makes sense, but it also doesn't seem to match where Java is used most these days -- in a server environment, where people tend to just load everything and let it run.
Preventing "Cruft" in my heap by doing "deep" memory frees of complex structures as soon as I no longer need them instead of at "some random time in the future if ever".
This is the part that GC is for. If you absolutely need that memory back immediately and you have the benchmarks/profiling to back it up, then you're right, you need a language like C.
But GC has gotten pretty damned good. Closing filehandles immediately makes sense, because the OS limits how many of those you can have open, but memory? Depending on what you're doing, GC can actually perform better than manually freeing those structures.
Changing modes and states on devices using ioctl() etc. (e.g. when the last "raw" use of the controlling terminal goes out of scope you put the terminal back into line mode until/unless you need to bring it back into raw mode.)
Interesting... I can't remember ever having to do that.
Resetting hardware on last use. Emulating devices and subsystems that, by definition, reset themselves on last use.
And now we're definitely beyond the realm of "application development", I would think.
Doing all of the above with "exception safety" without having to write a ass-ton of "finally" blocks (though I _do_ whish C++ had "finally" 8-).
Ruby developed a clever approach to this using blocks, which are effectively closures. The general pattern is:
open 'filename' do |file|
#... do a bunch of stuff with "file" end
This translates into, "Call the 'open' method, and pass it this block of code." That method would be defined something like:
def open filename
file = real_open_file filename #whatever it is, I don't remember
begin
yield file
finally
file.close if file.open?
end end
The 'yield' calls the block you passed. Effectively, you can develop an API which defines a scope in which you get to work with the file (or whatever it is), and the API handles the exceptions.
You are like a blind guy asking "when was the last time you really used your eyes for anything but reading" because you have never heard of art,
More like, I'm an engineer who doesn't often think of working with art, to the extent that the analogy works at all. See...
you presume destructors are "really just for freeing memory"
I didn't ever assume that.
They are, however, for freeing resources, which fits very nearly every single use case you mentioned. And maybe it's just the code I worked with, but it did seem like most of the time, destructors are there to free memory.
Hell, most of the time, a destructor was only there as a defined virtual in case any descendant classes wanted to free some memory.
I work with too many system internals to think the JVM is a win.
And my work tends to be too far removed from system internals to think th
I don't like Java, but I do have a couple of issues here:
Java doesn't have pointers" my pasty white behind, every object is a pointer in java,
Every object is a reference in Java. There is a world of difference between a name which refers to some object and an integer which might refer to some object, but you can still do integer math, and the object might not even be there anymore...
This is almost as if you're trying not to see the advantages. No more segfaults. No double-frees, no crazy-ass debugging where the wrong method gets called because your pointer is pointing to the wrong (or a corrupt) vtable, and you really have to try to get a memory leak.
they do manage to use pointers to prevent first class object copying, so then they added clone() etc.
And the number of times I should've just passed the original object, vs the number of times I really didn't want it to implicitly clone something? Again, I have to give this one to Java, with the caveat that the interface to clone() kind of sucks. Ruby has dup, and all objects have it by default. Implementing clone() in Java is a pain, and if an object doesn't implement it, you're SOL.
the code out to know when the last object reference is going out of scope so it can call a destructor manually if it wants. That was a stopper for me.
Really? This?
Think back to all the destructors you've ever written in C++. How many of them can you count that did more than free memory? In other words, how many destructors have you ever written which aren't entirely replaced by the garbage collector?
I can pretty much count them on one hand. Filehandles, DB handles, etc. Yes, it sucks, but having to close a filehandle vs having to free every bit of memory I ever allocate? I'll take the filehandle.
So now Ruby fans want to take their niche language and cram it into the fundamentally flawed Java VM.
Wait, what?
You haven't mentioned a single issue with the JVM. Your complaints have been about the Java language. Surely you can tell the difference?
Oh, alright, you had one other complaint: You don't like the lack of proper destructors. Guess what? Ruby doesn't have them either. Ruby has finalizers, just like Java. Of course, I don't see anything about the JVM's design that prevents a language from implementing destructors anyway.
It's also funny how you, like most of Slashdot, seems to have missed the point: JRuby exists, and is pretty much neck and neck with the official C Ruby implementation in terms of performance. It's just as stable, and almost everything that works in one implementation works in the other -- kind of like how you can have multiple C compiles.
This article was about Mirah, which is not Ruby, nor trying to be. It's a way to make Java suck less, at least syntactically. If your gripe isn't with the syntax, you probably won't care about Mirah.
And for a bit of balance, here's the features I really, really miss in Java:
Closures
Better setters/getters
Operator overloading (or something other than the retarded handling of == vs equals)
What's more, JRuby exists, and Mirah doesn't compete with JRuby. In fact, it seems one of the motivations for its creation was to make it easier to hack on JRuby itself, which is, after all, quite a lot of Java code.
You're going to have to slow down a bit, because I'm seeing you make a lot of points without connecting them at all. For example:
if 5 year plus old games like Far Cry or FEAR can run damned well on a 3.4Ghz P4 with an HD3650
Granted...
then there is no damned excuse why your 2011 game looks like ass and runs like shit on the latest and greatest, there just isn't.
What? Why on earth would you assume that newer games would perform better than older games?
Seriously -- Half-Life runs great on any modern PC, probably even Intel GMA. By your logic, I should expect Half-Life 2 to run faster and better than Half-Life. Go look at some screenshots of each game, and then tell me how that makes sense.
I have found even the big budget games that run like ass turn out to be console ports that is obvious there was ZERO optimization on the platform.
So you've disassembled them, have you? Combed carefully through the code from the console version and the PC version to see if you could find a difference in quality?
Not that it matters -- what does this have to do with my post? Zero optimization for a given platform doesn't mean zero optimization, and optimization in the first place can have an adverse effect on stability.
you can't just drop PPC code straight onto i586, be it x86 or x64, and expect to have it run well, you just can't do it.
If their code is that closely tied to a given architecture, they are Doing It Wrong on a very profound level. How much actual PPC code does a game developer write? Not nearly as much as they write, say, C++. In fact, you also seem to be aware of a more likely problem, but it's hard to see through all the bullshit:
the same optimizations for the constrained CPU,RAM, and GPU of the console and not instead taking advantage of the platform
And yes, there are games that do this.
I believe most game coder jobs ARE shitty, but still that is no excuse.
Why not? Do you really believe that it was up to the husband of EA Spouse whether or not the game ran well on a PC? He's already spending an 80-hour week trying to get the console release out the door, where's he going to get another 80 hours to finish up the PC port unless his manager actually gives him that time?
some console reguritation designed to play "lets screw them out of some cash"
So, you've gone from "New games all run like shit" to "They just aren't optimized for the platform" to "It's so bad I want my money back!"
Really?
Or is it that you buy the same game for multiple platforms, and you don't feel the PC version is worth it when you already have a console?
How about less rant and more point?
And sorry about the length but after getting burnt so many times by console lameness...
See, it's not the length that bothers me, it's the amount of kneejerk vitriol here. At this point, it's sounding like every time a game gives you technical issues, you blame the consoles and the developers, when it's not the developers who are choosing the consoles, and most developers really aren't in a position to make things better.
The amount of rage here makes it unlikely any developer is going to take you seriously, which makes it harder to solve the real issues.
I'm sorry but its true, you guys really really REALLY suck.
Somewhat, but not as much as you imagine. In particular:
every damned game that comes out nowadays needs damned near the size of the game in fricking patches because your shit is so buggy?
I would put the blame for this mostly on management, and on the industry as a whole.
See, game developers are forced to do the two worst possible things for stability: They're forced to optimize the hell out of their games by working at a very low level, and they're forced to develop games as fast as they possibly can. Failure to do either of these means your game looks worse than the competition -- if you work at a higher level, your game runs slower, which means it either lags or doesn't look as good. If you don't get to market fast enough, the entire industry may have shifted, or at the very least, your game just won't look as awesome visually compared to what people are doing these days.
Consoles have made the "get to market immediately" part less important, because most gamers are on consoles with the same hardware, and if TFA is right, the PC just doesn't look that much better, no matter how much hardware you throw at the problem. But the industry is still built around the idea that you need to build the next Quake -- something which pushes the boundaries of what your hardware can do, and does it before everyone else does.
Now consider that games are on the order of multiple gigabytes, much more than most other applications require. I challenge you to find a single game which has been patched as often as any modern browser -- but the game's patches will be bigger, because the game itself is bigger.
I tend to agree that game developers suck, but that's only because it seems to me that every single one of these problems is solvable. Even on a console, it seems like most aspects of most games could take a performance hit of 5x or more and still run just as smoothly. Especially with consoles around, it seems like being first to market with a buggy game isn't going to be that much better than spending a few more months on testing and refinement, especially on any sort of investment in a solid engine you can carry from game to game.
Still, I have to call bullshit on this:
When my quad core with an HD4850 struggles because of your crap console code it ain't the fault of DirectX, it is your fault for putting out lame console shit without bothering to optimize for the platform.
This may be the case, and certainly is the case with some games, but if a game can be thoroughly optimized for the 360, PS3, sometimes even a Wii, you'd think they'd be able to optimize for the PC. Maybe they're onto something -- maybe sometimes, they do actually have the budget, time, and skills to optimize for the PC just as they could optimize for a console, but there's something about the PC platform which gets in the way.
Slashdot Mirror
Which is the best reason to have a CLI. A CLI is usable interactively, but almost automatically, anything you do with a CLI, you can script. The same is not true of a GUI in any practical sense.
Maybe, but I've always been skeptical of those. CLIs are generally meant to be scripted -- they're both usable in realtime by a competent admin wanting to make a one-off change right now, and a serviceable API.
Of course, nothing's stopping you from having a GUI to supplement this situation, so long as everything is still possible with the CLI.
veil, not vail.
Right. A veil is a garment, often used as a metaphor. Vail is a mountain. Please try to keep them straight.
This hack in particular isn't a question of the design of anything. It's a bug in their website code, and a damned stupid bug at that -- one which, as MoNsTeR suggested, could've been avoided by adopting a slightly different coding style (bind variables) which is faster with many databases, and completely avoids SQL injection, which is what happened here.
The LIKE example I gave was just to show that bind variables don't automatically make you secure, but it's irrelevant to what actually happened here. But still, it's a lot easier to pay attention to whether you're doing stupid things with user input (like passing it unescaped into a LIKE query) when you don't also have to wonder if Bobby Tables will ruin your day.
*facepalm*
Really?
First, Base64-encoding any input you receive from a user is going to be exactly as effective as quote-escaping any input you receive from a user -- that is, it works until you forget to do it. Except your method has the added bonus of increasing the amount of storage and making maintenance a headache.
Second, WTF does "rock the DB" mean? And even if you're building strings manually, why would you deliberately concatenate user data in there, instead of refactoring/debugging your strings into prepared queries? For that matter, are you aware that there are awesome APIs for SQL databases which don't require you to write SQL all the time, yet allow plenty of refactoring/debugging?
I mean, really, this is like avoiding email viruses by printing, then scanning, any email before you read it. Effective, but it makes my eyes bleed.
I don't know about MySQL specifically, but a minute or so of Googling confirms my suspicion: LIKE is vulnerable to DOS attacks.
It's not strictly a SQL injection attack. Rather, the point is that you shouldn't assume that bind variables automatically make all user input safe, unless you also understand how that user input can be used in the query in question.
Most things are still perfectly safe. If all you're doing is select/insert/update with equality, you're probably fine.
The point here is that bind variables don't make you invincible, but they do make a certain class of vulnerabilities harder to create than to avoid, and they even make your code run faster.
I don't think this negates my argument at all, particularly because this is exactly the sort of thing I would put in a library and never look at again. The other responses suggest that this has been done, which doesn't really surprise me.
I have to agree with the AC here. And bind variables don't have to be inconvenient, either -- check out Rails (or, really, any Ruby ORM), and I think .NET has something similar, where an internal DSL is used to define the query you're going to execute.
Really, is this contrived example of checking whether a user is an admin:
so much more "convenient" than this:
Note that this doesn't mean you should assume you're safe just because you're using bind variables -- be aware of stuff like LIKE, for instance.
But yes, that is exactly the frustration I have when I hear about things like this. There's pretty much never a reason to build your own SQL string outside of a library.
From TFA:
the Samba team has moved active development of the project to the more strict GPLv3 license, which prevents Apple from using the software commercially.
I know nothing that GPLv3 does which prevents anyone from using it commercially, certainly nothing it does that GPLv2 doesn't. TFA doesn't say what Apple's actual problem is, but as evil as Apple has been, they aren't this stupid.
On the other hand, the version of Samba Apple had been using prevented Macs from seamlessly working with modern PCs running Windows 7, which include security changes in how encryptions protocols work. Apple's own software won't be constrained by the design limitation of Samba.
Wait, how is this lack of a feature a "design limitation" of Samba? They don't provide any source for this claim, and I very much doubt that it's a design limitation. I can believe it exists, but I find it hard to believe something in the design of Samba would prevent them from adding this feature.
There were a few things in TFA that seem plausible, but it really looks like they lose a lot in translation. I have to ask, what is the potential audience for such an article? I usually only see two types of Mac users, the Unix people who gave up on Linux, and the "It's easier, it Just Works" people who gave up on Windows. The "Just Works" people don't care about Samba, and if OS X won't play nice with Win7, they'll either blame Win7 or ask an Apple "Genius" to just fix it. The Unix people are going to be perfectly capable of using Samba if they want, and would probably like a lot more information about what's actually going on, including why GPLv3 is an issue.
It's more than that.
Since Apple has chosen to actually enforce their own moral standards on their app store, every app they approve or reject on the basis of being "offensive" is effectively an opinion statement from Apple. This app in particular was a no-brainer: If Apple continued to allow it, they would be deliberately and knowingly profiting from the efforts of people who still believe homosexuality is a mental disorder. By disallowing it, they are making a statement that they don't want to be part of any such thing.
By having much less subjective standards -- things like "no spyware", but not really caring about content at all -- Android could carry as many ex-gay apps as the ex-gays can write, because Google has decided that it's not up to them. What's more, Google isn't going to stop you from installing apps from third-party sources. Nothing's stopping you from forming your own app store which filters what you care about, or applying filters to the official Google app store.
In other words, if an ex-gay app shows up on my Android phone, the very worst thing you could say about it is that you don't like the open-ness which allows that sort of thing to exist -- you certainly couldn't say Google approves of it. By contrast, when that app shows up in Apple's store, because of how it's set up, Apple is giving tacit approval.
Note that you are simply wrong. Your assumptions are flawed in terms of what is possible and they remain flawed in terms of it being "a royal pain in the ass".
Does not follow. Being subjective is not "simply wrong."
Well dude, mine will run in linear time and involves none of that executable data on a stack frame
Congratulations! You just proved that closures can run in linear time and do not require executable data on a stack frame.
It'd be nice if you actually admitted you were wrong, earlier, when these were exactly your complaints about closures, as a language feature.
(e.g. the number one vector for buffer over-runs and system smashing, one so pervasive that hardware manufacturers actually changed the way me make CPUs in order to defeat that hole that your language _requires_)
That code written in my language cannot ever cause.
It's kind of funny how backwards you have this. In C -- and, by extension, C++ -- hardware manufacturers actually changed the way we make CPUs in order to force you guys to not accidentally execute data, because fundamentally, pointers are all just integers, after you remove the "smoke and mirrors".
By contrast, it is impossible to write Ruby code which has a buffer overrun. It is possible for the interpreter to have an overrun, sure -- but it's also possible for CPUs to have security flaws. (And before you say it, by "interpreter" I really mean "VM", and by "VM" I really mean "Runtime".)
It's ironic, really. In Ruby, it's true, I could "eval" a string and thus turn user input into executable code right at that point. But until I actually call "eval" (which I generally don't), there is no way a user can enter a string which can make my program execute arbitrary code.
You can write C++ that is reasonably safe -- yes, I'm aware that C++ strings are. But then, there's always stuff like gets() lurking around the corner, and it isn't realistic to write C++ without using pointers at some point.
You want to get into a measuring contest? I can whip out boost::qi and write an entire recursive descent parser in overloaded operators like "source >> double_ % ','" to parse and store a list of one or more floating point numbers separated by commas.
Contrast to:
Built into the language, and a bit more readable than your example, I think. But get back to me when you have something comparable to rspec.
But unlike your interpreted language it can be fully optimized at compile time,
So what? Was I ever once suggesting that Ruby is as fast as C?
What's more, I'm not convinced languages like Ruby can't be optimized, even at compile time. They just generally aren't. Ok, it's being compiled again and again every time I start my Rails server. In what world does it matter that it takes a few seconds for the app to start, if it's then going to be running continuously for months?
No language is the be-all or end-all of languages.
We're again in complete agreement!
And yes, I can be won over by elegant syntax. Your closure syntax isn't it. Ruby sure wasn't it.
Note that you are simply wrong.
Or are you willing to say that this is also subjective?
It's impossible, more or less, to write C++ that will fail to dispatch a method when a method is called.
"More or less."
It is, in fact, possible to write C++ that will dispatch to the wrong method when a method is called.
Suppose you cast a pointer to void, then back to another type which is compatible with the type you started with -- maybe a parent type, maybe a child type. This is how things work in C with void pointers, and it's how they work
Before we go any further, you need to demonstrate some reading comprehension:
Your language was written in my language dude, if my language couldn't do it yours wouldn't be able to do it either.
I addressed this argument, at length, and rather than refute any of my arguments, you're ignoring it and repeating your own. That strongly suggests you didn't read my comment at all.
Again: "Your language was written in my language" is as relevant to the topic at hand as the fact that all languages being discussed are Turing-complete, and that your language was written in assembly. The implication of your argument is that we should all use assembly, since it "by definition" has all features of all other languages. Do you really believe that?
Taking it a step further, as much as you talk like you understand how VMs are implemented, you still use an argument which suggests that Ruby code is compiled to C or C++ first, and then executed, and while there have been some interesting attempts, this was never the mainstream approach. Ruby closures are not implemented this way, and do not depend on any closure-like syntax you could build in C/C++.
God, you are so right... I wish I could do this in C++... Well its not possible in C though right?
I never once claimed these were impossible, and when people start strawmanning me, I generally stop listening.
In fact, I explicitly said that it was technically possible, thanks to Turing-completeness.
now I left off all sorts of syntatic and semantic sugar from a fully body of ready to use code,
Yes, you did, and that is exactly what counts. With your model here, my "each" example is now at a minimum:
Contrast to:
Your example is already more needlessly verbose before you even get to the actual data. It looks as though you need at least some preprocessor hacks, probably built on top of something like nested functions -- ugly as hell, compared to what you'd be able to do with at least anonymous functions.
well doggie, you have it all with none of the waste.
If you really believe that, you understand far less about high-level languages than I do about C++. Please explain how smart_ptr prevents me from ever having a segfault, from my own stupidity or otherwise.
I don't know that this matters so much, since we could always ship Ruby code with a JRuby dependency. In fact, I'm fairly sure there are tools for packaging a JRuby app into a war file, so it shouldn't be too hard to make a JRuby jar.
It's more for the places where you need Java, and you can't use JRuby. I was first introduced to it with appengine-jruby, which lets you run Rack apps (including Rails apps!) on Google App Engine. Awesome, but App Engine has a quirk where unless you're paying for a reserved instance (and maybe sometimes even then), Google will automatically scale your app up and down by spinning up new instances of it on demand.
This means any given page load might boot your app, and JRuby adds seconds to that. Mirah, on the other hand, runs just like Java, but you can actually convert simple Rails controllers almost directly, and some templates even work -- so you can take the pages that you care the most about, or at least the ones that are going to be hit first, and convert those to Mirah as needed, while leaving the rest of your app in JRuby.
Another example might be something like Rawr. I'm not sure how it's done now -- I think they just have some Java code. It's not much, but getting rid of that and just using Ruby would be nice.
Still, I can't think of ever wanting to use Mirah instead of JRuby, only being forced to do so. After all, JRuby already gives me the part of this equation I want -- I can use pretty much any Java library in JRuby, and it pretty much works exactly the way I'd expect, I almost never have to look up how to do something. I just pretend it does what you'd think it would do -- I even sort of pretend it was written in Ruby -- and it just works.
I doubt such an animal would ever happen.
It seems like people are using Mirah where they really need something that's effectively native Java, but they can't stand looking at the ugliness that is the Java language. I believe the original use case is making the JRuby code itself (most of which is written in Ruby) easier to work with, particularly for Rubyists.
Another good use case is for appengine-jruby -- Google App Engine may arbitrarily spin up or spin down instances of your app on demand, so startup time is essential -- basically, any given page load might boot your app. JRuby adds a few seconds to that start time. So you write your app in something like Rails or Sinatra, but maybe you port the homepage over to Mirah.
Besides, Rails already runs on JRuby. I'd guess most people who are using Rails don't really care about the JRuby overhead for their Rails apps, so they'd mainly be using Mirah, again, anywhere they would otherwise have to write raw Java -- maybe you want to optimize something by writing it in Java, but not C, since Java is easier (and doubly so with Mirah), and JRuby calling Java is probably better than JNI.
Oh, and whoosh, I know, but I can't resist answering a good question even if it was asked sarcastically.
It's not just the limit, it's that it impacts performance, and sometimes you really do want to make sure stuff gets flushed to disk.
In any case, the main problem isn't that you want to open 10k files at once. It's that you want to open maybe 10 files at once, and then a different 10 files, and so on. The only reason your finalizer will ever be called is if the GC cleans up that object. But it's not going to clean up that object because you're low on filehandles, only when you're low on memory.
It's also not just files, but, say, database handles, sockets, etc.
This is one of two main annoyances I have with GC'd languages, the other being that while I think I have seen languages shrink their heaps (I think?), they do it on their own sweet time. It'd be really nice if there was a way for garbage collectors and caches to register themselves with the OS, so that when the OS itself is low on memory, it can ask stuff to GC and/or purge caches.
Then again, 99% of the time, the block hack does what I want to do.
No more segfaults... instead, you get NullPointerExceptions.
Which throw a beautiful stacktrace, and generally take a few minutes to debug.
By contrast, a segfault may be caused by code that lives in an entirely different part of your program because you somehow screwed up how you're handling pointers.
What I don't like most about languages like Java and C# is that they lack the notion of const objects.
I really don't miss it, because it didn't really seem to have well-defined semantics in the first place. Java does have 'final', but it doesn't quite do the same thing.
However, when this is actually an issue, you can either use deliberately immutable classes, or you can copy it ahead of time. Not as nice as const, partly because it's not universally supported -- but neither is const.
There is a solution I've used from time to time which is kind of gross, but very workable -- since well-designed Java APIs use interfaces, if I need to return an object or pass it to another object and be absolutely sure it won't be modified, I can create an immutable wrapper object -- tedious, but not hard.
Incidentally, this is one reason I love Ruby -- such wrapper objects are relatively easy to create, and I can write libraries to make them easier. No need to implement every single method in the interface, I can just give it a list of methods to proxy and let it do the rest.
A closure is a snapshot of memory from a context so that you can peer back into that moment of time to the values in place at the time, to arbitrary depth.
That's the most obvious implementation, but it's not the only possible implementation. For one, unless the code in that closure has a call to "eval", you can pretty much read the symbols in it and figure out which variables it needs access to. In other words:
In C++ you have to return the information explicitly. That is you have to decide at the "moment of closure" what memory you are going to save
In a proper implementation of closures, it's still deciding what memory you're going to save, and it's doing it at compilation time -- so the net result is the same, you just have to do less work. What's more, in a language with a Java-like memory model (which Ruby kind of has), it's copying either primitives or references, not whole objects, so it's quite cheap.
Closures in your language of choice were implemented in C so by definition you can implement them in C.
First, not necessarily. I'm fairly sure there are Lisp compilers that were not written in C. Also, given the state of the best closure-enabled VMs or compilers, the C "implementation" is effectively a compiler written in C -- it's certainly not just translating the construct from that language into C.
Second, that's as irrelevant as saying, "Everything in language X was written in something which was written in something which eventually was written in assembly. By definition, you can implement anything in language X in assembly." Would you rather use assembly than C++?
The point of closures isn't that they enable you to do anything you can't do in any other language -- Turing-completeness means that anything you can do in one language, you can emulate in another.
The question is, how ugly is it going to be?
You answered this yourself. You went "eeeew" every time you suggested a way of getting at the functionality in C++. In Ruby, a closure is do...end, and it's quite efficient, considering that this is how most loops are implemented:
Figure most of your for loops would be replaced by that. Yeah, they're going to want to optimize the hell out of that.
Now, I have to ask:
I know the technologies quite well, and I know their implications.
If that's true, it is possible I'm missing something. Is there a reason my suggestion wouldn't work? That is, is there a reason a closure has to actually create a snapshot of memory, or is it enough for it to conceptually do so?
It's hard to imagine how you could be more wrong.
The fact that Ruby to C produces code "neck and neck" with ruby running inside the JVM is pretty much a universal indictment of Ruby,
On the grounds of... what? Performance comparable with... what?
See the plain truth is that the JVM is a least-common-denominator.
It is, but only in a certain context -- in particular, enterprise applications. It's certainly not a least-common denominator for desktop apps -- look how many people have to install Java just to get Minecraft running.
It is an interpreter for gawd's sake,
You pretty directly contradict this with:
and one that knows it is sufficiently crap that it has a "just in time compiler"
You know what? C can be interpreted, too. You wouldn't run it that way, though, would you?
So, Java can be interpreted. It can also be compiled. The JVM includes both.
What about this implies the JVM "sucks"? That it has more features? Or that some of its features aren't a good idea all the time (interpreter), so it automatically chooses a more appropriate mode of operation (compiling)?
why not just JIT the entire code base?
To reduce startup time. You do understand the difference between just in time and ahead of time, right?
And if that, why not just compile the code base once to begin wiht?
You know what? gcj does just that.
But then you lose the runtime flexibility. Reflection can be useful, for one, and that pretty much demands that you keep some sort of intermediate representation around. And then there's the part where I can compile a program for one architecture on one OS, and copy the bytecode files to another architecture and OS, and expect it to work.
Why don't you ask the JavaScript developers why they don't just compile everything? They do compile quite a lot, and I think they might even be doing a better job than the JVM, but a language that dynamic just doesn't make sense as a binary blob.
And then there are the pathological cases where runtime-optimized code can perform better than ahead-of-time compiled code, because the runtime can take into account what is actually happening.
claiming it is new, novel, "a work of art" or any other damn thing is...
Something I see no one here doing. Strawman much?
Ask yourself why JINI had to be invented?
Because there's tons of stuff written in C.
Yes, you can occasionally get a speedup by translating chunks of your program from Java to C. Ask yourself why it's only isolated libraries that do this, and not large chunks of applications. Turns out Java is "fast enough" -- half the speed of C is still plenty fast for most applications, especially with the other advantages you get.
Ask yourself why JIT?
Again, why are you seeing JIT as a bad thing, and why are you seeing it as not part of the JVM?
The whole "compile once, run anywhere" thing is a _lie_ for two reasons.
I guess that program I wrote on my x64 Linux, then sent to someone else running a 32-bit Windows machine, was a figment of my imagination?
(1) the results "run anywhere" but only for _extremely_ constrained definitions of "anywhere"
Any desktop OS is still pretty damned good. The only reason it's not more relevant is that web browsers have gotten good enough that most of the original use cases of desktop Java don't matter anymore.
you "compile once" so the JVM can compile it again and again during runtime.
You mean, so it can compile it once per run, once it determines that it's worth compiling that chunk of code.
Releasing, e.g. _unlocking_ regions of files shared between applications (e.g. matching flock() calls between constructor and destructor to lock and release records at precise times).
Fair point, though I don't know that this saves you from the problem of locking in general. For a significantly parallel app, I'd be looking at either more granularity (Erlang) or less.
Unlocking and dismissing shared object libraries (e.g. undoing dlopen()) when, but not before, the last instance of any/every object dependent on the shared object file goes out of scope.
This makes sense, but it also doesn't seem to match where Java is used most these days -- in a server environment, where people tend to just load everything and let it run.
Preventing "Cruft" in my heap by doing "deep" memory frees of complex structures as soon as I no longer need them instead of at "some random time in the future if ever".
This is the part that GC is for. If you absolutely need that memory back immediately and you have the benchmarks/profiling to back it up, then you're right, you need a language like C.
But GC has gotten pretty damned good. Closing filehandles immediately makes sense, because the OS limits how many of those you can have open, but memory? Depending on what you're doing, GC can actually perform better than manually freeing those structures.
Changing modes and states on devices using ioctl() etc. (e.g. when the last "raw" use of the controlling terminal goes out of scope you put the terminal back into line mode until/unless you need to bring it back into raw mode.)
Interesting... I can't remember ever having to do that.
Resetting hardware on last use.
Emulating devices and subsystems that, by definition, reset themselves on last use.
And now we're definitely beyond the realm of "application development", I would think.
Doing all of the above with "exception safety" without having to write a ass-ton of "finally" blocks (though I _do_ whish C++ had "finally" 8-).
Ruby developed a clever approach to this using blocks, which are effectively closures. The general pattern is:
This translates into, "Call the 'open' method, and pass it this block of code." That method would be defined something like:
The 'yield' calls the block you passed. Effectively, you can develop an API which defines a scope in which you get to work with the file (or whatever it is), and the API handles the exceptions.
You are like a blind guy asking "when was the last time you really used your eyes for anything but reading" because you have never heard of art,
More like, I'm an engineer who doesn't often think of working with art, to the extent that the analogy works at all. See...
you presume destructors are "really just for freeing memory"
I didn't ever assume that.
They are, however, for freeing resources, which fits very nearly every single use case you mentioned. And maybe it's just the code I worked with, but it did seem like most of the time, destructors are there to free memory.
Hell, most of the time, a destructor was only there as a defined virtual in case any descendant classes wanted to free some memory.
I work with too many system internals to think the JVM is a win.
And my work tends to be too far removed from system internals to think th
I don't like Java, but I do have a couple of issues here:
Java doesn't have pointers" my pasty white behind, every object is a pointer in java,
Every object is a reference in Java. There is a world of difference between a name which refers to some object and an integer which might refer to some object, but you can still do integer math, and the object might not even be there anymore...
This is almost as if you're trying not to see the advantages. No more segfaults. No double-frees, no crazy-ass debugging where the wrong method gets called because your pointer is pointing to the wrong (or a corrupt) vtable, and you really have to try to get a memory leak.
they do manage to use pointers to prevent first class object copying, so then they added clone() etc.
And the number of times I should've just passed the original object, vs the number of times I really didn't want it to implicitly clone something? Again, I have to give this one to Java, with the caveat that the interface to clone() kind of sucks. Ruby has dup, and all objects have it by default. Implementing clone() in Java is a pain, and if an object doesn't implement it, you're SOL.
the code out to know when the last object reference is going out of scope so it can call a destructor manually if it wants. That was a stopper for me.
Really? This?
Think back to all the destructors you've ever written in C++. How many of them can you count that did more than free memory? In other words, how many destructors have you ever written which aren't entirely replaced by the garbage collector?
I can pretty much count them on one hand. Filehandles, DB handles, etc. Yes, it sucks, but having to close a filehandle vs having to free every bit of memory I ever allocate? I'll take the filehandle.
So now Ruby fans want to take their niche language and cram it into the fundamentally flawed Java VM.
Wait, what?
You haven't mentioned a single issue with the JVM. Your complaints have been about the Java language. Surely you can tell the difference?
Oh, alright, you had one other complaint: You don't like the lack of proper destructors. Guess what? Ruby doesn't have them either. Ruby has finalizers, just like Java. Of course, I don't see anything about the JVM's design that prevents a language from implementing destructors anyway.
It's also funny how you, like most of Slashdot, seems to have missed the point: JRuby exists, and is pretty much neck and neck with the official C Ruby implementation in terms of performance. It's just as stable, and almost everything that works in one implementation works in the other -- kind of like how you can have multiple C compiles.
This article was about Mirah, which is not Ruby, nor trying to be. It's a way to make Java suck less, at least syntactically. If your gripe isn't with the syntax, you probably won't care about Mirah.
And for a bit of balance, here's the features I really, really miss in Java:
What's more, JRuby exists, and Mirah doesn't compete with JRuby. In fact, it seems one of the motivations for its creation was to make it easier to hack on JRuby itself, which is, after all, quite a lot of Java code.
Because it compiles down to native Java, without any of the JRuby overhead.
You're going to have to slow down a bit, because I'm seeing you make a lot of points without connecting them at all. For example:
if 5 year plus old games like Far Cry or FEAR can run damned well on a 3.4Ghz P4 with an HD3650
Granted...
then there is no damned excuse why your 2011 game looks like ass and runs like shit on the latest and greatest, there just isn't.
What? Why on earth would you assume that newer games would perform better than older games?
Seriously -- Half-Life runs great on any modern PC, probably even Intel GMA. By your logic, I should expect Half-Life 2 to run faster and better than Half-Life. Go look at some screenshots of each game, and then tell me how that makes sense.
I have found even the big budget games that run like ass turn out to be console ports that is obvious there was ZERO optimization on the platform.
So you've disassembled them, have you? Combed carefully through the code from the console version and the PC version to see if you could find a difference in quality?
Not that it matters -- what does this have to do with my post? Zero optimization for a given platform doesn't mean zero optimization, and optimization in the first place can have an adverse effect on stability.
you can't just drop PPC code straight onto i586, be it x86 or x64, and expect to have it run well, you just can't do it.
If their code is that closely tied to a given architecture, they are Doing It Wrong on a very profound level. How much actual PPC code does a game developer write? Not nearly as much as they write, say, C++. In fact, you also seem to be aware of a more likely problem, but it's hard to see through all the bullshit:
the same optimizations for the constrained CPU,RAM, and GPU of the console and not instead taking advantage of the platform
And yes, there are games that do this.
I believe most game coder jobs ARE shitty, but still that is no excuse.
Why not? Do you really believe that it was up to the husband of EA Spouse whether or not the game ran well on a PC? He's already spending an 80-hour week trying to get the console release out the door, where's he going to get another 80 hours to finish up the PC port unless his manager actually gives him that time?
some console reguritation designed to play "lets screw them out of some cash"
So, you've gone from "New games all run like shit" to "They just aren't optimized for the platform" to "It's so bad I want my money back!"
Really?
Or is it that you buy the same game for multiple platforms, and you don't feel the PC version is worth it when you already have a console?
How about less rant and more point?
And sorry about the length but after getting burnt so many times by console lameness...
See, it's not the length that bothers me, it's the amount of kneejerk vitriol here. At this point, it's sounding like every time a game gives you technical issues, you blame the consoles and the developers, when it's not the developers who are choosing the consoles, and most developers really aren't in a position to make things better.
The amount of rage here makes it unlikely any developer is going to take you seriously, which makes it harder to solve the real issues.
I'm sorry but its true, you guys really really REALLY suck.
Somewhat, but not as much as you imagine. In particular:
every damned game that comes out nowadays needs damned near the size of the game in fricking patches because your shit is so buggy?
I would put the blame for this mostly on management, and on the industry as a whole.
See, game developers are forced to do the two worst possible things for stability: They're forced to optimize the hell out of their games by working at a very low level, and they're forced to develop games as fast as they possibly can. Failure to do either of these means your game looks worse than the competition -- if you work at a higher level, your game runs slower, which means it either lags or doesn't look as good. If you don't get to market fast enough, the entire industry may have shifted, or at the very least, your game just won't look as awesome visually compared to what people are doing these days.
Consoles have made the "get to market immediately" part less important, because most gamers are on consoles with the same hardware, and if TFA is right, the PC just doesn't look that much better, no matter how much hardware you throw at the problem. But the industry is still built around the idea that you need to build the next Quake -- something which pushes the boundaries of what your hardware can do, and does it before everyone else does.
Now consider that games are on the order of multiple gigabytes, much more than most other applications require. I challenge you to find a single game which has been patched as often as any modern browser -- but the game's patches will be bigger, because the game itself is bigger.
I tend to agree that game developers suck, but that's only because it seems to me that every single one of these problems is solvable. Even on a console, it seems like most aspects of most games could take a performance hit of 5x or more and still run just as smoothly. Especially with consoles around, it seems like being first to market with a buggy game isn't going to be that much better than spending a few more months on testing and refinement, especially on any sort of investment in a solid engine you can carry from game to game.
Still, I have to call bullshit on this:
When my quad core with an HD4850 struggles because of your crap console code it ain't the fault of DirectX, it is your fault for putting out lame console shit without bothering to optimize for the platform.
This may be the case, and certainly is the case with some games, but if a game can be thoroughly optimized for the 360, PS3, sometimes even a Wii, you'd think they'd be able to optimize for the PC. Maybe they're onto something -- maybe sometimes, they do actually have the budget, time, and skills to optimize for the PC just as they could optimize for a console, but there's something about the PC platform which gets in the way.