I don't think Java could have made it as slow as it was. Is it better now?
Also: It's supposedly an open standard, and should be implementable in things other than Java. However, the implementation is complex enough that I'm glad to have at least one guaranteed-portable implementation.
How about open source flash? Or at least a Flash open standard?
Adobe seems to want Flash (and now AIR) to be the new way to develop web apps -- it almost looks like they want it to replace HTML/JavaScript. I have many problems with this, but the biggest one is that Flash is proprietary, and I don't want to go back to a proprietary Internet. I thought we got rid of that when IE stopped being the defacto standard...
That requirement of knowledge make for better engineers, IMHO.
I'd argue the only real reason it did is that it filtered out the people who couldn't grasp those concepts. I don't believe that knowledge is useful today, except applied in the same context -- filtering out people who have no skill.
If it is as efficient and is as predictable in implementation as C, but has additional features that help you write code, why not use it?
That's a LOT of assumptions in one sentence. Let me enumerate them:
If it is as efficient
and is as predictable in implementation
but has additional features that help you write code
features that help you write code are desirable (as opposed to features that help you write better code, or help you write more efficiently)
Or, alternately, the features C++ adds help you write better code, or help you write it more efficiently.
And why not to use it? Because the language is much more complex, has many hidden surprises, and the compiler is slower. If you are using mostly C-like structures anyway, I don't think it's worth it, especially when there are many people out there developing C. You'd be stuck between two communities -- those who use C, and those who use C++.
"C" isn't a proper subset of C++. The "class" construct makes all the difference. Using classes to represent logical hierarchies is very important to good software design.
Which has nothing to do with it being a subset or not.
Besides, while I'd agree object-oriented programming is important, you don't need C++ classes to do it, or even anything vaguely resembling C++ classes. The logical hierarchies you're talking about don't need to be rigidly applied as a language feature.
Where ruby is lacking is in the static department. Static polymorphism, static typechecks, metaprogramming and that stuff.
You can still use the === operator, or the kind_of? method. And I'm fairly certain metaprogramming is supported.
I've just found that static type checking is about all that's missing, and it isn't incredibly useful, especially when you're doing unit tests.
Just wish they had used unicode as the compiler language, then we could have gotten real less-than-or-equal operators:)
I'd assumed they did? After all, Ruby is from Japan...
It is nice that it really only uses ASCII for the language itself, though. I should add that to my list.
Indeed, but only dynamic. Not overloading, specialisation or anything like that.:(
I'm feeling a bit lost in this jargon... Can you give me some specific examples?
For big projects, code completion, class summaries and refactoring support is very nice.
When these are done for me, via things like Eclipse plugins, I don't worry too much about how complex they are under the hood, so long as they work.
Real constants and constant functions would be nice, though.
For what, though?
The existing constants are difficult enough to override without at least a warning, and I think that's really all you need. The same could be said of the private/protected methods -- there is a bit of a mess with the usage of 'send', but in a language which truly supports reflection and metaprogramming, private/protected is effectively only a warning anyway, as there's always a way around it.
Rather, I'm thinking of stuff like "you write a grammar, and the compiler+library builds the parser from that."
Ruby is at least as strong as C++, I'd think, due to how easy lambdas are. This seems to be about DSLs again, right?
The syntax for calling functions, and for passing them blocks, is simple and clean enough that it almost feels like defining your own language directives. Yet it's all still valid Ruby, which means it's usually readable by anyone who understands Ruby, and it's easy to mix and match.
This is a point very C++ is extremely strong, though far from perfect. In practice, it requires the compilation part of the language to be Turing complete.
In other words, LISP.
Duck typing does not require the typing to be implicit. I want the compilation to fail if and only if the type passed does not meet the required abilities.
I'd argue that the sanest way to do this is to just make the typing implicit.
C++ does this with templated methods.
Which still means that you have to put everything (somehow) into the type system, in order for the template to match, if I understand it. It also means that you have that extra template syntax in order to give you something that I think should be on by default.
Yes, but it relies on a virtual machine. I do not like that requirement, and I don't think it is strictly necessary.
Why don't you like that requirement?
It is merely that if I have a function that adds to numbers, I should be able to make a function that computes a number + 4.
In the simplest case, I suppose you can define such a function explicitly:
def add(a, b) a + b end def add_four(x) add(x, 4) end
But I suspect that's not what you want. I suspect you're talking about bind variables, which Ruby can do. (Even JavaScript can do those.)
Arrays also have a length, and are generally meant to be iterated over. Dictionaries have no natural ordering.
You could build an array on top of a dictionary, but it wouldn't be pretty.
Good garbage collection is almost never built on top of malloc/free.
Maybe I've got a wrong assumption that there is another way to return memory to the system?
I understand that good garbage collection will typically try to allocate/free large chunks at once. I assumed that still would eventually call malloc/free, at some point.
All you can think of is threads and locks, which only applies to shared memory and multicore systems.
I can also think of "networks of workstations" -- the problem is the situation where you do have a multicore system. Yes, you can program such a system with sockets, but that's going to be a bit of a performance hit serializing and unserializing all the time just to move between cores.
And I do think a proper abstraction should allow a parallel design to be built such that it should be portable to different kinds of parallel computing. Example: Some operations make sense written as if for SIMD, but may never have dedicated hardware, and should thus be able to (on a single machine, on a typical OS, with multiple cores) run in multiple threads, probably synchronized via locks.
You don't get parallel programming by making libraries thread safe.
However, having libraries which are not thread-safe is a problem when you do, in fact, need threads. Either the library can be thread-safe, or you can implement thread-safety on top of it -- but in the cases where you care, the library really should be thread-safe, for performance reasons.
In my experience, this works with women who have had all the children they want (or are past childbearing age).
Mine too, unfortunately. By accident, I seem to always have a fan club of women in their 40s -- since I was in my teens. It probably wasn't sexual (I hope not!), but certainly, being gentle, polite, intelligent, sincere, interested, tend to keep older women around.
I have no idea why that is.
Younger women seem to me to be more interested in loud, self-centered bullies than 'nice guys'.
The trick is, then, how to be loud and self-centered in such a way as to appear confident, and not a bully.
The way I've heard it described is "Cocky but Funny" -- the theory being that she can't ignore you if you're being a loud asshole, and she can't hate you if she's laughing. (This, by the way, should save you from having to buy the book "Double your Dating" -- that's basically the whole premise for the book, but it really doesn't need the space of an entire book.)
Of course, no formula will always work, and certainly not forever. But it would make an interesting experiment -- watch the assholes at work, and try to figure out exactly what it is about them that works.
Or, in other words, when you're hot, you're hot, and when you're not, you're not, and that's not entirely under your control.
You were modded funny, but an understanding of that -- especially an understanding that it's got nothing to do with things like affection, fairness, or conscious choice -- has got to be one of the most important things to know about a relationship, from either side.
However, speaking as a man, that "reset button" is still going to piss me off every time. Sorry:(
Nothing is perfect, no language, no computer, nothing.
True. Some, however, are hideously worse than others.
With the [java |.net] proponents focusing on ambiguities in C++ or (gasp) pointers.
Pointers are a powerful tool, in the very few cases where you actually need them. Otherwise, they're just a buffer overflow or segmentation fault waiting to happen. (And there are languages which can't have either.)
Practitioners found it both necessary and valuable to know and understand "how" their programs actually worked.
That is still useful, to some extent. However...
We needed to know how macros in the assembler worked.
Really? In what way is that valuable? I can see how it would be interesting, but I can't imagine how it would make my programs better in any measurable way.
C++ has its flaws, absolutely. However, if you use "C" constructs, it is as efficient and as readable as C.
And slower to compile, for no good reason. And still might have some syntactical surprises. If you use 'C' constructs, why not just write C?
The root cause of bad C++ is bad C++ programmers. It is not COBOL and it will not protect you from doing something stupid.
All programmers, good or not, do stupid things from time to time.
There was a study done once. I don't remember which languages were covered, but I do remember that some were very low-level, and some very high-level.
What they found is that the ratio of bugs to lines of code remained constant across all languages. Therefore, a higher-level language, which results in fewer lines of code to perform the same task, will likely result in a less buggy program -- not to mention a much more maintainable one.
Stop wanting everything to be "easier" to learn, some things become "easier" with learning.
Come back when you've done anything significant in LISP, or any language which supports closures.
Yes, especially in programming, it's better to focus on making things easier for an expert to use, rather than making the learning curve easier. Unfortunately, C++ is neither, and most experts will tell you to use a subset of the language. In today's world, the main place where C++ is invaluable is for code which must perform well, especially when you need enough of it that writing it all in assembly is out of the question. But as someone else posted, the proper subset of C++ to fill that role is C.
The problem with C++ is that this "purely structural thing" is so complex that no one person can hold it in their head. There are entirely too many surprises, bits of unnecessary complexity...
C has a performance-oriented level of interaction with the machine. It has some basic, primitive concepts, on top of which you can build an object-oriented program if you want, but you don't need C++ to do so. Just about any reason I can think of for using C++ is better served by some other language, and the performance/low-level considerations are best served by C, at least for now.
If you're working on a large enough program that you really need OOP baked into the language, there are other options than C++, most of them better. A favorite combination now seems to be a high-level, dynamic language like Ruby, Python, or Perl, with mechanisms to make it easy to extend in C.
Oh, and I kind of doubt Bjarne himself would've said that about MapReduce, given that MapReduce could be created in many other languages. For that matter, Google extensively uses Python. If C++ were good enough, why is Gmail written in Java? And so on...
I feel your pain -- I don't agree with everything you've listed, but it seems most languages provide maybe half.
Let me try what I know -- Ruby does this:
DSLs in Ruby are pretty reasonable. Operator overloading and syntactic sugar make it easy to do things like... well, look at Rake or Capistrano for examples.
Polymorphic by default.
Tricky -- Lambdas are just slightly awkward, but it has a "block" syntax which works well for the most common uses of lambdas -- that is, one lambda passed to one function. In fact, the inline lambda syntax is a specific example of block syntax.
I don't know what this means. (I've read the Wikipedia article, but I don't grok it enough to know at a glance.) Personally, I'd be willing to sacrifice compiler/tool simplicity for language readability.
All classes are open. Everything's an object. There's so much metaprogramming you can do that much advice is written about when not to apply it.
I'm not entirely sure how this differs from the above, but I'm going to say it's possible. It's possible to get a list of method names as strings, and possible to retrieve a method by its name. Not quite as much as LISP, I imagine.
Static typing, but implicit typing. The term is "duck typing." However, if you really want to, you can build your own static type checking.
Ruby seems to run pretty much everywhere C does, and I've developed on x86_64 Linux in parallel with people on 32-bit Windows or some flavor of OS X.
Performance sucks. It's getting better, but it still sucks. I keep looking for something with at least most of the features I like from Ruby, but with reasonable performance.
I'm going to say yes.
I'm not quite sure what this means, I'd need to see an example. I suspect it's a yes, or at least a "you can implement it yourself".
So, by my count, 7 yes, 2 maybe, 1 no, and 1 I don't know at all.
I probably have a slightly longer list, but I am constantly frustrated by just these three:
Reasonably powerful language, such that I can implement any missing features (including reasonable syntax) myself. (Also, bindings should be sane, but I'm operating under the assumption that most bindings I care about will already be written.)
Reasonable performance -- should be at least 80-90% of what I could expect from C/C++. I don't want to have to write C extensions purely for performance, except in very rare and isolated situations where I actually do need another 10%. And yes, I do think this is possible.
Platform independence, or at least support for platforms I care about. Lack of x86_64 support is a deal-breaker.
I can occasionally get two. Ruby is #1 and #3. Squeak/Smalltalk seems to be #1 and #2. Java/C# might be #2 and #3. I write Ruby because I'm currently writing web apps, and I can actually just throw more servers at the problem to make it go away.
But I keep finding new ideas that I wish I had elsewhere -- Erlang's parallelism, though it isn't much, still contains features I find missing from most languages. Haskell's lazy evaluation shouldn't require a purely functional language.
But if I could ever find a language which supported all three of those core ideas, I'd happily implement the rest on top of it.
That's how humans learn. But I still didn't notice a lot of repetition -- I saw a simple progression.
I had a friend go through some of their sessions, and I gave up talking to him about it (and, indeed, most other things) when it seemed like he was more interested in being a robot preaching the virtues of the sessions than a real human being.
Sounds bad, but it could have been worse. He could've been into Star Trek.
Sites that only work in IE are just about dead -- mostly replaced by sites that only work in IE/Firefox, or only in IE/Firefox/Safari. Opera is about fourth in the list, and Konquerer is pretty much nowhere. But these are understandable, and getting rarer, as by the time you have a site that works in IE/Firefox/Safari, you're hopefully reducing the number of browser-specific hacks you need, rather than increasing.
Silverlight is both more open (it looks like Moonlight might actually be good) and less relevant -- practically no sites require Silverlight.
Sites that would be more usable as a desktop app are also irrelevant, as they can still work in any browser. (I haven't seen any lately.) And ActiveX is pretty much dead.
Compare all that to Flash, which is the real problem here -- Flash is insidious. It's installed on some ungodly number of computers -- it's more popular than Windows is -- and it's on mobile devices. Yet it's completely controlled by one company, making it worse than IE ever was. And it provides things that there's really not any other standard, cross-platform way of doing.
Thus, for someone who only sees standards-compliance as a means to an end -- as a way of making your site more compatible for more people -- Flash seems like a sensible compromise. That is what makes it so dangerous.
I mean, not that it would happen, but Adobe could literally throw an auto-update switch and every Flash-based site would instantly break. Or they could selectively disable sites they don't like -- goodbye YouTube.
If we could replace Flash with something open, I honestly wouldn't mind about any of the rest, because we'd be back to 1% of the Internet that's incompatible with some browsers, instead of, say, 25% (conservative estimate).
Sites that only work in IE are just about dead -- mostly replaced by sites that only work in IE/Firefox, or only in IE/Firefox/Safari. Opera is about fourth in the list, and Konquerer is pretty much nowhere. But these are understandable, and getting rarer, as by the time you have a site that works in IE/Firefox/Safari, you're hopefully reducing the number of browser-specific hacks you need, rather than increasing.
Silverlight is both more open (it looks like Moonlight might actually be good) and less relevant -- practically no sites require Silverlight.
Sites that would be more usable as a desktop app are also irrelevant, as they can still work in any browser. (I haven't seen any lately.) And ActiveX is pretty much dead.
Compare all that to Flash, which is the real problem here -- Flash is insidious. It's installed on some ungodly number of computers -- it's more popular than Windows is -- and it's on mobile devices. Yet it's completely controlled by one company, making it worse than IE ever was. And it provides things that there's really not any other standard, cross-platform way of doing.
Thus, for someone who only sees standards-compliance as a means to an end -- as a way of making your site more compatible for more people -- Flash seems like a sensible compromise. That is what makes it so dangerous.
I mean, not that it would happen, but Adobe could literally throw an auto-update switch and every Flash-based site would instantly break. Or they could selectively disable sites they don't like -- goodbye YouTube.
If we could replace Flash with something open, I honestly wouldn't mind about any of the rest, because we'd be back to 1% of the Internet that's incompatible with some browsers, instead of, say, 25% (conservative estimate).
In addition, OS advocacy requires a lot more effort on the part of whoever will be using it. No matter how perfectly I install Ubuntu, or hand-pick OS X apps, there's still going to be some incompatibility or missing software, to the point where the smart thing would be to include both Wine and virtualization, which requires even more effort on the part of the user.
I do hope OS advocacy works, eventually. For now, it seems to be having an effect against Vista.
Hardware, on the other hand, is completely invisible to the consumer. Despite all the system-tray bullshit you install, most people won't even know the difference between brands of video cards, let alone soundcards. I could swap out a soundcard in most people's computers that I know, and they'd never know the difference.
Throw in the fact that Creative cards aren't usually included with the PC -- they're almost always an upgrade. That means that it was generally something like, my father complains that his computer sounds tinny on his speakers, and I tell him to get a new soundcard. I can directly influence Creative's sales here.
Java is one way. SVG+JavaScript is another, although that would be more of a vector program than a photo editing program. And this is Adobe, so it's not like I expected them to do it any other way.
It's not the idea of Flash that I object to, it's the implementation. If Adobe would at least release enough specs to finish Gnash -- or if they'd just give up and GPL the whole Flash player -- I'd have much less to complain about; it'd be about accessibility, then, and it's possible to engineer around that -- to make a site that's flash if you have it, and HTML if you're on lynx.
But as it is, I'm on 64-bit Linux, and I like Konqueror. Which means I have to go out of my way, and introduce at least two levels of indirection to hack to where I can even run the Flash plugin, and then I have to pray it works properly.
Next, the CPU in the iPhone is running at 412Mhz, so there is a lot less CPU than there is on your laptop or desktop. Less CPU means less idle time.
At four hundred and twelve million cycles per second, there's still going to be a lot of idle time if all it's doing is polling. Seriously, how many cycles does polling take? A couple thousand? That's still 99.8% idle. How far back does it throttle?
It's not just the CPU that the iPhone throttles back, it's the wifi connection as well. When the system goes idle, the wifi connection is turned off. I see it happening regularly. This means that if there is an open socket, there will be traffic on the connection and neither the wifi (nor the CPU) can be throttled back, regardless of polling.
In other words, close all your network connections -- no manual way to turn off the wifi? -- and that, too, seems odd, as I can be on the wireless with my CPU at 1 ghz.
Threads and locks are a useful low-level primitives on multicore and multi-CPU machines. Most of what one needs to build can be built on top of that. After all, programming languages still have arrays even though they also have dictionaries.
That's not entirely fair -- arrays are still useful on their own, and they can do things dictionaries can't. They are a different animal.
But in many higher-level languages, there is a difference between arrays and pointers, and "arrays" are the equivalent of C++ "vectors" in that they acquire and release memory as they grow and shrink. I see threading and locking as being equivalent to manual memory management.
Certainly, any garbage collection system is ultimately going to be built on top of malloc and free, at a low level. It's when I see malloc and free in an application, particularly one in which that level of manual performance tweaking isn't required, that I worry.
The problem with people like you seems to be education: you don't know what's out there and what has been done. In fact, even your view of parallel programming is depressingly narrow.
Where's my view narrow?
And I do have a fair idea of what's out there. I don't see the better techniques I know of incorporated into the languages and tools that I might want to use in the real world. And I see entirely too many real-world libraries being thread-unsafe.
You may think the Sci-Fi channel has low standards -- and in some cases, you'd be right. But honestly, pretty much any Stargate episode is going to be better than the Xenu story.
It's not just that their religion is science-fiction -- it's that it's horribly bad, drug-induced science-fiction. L. Ron Hubbard couldn't sell his books normally, so he made them into a religion.
Slashdot Mirror
I don't think Java could have made it as slow as it was. Is it better now?
Also: It's supposedly an open standard, and should be implementable in things other than Java. However, the implementation is complex enough that I'm glad to have at least one guaranteed-portable implementation.
This is exactly what was always said about Freenet -- leave your node connected for awhile, large files work well, change your browser settings, etc.
And I did this, and it worked, somewhat. It was just staggeringly unusable, most of the time.
Been awhile since I read it, so I honestly don't remember the misogynistic parts -- or maybe I was too young.
I do remember a few very simple, insightful things that do work, but they don't need to fill a book.
Besides, it's high time we had The Rules for guys.
And to every architecture, and to pretty much anything we want. That's why open standards exist -- or rather, why standards should be open.
It's also a great technology if I have a web application that, for some reason or other, people are convinced they want as a desktop app.
And it does pick up the system's native UI widgets, I think -- at least it does for its embedded WebKit.
How about open source flash? Or at least a Flash open standard?
Adobe seems to want Flash (and now AIR) to be the new way to develop web apps -- it almost looks like they want it to replace HTML/JavaScript. I have many problems with this, but the biggest one is that Flash is proprietary, and I don't want to go back to a proprietary Internet. I thought we got rid of that when IE stopped being the defacto standard...
I'd argue the only real reason it did is that it filtered out the people who couldn't grasp those concepts. I don't believe that knowledge is useful today, except applied in the same context -- filtering out people who have no skill.
That's a LOT of assumptions in one sentence. Let me enumerate them:
And why not to use it? Because the language is much more complex, has many hidden surprises, and the compiler is slower. If you are using mostly C-like structures anyway, I don't think it's worth it, especially when there are many people out there developing C. You'd be stuck between two communities -- those who use C, and those who use C++.
Which has nothing to do with it being a subset or not.
Besides, while I'd agree object-oriented programming is important, you don't need C++ classes to do it, or even anything vaguely resembling C++ classes. The logical hierarchies you're talking about don't need to be rigidly applied as a language feature.
You can still use the === operator, or the kind_of? method. And I'm fairly certain metaprogramming is supported.
I've just found that static type checking is about all that's missing, and it isn't incredibly useful, especially when you're doing unit tests.
I'd assumed they did? After all, Ruby is from Japan...
It is nice that it really only uses ASCII for the language itself, though. I should add that to my list.
I'm feeling a bit lost in this jargon... Can you give me some specific examples?
When these are done for me, via things like Eclipse plugins, I don't worry too much about how complex they are under the hood, so long as they work.
For what, though?
The existing constants are difficult enough to override without at least a warning, and I think that's really all you need. The same could be said of the private/protected methods -- there is a bit of a mess with the usage of 'send', but in a language which truly supports reflection and metaprogramming, private/protected is effectively only a warning anyway, as there's always a way around it.
Ruby is at least as strong as C++, I'd think, due to how easy lambdas are. This seems to be about DSLs again, right?
The syntax for calling functions, and for passing them blocks, is simple and clean enough that it almost feels like defining your own language directives. Yet it's all still valid Ruby, which means it's usually readable by anyone who understands Ruby, and it's easy to mix and match.
In other words, LISP.
I'd argue that the sanest way to do this is to just make the typing implicit.
Which still means that you have to put everything (somehow) into the type system, in order for the template to match, if I understand it. It also means that you have that extra template syntax in order to give you something that I think should be on by default.
Why don't you like that requirement?
In the simplest case, I suppose you can define such a function explicitly:
But I suspect that's not what you want. I suspect you're talking about bind variables, which Ruby can do. (Even JavaScript can do those.)
That is, you want something like:
And this can be
Arrays also have a length, and are generally meant to be iterated over. Dictionaries have no natural ordering.
You could build an array on top of a dictionary, but it wouldn't be pretty.
Maybe I've got a wrong assumption that there is another way to return memory to the system?
I understand that good garbage collection will typically try to allocate/free large chunks at once. I assumed that still would eventually call malloc/free, at some point.
I can also think of "networks of workstations" -- the problem is the situation where you do have a multicore system. Yes, you can program such a system with sockets, but that's going to be a bit of a performance hit serializing and unserializing all the time just to move between cores.
And I do think a proper abstraction should allow a parallel design to be built such that it should be portable to different kinds of parallel computing. Example: Some operations make sense written as if for SIMD, but may never have dedicated hardware, and should thus be able to (on a single machine, on a typical OS, with multiple cores) run in multiple threads, probably synchronized via locks.
However, having libraries which are not thread-safe is a problem when you do, in fact, need threads. Either the library can be thread-safe, or you can implement thread-safety on top of it -- but in the cases where you care, the library really should be thread-safe, for performance reasons.
Mine too, unfortunately. By accident, I seem to always have a fan club of women in their 40s -- since I was in my teens. It probably wasn't sexual (I hope not!), but certainly, being gentle, polite, intelligent, sincere, interested, tend to keep older women around.
I have no idea why that is.
The trick is, then, how to be loud and self-centered in such a way as to appear confident, and not a bully.
The way I've heard it described is "Cocky but Funny" -- the theory being that she can't ignore you if you're being a loud asshole, and she can't hate you if she's laughing. (This, by the way, should save you from having to buy the book "Double your Dating" -- that's basically the whole premise for the book, but it really doesn't need the space of an entire book.)
Of course, no formula will always work, and certainly not forever. But it would make an interesting experiment -- watch the assholes at work, and try to figure out exactly what it is about them that works.
Or, in other words, when you're hot, you're hot, and when you're not, you're not, and that's not entirely under your control.
:(
You were modded funny, but an understanding of that -- especially an understanding that it's got nothing to do with things like affection, fairness, or conscious choice -- has got to be one of the most important things to know about a relationship, from either side.
However, speaking as a man, that "reset button" is still going to piss me off every time. Sorry
True. Some, however, are hideously worse than others.
Pointers are a powerful tool, in the very few cases where you actually need them. Otherwise, they're just a buffer overflow or segmentation fault waiting to happen. (And there are languages which can't have either.)
That is still useful, to some extent. However...
Really? In what way is that valuable? I can see how it would be interesting, but I can't imagine how it would make my programs better in any measurable way.
And slower to compile, for no good reason. And still might have some syntactical surprises. If you use 'C' constructs, why not just write C?
All programmers, good or not, do stupid things from time to time.
There was a study done once. I don't remember which languages were covered, but I do remember that some were very low-level, and some very high-level.
What they found is that the ratio of bugs to lines of code remained constant across all languages. Therefore, a higher-level language, which results in fewer lines of code to perform the same task, will likely result in a less buggy program -- not to mention a much more maintainable one.
Come back when you've done anything significant in LISP, or any language which supports closures.
Yes, especially in programming, it's better to focus on making things easier for an expert to use, rather than making the learning curve easier. Unfortunately, C++ is neither, and most experts will tell you to use a subset of the language. In today's world, the main place where C++ is invaluable is for code which must perform well, especially when you need enough of it that writing it all in assembly is out of the question. But as someone else posted, the proper subset of C++ to fill that role is C.
The problem with C++ is that this "purely structural thing" is so complex that no one person can hold it in their head. There are entirely too many surprises, bits of unnecessary complexity...
C has a performance-oriented level of interaction with the machine. It has some basic, primitive concepts, on top of which you can build an object-oriented program if you want, but you don't need C++ to do so. Just about any reason I can think of for using C++ is better served by some other language, and the performance/low-level considerations are best served by C, at least for now.
If you're working on a large enough program that you really need OOP baked into the language, there are other options than C++, most of them better. A favorite combination now seems to be a high-level, dynamic language like Ruby, Python, or Perl, with mechanisms to make it easy to extend in C.
We've seen this before.
Oh, and I kind of doubt Bjarne himself would've said that about MapReduce, given that MapReduce could be created in many other languages. For that matter, Google extensively uses Python. If C++ were good enough, why is Gmail written in Java? And so on...
I feel your pain -- I don't agree with everything you've listed, but it seems most languages provide maybe half.
Let me try what I know -- Ruby does this:
So, by my count, 7 yes, 2 maybe, 1 no, and 1 I don't know at all.
I probably have a slightly longer list, but I am constantly frustrated by just these three:
I can occasionally get two. Ruby is #1 and #3. Squeak/Smalltalk seems to be #1 and #2. Java/C# might be #2 and #3. I write Ruby because I'm currently writing web apps, and I can actually just throw more servers at the problem to make it go away.
But I keep finding new ideas that I wish I had elsewhere -- Erlang's parallelism, though it isn't much, still contains features I find missing from most languages. Haskell's lazy evaluation shouldn't require a purely functional language.
But if I could ever find a language which supported all three of those core ideas, I'd happily implement the rest on top of it.
Looks good, thanks...
Still looking for a Xenu movie. I mean, the South Park episode was hilarious enough...
That's how humans learn. But I still didn't notice a lot of repetition -- I saw a simple progression.
Sounds bad, but it could have been worse. He could've been into Star Trek.
Damnit! Reposting...
Sites that only work in IE are just about dead -- mostly replaced by sites that only work in IE/Firefox, or only in IE/Firefox/Safari. Opera is about fourth in the list, and Konquerer is pretty much nowhere. But these are understandable, and getting rarer, as by the time you have a site that works in IE/Firefox/Safari, you're hopefully reducing the number of browser-specific hacks you need, rather than increasing.
Silverlight is both more open (it looks like Moonlight might actually be good) and less relevant -- practically no sites require Silverlight.
Sites that would be more usable as a desktop app are also irrelevant, as they can still work in any browser. (I haven't seen any lately.) And ActiveX is pretty much dead.
Compare all that to Flash, which is the real problem here -- Flash is insidious. It's installed on some ungodly number of computers -- it's more popular than Windows is -- and it's on mobile devices. Yet it's completely controlled by one company, making it worse than IE ever was. And it provides things that there's really not any other standard, cross-platform way of doing.
Thus, for someone who only sees standards-compliance as a means to an end -- as a way of making your site more compatible for more people -- Flash seems like a sensible compromise. That is what makes it so dangerous.
I mean, not that it would happen, but Adobe could literally throw an auto-update switch and every Flash-based site would instantly break. Or they could selectively disable sites they don't like -- goodbye YouTube.
If we could replace Flash with something open, I honestly wouldn't mind about any of the rest, because we'd be back to 1% of the Internet that's incompatible with some browsers, instead of, say, 25% (conservative estimate).
Sites that only work in IE are just about dead -- mostly replaced by sites that only work in IE/Firefox, or only in IE/Firefox/Safari. Opera is about fourth in the list, and Konquerer is pretty much nowhere. But these are understandable, and getting rarer, as by the time you have a site that works in IE/Firefox/Safari, you're hopefully reducing the number of browser-specific hacks you need, rather than increasing. Silverlight is both more open (it looks like Moonlight might actually be good) and less relevant -- practically no sites require Silverlight. Sites that would be more usable as a desktop app are also irrelevant, as they can still work in any browser. (I haven't seen any lately.) And ActiveX is pretty much dead. Compare all that to Flash, which is the real problem here -- Flash is insidious. It's installed on some ungodly number of computers -- it's more popular than Windows is -- and it's on mobile devices. Yet it's completely controlled by one company, making it worse than IE ever was. And it provides things that there's really not any other standard, cross-platform way of doing. Thus, for someone who only sees standards-compliance as a means to an end -- as a way of making your site more compatible for more people -- Flash seems like a sensible compromise. That is what makes it so dangerous. I mean, not that it would happen, but Adobe could literally throw an auto-update switch and every Flash-based site would instantly break. Or they could selectively disable sites they don't like -- goodbye YouTube. If we could replace Flash with something open, I honestly wouldn't mind about any of the rest, because we'd be back to 1% of the Internet that's incompatible with some browsers, instead of, say, 25% (conservative estimate).
In addition, OS advocacy requires a lot more effort on the part of whoever will be using it. No matter how perfectly I install Ubuntu, or hand-pick OS X apps, there's still going to be some incompatibility or missing software, to the point where the smart thing would be to include both Wine and virtualization, which requires even more effort on the part of the user.
I do hope OS advocacy works, eventually. For now, it seems to be having an effect against Vista.
Hardware, on the other hand, is completely invisible to the consumer. Despite all the system-tray bullshit you install, most people won't even know the difference between brands of video cards, let alone soundcards. I could swap out a soundcard in most people's computers that I know, and they'd never know the difference.
Throw in the fact that Creative cards aren't usually included with the PC -- they're almost always an upgrade. That means that it was generally something like, my father complains that his computer sounds tinny on his speakers, and I tell him to get a new soundcard. I can directly influence Creative's sales here.
Java is one way. SVG+JavaScript is another, although that would be more of a vector program than a photo editing program. And this is Adobe, so it's not like I expected them to do it any other way.
It's not the idea of Flash that I object to, it's the implementation. If Adobe would at least release enough specs to finish Gnash -- or if they'd just give up and GPL the whole Flash player -- I'd have much less to complain about; it'd be about accessibility, then, and it's possible to engineer around that -- to make a site that's flash if you have it, and HTML if you're on lynx.
But as it is, I'm on 64-bit Linux, and I like Konqueror. Which means I have to go out of my way, and introduce at least two levels of indirection to hack to where I can even run the Flash plugin, and then I have to pray it works properly.
At four hundred and twelve million cycles per second, there's still going to be a lot of idle time if all it's doing is polling. Seriously, how many cycles does polling take? A couple thousand? That's still 99.8% idle. How far back does it throttle?
In other words, close all your network connections -- no manual way to turn off the wifi? -- and that, too, seems odd, as I can be on the wireless with my CPU at 1 ghz.
That's not entirely fair -- arrays are still useful on their own, and they can do things dictionaries can't. They are a different animal.
But in many higher-level languages, there is a difference between arrays and pointers, and "arrays" are the equivalent of C++ "vectors" in that they acquire and release memory as they grow and shrink. I see threading and locking as being equivalent to manual memory management.
Certainly, any garbage collection system is ultimately going to be built on top of malloc and free, at a low level. It's when I see malloc and free in an application, particularly one in which that level of manual performance tweaking isn't required, that I worry.
Where's my view narrow?
And I do have a fair idea of what's out there. I don't see the better techniques I know of incorporated into the languages and tools that I might want to use in the real world. And I see entirely too many real-world libraries being thread-unsafe.
That seemed to be more inspired by Scientology than a direct translation of Scientology. It's based on another Hubbard book (just as bad).
I'd still like to see a movie made about the real Scientology story. Trust me, it'd give us much more to laugh at.
Not really.
You may think the Sci-Fi channel has low standards -- and in some cases, you'd be right. But honestly, pretty much any Stargate episode is going to be better than the Xenu story.
It's not just that their religion is science-fiction -- it's that it's horribly bad, drug-induced science-fiction. L. Ron Hubbard couldn't sell his books normally, so he made them into a religion.