The primary reason its okay for python to be slow, but not for java, is that python isn't a crippled version of C++ that runs at 1/10 the speed, whereas java is.
Now you are being unfair. Java code runs often runs at almost half the speed of C++, and have a few features (such as better enums, reflection, simpler parse) which C++ doesn't.
If you use the server VM, the java VM can actually inline code. Amazing!
"You are trying to support that Wikipedia is unreliable..."
No what I am saying is that you should NEVER directly cite a Wikipedia article in an academic paper,
Really? Despite reading your post again, I didn't get that impression. Sorry about that. Anyway, in my experience, most academic papers are frankly not worth the paper they are printed on. Of course, the ones that are good are sometimes very, very good and makes it all worthwhile. But then, I only use academic papers, I don't produce any.
But that doesnt mean that I think Wikipedia is useless; far from it in fact. It's great for Background information, Links, Keywords and References. It's a great tool to help focus research and get a little context and background information. Kind of like an encyclopedia, but where the information can change quickly and sometimes inaccurately (at least until corrected by the admins).
Indeed. Wikipedia is sometimes inaccurate on a given day, encycleopedias are sometimes inaccurate on a given subject.
But don't listen to me... listen to Wikipedia itself: I don't get where you are going with this, sorry:)
Now, that article is pretty funny. Take e.g. the first paragraph:
The website (pronounced wikee/pee/dee/er) is one of the world's great co-operative ventures, an online encyclopedia compiled by thousands of global users - or is it just another unreliable website full of mistakes, misconceptions and misleading entries?
Indeed. Actually, it is over 100 of thousands global users... 158458 as of January, to be exact. Will the independent continue to be just another unreliable website full of mistakes, misconceptions and misleading entries?
If you manage to get past the first drivel, it's not bad. The overall conclusion seems be that wikipedia is quite accurate, though at times rather obviously slanted for biographies. (My favorite quote was the one about Tony Blair entering GB into many armed conflicts despite being a devout Christian. As if religious people are not infamously violent.
You are trying to support that Wikipedia is unreliable by quoting a newspaper (which as usual gets just about every fact wrong), a blogger (proof that journalists are not the worst people at getting facts right) and finally the freaking register, which hates Wikipedia so much that the foaming around the mouth was visible from the international space station earlier this month.
Nope. Imagine this scenario: I'm a teacher, and I ask for an assignment about, let's say, Abraham Lincoln. Then I go to Wikipedia's entry on him and edit it, subtlely. How will students know that AL date of birth is wrong ? They can tell unless they use another source.
Go ahead and try. It will be fixed within 24 hours, for such a prominent article --- there will be too many who have that article on their "watch list". Wikipedia's problem is the obscure subjects without many or any watchers.
And of course, by design, wikipedia is vulnerable to urban myths, though the discussion pages tends to weed those out over time.
But I admit wikipedia is hard to predict. E.g, I am amazed at the amount of mathematical knowledge that is accessible there. Like the other day, when I couldn't find a textbook and I was wondering which properties the dual of a LP system had away from optimality. Took a bit of searching, but I ended up finding it on wikipedia through google.
It was funny to me that the movie would suggest that an MIT senior taking advanced math classes had never heard the Monte Hall problem before, let alone that the whole room full of students had never heard the problem before. When I heard it in my 7th grade math class, I already knew it, and I never went out of my way to find problems like that.
Moreover, and I might be a mathematician but certainly not a genius, had no trouble finding the correct answer in my heads in a few seconds when I was presented with the problem in my late teens. It's not exactly a hard problem:)
No VM is needed for that. Any decent implementation of eval will check the input string against a cache. Branch prediction is another example of what you are talking of, and again, no VM is required.
And also garbage collection, and other things.
Garbage collection is on the verge of being included in C++. So it must be possible to do without a VM. (Personally, I think garbage collection is only good for covering up bad design, but let's do that another time --- but anyway, that's my excuse for only knowing the big picture as garbage collection goes. )
I suppose the proper word is "runtime", because I do believe there are optimizations which can only be done effectively at runtime.
So you claim:) I disagree, though. Or at least, it seems to me that the penalty for those optimizations outweights the benefits. Also, for security reasons, I prefer the executable part of an application to be in a non-writable segment.
Anything specific?
Probably the biggest thing that bothers me right now is the fact that any sufficiently complex file is going to end like this:
end
end
end
end
end
That's something I can get around with a preprocessor, though, and people have -- basically, to make Ruby behave like Python. But that's a minor irritation anyway -- I type fast, and it has the advantage of having most editors understand C-like syntax (and be able to jump from start to end tags and back).
Hm. I would prefer having endmethod, endclass and so on, but otherwise I'm find with something like this. Python style blocks I never liked.
There's also the lambda/block syntax -- it's very good for when you only need to pass a single block, but I do wish it was easier to pass a pair or more.
I always assumed I just didn't get how to do this simply:o)
And there's the fact that unlike JavaScript, methods are very much stuck to a class. It's something a lot of people seem to hate about it, but I loved -- I can rip a function out of anywhere, any class, any object, and apply it to something completely different. I can assemble a class not only from modules explicitly specified as such, or from direct inheritance from multiple other classes, but from, well, anywhere I want. I can completely make up my own class system.
Most of that is available through things like Object.extend in Ruby, but that's not as easy to build classes with, and is complicated by the difference between "extend" and "include".
I would imagine it would also make your code hard to read or understand.
I suspect that the main things I prefer about Javascript (instead of Ruby) is that Javascript is prototype-based, whereas Ruby is traditional class inheritance with mixins. It seems to me that a prototype system is a simpler set of primitives than a class system, even if it might be possible to build one from the other.
That is an old battle. On the balance, I prefer the class system, again because I find it easier to express my intent clearly. Not a huge deal for me either way, though.
I agree -- to a point. At some point, the code is either too trivial to test or requires too much scaffolding to test.
I find that I mostly get into the latter situation out of my own lack of discipline. But at the same time, there's a lot of scaffolding out there -- there are browser-based unit tests for webapps.
Webapps are easy for many reasons. Make sure that a method that is supposed to tighten a linear constraint in a linear system is worse. Sure, you can make a test for the simple cases, but most of the code is about stuff like numerical instability. Scaffolding stuff lik
I'd say that gathering statistics of what's actually being done is probably a strong enough indicator of future calls. Consider the following:
source = 'some really long string of source code, possibly generated'
eval source
Will the code be compiled every time? I'd argue that a reasonably intelligent VM might notice that the source string isn't changing, and cache the result of that call. And if it's a sufficiently long string, it absolutely would be a net win in efficiency, even including VM overhead.
No VM is needed for that. Any decent implementation of eval will check the input string against a cache. Branch prediction is another example of what you are talking of, and again, no VM is required. I can see where VMs theoretically can give a small boost to performance in some cases, but so far I've not seen a VM that performs better than 50% of bare iron.
The compiler cannot assume a sane design:)
No, but it should optimize for a sane design, right?
Of course, but that doesn't help it if it trying to detect errors at the compile time. You cannot have false positives here.
Many people would say they don't need unit test everywhere:p I do get that you don't want to specify types, and that is fine by me. It still means that ruby is not the perfect language for me.
There are other reasons why I don't consider it the perfect language. Even syntactical reasons.
Anything specific?
And I think I could make a strong argument for unit tests everywhere -- again, I see a type check as just another form of unit test. But tests in general make it that much easier to make larger changes -- because after making the change, you can just run the test to see if it worked.
I agree -- to a point. At some point, the code is either too trivial to test or requires too much scaffolding to test.
There's even test-driven design, but that takes discipline.
I know, I use it extensively for writing parsers and such. It's excellent when you have some good testcases up front. Unfortunately, in my line of work, we often have to make up the test data as we go along, and anyway, the problem we set out to solve is seldom the problem that turns out to be solvable.
Besides, it allows you to specify intent in a very clear way --- the ! sometimes means constant, but sometimes it is more like "watch out, dangerous function".
Well, it actually means "non-constant", but yes,
Woops, you are correct, of course.
I've seen it abused that way.
To be fair, const can be misused with a bit of effort as well. But the thing is, people usually agree on what const means, while ! means sort of dangerous to some, destructive to others and apparently constant to a third group. Besides, string concatenation is no way to store information:/
Example: Calling foo.save! in Rails will throw exceptions on validation errors, but what is the point of foo.save, which simply returns true or false depending on whether it was successful? If I just want to see if the object is valid, I can call.valid?
Totally agree. Silly design, really. Not really the language's fault, though.
I do get what you mean now about expressing intent, and why that's important -- and I think that's what a high-level language is about. I'm also considering subverting it into an argument against explicit typing -- I don't intend for something to be any given type, I only intend for it to be able to do a certain thing.
I worry that you have misunderstood me. It's the compiletime checki
it is in general not possible for a compiler to see what parameters a function will be called with, as the function could be called with the result of an arbitrary function
It is, however, possible for a VM to watch what parameters a function is actually called with. I'm afraid I've fallen into the habit of calling any tool a "compiler", occasionally.
Ok, sorry for the confusion. It is, however, not possible for a VM to predict future calls either, and anyway, the VM would then have to waste clockcycles during every run, instead of having it calculated once and for all.
That is one example. I haven't had enough sleep for a proper reply, so I am not sure if I can find a good code example, but I'm going to suggest that you can have things like this occur in an explicitly-typed language. Templates and anywhere you typecast are places you could have potentially interesting interactions.
You can't. That's the point about type-safety, it's a strong garantee. The code might fail, but it will be during compiletime. Barring bugs in the compiler or language, of course:)
More importantly, you have to wonder at the wisdom of myfunc returning these incompatible types in the first place -- what is so complex about myfunc that it can't return something predictable? Is this something which could be helped by simplifying the design?
The compiler cannot assume a sane design:) Besides, it's a complex world, and sometimes you will need a complex design to solve the issue at hand. You yourself mention using evals at times, something which might return *anything*.
Like looking up in a hash table, but accidentially using a converted form (say, to string) of the key instead of the intended key.
I honestly cannot ever remember doing that. Not once.
Of all the problems I have debugged in Java, that and comparing strings with == is the most common in both my code and in other peoples code. If you have not seen it yet, count yourself lucky, it can be very hard to spot:)
Well, I find explicit typing to be that much more clutter. I don't need pre and postcondition checks everywhere.
Many people would say they don't need unit test everywhere:p I do get that you don't want to specify types, and that is fine by me. It still means that ruby is not the perfect language for me.
There is a keyword for handling that case. mutable, if you want to check up on it.
I'll have to let that digest for a bit. My initial reaction is that this is still less flexible -- I realize that's on purpose, of course.
I have used it for years, and I'm pretty sure you can do anything you want with it, while still preventing lots of errors. Besides, it allows you to specify intent in a very clear way --- the ! sometimes means constant, but sometimes it is more like "watch out, dangerous function".
But one thing I love about accessors in the first place is the ability to shift the implementation around underneath of whatever's using it. I'm not sure mutable covers everything I might want to do with a former accessor.
It covers all instances of accessors I have ever seen. It does not cover everything people write as accessors, but is really something else, of course.
Now, it wasn't x86, and again, I can't find the article. (Probably some flavor of RISC?) But I think that, if anything, proves that VMs could be written which would beat native code, current implementations notwithstanding.
When those magic VMs comes, my hypothetical language will merely change the output target to compile to the VM rather than to bare iron. That is my point.
That would still be runtime. I want it to be compile time, so that I don't pay a runtime overhead for something that could be precomputed
My answer to that would be, eventually, smarter compilers could be built. If you expect to do a lot of differentiation based on the actual type you receive, you could define a DSL for that, which, if it became popular enough, could be implemented natively by future compilers, without actually doing anything to the base language.
I think that would amount to solving the halting problem, which is impossible as far as we know. I'm all for making the compilers do the hard work, but asking the impossible is never going to get us anywhere. E.g, it is in general not possible for a compiler to see what parameters a function will be called with, as the function could be called with the result of an arbitrary function, which would be the same as solving the halting problem.
And a more general answer: I want to get the language right first, in terms of what is most efficient to code in. Occasionally, I can see designing it so that it supports future optimizations -- Ruby's symbols are an example of this, even if they're currently implemented as strings (I think). But only if such modifications leave the language at least as clean and readable as it was before -- Ruby's symbols are actually one less character to type than using a string instead.
Most efficient is of course the goal, though I maintain that efficiency must be both in coding and maintenance. Anyway, the important thing is that the programmer can express intent as clearly as possible. Thus, I find
(1..10).each{ |i| puts i }
to be slightly better than a straight for loop, though the puts is a terrible function name. The stuff I mention is not (only) about execution efficiency, it's also about expression intent.
and so that type errors and other such trivia is out of the way before I begin testing.
I see type errors as just another thing to write unit tests for -- assuming they become an issue at all. If I already have unit tests covering most of my code, I probably don't have to think about types there, either.
So you think. However, a unit test cannot possible cover all possible interactions between all functions in any reasonable application. Thus, there will be cases not covered by your unittest, and those will fail horrible. Consider code like
"cheese".+ (myfunc()).
. Both this code and myfunc() might be behaving as they should, but their interaction could result in a type error, which would be trivial to catch for a statically typed language. Instead, you will be debugging a production problem with some helpful message ala "type error: cannot convert Fixnum to String".
It's hard to measure objectively, but how much time do you spend thinking about type hierarchies, or building additional code which wouldn't be needed with implicit typing? And how much time would you spend tracking down type errors?
A lot less than I spend writing unit test for type errors, not to mention debugging type errors. Like looking up in a hash table, but accidentially using a converted form (say, to string) of the key instead of the intended key.
I think we just have to disagree there. Unit test doesn't always save you from odd corner cases. Strict and static typing helps there.
Static typing won't always save you from odd corner cases, either. I'd argue that static typing in the absence of unit tests is significantly less robust than unit testing in the absence of static typing.
I never claimed they did, but they do catch some problems immediately that unit cannot catch.
What part of "pseudo-code" did you fail to understand? I left out several details, including checking that source was at eof, fixing the whitespace handling if I insisted on using copy and so on. But the important thing was the resource handling, so that was what I emphasized.
A garbage collector is bad idea? How is C++ better? C++ has memory leaks, and on top of it, C++ has GPF's or core dumps. So in the end C# and Java are actually better.
Try writing a Java program that copies one file into another, and then closes both files. Remember to handle exceptions, and don't assume that the file fits into memory. A simple task, no? In C++ pseudocode, that would be
Now, as an exercise, design a Java class that allows you to perform the given task without having to use finally (you can use it in the class, though).
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.
That would still be runtime. I want it to be compile time, so that I don't pay a runtime overhead for something that could be precomputed, and so that type errors and other such trivia is out of the way before I begin testing. It's like getting a free peer review:o)
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 think we just have to disagree there. Unit test doesn't always save you from odd corner cases. Strict and static typing helps there.
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 kind of ironic, but until recently ruby's unicode support sucked.
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?
Hmm. I hate giving examples in slashdot code. For specialization, std::hash is a nice example. std::hash is specialized for all object that want to support hashing. So if you have a class that can't or won't hash, the compiling fails. In ruby you'll fail at compile time. In Java, you'll get a weird behaviour, as i recall. Overloading is simple... instead of a function starting with a bunch of test to find out what sort of argument you got, the correct function will be inferred by the type. So operator/(double) is a completely different method than operator/(complex).
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.
Try getting that to work properly for C++. KDevelop is the best, and far from perfect in my experience.
Real constants and constant functions would be nice, though.
For what, though?
Again, for those compile-time checks. In C++ I can return a constant reference and *know* that it won't get modified. Or call a constant member and know that the method doesn't modify the object. (Like the conventions of ! and non-! in ruby, but more general).
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.
I agree, but constants variables are just the beginning. It's the constant methods and return values that are truly valuable.
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?
Dynamically, ruby is stronger. Statically, C++ is stronger.
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.
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:
Ruby is definitely my choice when performance is not an issue. It tends to be though:/ Where ruby is lacking is in the static department. Static polymorphism, static typechecks, metaprogramming and that stuff. Otherwise, it is a very strong language, including a lot of good features.
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.
This is one of the strongest points in Ruby. Natural and strong. Just wish they had used unicode as the compiler language, then we could have gotten real less-than-or-equal operators:)
Polymorphic by default.
Indeed, but only dynamic. Not overloading, specialisation or anything like that.:(
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.
It is plenty close. I'm not asking for perfection, if a language support as much of lambdas as Ruby does, I'm more than satisfied.
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.
For big projects, code completion, class summaries and refactoring support is very nice. It's not Java, so it doesn't need quite as much support. C++ is actually and actively held back because of the very complex parse.
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.
Another strong point in Ruby. Real constants and constant functions would be nice, though. (Damn, another point I forgot on my list:( ) Anyway, this is not metaprogramming, but reflection, as I understand it. Rather, I'm thinking of stuff like "you write a grammar, and the compiler+library builds the parser from that." 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.
Static typing, but implicit typing. The term is "duck typing." However, if you really want to, you can build your own static type checking.
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. E.g, a method that (only) calls one method should accept all parameters that have that method. Hope I make myself comprehensible:o) C++ does this with templated methods.
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.
Yes, but it relies on a virtual machine. I do not like that requirement, and I don't think it is strictly necessary.
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".
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. Of course, the compiler should infer the parameters and return values. In C++, you cannot do this in the general case, though the one I mentioned is supported (through std::bind1st). I don't think it is directly possible in Ruby, though you could make limited library support for it ala C++. Without a static type system, though, the result is not so useful.
The only language I ever heard of that comes close to all that is Common Lisp. And yes, it can be statically typed to large extent.
Thank you (and everyone else) for suggestions. I have never seriously learned Haskell because it's OO support is so poor, and even though I forgot it on the list, this is also important. Is LISP stronger in this area?
Python maybe? It's quite close to your spec I think.
Close (I prefer ruby, but they are very similar on this level). But it is sorely lacking in the static department (metaprogramming and typing and polymorphism). It also falls short on the performance target, though I can and do disregard that for many applications.
So let's see. While I will readily agree that C++ really needs a sane syntax, which would include having explicit the default, the real problem with the first program is poorly named functions and classes. Explicit would have saved you that time, but the poor naming would have killed you later anyway. The error in the second one is some programmer's inability to read warnings from the compiler, though again I agree that the default is a backwards. Yet, I have never been bitten by the either,eh, feature, though I have programmed C++ for some years now. (5? I forget).
So will C++ die? Someday, I hope. The problem is that very few languages support the features I need and want. I always forget some, but a short list would be
Ability to make domain-specific libraries reasonable. No, matrixA.times(matrixB) is not good enough, it really must be matrixA*matrixB or similar.
Polymorphy --- static and dynamic, of course.
Lambda functions (closures for extra points) with a simple, inline syntax.
LALR or similar simple syntax (for making programming tools easier to make)
Metaprogramming
Reflection
static typing, divorced from inheritance of course.
target agnostic (the language really shouldn't assume the target. I want to compile to i386, JVM or power5 as I wish
Reasonable performance. Say, no less than a 50% slowdown.
Direct, easy callable to C. JNI is a good example of how not to do this:o)
At least simple lambda calculus. I want to be able to take two functions and make a third from them, given the arguments and return types a compatible.
I do not think these requirements are unreasonable. Yet no language comes close to doing all of these. I've found C++ to be the closests match, but especially the LALR, reflection and lambda functions are sorely missing.
I'm always interested in hearing about languages who comes close to this ideal, btw:)
Except that I don't hold with deism wordage, as it is too easy to confuse the deistic god-as-the-natural-world with the god-the-listener-to-prayers, I don't disagree, except this.
Christianity, the core of it, is simply the addition of "we are as good as we treat eachother" to the scientific principle that specifies the validity of doing experiments.
That is one view, and hopefully a popular one. However, this requires discarding most of the contents of the bible. Indeed, I have been told that if you take a pair of scissors, and cut out everything that we know to be not true (no, Jesus cannot have been born in Nazarath, Jesus was not born to a virgin if born at all, a lot of the speeches attributed to Jesus are almost word-to-word copies of older texts etc) --- if you do that, then even with the help of the margins and the binders, the book cannot be picked up without falling apart.
I can hear you are well underway towards deism... and deist and atheist are not so unlike. Both tend to marvel at the world, and both to trust evidence over mysticism. And so I leave this conversation, I think there is little left to be said. If you want to talk futher, debate.atheist.dk is very open, and unlikely many of the other religious and atheist forums, never seems to ban anyone for having the "wrong" opinion. There are lots of theist, deist and atheists there.
Incidentally, do you know how many terrorist attacks that airport security at check-in have prevented?:) This is a very, very bad argument you try to use against these checks. [...]
I wasn't making an argument, just asking a question. But since you bring it up: How many terrorist have been caught by the check-in checks? If the measures work, I'd expect the checks to catch someone, at least occasionally.Of course, a lot more might simply give up before they try, but since the attacks do happen occasionally, there are still a basis for statistics. If the answer, as I suspect, is none, then I'd say that the checks are ineffective. Metal detectors? Give me a break, any idiot can get past *that* with whatever weapon she desires short of a tank.
Again you come off with the subtle social reasons. You should be an atheist because it's the "default position". The default position, in any subject really, is nothing but a popular idea, and in fact, I tend to think different. The default position is that the titanic is unsinkable. The default position is that hitler is a champion of the poor, protecting them from big scary jewish arms merchants. The default position is that Bush is a racist dictator, enriching himself, and Chavez is a champion of the poor, improving the life of venezuelans, and that he'll somehow behave different from all past communists, even when more and more news items say he is behaving exactly as might be predicted.
Nice strawman. It is the default position to not believe in any particular god just like it is the default position to not have any hobbies. A newborn is, e.g. an atheist,just like it doesn't have any hobbies yet.
These are "default positions",
No, they are not. You are just wildly inventing. You don't have to feel bad about not taking the default position, there is nothing that makes a default position better.
Second argument... atheism is supposedly courageous. Well, yes, active, proselytizing atheism in Saudi Arabia... THAT I might consider courageous. Atheism inside a liberal state with guaranteed human rights filled with agnosts and atheist... that's not courageous, that's going with the flow, becoming an unnoticeable nobody, safe in a mass of like-minded people. In fact, in most universities (certainly in mine) it's belief that is the courageous position.
I did not say it was courageous to be an atheist. To become one, though, you have to face that there is no purpose in life, nothing is holy, and we only get this one life. That takes courage. Once you have accepted this, there is nothing further courages about it, except of course as provided by society.Did you understand it this time?
Now you could say that a given book has little relation to the truth, and that the bible is just that, just a book. And you're right obviously. So that book cannot, by itself be the reason to believe. I don't claim different.
Indeed, yet many claim otherwise.
In truth however, it is beyond ridiculous to state that there "is no God". Everybody can see around them that there is some entity that is at every single location, everywhere and anywhere, enforcing a set of rules, enforcing the equality that you find in everything that is the basis of science, on people as well as on rocks, plants and animals. This is obviously what science is, science is based on a belief in a STRICTLY mechanical "God", that is just as eternal as the entity described in the bible. Faith, or at least Christian faith*, simply adds a little to the belief that founded science, and that is that we, humans, are a force for good, that this mechanical "God" skips just a little rule every now and then to make it possible for humans to believe in themselves, in eachother, and in him.
So you are saying that Christianity is just adding a few unsubstantiated claims to deism? That seems fair enough. Doesn't make it less wrong, of course. At this point, let me be clear when I say "there is no god", I mean god in the sense of a being who do miracles and listen to prayers, and even pays heed to those prayers at least occasionally. I have no quarrel with the deistic "mechanical" god as you claim it, though I think it is a silly, misleading use of the word.
the other completely ridiculous claim you make is that every religion is the same.
I have made no such claim. I asked whether you believed in any of these religions. Which you obviously don't, considering most of what follows this would be blasphemy for followers of those religion. I maintain that when you understand why you don't believe in those other religions, you will unders
don't see how a plastic bag makes make-up less dangerous though
The argument is that the liquids they are afraid of are volatile and hard to contain in cans, and thus you would see condensation on the inside of the bag.
Incidentally, do you know how many terrorist attacks that airport security at check-in have prevented?:)
Slashdot Mirror
At work we use it, and it works fine.
Now you are being unfair. Java code runs often runs at almost half the speed of C++, and have a few features (such as better enums, reflection, simpler parse) which C++ doesn't.
If you use the server VM, the java VM can actually inline code. Amazing!
No what I am saying is that you should NEVER directly cite a Wikipedia article in an academic paper,
Really? Despite reading your post again, I didn't get that impression. Sorry about that. Anyway, in my experience, most academic papers are frankly not worth the paper they are printed on. Of course, the ones that are good are sometimes very, very good and makes it all worthwhile. But then, I only use academic papers, I don't produce any.
But that doesnt mean that I think Wikipedia is useless; far from it in fact. It's great for Background information, Links, Keywords and References. It's a great tool to help focus research and get a little context and background information. Kind of like an encyclopedia, but where the information can change quickly and sometimes inaccurately (at least until corrected by the admins).Indeed. Wikipedia is sometimes inaccurate on a given day, encycleopedias are sometimes inaccurate on a given subject.
But don't listen to meNow, that article is pretty funny. Take e.g. the first paragraph:
The website (pronounced wikee/pee/dee/er) is one of the world's great co-operative ventures, an online encyclopedia compiled by thousands of global users - or is it just another unreliable website full of mistakes, misconceptions and misleading entries?Indeed. Actually, it is over 100 of thousands global users... 158458 as of January, to be exact. Will the independent continue to be just another unreliable website full of mistakes, misconceptions and misleading entries?
If you manage to get past the first drivel, it's not bad. The overall conclusion seems be that wikipedia is quite accurate, though at times rather obviously slanted for biographies. (My favorite quote was the one about Tony Blair entering GB into many armed conflicts despite being a devout Christian. As if religious people are not infamously violent.
You are trying to support that Wikipedia is unreliable by quoting a newspaper (which as usual gets just about every fact wrong), a blogger (proof that journalists are not the worst people at getting facts right) and finally the freaking register, which hates Wikipedia so much that the foaming around the mouth was visible from the international space station earlier this month.
Now *that* is what I call ironic :p
Go ahead and try. It will be fixed within 24 hours, for such a prominent article --- there will be too many who have that article on their "watch list". Wikipedia's problem is the obscure subjects without many or any watchers.
And of course, by design, wikipedia is vulnerable to urban myths, though the discussion pages tends to weed those out over time.
But I admit wikipedia is hard to predict. E.g, I am amazed at the amount of mathematical knowledge that is accessible there. Like the other day, when I couldn't find a textbook and I was wondering which properties the dual of a LP system had away from optimality. Took a bit of searching, but I ended up finding it on wikipedia through google.
Moreover, and I might be a mathematician but certainly not a genius, had no trouble finding the correct answer in my heads in a few seconds when I was presented with the problem in my late teens. It's not exactly a hard problem :)
And also garbage collection, and other things.
Garbage collection is on the verge of being included in C++. So it must be possible to do without a VM. (Personally, I think garbage collection is only good for covering up bad design, but let's do that another time --- but anyway, that's my excuse for only knowing the big picture as garbage collection goes. )
I suppose the proper word is "runtime", because I do believe there are optimizations which can only be done effectively at runtime.
So you claim :) I disagree, though. Or at least, it seems to me that the penalty for those optimizations outweights the benefits. Also, for security reasons, I prefer the executable part of an application to be in a non-writable segment.
Probably the biggest thing that bothers me right now is the fact that any sufficiently complex file is going to end like this:
That's something I can get around with a preprocessor, though, and people have -- basically, to make Ruby behave like Python. But that's a minor irritation anyway -- I type fast, and it has the advantage of having most editors understand C-like syntax (and be able to jump from start to end tags and back).
Hm. I would prefer having endmethod, endclass and so on, but otherwise I'm find with something like this. Python style blocks I never liked.
There's also the lambda/block syntax -- it's very good for when you only need to pass a single block, but I do wish it was easier to pass a pair or more.
I always assumed I just didn't get how to do this simply :o)
And there's the fact that unlike JavaScript, methods are very much stuck to a class. It's something a lot of people seem to hate about it, but I loved -- I can rip a function out of anywhere, any class, any object, and apply it to something completely different. I can assemble a class not only from modules explicitly specified as such, or from direct inheritance from multiple other classes, but from, well, anywhere I want. I can completely make up my own class system.
Most of that is available through things like Object.extend in Ruby, but that's not as easy to build classes with, and is complicated by the difference between "extend" and "include".
I would imagine it would also make your code hard to read or understand.
I suspect that the main things I prefer about Javascript (instead of Ruby) is that Javascript is prototype-based, whereas Ruby is traditional class inheritance with mixins. It seems to me that a prototype system is a simpler set of primitives than a class system, even if it might be possible to build one from the other.
That is an old battle. On the balance, I prefer the class system, again because I find it easier to express my intent clearly. Not a huge deal for me either way, though.
I find that I mostly get into the latter situation out of my own lack of discipline. But at the same time, there's a lot of scaffolding out there -- there are browser-based unit tests for webapps.
Webapps are easy for many reasons. Make sure that a method that is supposed to tighten a linear constraint in a linear system is worse. Sure, you can make a test for the simple cases, but most of the code is about stuff like numerical instability. Scaffolding stuff lik
I'd say that gathering statistics of what's actually being done is probably a strong enough indicator of future calls. Consider the following:
Will the code be compiled every time? I'd argue that a reasonably intelligent VM might notice that the source string isn't changing, and cache the result of that call. And if it's a sufficiently long string, it absolutely would be a net win in efficiency, even including VM overhead.
No VM is needed for that. Any decent implementation of eval will check the input string against a cache. Branch prediction is another example of what you are talking of, and again, no VM is required. I can see where VMs theoretically can give a small boost to performance in some cases, but so far I've not seen a VM that performs better than 50% of bare iron.
No, but it should optimize for a sane design, right?
Of course, but that doesn't help it if it trying to detect errors at the compile time. You cannot have false positives here.
There are other reasons why I don't consider it the perfect language. Even syntactical reasons.
Anything specific?
And I think I could make a strong argument for unit tests everywhere -- again, I see a type check as just another form of unit test. But tests in general make it that much easier to make larger changes -- because after making the change, you can just run the test to see if it worked.
I agree -- to a point. At some point, the code is either too trivial to test or requires too much scaffolding to test.
There's even test-driven design, but that takes discipline.
I know, I use it extensively for writing parsers and such. It's excellent when you have some good testcases up front. Unfortunately, in my line of work, we often have to make up the test data as we go along, and anyway, the problem we set out to solve is seldom the problem that turns out to be solvable.
Well, it actually means "non-constant", but yes,
Woops, you are correct, of course.
I've seen it abused that way.
To be fair, const can be misused with a bit of effort as well. But the thing is, people usually agree on what const means, while ! means sort of dangerous to some, destructive to others and apparently constant to a third group. Besides, string concatenation is no way to store information :/
Example: Calling foo.save! in Rails will throw exceptions on validation errors, but what is the point of foo.save, which simply returns true or false depending on whether it was successful? If I just want to see if the object is valid, I can call .valid?
Totally agree. Silly design, really. Not really the language's fault, though.
I do get what you mean now about expressing intent, and why that's important -- and I think that's what a high-level language is about. I'm also considering subverting it into an argument against explicit typing -- I don't intend for something to be any given type, I only intend for it to be able to do a certain thing.
I worry that you have misunderstood me. It's the compiletime checki
It is, however, possible for a VM to watch what parameters a function is actually called with. I'm afraid I've fallen into the habit of calling any tool a "compiler", occasionally.
Ok, sorry for the confusion. It is, however, not possible for a VM to predict future calls either, and anyway, the VM would then have to waste clockcycles during every run, instead of having it calculated once and for all.
That is one example. I haven't had enough sleep for a proper reply, so I am not sure if I can find a good code example, but I'm going to suggest that you can have things like this occur in an explicitly-typed language. Templates and anywhere you typecast are places you could have potentially interesting interactions.
You can't. That's the point about type-safety, it's a strong garantee. The code might fail, but it will be during compiletime. Barring bugs in the compiler or language, of course :)
More importantly, you have to wonder at the wisdom of myfunc returning these incompatible types in the first place -- what is so complex about myfunc that it can't return something predictable? Is this something which could be helped by simplifying the design?
The compiler cannot assume a sane design :) Besides, it's a complex world, and sometimes you will need a complex design to solve the issue at hand. You yourself mention using evals at times, something which might return *anything*.
I honestly cannot ever remember doing that. Not once.
Of all the problems I have debugged in Java, that and comparing strings with == is the most common in both my code and in other peoples code. If you have not seen it yet, count yourself lucky, it can be very hard to spot :)
Well, I find explicit typing to be that much more clutter. I don't need pre and postcondition checks everywhere.
Many people would say they don't need unit test everywhere :p I do get that you don't want to specify types, and that is fine by me. It still means that ruby is not the perfect language for me.
I'll have to let that digest for a bit. My initial reaction is that this is still less flexible -- I realize that's on purpose, of course.
I have used it for years, and I'm pretty sure you can do anything you want with it, while still preventing lots of errors. Besides, it allows you to specify intent in a very clear way --- the ! sometimes means constant, but sometimes it is more like "watch out, dangerous function".
But one thing I love about accessors in the first place is the ability to shift the implementation around underneath of whatever's using it. I'm not sure mutable covers everything I might want to do with a former accessor.
It covers all instances of accessors I have ever seen. It does not cover everything people write as accessors, but is really something else, of course.
Now, it wasn't x86, and again, I can't find the article. (Probably some flavor of RISC?) But I think that, if anything, proves that VMs could be written which would beat native code, current implementations notwithstanding.
When those magic VMs comes, my hypothetical language will merely change the output target to compile to the VM rather than to bare iron. That is my point.
My answer to that would be, eventually, smarter compilers could be built. If you expect to do a lot of differentiation based on the actual type you receive, you could define a DSL for that, which, if it became popular enough, could be implemented natively by future compilers, without actually doing anything to the base language.
I think that would amount to solving the halting problem, which is impossible as far as we know. I'm all for making the compilers do the hard work, but asking the impossible is never going to get us anywhere. E.g, it is in general not possible for a compiler to see what parameters a function will be called with, as the function could be called with the result of an arbitrary function, which would be the same as solving the halting problem.
And a more general answer: I want to get the language right first, in terms of what is most efficient to code in. Occasionally, I can see designing it so that it supports future optimizations -- Ruby's symbols are an example of this, even if they're currently implemented as strings (I think). But only if such modifications leave the language at least as clean and readable as it was before -- Ruby's symbols are actually one less character to type than using a string instead.
Most efficient is of course the goal, though I maintain that efficiency must be both in coding and maintenance. Anyway, the important thing is that the programmer can express intent as clearly as possible. Thus, I find
to be slightly better than a straight for loop, though the puts is a terrible function name. The stuff I mention is not (only) about execution efficiency, it's also about expression intent.
I see type errors as just another thing to write unit tests for -- assuming they become an issue at all. If I already have unit tests covering most of my code, I probably don't have to think about types there, either.
So you think. However, a unit test cannot possible cover all possible interactions between all functions in any reasonable application. Thus, there will be cases not covered by your unittest, and those will fail horrible. Consider code like
. Both this code and myfunc() might be behaving as they should, but their interaction could result in a type error, which would be trivial to catch for a statically typed language. Instead, you will be debugging a production problem with some helpful message ala "type error: cannot convert Fixnum to String".
It's hard to measure objectively, but how much time do you spend thinking about type hierarchies, or building additional code which wouldn't be needed with implicit typing? And how much time would you spend tracking down type errors?
A lot less than I spend writing unit test for type errors, not to mention debugging type errors. Like looking up in a hash table, but accidentially using a converted form (say, to string) of the key instead of the intended key.
Static typing won't always save you from odd corner cases, either. I'd argue that static typing in the absence of unit tests is significantly less robust than unit testing in the absence of static typing.
I never claimed they did, but they do catch some problems immediately that unit cannot catch.
There's an additional argument th
What part of "pseudo-code" did you fail to understand? I left out several details, including checking that source was at eof, fixing the whitespace handling if I insisted on using copy and so on. But the important thing was the resource handling, so that was what I emphasized.
Try writing a Java program that copies one file into another, and then closes both files. Remember to handle exceptions, and don't assume that the file fits into memory. A simple task, no? In C++ pseudocode, that would be
Now, as an exercise, design a Java class that allows you to perform the given task without having to use finally (you can use it in the class, though).
You can still use the === operator, or the kind_of? method. And I'm fairly certain metaprogramming is supported.
That would still be runtime. I want it to be compile time, so that I don't pay a runtime overhead for something that could be precomputed, and so that type errors and other such trivia is out of the way before I begin testing. It's like getting a free peer review :o)
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 think we just have to disagree there. Unit test doesn't always save you from odd corner cases. Strict and static typing helps there.
I'd assumed they did? After all, Ruby is from Japan...
It is kind of ironic, but until recently ruby's unicode support sucked.
I'm feeling a bit lost in this jargon... Can you give me some specific examples?
Hmm. I hate giving examples in slashdot code. For specialization, std::hash is a nice example. std::hash is specialized for all object that want to support hashing. So if you have a class that can't or won't hash, the compiling fails. In ruby you'll fail at compile time. In Java, you'll get a weird behaviour, as i recall. Overloading is simple... instead of a function starting with a bunch of test to find out what sort of argument you got, the correct function will be inferred by the type. So operator/(double) is a completely different method than operator/(complex).
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.
Try getting that to work properly for C++. KDevelop is the best, and far from perfect in my experience.
For what, though?
Again, for those compile-time checks. In C++ I can return a constant reference and *know* that it won't get modified. Or call a constant member and know that the method doesn't modify the object. (Like the conventions of ! and non-! in ruby, but more general).
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.
I agree, but constants variables are just the beginning. It's the constant methods and return values that are truly valuable.
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?
Dynamically, ruby is stronger. Statically, C++ is stronger.
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.
I love that featu
The orientation is of little consequence. I will have to put it on my todo list, I see. Thanks!
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:
Ruby is definitely my choice when performance is not an issue. It tends to be though :/ Where ruby is lacking is in the static department. Static polymorphism, static typechecks, metaprogramming and that stuff. Otherwise, it is a very strong language, including a lot of good features.
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.
This is one of the strongest points in Ruby. Natural and strong. Just wish they had used unicode as the compiler language, then we could have gotten real less-than-or-equal operators :)
Polymorphic by default.
Indeed, but only dynamic. Not overloading, specialisation or anything like that. :(
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.
It is plenty close. I'm not asking for perfection, if a language support as much of lambdas as Ruby does, I'm more than satisfied.
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.
For big projects, code completion, class summaries and refactoring support is very nice. It's not Java, so it doesn't need quite as much support. C++ is actually and actively held back because of the very complex parse.
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.
Another strong point in Ruby. Real constants and constant functions would be nice, though. (Damn, another point I forgot on my list :( ) Anyway, this is not metaprogramming, but reflection, as I understand it. Rather, I'm thinking of stuff like "you write a grammar, and the compiler+library builds the parser from that." 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.
Static typing, but implicit typing. The term is "duck typing." However, if you really want to, you can build your own static type checking.
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. E.g, a method that (only) calls one method should accept all parameters that have that method. Hope I make myself comprehensible :o) C++ does this with templated methods.
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.
Yes, but it relies on a virtual machine. I do not like that requirement, and I don't think it is strictly necessary.
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".
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. Of course, the compiler should infer the parameters and return values. In C++, you cannot do this in the general case, though the one I mentioned is supported (through std::bind1st). I don't think it is directly possible in Ruby, though you could make limited library support for it ala C++. Without a static type system, though, the result is not so useful.
Thank you (and everyone else) for suggestions. I have never seriously learned Haskell because it's OO support is so poor, and even though I forgot it on the list, this is also important. Is LISP stronger in this area?
Close (I prefer ruby, but they are very similar on this level). But it is sorely lacking in the static department (metaprogramming and typing and polymorphism). It also falls short on the performance target, though I can and do disregard that for many applications.
So let's see. While I will readily agree that C++ really needs a sane syntax, which would include having explicit the default, the real problem with the first program is poorly named functions and classes. Explicit would have saved you that time, but the poor naming would have killed you later anyway. The error in the second one is some programmer's inability to read warnings from the compiler, though again I agree that the default is a backwards. Yet, I have never been bitten by the either,eh, feature, though I have programmed C++ for some years now. (5? I forget).
So will C++ die? Someday, I hope. The problem is that very few languages support the features I need and want. I always forget some, but a short list would be
I do not think these requirements are unreasonable. Yet no language comes close to doing all of these. I've found C++ to be the closests match, but especially the LALR, reflection and lambda functions are sorely missing.
I'm always interested in hearing about languages who comes close to this ideal, btw :)
Yeah, but in the haters' defense his gray font does indeed suck ;)
Why does it matter if it is written in C? (unless you are hacking on it yourself, of course).
Except that I don't hold with deism wordage, as it is too easy to confuse the deistic god-as-the-natural-world with the god-the-listener-to-prayers, I don't disagree, except this.
Christianity, the core of it, is simply the addition of "we are as good as we treat eachother" to the scientific principle that specifies the validity of doing experiments.That is one view, and hopefully a popular one. However, this requires discarding most of the contents of the bible. Indeed, I have been told that if you take a pair of scissors, and cut out everything that we know to be not true (no, Jesus cannot have been born in Nazarath, Jesus was not born to a virgin if born at all, a lot of the speeches attributed to Jesus are almost word-to-word copies of older texts etc) --- if you do that, then even with the help of the margins and the binders, the book cannot be picked up without falling apart.
I can hear you are well underway towards deism... and deist and atheist are not so unlike. Both tend to marvel at the world, and both to trust evidence over mysticism. And so I leave this conversation, I think there is little left to be said. If you want to talk futher, debate.atheist.dk is very open, and unlikely many of the other religious and atheist forums, never seems to ban anyone for having the "wrong" opinion. There are lots of theist, deist and atheists there.
I wasn't making an argument, just asking a question. But since you bring it up: How many terrorist have been caught by the check-in checks? If the measures work, I'd expect the checks to catch someone, at least occasionally.Of course, a lot more might simply give up before they try, but since the attacks do happen occasionally, there are still a basis for statistics. If the answer, as I suspect, is none, then I'd say that the checks are ineffective. Metal detectors? Give me a break, any idiot can get past *that* with whatever weapon she desires short of a tank.
Again you come off with the subtle social reasons. You should be an atheist because it's the "default position". The default position, in any subject really, is nothing but a popular idea, and in fact, I tend to think different. The default position is that the titanic is unsinkable. The default position is that hitler is a champion of the poor, protecting them from big scary jewish arms merchants. The default position is that Bush is a racist dictator, enriching himself, and Chavez is a champion of the poor, improving the life of venezuelans, and that he'll somehow behave different from all past communists, even when more and more news items say he is behaving exactly as might be predicted.
Nice strawman. It is the default position to not believe in any particular god just like it is the default position to not have any hobbies. A newborn is, e.g. an atheist,just like it doesn't have any hobbies yet.
These are "default positions",
No, they are not. You are just wildly inventing. You don't have to feel bad about not taking the default position, there is nothing that makes a default position better.
Second argument ... atheism is supposedly courageous. Well, yes, active, proselytizing atheism in Saudi Arabia ... THAT I might consider courageous. Atheism inside a liberal state with guaranteed human rights filled with agnosts and atheist ... that's not courageous, that's going with the flow, becoming an unnoticeable nobody, safe in a mass of like-minded people. In fact, in most universities (certainly in mine) it's belief that is the courageous position.
I did not say it was courageous to be an atheist. To become one, though, you have to face that there is no purpose in life, nothing is holy, and we only get this one life. That takes courage. Once you have accepted this, there is nothing further courages about it, except of course as provided by society.Did you understand it this time?
Now you could say that a given book has little relation to the truth, and that the bible is just that, just a book. And you're right obviously. So that book cannot, by itself be the reason to believe. I don't claim different.
Indeed, yet many claim otherwise.
In truth however, it is beyond ridiculous to state that there "is no God". Everybody can see around them that there is some entity that is at every single location, everywhere and anywhere, enforcing a set of rules, enforcing the equality that you find in everything that is the basis of science, on people as well as on rocks, plants and animals. This is obviously what science is, science is based on a belief in a STRICTLY mechanical "God", that is just as eternal as the entity described in the bible. Faith, or at least Christian faith*, simply adds a little to the belief that founded science, and that is that we, humans, are a force for good, that this mechanical "God" skips just a little rule every now and then to make it possible for humans to believe in themselves, in eachother, and in him.
So you are saying that Christianity is just adding a few unsubstantiated claims to deism? That seems fair enough. Doesn't make it less wrong, of course. At this point, let me be clear when I say "there is no god", I mean god in the sense of a being who do miracles and listen to prayers, and even pays heed to those prayers at least occasionally. I have no quarrel with the deistic "mechanical" god as you claim it, though I think it is a silly, misleading use of the word.
the other completely ridiculous claim you make is that every religion is the same.
I have made no such claim. I asked whether you believed in any of these religions. Which you obviously don't, considering most of what follows this would be blasphemy for followers of those religion. I maintain that when you understand why you don't believe in those other religions, you will unders
The argument is that the liquids they are afraid of are volatile and hard to contain in cans, and thus you would see condensation on the inside of the bag.
Incidentally, do you know how many terrorist attacks that airport security at check-in have prevented? :)