Not so much, I think. You'd just land or start hovering before you make the turn. Worst case, you leave the traffic lights, and stop traffic when someone wants to turn -- which is a lot better than stopping it just to allow through traffic going the other way.
Re:The more I learn about JavaScript...
on
GWT in Action
·
· Score: 1
I'm not arguing that either.
I do believe, however, that it's possible to create a common runtime, and maybe even a common language, for all general purpose tasks.
Yes, ALL. Embed it in the browser, write the browser in it (and the webserver), write little scripts to run your system, use it as a command shell, use it to write games or OS kernels...
Basically, use it for anything that doesn't almost physically force you to use a language like Assembly or the GL Shading Language.
So, I keep running into languages that come up short in some ways. You've pointed out some problems with Javascript, and I could probably find a few more. I've pointed out some problems with Java, and the JVM -- and we know that any Javascript or Ruby runtime would likely be slower than any Java runtime, for long-running tasks.
The problem is, I haven't found a single language that I would use for every single one of these things. In fact, pretty much all of them fail at either being faster than C or being able to at least pretend to be interpreted (for an interactive shell/console/debugger, for example -- I know C++ has a debugger, but can I just arbitrarily change the class definition in mid-program?)
I was even open to weird syntax like Erlang or Haskell, but those have weird performance issues. Erlang also pretty clearly illustrated my point by providing the option to compile something or just run it -- I don't remember if this is a choice between bytecode and native, or between bytecode and interpreted. I do remember that the "compiled" version could not allow you to dynamically reload a given function, which is one of the killer selling points of Erlang -- being able to update your program, in many cases without even restarting it, because you can dynamically replace functions so easily. (Easier than Reflections, I'd bet, but I don't know Reflections.)
Perhaps the closest, when I lower my standards enough, is Python. It's been long enough since I've used it that the syntax looks clean, it has a reasonably fast implementation, with the promise of faster-than-C with projects like Psyco and PyPy, and it's got very cool things like continuations that make threading just mindlessly simple.
But the GIL just kills it. I really don't see a way to implement Python properly, and have it scale to multiple cores.
And at this point in my life, I don't really have the time to get started on a project like a new language/runtime, and I don't know enough, particularly about the low-level concepts I'd need. But if there's enough interest, or if there's a project that's close enough, I'd like to help out, at least with testing.
The sad part is, from what I've seen and heard, this Storm "virus" does need human intervention.
It doesn't do anything technically new. The only thing new here is the particular brand of social engineering used, and it bothers me that this still works.
If you have the money, why not just bank some $2000 towards replacing the computer? You know you're going to have to replace it at some point, and that Moore's Law dictates that $2000 will pretty much always buy you a decent computer -- more than decent, top-of-the-line, really.
Then again, I usually get a warranty because I tend to abuse my computers more than most, and I also tend to not have enough money on hand, because if I have $2k, I won't buy a $1k computer and save $1k for later. I'll buy a $2k computer.
Re:The more I learn about JavaScript...
on
GWT in Action
·
· Score: 1
Sure, but the point is that there are languages like Scala that work on the JVM, have closures, first class functions, etc., and are also strongly typed with support for type inference. So if the question is "why not Javascript?", my answer will be "why not Scala?"
At the moment, the JVM is still unbearably slow to start, and has just been bloated and not entirely portable, in my (limited) experience. (As an example, we complain about having no 64-bit support for Flash, but there's no 64-bit browser plugin for Java, either.)
Note that I say: "so it's actually *not always* a bad idea to fix yourself"
I see. Sorry about that.
But then...
Unit testing, the wonderful solution for everything, whether it involves syntax checking or API evolution. Sorry, but I don't buy that.
I didn't say it was a solution to everything. It is, however, a very useful tool, as is test-driven development. And where I can, I would rather specify things as part of a more comprehensive test than as part of the actual code.
Which is probably a bad idea in a dynamically-typed language. I do have an idea for a way around that...
The only place where that's absolutely a good idea is when all those implementations are supposed to have the same sig/API, so you would want to change all of them at once anyway.
Yep, I prefer to break hard an early. I would typically make the old method final on abstract classes or remove it if it is part of the interface. That together with library versions in case there are multiple projects depending on it, ensures that no-one will miss it.
It also ensures that your library is going to be a pain to work with on systems that do shared libraries well. Sure, multiple versions can be installed at the same time, but generally, you only want to do that with major revisions -- especially since you need your app to know which version it needs, while at the same time not forcing them to one particular revision.
In other words: Consider OpenGL. Apps on my system link against/usr/lib/libGL.so.1. On my system, that's a symlink to libGL.so.1.0.9755, which is a specific version of the nVidia driver.
Obviously, you'd want incremental updates to that driver, maybe even introduce some incompatible new APIs that programs can detect and use, if they're available. But if you really want to break apps, you'd define OpenGL v2, and you might even have/usr/lib/libGL.so.1 is entirely wrappers around/usr/lib/libGL.so.2, which new apps link against.
But see, *you* are the one making the change, so you probably know best what the implications are so it's actually not always a bad idea to fix yourself.
Maybe so. But I also don't necessarily know my way around everyone else's code, so I don't necessarily know best what the implications are if I make the change there. Generally, if it's an incompatible change, it is actually going to require more than just changing the one line in which my method is called.
It also doesn't address the problem of projects that I don't actually control.
But I'm arguing you should want proper support for both. And static typing is helpful in that.
Maybe so. I think, though, that if you actually remove the old method (interface, API, etc) and provide a new one, that's sufficient to break it. I think the only difference is whether the break happens at compiletime or runtime, but as we're learning now, unit testing is a must for any sizable project, and unit testing is basically trying to break it at runtime.
What do I need type info for, when I can just search for the method name?
Re:The more I learn about JavaScript...
on
GWT in Action
·
· Score: 1
But of course you care! You have to know that alert() takes an object with toString() defined. That's type information.
True enough. I know that because I read the alert() documentation.
alert() is a cherry-picked example anyways -- it is simple and ubiquitous
And anything with documentation is going to be able to tell me what the type is.
I know Java has the type right there in the argument list. However, I still have to go look up that list (the method signature), and I then have to go look up what each of those types actually is.
Are you honestly telling me that you don't have to care about types when calling those methods?
Be more specific. Looking at a few random ones, I only saw various strings, or occasionally a hash table of strings, so no, not much type information to care about here.
Nope. It works as if I had written it out. The compiler knows the types by inferring them. Wikipedia has an entry on it.
The sad fact is, even C++ has more type inference than Java. Among other things, it doesn't force me to declare "throws IOException" on absolutely every function that might, however indirectly, touch IO.
Yes, I have actually used Java for a bit more than a "Hello World" program. I still don't like it.
They break the API, try to compile and fix all references, and you benefit as a result.
Actually, they generally don't. Take a look at OSS and ALSA -- they discovered that they were going to have to replace OSS. So they developed ALSA alongside it, and ALSA provides OSS emulation. You can use either, but if you choose to use ALSA, your old OSS programs will keep working.
You cannot do this practically with Javascript since any Javascript code over 500 lines ends up using eval.
Bullshit. And I say that, having just written a Javascript program over 500 lines long.
I didn't use document.write or innerHTML, either.
Or you might at runtime decide to add a method to a JS class if a certain event happens. Eclipse won't pick up that method until the program actually runs.
True, at which point you can look at it in a debugger. Which solves eval, too, if you were using eval anyway, which you shouldn't.
Java, on the flipside, doesn't offer the nice type tricks you can do in Javascript.
That would be because Javascript essentially has no types.
You on the other hand, wax poetically about the wonders of Javascript. You are a Javascript fanboi.
In other words, it's impossible to not be a fanboi unless I have a neutral opinion?
If someone has a valid reason for Java stinking, I will listen if it's a good point.
Alright, here you go: It has no closures or anonymous classes. I don't remember it having anonymous functions/methods, either.
It also has a type system stricter than any I know of. Everything I hated about C++ header files is even worse in Java -- I have to write probably five lines of structure for every one line that actually does something.
It manages to be much more verbose than it even needed to be for that. Why do I have to declare what exceptions I might throw? That's information that any decent compiler/IDE should be able to figure out for me. Forcing me to type it myself just adds more carpal tunnel and more chances for stupid compile-time errors.
It caches. The GWT compiler at compile time assembles the JS into different files and decides based on the browser, language, property files, which files to send over.
In other words, it goes by user-agent? Man, that sucks.
But apparently you didn't read the rest of my post. Yes, it'll cache -- for one browser, for one version. Update one line of code in a 1k file? Too bad, the users now have to download all 100k of your script. Caching proxy? Has to cache one version of the entire script for each browser, instead of being able to share everything except the small, browser-specific differences.
Now, practically, most users don't care about this. Most users wouldn't care if it was cacheable at all. But it is a concern.
Java kool-aid. Yes I see the fanboi in you comes out. No facts, just fanboism and ancient tribalism over a programming language. Java bad. Javascript good.
Not sure how "ancient" it can be, given how Javascript sucked when it first came out...
And you're certainly one to talk. Calling names rather than bringing valid facts. Strawmen instead of valid arguments.
If you have opera, you will download the IE checks.
All ten lines of them. The horror!
You rely on me to educate you about GWT vs using it or even reading about it.
Ditto.
Your little life lesson would be a lot more helpful if you'd actually tried to read and understand my post. Instead, you instantly branded me a "fanboi" and stopped taking me seriously. What does that say about you?
Unfortunately, in my experience, deprecated warnings are often ignored by people, *even* if their IDE warns them.
You'd rather break their code immediately?
having to be back wards compatible can be a pain as well that slows you down properly fixing/ improving things.
Ultimately, yes. Eventually, you'd want to throw all your backwards compatibility in some "compat" library.
But if you do this incrementally, I don't see that you'd have that much to maintain. If you find, down the road, that it's become too expensive to maintain a particular depricated function, drop it then -- but not when you can wrap it in 20 seconds.
I'd also rather have 10 programmers fix 2 calls each than have to fix all 20 calls myself.
Re:The more I learn about JavaScript...
on
GWT in Action
·
· Score: 1
Reflection isn't hard, and it's built into the language.
So implement closures with reflections... Not so easy, is it?
However, implementing namespaces in Javascript is natural and easy.
But it wasn't, and so ad-hoc solutions are proposed, which breaks down when you try to compose 3rd party libraries. It sure is nice having it built-in from the start.
In other words, you'd prefer a language that forces best practices onto you, so that everyone will use them, than a language which lets you do whatever you want, including best practices?
I prefer flexibility. I think it's easier to build a restrictive subset of a flexible language than it is to tack on flexibility to a restrictive language.
Also: If you make the base language too restrictive, you'll always find people willing to use another language, just to avoid working in yours. And this will be true of libraries, as well.
However what you gain via dynamic hacks you lose in explicitly expressing your abstractions. Take "goto" as an example. In one sense it is low-level, but in another sense it is powerful.
Ah, but goto is actually harmful -- it produces extremely buggy, error-prone code. Breaking out of nested code is better handled by things like exceptions and loop labels, and I really can't think of any other legitimate uses of goto.
At the same time, I can see a language that included goto, and then built other, higher-level structures as part of a standard library which wrapped around goto.
However, these namespace "hacks" do produce good, readable, re-usable code. I'd even argue that it's more re-usable than a static definition of a "namespace". Wrap it in a library, and you have the option of building development suites which understand that library, thus understanding your higher-level abstractions.
Easier to build from a flexible language than to bend an inflexible one.
It's called "backwards-compatibility", and it lasts as long as you care to maintain it.
Obviously, you should also post something to the changelog/mailing list/whatever letting everyone know what you did, so that they can update their methods on their own. And you can always try removing that wrapper function and seeing if your code runs -- if it's a private interface, that should be the end goal.
Even in a public interface, that should be the end goal, but I don't think there's much harm in carrying around a wrapper with a big fat "DEPRICATED -- DO NOT USE" sign on it. It lets people's programs keep working for now, while they update it themselves -- you pretty much have to do it this way for public interfaces.
Re:The more I learn about JavaScript...
on
GWT in Action
·
· Score: 1
I've seen enough dynamically written code to know that the types are there, but latent. For example, if a method takes a "foo" argument, the method is written with knowledge of what a foo is.
Not entirely true. It's not the types that are there, it's the interfaces.
For example: Consider Javascript's alert function. It only needs an object that has a toString method. In fact, it can take any object, because Object has a toString method. The only way it wouldn't work is if you deliberately overrode toString with something that's not a method.
I know Java has similar things -- it has Interfaces, with a capital I, which is a way of getting around Java's lack of multiple inheritance. So in Java, you would have to define a "Stringable" interface, which defines what a toString method looks like. It's a nice way of forcing people to write documentation, and it does improve compile-time checking, but that's all.
In Javascript, I can just define toString and use it. I don't have to define some complex system of interfaces and inheritance just to make sure that by the time I pass in an object that I already know will work in this case, the compiler agrees with me that it will work. Instead, it's just a matter of "Does foo have a toString defined? Yes? Ok, I assume you know what you're doing."
And I say it's nice when the compiler keeps track of types for me!
So do I -- which is why I don't like Java. Java forces me to keep track of the types myself, verbosely. At least the compiler will make sure I'm doing it right, most of the time -- which is basically like running my C/C++ program through Valgrind looking for memory leaks.
And I like Javascript because I don't have to know about types anyway. It doesn't care what type something is, only what it can do.
But there are much better statically typed systems that infer the type for you, so you don't have to write it out all the time.
In which case, it gets closer to a dynamically-typed language. And if you don't have to write it out all the time, it also gets rid of your "find everything you need with a simple click" advantage.
Javascript is actually not my ideal language -- really, it sucks. But all languages suck. My ideal language doesn't exist yet, and it would also be a very tough one to write.
I would call it refactoring to "make a new method and wrap it with the old one."
It's just the kind of refactoring that doesn't require cooperation from everyone at once, or a massive search/replace through all your code.
Re:The more I learn about JavaScript...
on
GWT in Action
·
· Score: 1
In this thread you've made statements along the lines that features which are lacking in Javascript can be mimicked with hacking.
The kind of hacking I'm talking about is actually intentional to the language. It's convenient, easy to do, and makes sense.
But as far as I'm concerned, by the time we're talking about reflection, it's more than just "not built-in", we're getting into the realm of "Well, you can do anything you want, as long as you write a preprocessor..." In other words, at this point, the distinction becomes kind of meaningless, because you can compile Java into Javascript (GWT), and vice versa (Rhino).
Compared to, for example, the claimed lack of namespace -- that can be done so easily it may as well have been a language feature.
Language design is all about tradeoffs.
That much is true.
There isn't some magical "power" number you can ascribe to them, especially when they're Turing complete.
Turing-completeness has nothing to do with power. It would be difficult for me to define what I mean by "powerful", but I think we can all agree that assembly language isn't particularly powerful, and neither is Basic.
Where I find a lack of power, where I find places where I say "This feature isn't in the language," is when you have to actually tie yourself and your code in knots to pretend a feature is there when it's not -- when there's no syntax for it, and no easy way to derive the feature from existing syntax. Reflections don't count any more than writing an interpreter in your language does -- for example, Rhino does not prove that Java is as powerful as Javascript (even if Rhino targeted Java directly; it targets bytecode).
Where I find an abundance of power is in places where it's easy and natural to extend a language, or where useful patterns are available within a few lines of code. Just about everything I was missing in Javascript can be added in less than ten lines of code -- of Javascript code -- or in two and there line patterns. I haven't used Java reflections, but I doubt it's anywhere near that easy.
One example of a feature that's actually missing from Javascript is the ability to support true integers. Hacking around it won't make it actually use integers at the interpreter level, and your hacks would be fairly ugly. I don't run into this often in practice, though -- rounding a float is easy enough, if I need to.
Another example is foreach loops. Javascript does have them, but the syntax is annoying -- I get the index, not the value, meaning I can't do this with anonymous arrays. I may be able to work around this later, though -- I imagine it won't be hard.
And then there's + for concatenation, and things like that.
But these are not things that actually make me pull my hair out and refuse to work in a language. Java's explicit exception re-throwing does, along with other verbosity.
Are you really comparing software run on my own machine, scanning software I download from you for GPL violations, to DRM that I might impose on you and your machine?
The FSF will only work to enforce the GPL if the GPL code in question is signed over to the FSF.
Um... duh?
If I'm not going to hold my own copyright, why not just specifically disavow copyright and let it enrich everybody via the public domain?
That's up to you.
But keep in mind -- you can hold your own copyright, and not sign it away to the FSF, and also GPL it. This gives you the freedom to change the license later on.
In fact, you'll notice that many large projects like MySQL do request that you sign over your patches to them, so that they can re-license them for other uses. Even completely open projects, like Gentoo, retain that right. It lets them actually make choices about things like GPLv3, as compared to Linux, which has no choice but to stay GPLv2 or undergo a fairly massive rewrite.
I think it's just a bit petty to show the code but not authorize its use.
Ok, you do understand the point of the GPL, right? That you can only re-use it if you release your own code under the GPL?
So let me get this straight -- you want it to only be possible to download GPL'd code once you release all of your own source? Or something like that? Because that seems to be the only way to do what you're asking.
One more thing: The GPLv2 only covers redistribution. GPLv3 might cover more things, but with GPLv2, you can, in fact, download the code and use it any way you want, as long as you don't give it to anyone else. This is how we get binary blobs in the kernel -- they force the users to apply the patches themselves. It also means that it's entirely possible to roll your own webapp based on some GPL'd one, and keep all of your changes to yourself -- your users aren't actually downloading your app, so the GPL doesn't affect you at all.
How is that any more "petty" than letting someone download, say, a free demo of a game, and then dictating the terms under which they might share it (or not)?
It would be legal if they actually included the GPL and were prepared to provide source code for those commandline utilities.
But yeah... clueless.
Re:The more I learn about JavaScript...
on
GWT in Action
·
· Score: 1
In a Java IDE like Eclipse
That's not compile time, that's IDE time. In which case, you can use Eclipse for Javascript. I believe Aptana is a variant of eclipse specifically designed for this.
You can see the types of all arguments to functions, which makes it easier to reason about code.
I just don't find this to be true at all. Maybe I think a different way, but it was a breath of fresh air when I discovered that I no longer had to care about the type of a given object, argument, or whatever. I never really found types useful, just one more thing I had to keep track of -- kind of like memory management. It's just nice to be able to work in a garbage-collected language.
Re:The more I learn about JavaScript...
on
GWT in Action
·
· Score: 1
Also, I end up having to debug my javascript in both IE and FF in order to make sure that it works in both browsers.
Maybe I'm just naive, but I haven't found many places where the Javascript implementation itself is any different in IE. The DOM and various APIs, sure, but once you've abstracted those away in a (very small) library, you're done -- you can develop in Firefox and deploy in IE.
If you create an object and call a method on that object, then the this variable within the scope of the method refers to the object whose method has been called. However, if you set that method as the target to an event and that event gets fired, then the this variable within the scope of the method refers to the object that fired the event.
That's not a bug, it's a feature, although perhaps not a very commonly-used one...
I haven't tested it, but I believe you can do something like: foo.method = bar.method
That's kind of a Ruby pattern -- mixins.
As for the workaround, like I keep saying to everyone, read Douglas Crockford. If you don't like which "this" is being used, you can always reassign it with: var that = this
Because Javascript supports closures, the "that" variable will always be available through the scope in which you defined your method. It makes it very easy to explicitly define which object you're talking about, even if you end up defining other singleton objects within your main class/constructor.
I realize that there are libraries (e.g. prototype binding) that get around this but the fact that you have to use a library for a properly working this variable reflects poorly on the language.
I disagree -- the fact that you can use a library to fix something you don't like about a language demonstrates just how powerful it is.
In other words: Javascript is quirky, and this is to be expected, given its history. But just about every single one of those quirks that's actually a problem can be worked around within the language itself, and you can put those workarounds in a library. Not many other languages can do that.
You can's easily load & remove them like its nothing as part of the core language; you have to rely on tricks.
These "tricks" are not difficult, as I've just demonstrated. In fact, you could probably implement something like Java's "import", if it's not there already. You can certainly do things that Java doesn't let you -- for instance, you can rename a namespace, as I just demonstrated.
So in what way is it "not real namespaces" other than not being a part of the language? (Because that buys you nothing -- most of Ruby, for example, is written in Ruby.)
More importantly you have to rely on library writers adhering to this design pattern.
News flash: Libraries don't always behave the way you want. News at 11.
It doesn't prevent you from using namespaces in your own projects, and if you must use poorly-designed libraries, you can still do so. It's a bit like writing a C++ project and calling C code. Or, hell, it's like writing a Java project and calling C code.
Speaking of which, C has done fairly well without namespaces at all. They stick to naming conventions. I'm not saying that's better, but I don't see namespaces as such a crucial feature anymore.
Now let's say you have your javascript method that 10 developers call in 20 different ways. Let's say you change that method signature.
I'd have to think very hard to come up with a situation in which I have to change a method signature that's already being used by 10 developers, rather than simply making a new method and wrapping it with the old one. Isn't that the whole point of Java "interfaces", to define a public API and then leave it alone?
You have just hosed the code base and pissed off 10 developers, or you can spend 10-30 mins updating all references, hoping you haven't made an stupid spelling mistakes which you would only find at runtime.
Or I can use an IDE which supports Javascript -- surprise, Eclipse does! And finding all of the references is as easy as grep -- or if it's not, you have yet to explain why not.
GWT doesn't dumbly cat together files. It only streams what you need which decreases response time.
In other words, it "intelligently" cats together files in a way that makes caching impossible. I believe I did address that, while you were busy making jokes about "virginal nerds."
Oh wait -- you were wrong here. Looking at the actual page, it suggests that GWT simply generates a version of the code for each browser -- which decreases cacheability for proxies, and is also very easy to do with cat. Combine it with make, split browser-specific parts into src/browser/firefox.js and src/browser/opera.js. Done.
In a well-designed framework, these end up being small enough (1-2k) not to make a difference. And that 1-2k becomes pretty insignificant once it gets gzipped down to a few hundred bytes.
Fortunately for me, my boss has not drunk the Java kool-aid, so I can afford to make smart decisions here.
Slashdot Mirror
Not so much, I think. You'd just land or start hovering before you make the turn. Worst case, you leave the traffic lights, and stop traffic when someone wants to turn -- which is a lot better than stopping it just to allow through traffic going the other way.
I'm not arguing that either.
I do believe, however, that it's possible to create a common runtime, and maybe even a common language, for all general purpose tasks.
Yes, ALL. Embed it in the browser, write the browser in it (and the webserver), write little scripts to run your system, use it as a command shell, use it to write games or OS kernels...
Basically, use it for anything that doesn't almost physically force you to use a language like Assembly or the GL Shading Language.
So, I keep running into languages that come up short in some ways. You've pointed out some problems with Javascript, and I could probably find a few more. I've pointed out some problems with Java, and the JVM -- and we know that any Javascript or Ruby runtime would likely be slower than any Java runtime, for long-running tasks.
The problem is, I haven't found a single language that I would use for every single one of these things. In fact, pretty much all of them fail at either being faster than C or being able to at least pretend to be interpreted (for an interactive shell/console/debugger, for example -- I know C++ has a debugger, but can I just arbitrarily change the class definition in mid-program?)
I was even open to weird syntax like Erlang or Haskell, but those have weird performance issues. Erlang also pretty clearly illustrated my point by providing the option to compile something or just run it -- I don't remember if this is a choice between bytecode and native, or between bytecode and interpreted. I do remember that the "compiled" version could not allow you to dynamically reload a given function, which is one of the killer selling points of Erlang -- being able to update your program, in many cases without even restarting it, because you can dynamically replace functions so easily. (Easier than Reflections, I'd bet, but I don't know Reflections.)
Perhaps the closest, when I lower my standards enough, is Python. It's been long enough since I've used it that the syntax looks clean, it has a reasonably fast implementation, with the promise of faster-than-C with projects like Psyco and PyPy, and it's got very cool things like continuations that make threading just mindlessly simple.
But the GIL just kills it. I really don't see a way to implement Python properly, and have it scale to multiple cores.
And at this point in my life, I don't really have the time to get started on a project like a new language/runtime, and I don't know enough, particularly about the low-level concepts I'd need. But if there's enough interest, or if there's a project that's close enough, I'd like to help out, at least with testing.
The sad part is, from what I've seen and heard, this Storm "virus" does need human intervention.
It doesn't do anything technically new. The only thing new here is the particular brand of social engineering used, and it bothers me that this still works.
Dell provides Ubuntu now. You can also build your own and get no OS on it.
If you have the money, why not just bank some $2000 towards replacing the computer? You know you're going to have to replace it at some point, and that Moore's Law dictates that $2000 will pretty much always buy you a decent computer -- more than decent, top-of-the-line, really.
Then again, I usually get a warranty because I tend to abuse my computers more than most, and I also tend to not have enough money on hand, because if I have $2k, I won't buy a $1k computer and save $1k for later. I'll buy a $2k computer.
At the moment, the JVM is still unbearably slow to start, and has just been bloated and not entirely portable, in my (limited) experience. (As an example, we complain about having no 64-bit support for Flash, but there's no 64-bit browser plugin for Java, either.)
I see. Sorry about that.
But then...
I didn't say it was a solution to everything. It is, however, a very useful tool, as is test-driven development. And where I can, I would rather specify things as part of a more comprehensive test than as part of the actual code.
Which is probably a bad idea in a dynamically-typed language. I do have an idea for a way around that...
The only place where that's absolutely a good idea is when all those implementations are supposed to have the same sig/API, so you would want to change all of them at once anyway.
It also ensures that your library is going to be a pain to work with on systems that do shared libraries well. Sure, multiple versions can be installed at the same time, but generally, you only want to do that with major revisions -- especially since you need your app to know which version it needs, while at the same time not forcing them to one particular revision.
In other words: Consider OpenGL. Apps on my system link against /usr/lib/libGL.so.1. On my system, that's a symlink to libGL.so.1.0.9755, which is a specific version of the nVidia driver.
Obviously, you'd want incremental updates to that driver, maybe even introduce some incompatible new APIs that programs can detect and use, if they're available. But if you really want to break apps, you'd define OpenGL v2, and you might even have /usr/lib/libGL.so.1 is entirely wrappers around /usr/lib/libGL.so.2, which new apps link against.
Maybe so. But I also don't necessarily know my way around everyone else's code, so I don't necessarily know best what the implications are if I make the change there. Generally, if it's an incompatible change, it is actually going to require more than just changing the one line in which my method is called.
It also doesn't address the problem of projects that I don't actually control.
Maybe so. I think, though, that if you actually remove the old method (interface, API, etc) and provide a new one, that's sufficient to break it. I think the only difference is whether the break happens at compiletime or runtime, but as we're learning now, unit testing is a must for any sizable project, and unit testing is basically trying to break it at runtime.
What do I need type info for, when I can just search for the method name?
True enough. I know that because I read the alert() documentation.
And anything with documentation is going to be able to tell me what the type is.
I know Java has the type right there in the argument list. However, I still have to go look up that list (the method signature), and I then have to go look up what each of those types actually is.
Be more specific. Looking at a few random ones, I only saw various strings, or occasionally a hash table of strings, so no, not much type information to care about here.
The sad fact is, even C++ has more type inference than Java. Among other things, it doesn't force me to declare "throws IOException" on absolutely every function that might, however indirectly, touch IO.
Yes, I have actually used Java for a bit more than a "Hello World" program. I still don't like it.
Actually, they generally don't. Take a look at OSS and ALSA -- they discovered that they were going to have to replace OSS. So they developed ALSA alongside it, and ALSA provides OSS emulation. You can use either, but if you choose to use ALSA, your old OSS programs will keep working.
Bullshit. And I say that, having just written a Javascript program over 500 lines long.
I didn't use document.write or innerHTML, either.
True, at which point you can look at it in a debugger. Which solves eval, too, if you were using eval anyway, which you shouldn't.
That would be because Javascript essentially has no types.
In other words, it's impossible to not be a fanboi unless I have a neutral opinion?
Alright, here you go: It has no closures or anonymous classes. I don't remember it having anonymous functions/methods, either.
It also has a type system stricter than any I know of. Everything I hated about C++ header files is even worse in Java -- I have to write probably five lines of structure for every one line that actually does something.
It manages to be much more verbose than it even needed to be for that. Why do I have to declare what exceptions I might throw? That's information that any decent compiler/IDE should be able to figure out for me. Forcing me to type it myself just adds more carpal tunnel and more chances for stupid compile-time errors.
In other words, it goes by user-agent? Man, that sucks.
But apparently you didn't read the rest of my post. Yes, it'll cache -- for one browser, for one version. Update one line of code in a 1k file? Too bad, the users now have to download all 100k of your script. Caching proxy? Has to cache one version of the entire script for each browser, instead of being able to share everything except the small, browser-specific differences.
Now, practically, most users don't care about this. Most users wouldn't care if it was cacheable at all. But it is a concern.
Not sure how "ancient" it can be, given how Javascript sucked when it first came out...
And you're certainly one to talk. Calling names rather than bringing valid facts. Strawmen instead of valid arguments.
All ten lines of them. The horror!
Ditto.
Your little life lesson would be a lot more helpful if you'd actually tried to read and understand my post. Instead, you instantly branded me a "fanboi" and stopped taking me seriously. What does that say about you?
You'd rather break their code immediately?
Ultimately, yes. Eventually, you'd want to throw all your backwards compatibility in some "compat" library.
But if you do this incrementally, I don't see that you'd have that much to maintain. If you find, down the road, that it's become too expensive to maintain a particular depricated function, drop it then -- but not when you can wrap it in 20 seconds.
I'd also rather have 10 programmers fix 2 calls each than have to fix all 20 calls myself.
So implement closures with reflections... Not so easy, is it?
However, implementing namespaces in Javascript is natural and easy.
In other words, you'd prefer a language that forces best practices onto you, so that everyone will use them, than a language which lets you do whatever you want, including best practices?
I prefer flexibility. I think it's easier to build a restrictive subset of a flexible language than it is to tack on flexibility to a restrictive language.
Also: If you make the base language too restrictive, you'll always find people willing to use another language, just to avoid working in yours. And this will be true of libraries, as well.
Ah, but goto is actually harmful -- it produces extremely buggy, error-prone code. Breaking out of nested code is better handled by things like exceptions and loop labels, and I really can't think of any other legitimate uses of goto.
At the same time, I can see a language that included goto, and then built other, higher-level structures as part of a standard library which wrapped around goto.
However, these namespace "hacks" do produce good, readable, re-usable code. I'd even argue that it's more re-usable than a static definition of a "namespace". Wrap it in a library, and you have the option of building development suites which understand that library, thus understanding your higher-level abstractions.
Easier to build from a flexible language than to bend an inflexible one.
It's called "backwards-compatibility", and it lasts as long as you care to maintain it.
Obviously, you should also post something to the changelog/mailing list/whatever letting everyone know what you did, so that they can update their methods on their own. And you can always try removing that wrapper function and seeing if your code runs -- if it's a private interface, that should be the end goal.
Even in a public interface, that should be the end goal, but I don't think there's much harm in carrying around a wrapper with a big fat "DEPRICATED -- DO NOT USE" sign on it. It lets people's programs keep working for now, while they update it themselves -- you pretty much have to do it this way for public interfaces.
Not entirely true. It's not the types that are there, it's the interfaces.
For example: Consider Javascript's alert function. It only needs an object that has a toString method. In fact, it can take any object, because Object has a toString method. The only way it wouldn't work is if you deliberately overrode toString with something that's not a method.
I know Java has similar things -- it has Interfaces, with a capital I, which is a way of getting around Java's lack of multiple inheritance. So in Java, you would have to define a "Stringable" interface, which defines what a toString method looks like. It's a nice way of forcing people to write documentation, and it does improve compile-time checking, but that's all.
In Javascript, I can just define toString and use it. I don't have to define some complex system of interfaces and inheritance just to make sure that by the time I pass in an object that I already know will work in this case, the compiler agrees with me that it will work. Instead, it's just a matter of "Does foo have a toString defined? Yes? Ok, I assume you know what you're doing."
So do I -- which is why I don't like Java. Java forces me to keep track of the types myself, verbosely. At least the compiler will make sure I'm doing it right, most of the time -- which is basically like running my C/C++ program through Valgrind looking for memory leaks.
And I like Javascript because I don't have to know about types anyway. It doesn't care what type something is, only what it can do.
In which case, it gets closer to a dynamically-typed language. And if you don't have to write it out all the time, it also gets rid of your "find everything you need with a simple click" advantage.
Javascript is actually not my ideal language -- really, it sucks. But all languages suck. My ideal language doesn't exist yet, and it would also be a very tough one to write.
I would call it refactoring to "make a new method and wrap it with the old one."
It's just the kind of refactoring that doesn't require cooperation from everyone at once, or a massive search/replace through all your code.
The kind of hacking I'm talking about is actually intentional to the language. It's convenient, easy to do, and makes sense.
But as far as I'm concerned, by the time we're talking about reflection, it's more than just "not built-in", we're getting into the realm of "Well, you can do anything you want, as long as you write a preprocessor..." In other words, at this point, the distinction becomes kind of meaningless, because you can compile Java into Javascript (GWT), and vice versa (Rhino).
Compared to, for example, the claimed lack of namespace -- that can be done so easily it may as well have been a language feature.
That much is true.
Turing-completeness has nothing to do with power. It would be difficult for me to define what I mean by "powerful", but I think we can all agree that assembly language isn't particularly powerful, and neither is Basic.
Where I find a lack of power, where I find places where I say "This feature isn't in the language," is when you have to actually tie yourself and your code in knots to pretend a feature is there when it's not -- when there's no syntax for it, and no easy way to derive the feature from existing syntax. Reflections don't count any more than writing an interpreter in your language does -- for example, Rhino does not prove that Java is as powerful as Javascript (even if Rhino targeted Java directly; it targets bytecode).
Where I find an abundance of power is in places where it's easy and natural to extend a language, or where useful patterns are available within a few lines of code. Just about everything I was missing in Javascript can be added in less than ten lines of code -- of Javascript code -- or in two and there line patterns. I haven't used Java reflections, but I doubt it's anywhere near that easy.
One example of a feature that's actually missing from Javascript is the ability to support true integers. Hacking around it won't make it actually use integers at the interpreter level, and your hacks would be fairly ugly. I don't run into this often in practice, though -- rounding a float is easy enough, if I need to.
Another example is foreach loops. Javascript does have them, but the syntax is annoying -- I get the index, not the value, meaning I can't do this with anonymous arrays. I may be able to work around this later, though -- I imagine it won't be hard.
And then there's + for concatenation, and things like that.
But these are not things that actually make me pull my hair out and refuse to work in a language. Java's explicit exception re-throwing does, along with other verbosity.
Are you really comparing software run on my own machine, scanning software I download from you for GPL violations, to DRM that I might impose on you and your machine?
You must be joking.
Um... duh?
That's up to you.
But keep in mind -- you can hold your own copyright, and not sign it away to the FSF, and also GPL it. This gives you the freedom to change the license later on.
In fact, you'll notice that many large projects like MySQL do request that you sign over your patches to them, so that they can re-license them for other uses. Even completely open projects, like Gentoo, retain that right. It lets them actually make choices about things like GPLv3, as compared to Linux, which has no choice but to stay GPLv2 or undergo a fairly massive rewrite.
Ok, you do understand the point of the GPL, right? That you can only re-use it if you release your own code under the GPL?
So let me get this straight -- you want it to only be possible to download GPL'd code once you release all of your own source? Or something like that? Because that seems to be the only way to do what you're asking.
One more thing: The GPLv2 only covers redistribution. GPLv3 might cover more things, but with GPLv2, you can, in fact, download the code and use it any way you want, as long as you don't give it to anyone else. This is how we get binary blobs in the kernel -- they force the users to apply the patches themselves. It also means that it's entirely possible to roll your own webapp based on some GPL'd one, and keep all of your changes to yourself -- your users aren't actually downloading your app, so the GPL doesn't affect you at all.
How is that any more "petty" than letting someone download, say, a free demo of a game, and then dictating the terms under which they might share it (or not)?
It would be legal if they actually included the GPL and were prepared to provide source code for those commandline utilities.
But yeah... clueless.
That's not compile time, that's IDE time. In which case, you can use Eclipse for Javascript. I believe Aptana is a variant of eclipse specifically designed for this.
I just don't find this to be true at all. Maybe I think a different way, but it was a breath of fresh air when I discovered that I no longer had to care about the type of a given object, argument, or whatever. I never really found types useful, just one more thing I had to keep track of -- kind of like memory management. It's just nice to be able to work in a garbage-collected language.
Maybe I'm just naive, but I haven't found many places where the Javascript implementation itself is any different in IE. The DOM and various APIs, sure, but once you've abstracted those away in a (very small) library, you're done -- you can develop in Firefox and deploy in IE.
That's not a bug, it's a feature, although perhaps not a very commonly-used one...
I haven't tested it, but I believe you can do something like: foo.method = bar.method
That's kind of a Ruby pattern -- mixins.
As for the workaround, like I keep saying to everyone, read Douglas Crockford. If you don't like which "this" is being used, you can always reassign it with: var that = this
Because Javascript supports closures, the "that" variable will always be available through the scope in which you defined your method. It makes it very easy to explicitly define which object you're talking about, even if you end up defining other singleton objects within your main class/constructor.
I disagree -- the fact that you can use a library to fix something you don't like about a language demonstrates just how powerful it is.
In other words: Javascript is quirky, and this is to be expected, given its history. But just about every single one of those quirks that's actually a problem can be worked around within the language itself, and you can put those workarounds in a library. Not many other languages can do that.
These "tricks" are not difficult, as I've just demonstrated. In fact, you could probably implement something like Java's "import", if it's not there already. You can certainly do things that Java doesn't let you -- for instance, you can rename a namespace, as I just demonstrated.
So in what way is it "not real namespaces" other than not being a part of the language? (Because that buys you nothing -- most of Ruby, for example, is written in Ruby.)
News flash: Libraries don't always behave the way you want. News at 11.
It doesn't prevent you from using namespaces in your own projects, and if you must use poorly-designed libraries, you can still do so. It's a bit like writing a C++ project and calling C code. Or, hell, it's like writing a Java project and calling C code.
Speaking of which, C has done fairly well without namespaces at all. They stick to naming conventions. I'm not saying that's better, but I don't see namespaces as such a crucial feature anymore.
I'd have to think very hard to come up with a situation in which I have to change a method signature that's already being used by 10 developers, rather than simply making a new method and wrapping it with the old one. Isn't that the whole point of Java "interfaces", to define a public API and then leave it alone?
Or I can use an IDE which supports Javascript -- surprise, Eclipse does! And finding all of the references is as easy as grep -- or if it's not, you have yet to explain why not.
In other words, it "intelligently" cats together files in a way that makes caching impossible. I believe I did address that, while you were busy making jokes about "virginal nerds."
Oh wait -- you were wrong here. Looking at the actual page, it suggests that GWT simply generates a version of the code for each browser -- which decreases cacheability for proxies, and is also very easy to do with cat. Combine it with make, split browser-specific parts into src/browser/firefox.js and src/browser/opera.js. Done.
In a well-designed framework, these end up being small enough (1-2k) not to make a difference. And that 1-2k becomes pretty insignificant once it gets gzipped down to a few hundred bytes.
Fortunately for me, my boss has not drunk the Java kool-aid, so I can afford to make smart decisions here.