The next "big thing" will be some dipshit who writes an HTML rendering engine using nothing but JavaScript and HTML5 canvas.
Nope, canvas clearly isn't the right choice. If some dipshit were to seriously consider this, they'd use OpenGL.
Just because this is how the Web community does things, that JavaScript/HTML5/canvas browser will in turn get a new scripting language that's even shittier than JavaScript is.
First: Where's your evidence that this is how the Web community does things? I honestly can't remember the last time I wrote a scripting language within a scripting language in anything at all related to web development.
Second: What, exactly, is shitty about JavaScript? Most people who think JavaScript is shitty don't understand it. It's actually a very nice language, albeit with a few ugly quirks.
Soon it'll be hyped even more than Ruby on Rails, AJAX and Cloud Computing were.
Nope, because as much as you'd like to believe otherwise, each of those things actually has something of value to contribute to the world. You may not like Rails, but it did remind everyone that MVC is a Good Idea, and new Web frameworks generally include at least that concept. AJAX allows applications to run in the browser -- again, like it or not, that's something which has value. Cloud computing, in either sense -- whether you're talking about web apps keeping your data, or utility computing -- again have something to contribute.
What does your hypothetical browser contribute? It does the exact same thing as everything we have, only slower and shittier. (And before you claim that this is how web apps work, how, exactly, could I safely run an application without installing it before now? Again, it actually has some positive points, whether or not they're things you want -- your idea has none.)
Managers around the world will force their developers to rewrite all of their web sites and web apps to target this new shitty scripting language and browser.
I don't know any managers who have suggested something so stupid with the current generation.
I don't disagree on any particular point, except maybe your use of "young".
However, asking for a specific number of years of experience is pure bullshit, and you can usually tell when they ask for ten years of experience with a technology which has existed for five years. What's important is not age or years, but experience.
- They must be able to host their repository meta-data on an SSL protected connection. - All packages must be digitally signed with a certificate that chains back to to a commonly-accepted CA.
Why do you need both? Why not just sign the repository meta-data the way you're signing the packages?
Among other things, this would mean it's easier to accelerate with proxies, cheaper, and less resource-intensive. About the only downside I can think of is the possibility of a MITM presenting an older version of the repository (which would still be signed), but they could just as easily block the SSL connection, so I'm not sure what that buys you.
Also (and I should probably ask this elsewhere), there are multiple open source package managers for Windows, though I don't know how good any of them are at this point. Why start from scratch -- what's the problem with any of these? (Cygwin is obviously not a great fit, but the rest?)
You do have a say when it comes to $BIGCORP by use of your wallet. You stop being their customer.
Since there are a huge number of places with only one ISP, and an even larger number of places where the only options are bad or worse, your choice is either to be the customer of an ISP you hate, or not use the Internet.
It seems likely that the latter may not be a possibility going forward, especially if America goes the way of Britain, where access to certain public services requires an Internet connection.
You don't have that choice when it comes to government.
Actually, you have the exact same choice. You can stop being the government's customer by simply moving. If you don't want to be the customer of any government, it's not terribly difficult to disappear, live off the grid, and stop enjoying the benefits of civilization -- but you also won't have to pay taxes.
I have yet to hear how government is supposed to be less biased and corrupt than corporations.
I'm not saying that government is absolutely better than the free market in all circumstances. I'm saying that the free market is not absolutely better than the government in all circumstances. In other words:
Governments are more corrupt.
It's moronic to argue either extreme. For example, governments can often be embarrassed into changing policy, and yes, the vote does work, though it's far less effective than it could be -- whereas corporations often have people right here on Slashdot defending their clearly immoral behavior using excuses like "They have a responsibility to their shareholders to make a profit."
Lobby groups and political parties would find ways to limit all kinds of traffic they didn't like.
The same way they do now with speech? Oh wait...
With a corporation, customer dissatisfaction prevents that abuse because the corporation must continue making money by keeping customers happy.
Unless there's a monopoly or an oligarchy, which is what we have with Internet service right now.
Customer dissatisfaction is not magical pixie dust, any more than government is. The fact that people like having castrated Internet better than having no Internet is not an example of the system working.
Market failure -- look it up. It should be in any decent Econ 101 course.
Internet service isn't a right. It's a privilege.
Again, look at europe -- it's likely to become a fundamental necessity, so I would certainly argue that it should be a right at that point.
Or wake up and open your eyes -- the Internet is the new soapbox, town square, cocktail party, and general medium of communication. When those other forms of expression, communication, and community are in jeopardy, we tend to agree they should be protected.
Suppose a corporation bought the town square, or a public park. Would you be OK with that? Do you really think that customer dissatisfaction would be sufficient in that case? (Hint: Once they pave over central park, no amount of customer dissatisfaction will bring back the trees.)
Unlike $BIGCORP, you can't replace us, but somehow, we're better to have than $BIGCORP.
Mostly because I actually have a say (however small) in $BIGGOV. I have no say whatsoever in $BIGCORP, other than, as you naively suggest, replacing them.
Yes, it is naive to assume there's a better option for an ISP, or even an option at all.
Actually, I can see how malloc would help, if you assume that they're always allocating small-ish amounts -- just keep a certain amount reserved, or don't free stuff instantly (in case it's about to be reallocated).
However, all of this seems very much like it could be done either inside libc (as proposed) or in the kernel, without having to touch existing apps, at least on platforms like Linux where libc is shared.
I'll be the first to agree with that. The problem is needless verbosity. For example:
Foo> x = new Foo>();
Even if you agree that templates are a good thing, why must I explicitly specify the type of x there?
also backwards compatibility is in a industrial/enterprise used language like Java a must.
Certainly, but at a certain point, I don't think it's worth it. There should've been an option to compile backwards-compatible bytecode (erasures), or non-backwards-compatible bytecode (proper generics).
If you want/need dynamic typing (for example for rapid development) just use Ruby, Python, JavaScript, etc. With JRuby/Jython you can it with Java easily.
That's more or less what I do, on my own time.
Java is in it's constrains a good, solid language.
The problem is what those constraints are actually good for -- why you would want to use Java instead of the alternatives. I could even make a case for using C++ over Java -- just as typesafe, you can add enough to be garbage-collected, but it at least has operator overloading.
More, with the JVM you can implement all your favorite languages and create easy to use binding between them and the Java API.
Which was my point overall -- I like the JVM, but there's a lot of room for improvement, and a lot of the oddities of the current JVM are related to Java, the language, which I hate with a burning passion.
Yes, it needs an update. No, it hasn't had one in a while. Many things should happen. Volunteers do what volunteers do.
Which is exactly why I'd prefer something which is either run by professionals, or by volunteers who at least keep documentation -- or pages which appear to be documentation -- up to date.
Wine, as just one example, had commercial support long before the release of Wine 1.0.
And even at 1.0, I wouldn't ever assume Wine worked -- I would test it thoroughly for each app. I would tend to recommend against Wine and towards Windows in a virtual machine, for stability reasons.
I'd believe that if there were any sort of consensus about what the word "strong" means in the context of typing.
Strict might be a better word. In this case, it refers to the fact that an object absolutely is a given type, and cannot be coerced into another type by the interpreter. For example, in Ruby, the only false values are nil and false, everything else is true -- you don't have Perl's weirdness where an empty string or a 0 integer value might also be false.
On the other hand, operators are implemented as methods, and it's entirely up to the method implementation how it reacts to a given object. Thus, in practice, you can pretend types don't exist when you know what you're doing, but it usually won't let you do things like add a number to a string.
I can't think of a specific example with the iPhone, but I can think of one on the Kindle -- it was 1984, actually. I see no compelling reason I should trust Apple more than I trust Amazon.
"Stability" and "maturity" mean different things to different people... You write that as if you believe that "production-ready" is a boolean quality.
It is boolean depending on the individual, yet we still generally seem to have a consensus about what the term means. For example, I doubt you would try to convince me that Rubinius is production-ready. The version number is another dead giveaway -- while sub-1.0 software can certainly be high quality, especially in the open source world, I feel much better with a stable, finished version that calls itself stable and finished when it's something as fundamental to what I'm doing as a language.
Another is that Ruby 1.9 is a much, much simpler language than Perl 6
In what way? I mean, I would consider that to be a good thing, but it certainly seems to be somewhat complex, at least syntactically.
Yet another is that the implementors have, at times, considered themselves free not to support core Ruby features.
Well, yes and no. For a very long time, "core Ruby features" meant "exactly what MRI does". It's only fairly recently that there's actually a standard to compare against. We still find some implementations deliberately not supporting features from that standard, or being able to optionally turn some off -- for example, I believe JRuby can turn off the ability to redefine arithmetic operators on numeric primitives (so you can't define 2+2 to be 5), which allows for significant optimizations.
However, the fact that Rails runs on JRuby is a good sign. Not because Rails is necessarily the best choice, but it is a fairly large, complex, and reflective bit of code, so it's a good stress test. I know of no such test I could perform on Rakudo to compare it to any other Perl6 implementations.
there's almost no type system in Ruby, for example
...what?
Yes there is. Ruby is, in fact, strongly typed. It's just also dynamically typed, which means you don't usually see it, but it does leak out occasionally.
Since it is UNusable by other processes, I fail to see the difference.
*facepalm*
mmap()ed memory is both usable by other processes in the sense that other processes can mmap the same file, and usable by other processes in the sense that it's not necessarily all in actual, physical RAM (and will never be in swap).
It's more or less the difference between "This program has opened a 1 gig file for reading and read a single byte" and "This program uses 1 gigs of RAM". Does that make it clearer?
Basically, this page has a large and scary list of stuff that's not done yet, but is in the basic language spec. It's also pretty clear they're nowhere near 1.0.
I admit, that's much farther along than any Perl6 was last I checked, but contrast to, say, JRuby, which is in version 1.4, has access to tons of Java libraries (Does Rakudo connect me to Perl5 libraries from CPAN?), and is, in general, actually production-ready.
Then buy an Android tablet. Oh wait you cannot since none of the promised/announced products are in stores yet,
That's fine, I'm patient. I remember the third generation of iPhones vs the first generation, so even if I was after an iPad, I'd wait.
Or I could buy a general-purpose Linux tablet, which have existed for years.
People complain that you cannot install what you want on the Apple devices, but for those of us who find anything we want to install on the app store, we can.
Good for you. Better pray to Jobs that Apple doesn't decide to spontaneously remove what you want, even delete it from your device. Yes, they can do that.
Jailbreaking the iPhone to install what you want in general seems to just be to pirate apps anyway...
Irrelevant, even if true. While I've seen a few interesting apps for jailbroken iPhones (like tethering, thus refuting your point), the reality is, why would anyone want to put a huge amount of effort into a jailbroken app, when that same app could be released legitimately for a platform that's not so developer-hostile?
As an example, Firefox had a Windows Mobile version, but the latest version of Windows Mobile has removed the ability to develop native apps, so Firefox will no longer be maintained for Windows Mobile.
The fact that you won't consider their merit as the web continues to evolve is not a reason to continue this discussion.
There's an important distinction between refusing to consider, and discarding after consideration. In fact, my first reaction on returning to web development was, why not use a virtual machine?
It was only after a lot of research, looking for the perfect language and virtual machine, that I realized that neither of those exist, and furthermore, I'm not convinced either of them can exist. Because of that, any VM we standardized on would be about as flawed as any language we standardize on.
I did acknowledge one possible advantage (or disadvantage) of a VM -- bytecode is less transparent than script, so proprietary web apps are feasible.
This isn't an attempt to continue the discussion, I just resent that, after all that, you're accusing me of not even considering your idea. I thought that's what we were doing.
JavaScript is already being compiled to byte-code, in many implementations
So is Perl5 and Ruby, and neither of those provide any sort of convenient ways of getting at that bytecode representation.
The idea that a fast VM that supports many different languages couldn't be used in the browser is just nonsense.
The question is, again, which one? The idea that a universal bytecode could be built which efficiently supports every language seems a bit far-fetched.
In fact, someone corrected me about the viability of cross-platform LLVM bytecode. Apparently, the bytecode itself isn't cross-platform.
And, there are many variegated types of languages that successfully target VMs -- whether JVM, the CLR, or otherwise.
And what tortured hacks do some of them have to perform to work well on one vs another? The JVM doesn't support tail-calls particularly well, but the CLR seems to have tons of stuff (at least in libraries, if nothing else) heavily tied to Windows, plus that sticky patent issue.
The question is whether you could actually do this:
any VM designed for use in the browser could be made to play nice with many languages by not requiring garbage collection, supporting tail calls, etc.
In other words, you're assuming that there could be a sufficiently fast, low-level, cross-platform, cross-language VM. I'm pointing out that as far as I can tell, no such beast exists, and I don't know enough to say that it could.
Also, it does preclude allowing the user to make a number of webpages faster simply by upgrading their browser, the lower level you get -- for example, if you wanted to try a newer, better garbage collector, you'd have to upgrade all websites, rather than just the browser.
There is also the issue, for better or worse, of source code being available for JavaScript.
that is a far from optimal approach.
I just don't see that the other approaches (including yours) are sufficiently better than this one to merit the enormous effort it would take to get it implemented.
GWT is just a compromise to overcome the shortfalls of JavaScript.
I disagree -- I think GWT is a perversion built by people who don't understand the strengths of JavaScript.
I don't need or even want to spend hours similar to what I spend tweaking my PC also tweaking a tablet appliance.
Not every totally open device requires that. See: Android, Maemo (or now MeeGo)...
I really can't get anyone who considers themselves a tech enthusiast being too close minded to try one for themselves.
I'll be open-minded when they have open development. Short of that, if someone hands me one, sure, I'll play with it, but there's no way I'm buying one.
It describes the intended use cases the language is optimized for, and specifically the size of the applications it's meant to produce.
HTML was never meant to be dynamically generated. This very forum, even if you remove JavaScript, is a hack well beyond the design of the language.
Lisp's syntax was never intended to be final, and there was always the plan that other, higher-level, more intuitive languages would be built on top of it. But Lisp hackers found they actually liked s-expressions, so they stayed. Many people argue now that they're a feature of the language.
C was originally conceived as a high-level, portable language.
How about we evaluate what it's actually good for, and not its intended purpose?
C++ can't do anything C couldn't, yet it's preferred nowadays,
Depends who you talk to. Just try getting C++ in the Linux kernel, for example -- you'll be laughed out of the room. Yet you couldn't say the Linux kernel is a small project, and it certainly makes use of things like data-hiding.
You can do OO in C.
I agree with your point, I just think you chose a lousy example.
enforce a certain amount of discipline, which in turn makes large multi-person projects feasible.
What, the enforcement, or the discipline?
In order for your patch to even be considered into Rails, you have to generate a unit test which proves both that your patch works, and that it's needed. Culture trumps compiler-enforced discipline every time.
Now, does that mean I think we should go back to C, where a lack of discipline could lead to buffer overruns? Of course not -- that's a case where the machine can do work for you, reducing both the amount of effort on your part and your chances of screwing up. Static typing, at best, makes it harder for you to screw up -- but it means more work throughout, and it introduces a whole new category of screwups.
You have a rather interesting definition of a good programmer: "he who produces code the fastest."
Would it help if I said "makes good programmers less productive"?
You think that forcing the programmer to decide what kind of data he'll store in a variable to be crippling?
That alone? No, that sounds innocuous enough.
No, I'm talking about the byzantine class hierarchies, interface declarations, and arcane generics (or templates) which are required to accomplish the simplest of tasks -- not to mention the lack of certain language features, like closures and easy reflection...
As an example, take the following hypothetical Java method:
public static void<T> sort(T[] list, Comparator<T> comp) {... }
This is incorrect. Can you spot what's wrong with it?
Compare to the equivalent in a duck-typed language like Ruby -- I don't have to care that the list of things I've received is even an array, I only care that it responds to []. I don't even need a Comparator, I can just accept a block of code (think function pointer) and call that. It, in turn, likely cares about some specific property of the objects I'm comparing, not that they're of a specific type.
And what if you write in a strict language and run as many tests as you would with the sloppy language? How many errors do you get then?
Then you get the error of having taken 3-10 times as long to get to market as your competitors.
Type checking is a subset of unit testing.
Perhaps you might explain the significance of this to me? Because either way, the end result is the good old "cast everything to (void *)" pattern of C/C++.
Maybe in Javascript, though I doubt it. Not, for example, in Ruby.
The idea is "duck typing" -- rather than declare types explicitly, we go with what we actually ca
There's really no reason that JavaScript should be the only language supported by browsers.
Nothing except inertia, which does matter.
Using a byte-code based VM would negate the need for browsers to support more than one language: anyone could create compilers that target that byte-code, and we could use whatever language we want.
Ah, but which one? No matter which one you choose, it's going to have issues. In fact, there are even advantages to a higher-level language to begin with -- while it's a lot harder to map any generic language onto JavaScript, it's a lot easier to swap out everything under the hood and optimize it.
So, doing it at a lower level (with bytecode), you get more languages that would work decently well, but less flexibility in how you optimize them.
Just look at any of the non-Java-like languages that target the JVM, and the incredible hoops they have to jump through.
That's why I'm actually not entirely opposed to one direction Google seems to be moving in -- sandboxed native code. That way, you could use any language you want, so long as it plays nice with the sandbox and supports the browser's API. The downside is that you're tied to a single CPU architecture (or anything that can quickly emulate it), which seems like a serious problem.
I don't really see a good solution here, and JavaScript seems like a reasonable trade-off.
I prefer internal DSLs (like JQuery) to external DSLs.
But that's not an example, that's still a general statement. Can you give an example where you actually want an external DSL in a web app which isn't already part of the stack somehow (like CSS)?
Slashdot Mirror
The next "big thing" will be some dipshit who writes an HTML rendering engine using nothing but JavaScript and HTML5 canvas.
Nope, canvas clearly isn't the right choice. If some dipshit were to seriously consider this, they'd use OpenGL.
Just because this is how the Web community does things, that JavaScript/HTML5/canvas browser will in turn get a new scripting language that's even shittier than JavaScript is.
First: Where's your evidence that this is how the Web community does things? I honestly can't remember the last time I wrote a scripting language within a scripting language in anything at all related to web development.
Second: What, exactly, is shitty about JavaScript? Most people who think JavaScript is shitty don't understand it. It's actually a very nice language, albeit with a few ugly quirks.
Soon it'll be hyped even more than Ruby on Rails, AJAX and Cloud Computing were.
Nope, because as much as you'd like to believe otherwise, each of those things actually has something of value to contribute to the world. You may not like Rails, but it did remind everyone that MVC is a Good Idea, and new Web frameworks generally include at least that concept. AJAX allows applications to run in the browser -- again, like it or not, that's something which has value. Cloud computing, in either sense -- whether you're talking about web apps keeping your data, or utility computing -- again have something to contribute.
What does your hypothetical browser contribute? It does the exact same thing as everything we have, only slower and shittier. (And before you claim that this is how web apps work, how, exactly, could I safely run an application without installing it before now? Again, it actually has some positive points, whether or not they're things you want -- your idea has none.)
Managers around the world will force their developers to rewrite all of their web sites and web apps to target this new shitty scripting language and browser.
I don't know any managers who have suggested something so stupid with the current generation.
I don't disagree on any particular point, except maybe your use of "young".
However, asking for a specific number of years of experience is pure bullshit, and you can usually tell when they ask for ten years of experience with a technology which has existed for five years. What's important is not age or years, but experience.
- They must be able to host their repository meta-data on an SSL protected connection.
- All packages must be digitally signed with a certificate that chains back to to a commonly-accepted CA.
Why do you need both? Why not just sign the repository meta-data the way you're signing the packages?
Among other things, this would mean it's easier to accelerate with proxies, cheaper, and less resource-intensive. About the only downside I can think of is the possibility of a MITM presenting an older version of the repository (which would still be signed), but they could just as easily block the SSL connection, so I'm not sure what that buys you.
Also (and I should probably ask this elsewhere), there are multiple open source package managers for Windows, though I don't know how good any of them are at this point. Why start from scratch -- what's the problem with any of these? (Cygwin is obviously not a great fit, but the rest?)
You do have a say when it comes to $BIGCORP by use of your wallet. You stop being their customer.
Since there are a huge number of places with only one ISP, and an even larger number of places where the only options are bad or worse, your choice is either to be the customer of an ISP you hate, or not use the Internet.
It seems likely that the latter may not be a possibility going forward, especially if America goes the way of Britain, where access to certain public services requires an Internet connection.
You don't have that choice when it comes to government.
Actually, you have the exact same choice. You can stop being the government's customer by simply moving. If you don't want to be the customer of any government, it's not terribly difficult to disappear, live off the grid, and stop enjoying the benefits of civilization -- but you also won't have to pay taxes.
I have yet to hear how government is supposed to be less biased and corrupt than corporations.
I'm not saying that government is absolutely better than the free market in all circumstances. I'm saying that the free market is not absolutely better than the government in all circumstances. In other words:
Governments are more corrupt.
It's moronic to argue either extreme. For example, governments can often be embarrassed into changing policy, and yes, the vote does work, though it's far less effective than it could be -- whereas corporations often have people right here on Slashdot defending their clearly immoral behavior using excuses like "They have a responsibility to their shareholders to make a profit."
Lobby groups and political parties would find ways to limit all kinds of traffic they didn't like.
The same way they do now with speech? Oh wait...
With a corporation, customer dissatisfaction prevents that abuse because the corporation must continue making money by keeping customers happy.
Unless there's a monopoly or an oligarchy, which is what we have with Internet service right now.
Customer dissatisfaction is not magical pixie dust, any more than government is. The fact that people like having castrated Internet better than having no Internet is not an example of the system working.
Market failure -- look it up. It should be in any decent Econ 101 course.
Internet service isn't a right. It's a privilege.
Again, look at europe -- it's likely to become a fundamental necessity, so I would certainly argue that it should be a right at that point.
Or wake up and open your eyes -- the Internet is the new soapbox, town square, cocktail party, and general medium of communication. When those other forms of expression, communication, and community are in jeopardy, we tend to agree they should be protected.
Suppose a corporation bought the town square, or a public park. Would you be OK with that? Do you really think that customer dissatisfaction would be sufficient in that case? (Hint: Once they pave over central park, no amount of customer dissatisfaction will bring back the trees.)
Unlike $BIGCORP, you can't replace us, but somehow, we're better to have than $BIGCORP.
Mostly because I actually have a say (however small) in $BIGGOV. I have no say whatsoever in $BIGCORP, other than, as you naively suggest, replacing them.
Yes, it is naive to assume there's a better option for an ISP, or even an option at all.
Actually, I can see how malloc would help, if you assume that they're always allocating small-ish amounts -- just keep a certain amount reserved, or don't free stuff instantly (in case it's about to be reallocated).
However, all of this seems very much like it could be done either inside libc (as proposed) or in the kernel, without having to touch existing apps, at least on platforms like Linux where libc is shared.
You don't want Java, you want a completely different language. So, why are you using Java in the first place?
Because of the advantages of the JVM (as I mentioned), and because the courses I'm taking require Java.
You want a magical language, which combines the advantages of at least Erlang, Ruby and C++.
Actually, just Erlang and Ruby would be nice. And there are attempts.
Btw, verbosity is sometimes a good thing,
I'll be the first to agree with that. The problem is needless verbosity. For example:
Foo> x = new Foo>();
Even if you agree that templates are a good thing, why must I explicitly specify the type of x there?
also backwards compatibility is in a industrial/enterprise used language like Java a must.
Certainly, but at a certain point, I don't think it's worth it. There should've been an option to compile backwards-compatible bytecode (erasures), or non-backwards-compatible bytecode (proper generics).
If you want/need dynamic typing (for example for rapid development) just use Ruby, Python, JavaScript, etc. With JRuby/Jython you can it with Java easily.
That's more or less what I do, on my own time.
Java is in it's constrains a good, solid language.
The problem is what those constraints are actually good for -- why you would want to use Java instead of the alternatives. I could even make a case for using C++ over Java -- just as typesafe, you can add enough to be garbage-collected, but it at least has operator overloading.
More, with the JVM you can implement all your favorite languages and create easy to use binding between them and the Java API.
Which was my point overall -- I like the JVM, but there's a lot of room for improvement, and a lot of the oddities of the current JVM are related to Java, the language, which I hate with a burning passion.
Yes, it needs an update. No, it hasn't had one in a while. Many things should happen. Volunteers do what volunteers do.
Which is exactly why I'd prefer something which is either run by professionals, or by volunteers who at least keep documentation -- or pages which appear to be documentation -- up to date.
Wine, as just one example, had commercial support long before the release of Wine 1.0.
And even at 1.0, I wouldn't ever assume Wine worked -- I would test it thoroughly for each app. I would tend to recommend against Wine and towards Windows in a virtual machine, for stability reasons.
I'd believe that if there were any sort of consensus about what the word "strong" means in the context of typing.
Strict might be a better word. In this case, it refers to the fact that an object absolutely is a given type, and cannot be coerced into another type by the interpreter. For example, in Ruby, the only false values are nil and false, everything else is true -- you don't have Perl's weirdness where an empty string or a 0 integer value might also be false.
On the other hand, operators are implemented as methods, and it's entirely up to the method implementation how it reacts to a given object. Thus, in practice, you can pretend types don't exist when you know what you're doing, but it usually won't let you do things like add a number to a string.
I'm not a smoker, but after a month of being cooped up with smokers,
So we're again back to the part where smarter people are less likely to be in that situation.
they might theoretically have this capability...
They do.
I've never seen it invoked.
I can't think of a specific example with the iPhone, but I can think of one on the Kindle -- it was 1984, actually. I see no compelling reason I should trust Apple more than I trust Amazon.
That list is a year out of date.
Out-of-date documentation is scary.
"Stability" and "maturity" mean different things to different people... You write that as if you believe that "production-ready" is a boolean quality.
It is boolean depending on the individual, yet we still generally seem to have a consensus about what the term means. For example, I doubt you would try to convince me that Rubinius is production-ready. The version number is another dead giveaway -- while sub-1.0 software can certainly be high quality, especially in the open source world, I feel much better with a stable, finished version that calls itself stable and finished when it's something as fundamental to what I'm doing as a language.
Another is that Ruby 1.9 is a much, much simpler language than Perl 6
In what way? I mean, I would consider that to be a good thing, but it certainly seems to be somewhat complex, at least syntactically.
Yet another is that the implementors have, at times, considered themselves free not to support core Ruby features.
Well, yes and no. For a very long time, "core Ruby features" meant "exactly what MRI does". It's only fairly recently that there's actually a standard to compare against. We still find some implementations deliberately not supporting features from that standard, or being able to optionally turn some off -- for example, I believe JRuby can turn off the ability to redefine arithmetic operators on numeric primitives (so you can't define 2+2 to be 5), which allows for significant optimizations.
However, the fact that Rails runs on JRuby is a good sign. Not because Rails is necessarily the best choice, but it is a fairly large, complex, and reflective bit of code, so it's a good stress test. I know of no such test I could perform on Rakudo to compare it to any other Perl6 implementations.
there's almost no type system in Ruby, for example
...what?
Yes there is. Ruby is, in fact, strongly typed. It's just also dynamically typed, which means you don't usually see it, but it does leak out occasionally.
To run optimally, the data has to be computed to a specific setting and then be stored locally for future use.
Erm, what?
Which data and what specific setting?
And there's nothing stopping you from storing precomputed values in HTML5's local storage.
Since it is UNusable by other processes, I fail to see the difference.
*facepalm*
mmap()ed memory is both usable by other processes in the sense that other processes can mmap the same file, and usable by other processes in the sense that it's not necessarily all in actual, physical RAM (and will never be in swap).
It's more or less the difference between "This program has opened a 1 gig file for reading and read a single byte" and "This program uses 1 gigs of RAM". Does that make it clearer?
I think it has something to do with resolution. The game is designed for any resolution,
Technically, so are flash games. In reality, they generally run in a fixed-size window, but those vector graphics are designed to scale.
lots of computation is needed to load a scene...
That's got nothing to do with what ultranova was talking about. Is there a bandwidth reason this wouldn't work?
Stability? Maturity?
Basically, this page has a large and scary list of stuff that's not done yet, but is in the basic language spec. It's also pretty clear they're nowhere near 1.0.
I admit, that's much farther along than any Perl6 was last I checked, but contrast to, say, JRuby, which is in version 1.4, has access to tons of Java libraries (Does Rakudo connect me to Perl5 libraries from CPAN?), and is, in general, actually production-ready.
Then buy an Android tablet. Oh wait you cannot since none of the promised/announced products are in stores yet,
That's fine, I'm patient. I remember the third generation of iPhones vs the first generation, so even if I was after an iPad, I'd wait.
Or I could buy a general-purpose Linux tablet, which have existed for years.
People complain that you cannot install what you want on the Apple devices, but for those of us who find anything we want to install on the app store, we can.
Good for you. Better pray to Jobs that Apple doesn't decide to spontaneously remove what you want, even delete it from your device. Yes, they can do that.
Jailbreaking the iPhone to install what you want in general seems to just be to pirate apps anyway...
Irrelevant, even if true. While I've seen a few interesting apps for jailbroken iPhones (like tethering, thus refuting your point), the reality is, why would anyone want to put a huge amount of effort into a jailbroken app, when that same app could be released legitimately for a platform that's not so developer-hostile?
As an example, Firefox had a Windows Mobile version, but the latest version of Windows Mobile has removed the ability to develop native apps, so Firefox will no longer be maintained for Windows Mobile.
The fact that you won't consider their merit as the web continues to evolve is not a reason to continue this discussion.
There's an important distinction between refusing to consider, and discarding after consideration. In fact, my first reaction on returning to web development was, why not use a virtual machine?
It was only after a lot of research, looking for the perfect language and virtual machine, that I realized that neither of those exist, and furthermore, I'm not convinced either of them can exist. Because of that, any VM we standardized on would be about as flawed as any language we standardize on.
I did acknowledge one possible advantage (or disadvantage) of a VM -- bytecode is less transparent than script, so proprietary web apps are feasible.
This isn't an attempt to continue the discussion, I just resent that, after all that, you're accusing me of not even considering your idea. I thought that's what we were doing.
JavaScript is already being compiled to byte-code, in many implementations
So is Perl5 and Ruby, and neither of those provide any sort of convenient ways of getting at that bytecode representation.
The idea that a fast VM that supports many different languages couldn't be used in the browser is just nonsense.
The question is, again, which one? The idea that a universal bytecode could be built which efficiently supports every language seems a bit far-fetched.
Take a look at LLVM or other similar projects.
I have.
In fact, someone corrected me about the viability of cross-platform LLVM bytecode. Apparently, the bytecode itself isn't cross-platform.
And, there are many variegated types of languages that successfully target VMs -- whether JVM, the CLR, or otherwise.
And what tortured hacks do some of them have to perform to work well on one vs another? The JVM doesn't support tail-calls particularly well, but the CLR seems to have tons of stuff (at least in libraries, if nothing else) heavily tied to Windows, plus that sticky patent issue.
The question is whether you could actually do this:
any VM designed for use in the browser could be made to play nice with many languages by not requiring garbage collection, supporting tail calls, etc.
In other words, you're assuming that there could be a sufficiently fast, low-level, cross-platform, cross-language VM. I'm pointing out that as far as I can tell, no such beast exists, and I don't know enough to say that it could.
Also, it does preclude allowing the user to make a number of webpages faster simply by upgrading their browser, the lower level you get -- for example, if you wanted to try a newer, better garbage collector, you'd have to upgrade all websites, rather than just the browser.
There is also the issue, for better or worse, of source code being available for JavaScript.
that is a far from optimal approach.
I just don't see that the other approaches (including yours) are sufficiently better than this one to merit the enormous effort it would take to get it implemented.
GWT is just a compromise to overcome the shortfalls of JavaScript.
I disagree -- I think GWT is a perversion built by people who don't understand the strengths of JavaScript.
I don't need or even want to spend hours similar to what I spend tweaking my PC also tweaking a tablet appliance.
Not every totally open device requires that. See: Android, Maemo (or now MeeGo)...
I really can't get anyone who considers themselves a tech enthusiast being too close minded to try one for themselves.
I'll be open-minded when they have open development. Short of that, if someone hands me one, sure, I'll play with it, but there's no way I'm buying one.
It's trivial to filter out Apple stories.
It describes the intended use cases the language is optimized for, and specifically the size of the applications it's meant to produce.
HTML was never meant to be dynamically generated. This very forum, even if you remove JavaScript, is a hack well beyond the design of the language.
Lisp's syntax was never intended to be final, and there was always the plan that other, higher-level, more intuitive languages would be built on top of it. But Lisp hackers found they actually liked s-expressions, so they stayed. Many people argue now that they're a feature of the language.
C was originally conceived as a high-level, portable language.
How about we evaluate what it's actually good for, and not its intended purpose?
C++ can't do anything C couldn't, yet it's preferred nowadays,
Depends who you talk to. Just try getting C++ in the Linux kernel, for example -- you'll be laughed out of the room. Yet you couldn't say the Linux kernel is a small project, and it certainly makes use of things like data-hiding.
You can do OO in C.
I agree with your point, I just think you chose a lousy example.
enforce a certain amount of discipline, which in turn makes large multi-person projects feasible.
What, the enforcement, or the discipline?
In order for your patch to even be considered into Rails, you have to generate a unit test which proves both that your patch works, and that it's needed. Culture trumps compiler-enforced discipline every time.
Now, does that mean I think we should go back to C, where a lack of discipline could lead to buffer overruns? Of course not -- that's a case where the machine can do work for you, reducing both the amount of effort on your part and your chances of screwing up. Static typing, at best, makes it harder for you to screw up -- but it means more work throughout, and it introduces a whole new category of screwups.
You have a rather interesting definition of a good programmer: "he who produces code the fastest."
Would it help if I said "makes good programmers less productive"?
You think that forcing the programmer to decide what kind of data he'll store in a variable to be crippling?
That alone? No, that sounds innocuous enough.
No, I'm talking about the byzantine class hierarchies, interface declarations, and arcane generics (or templates) which are required to accomplish the simplest of tasks -- not to mention the lack of certain language features, like closures and easy reflection...
As an example, take the following hypothetical Java method:
This is incorrect. Can you spot what's wrong with it?
Compare to the equivalent in a duck-typed language like Ruby -- I don't have to care that the list of things I've received is even an array, I only care that it responds to []. I don't even need a Comparator, I can just accept a block of code (think function pointer) and call that. It, in turn, likely cares about some specific property of the objects I'm comparing, not that they're of a specific type.
And what if you write in a strict language and run as many tests as you would with the sloppy language? How many errors do you get then?
Then you get the error of having taken 3-10 times as long to get to market as your competitors.
Type checking is a subset of unit testing.
Perhaps you might explain the significance of this to me? Because either way, the end result is the good old "cast everything to (void *)" pattern of C/C++.
Maybe in Javascript, though I doubt it. Not, for example, in Ruby.
The idea is "duck typing" -- rather than declare types explicitly, we go with what we actually ca
Whoever ported initially could port it again, I'd think.
...thus losing most of the advantages of using a newer engine, I'd think.
There's really no reason that JavaScript should be the only language supported by browsers.
Nothing except inertia, which does matter.
Using a byte-code based VM would negate the need for browsers to support more than one language: anyone could create compilers that target that byte-code, and we could use whatever language we want.
Ah, but which one? No matter which one you choose, it's going to have issues. In fact, there are even advantages to a higher-level language to begin with -- while it's a lot harder to map any generic language onto JavaScript, it's a lot easier to swap out everything under the hood and optimize it.
So, doing it at a lower level (with bytecode), you get more languages that would work decently well, but less flexibility in how you optimize them.
Just look at any of the non-Java-like languages that target the JVM, and the incredible hoops they have to jump through.
That's why I'm actually not entirely opposed to one direction Google seems to be moving in -- sandboxed native code. That way, you could use any language you want, so long as it plays nice with the sandbox and supports the browser's API. The downside is that you're tied to a single CPU architecture (or anything that can quickly emulate it), which seems like a serious problem.
I don't really see a good solution here, and JavaScript seems like a reasonable trade-off.
I prefer internal DSLs (like JQuery) to external DSLs.
But that's not an example, that's still a general statement. Can you give an example where you actually want an external DSL in a web app which isn't already part of the stack somehow (like CSS)?
So when will these actually be ready for general use?