Re:Anything else out there?
on
The State of X.Org
·
· Score: 2, Informative
The average collection time using openoffice to load and edit a document was 0.0018 seconds and max 0.004 on a pretty old pentium 4 system. Java 7 (ie openjdk) allocates objects on the stack using escape analysis. Malloc/free are often slower overall than gc unless you can allocate more than one object at a time, which for a lot of requests won't be the case.
Re:Anything else out there?
on
The State of X.Org
·
· Score: 3, Insightful
Is this the funny part? Java's reliance on garbage collection makes it perform too poorly for graphics. I like Java, but not for something like this. The only funny part is how stupid the mods on slashdot are. Starting openoffice writer did four garbage collections for a total of 0.03 seconds with a not even optimized server. Garbage collection is not a problem, and if you had read the post the X server hasn't done graphics for a long time -- it's just a middleman between the applications and hardware acceleration.
Have you guys ever actually tried Looking Glass? It doesn't stutter. There is no reason not to use Java for something like this except prejudice.
Personally, I'm still unconvinced that X is a particularly "good idea." 15 years later, and the promises of simplicity and compatibility are still unrealized, as every single implementation of the protocol has suffered from numerous problems. Perhaps it would be best to start from scratch, and revise X11 to be a more realistic/practical specification. The main problem I think is that X is written in C. Originally the X server did graphics itself, scan converting lines and such, so it had to be in C (and there weren't many real alternatives then). Now all it really does is manage a lot of information -- and C is a really really bad language for managing lots of information. Even a simple desktop has over a thousand "windows" that all have position, change listeners, and other properties. Then there are all the bitmaps, pens, backing stores, repaint regions, etc. Events, queues, messages.
The X server should be mostly scrapped and rewritten in Java. Java is a language that is suited for managing information like that, while still being high-performance (enough). The server could be rewritten in C++, but C++ is messy and is a complicated and archaic language at this point anyway.
Take a look at for instance weirdx which basically one person did. It handles most of the core functions of X and plenty fast (of course it is incomplete since it is one person's hobby). Or see Sun's Project Looking Glass, an opengl X server written in Java -- that was also written in one guy's spare time. With more development on these they could be real competitors to X.org while being more approachable, and I'll bet faster than the C code.
Re:Anything else out there?
on
The State of X.Org
·
· Score: 5, Informative
I would like to contribute to the X, but mostly what stops me is that the code is written for the 80s. Lots of internals are using macros and bit values and optimization hacks, and directly 'speaking' X11 protocol. The code is disorganized, with files in weird locations and with two-letter names. I'm not blaming the developers, because in the 80s this is what had to be done. And they are making huge progress making it modular and organizing the code. But it's still not an attractive codebase to dig into.
Then, once you have decided to work on it and have fully absorbed X11 protocol into your being, you basically need a vmware license in order to develop. It's almost as hard to try out the changes you made as it is for kernel developers... slightly easier, especially for debugging, but you still need to either shut down everything you are doing to run a new build or have multiple development systems.
So basically it is a really step hill to overcome just to start developing X. Perhaps steeper since the kernel at least has excellent, 'simple', modular code to work with.
QM conflicts with GR in the same way that for example scan-converting a line segment produces a solid line when you step back, but produces "ladders" and "jaggies" at a pixel scale. You can generalize about formulas for lines, but that is not going to explain the value of a particular pixel.
But more to the point, entanglement is like a pointer. If you have "p = q = &val" and send p to the space station and q on earth and measure *p and *q there are no superposition of states or multiple universes or faster than light travel. There is only the dereference.
Ok sure the 'universe is a simulation' may not be predictive, but as a mental framework maybe it helps to make sense of QM. Like particles being miniature solar systems did until we learned more.
Uh.. what? JavaScript has a Pascal/Algol/C style syntax (never mind that those are all Algol style). Ruby is very close to Smalltalk syntax except for a few minor points.
Which is of course the problem with Ruby. Staring at code with a bunch of { |a,b,c|... } all over is hardly better than looking at LISP code, and as annoying to write. And of course people use one-letter parameter names since Ruby code is so 'small' and 'elegant'. It's bs. Smalltalk and Ruby syntax both suck, and JavaScript is here to stay.
VI lost the editor war early on. Its focus on text files with little to no support for email or shell prompts or playing text-mode hangman made it unpopular. That's a situation that has changed (somewhat), but the stigma is still attached to it. Which is not really a problem. VI was developed to meet the needs of text editing. If it happens to meet the needs of other activities, great. If it doesn't, that's just as fine.
In any case, EMACS ended up being the "best of breed" solution. It offered all the features of the competing editors, was portable across platforms, had a significant tools (and games) appear practically overnight, and is used by HUGE OSS icons like RMS. I've used it in my own projects and have found that it is much easier and more dynamic than the classic, command/insert model of VI.
We obviously differ, because in my mind Java is one of the best languages yet made often precisely for those reasons that annoy people. Let me explain.
The 11 methods on Java Object are not some kind of golden ratio, but a reflection of the philosophy of the language. Java platform forms an (inverted) food pyramid with layers core classes, standard library, and then applications. Standard library never changes anything in core classes. Applications never change anything in standard library or core classes. The re are 4k classes in the standard library alone and once you learn a class once it is always the same, and this builds a common base of knowledge shared by all developers. A solid ground to work from.
It takes roughly 80x as long to learn something correctly after learning it 'wrong'. So when you have code that says "well in this program Object behaves completely differently in this context" because you have to unlearn what you learned before. So having a changeable core classes is a real problem imo. Most of the benefit from a dynamically typed language comes from not being verbose and being able to substitute objects that have the same methods and not from changeable classes. For instance, you can't change the core functions of perl yet perl is a widely successful dynamic language. For instance SmallScript improved on this slightly because at least when you change a core class the change is only visible in the same namespace. This segments the 'unlearning' to a single package, but it still doesn't really fix the problem.
Take the great example of the tax code for instance. Printed out it is what, tens of thousands of pages?, and filled with all sorts of exceptions and loopholes. So it's complex by any definition, but what makes it difficult is that it changes. If it were not changing then it might take a while, but eventually turbotax would 'understand' the whole code and then calculating the tax would actually be easier than a far simpler code, but one that changed every year. So, yes, Java methods are 'longer' and 'more complicated'. But they don't change often and this makes them so useful.
Files are great because you can do so many things (crudely) with so little effort. Like search: "grep -r somepattern src". Or zip, or svn, or edit them with vim, or email them, etc. Yes, I know there are Smalltalk specific ways to do these things within the image which are different but 'better'. Or you can 'export everything to files', then use file tools, then import the results -- but it's really cumbersome to do this. Consider how you check your changes in smalltalk into a subversion repository... you use some widget somebody wrote to interface Smalltalk to svn in some way (an export script, an adapter, etc) but ultimately somebody had to do some work to accomplish this. And then more work has to be done in order to support monotone, mercurial, git, darcs, etc. The point being that the images makes you need extra work for each and every way you would want to interact with other file-based programs. And there are so many existing programs that are file-based, and in real life you have to interact with them. So this is another way that Smalltalk fails, because it has to reinvent everything -- even though it's reinventions are typically better they only apply to Smalltalk.
Yes, I know you would never check changes into subversion except sometimes you have to for whatever reason. And it is these all-too-common stupid situations where you need to interact with the non-smalltalk world that make the image fail so badly.
So what makes javascript so successful (aside from the more natural algol syntax) vs smalltalk is mostly that it is file based and it is used for throw-away things like web pages. An image make both of those harder.
Anyway this topic is dead on/. if you want to continue please post someplace to do it. I don't have a web presence or blog to use.
You can wrap all the features in a language you want, but the wrong blend makes it taste terrible. Smalltalk did quite a nice job and that's the reason people give it credit and other languages follow suit. Did you ever stop and think maybe there is a reason people give it credit? Well personally I find Smalltalk 'tastes terrible'. I think Smalltalk gets credit mostly for a simple reason: Apple. It's legend that Apple borrowed the interface from Smalltalk, so Smalltalk gets credit for inspiring them. I don't think what goes through most people's minds that give Smalltalk credit for so much is any more complicated than seeing a picture of a Smalltalk WIMP and saying 'that looks familiar'. Never mind the facts that between Simula, LISP, and the mother of all demos it's quite clear that Smalltalk did not invent anything except the blend.
The point I am trying to make is that these things you mention that make up the blend that you like about Smalltalk are not signs of success but of failure. I might call Smalltalk successful at demonstrating what not to do in a language but that's all.
For instance talking about simplicity, Java's Object has 11 methods whereas Smalltalk's has generally over 100 methods -- Smalltalk is not simpler, it's just complex in different ways. If one could load all Smalltalk classes ever written Object would have thousands if not tens or even hundreds of thousands of methods. And I say 'could' because version conflicts make this impossible to do. Java would still have 11 methods on Object and can in fact load all classes from all programs ever written -- the mutable classes of smalltalk that let you do 'great work' inhibit the collective Smalltalk ecosystem from doing 'great work'.
Lacking files, the image (which you call a VM), lack of keywords, lack of operator precedence, etc have been selected out by industry, and it shows by the increased adoption of those language that have attempted to drop out these so-called features. For instance, SmallScript created added more syntax complexity, added files, added namespaces, dropped the image, etc, and this worked well for it -- but then it wasn't special enough to make it worth using over say Visual Basic. Ruby did some of the same things, like adding sane precedence, but again it didn't drop enough of the defects of Smalltalk to make it successful.
The blend of Smalltalk can be seen as essentially combining the Simula (object oriented) and LISP (prototype) lines, but it fails terribly at this. Javascript also combines Simula and LISP lines and is capable of all the same power as Smalltalk that helps you 'do great work', yet it is a very successful language. Javascript deserves a lot of credit as a successful blend and, IMHO, Smalltalk deserves very little -- although I concede that this is not the conventional wisdom.
If success is related to imitation and admiration, then Smalltalk is up there. Of course in itself, the language is derivative, but it's well-known enough to claim/steal credit for one of the best implementations of existing ideas. I have to laugh at other languages, especially Ruby, Python, C#, and Java as they are adding language features or libraries that emulate things that have existed in Smalltalk for 20+ years. That's rather laughable, but also an indicator of success. What's interesting to me is exactly that, how Smalltalk has in fact been able to claim/steal credit for the ideas you talk about and for which it did not invent.
First, all widely successful object-oriented languages are derived from Simula 67 not Smalltalk (C++, Java, C#, and many of the other 'substantial' ones) -- yet Smalltalk somehow gets credit with the masses for being the 'father of OO'. Even Java concepts like inner classes map directly to features in Simula. Second, the other features you imply like closures for instance and syntax simplicity, and most design patterns used heavily in Smalltalk were first perfected by LISP. Yet Smalltalk gets the credit for these things.
Frankly, "Smalltalk is successful" is nothing more than a sham. You yourself listed 12+ 'language killer' problems with Smalltalk, agree that basically nobody ever used it and that it is old and outdated... but you still call it a 'success'? !/boggle
It was Anders that specifically mentioned that methods that lack final "don't perform as well" when there is no difference to the JVM until a class is loaded that overrides the method. Methods that are final could be overridden just the same, except the VM prevents it because final is about security and correctness, not performance. So from the start Anders was either blowing smoke or actually did not understand this.
I see that you get the best of both worlds in that situation, but Andres is right in his unequivical "You cannot inline a virtual function." Because you cannot. You can inline exactly one version of a virtual function with an if at the top, or more if you use a bunch of ifs/a switch. But the latter removes the benefits of inlining Wrong on so many counts. If there is a virtual method and only one implementation, it can be inlined entirely with no 'if' in all of the same cases as if it were marked 'final'.
But more to the point, inlining a function is more than just about changing a jump into a compare. It is also about the code matching up with the caller so that registers are not shuffled around and whatnot. It's about determining that the object allocated by the caller and then passed down three levels of function calls never has a reference taken so it can be allocated on the stack.
If you think inlining means 'just avoiding a jump' then you couldn't be more wrong. But what Anders said does accurately describe CLR... it will never be able to inline effectively due to its type system ('real' generics) and bytecode (have to track types, no interpreting) and other defects conspiring to make deep inlining mostly impossible. CLR is always going to be slow at running 'safe' code because it was designed on false assumptions like 'no final == slow'.
[anders:] You can optimize for the case you saw last time and check whether it is the same as the last one, and then you just jump straight there Which is not the same thing as inlining, it's memoizing. So not only was Anders wrong initially, wrong to say inlining 'can never' be done, but he did not understand what the JVM does even after the interviewer explained it to him. This is your design hero?
As a developer, I am so completely convinced of the superiority of the.NET model and the C# language (Anders Hejlsberg has been my hero ever since he developed Delphi during his Borland years) that I cannot help but prefer its usage, even in a Linux environment. If.net took away your free will it doesn't sound like you had much of it to begin with.
After reading the interviews on artima.com with Anders it's pretty clear that he's mostly a blowhard -- like Beck, all style and no substance. Take this for example:
Bill Venners:... you said: "We can observe that as people write code in Java, they forget to mark their methods final. Therefore, those methods are virtual. Because they're virtual, they don't perform as well."... Another thing that happens in the adaptive optimizing JVMs is they'll inline virtual method invocations, because a lot of times only one or two implementations are actually being used.
Anders Hejlsberg: They can never inline a virtual method invocation.
Bill Venners: My understanding is that these JVM's first check if the type of the object on which a virtual method call is about to be made is the same as the one or two they expect, and if so, they can just plow on ahead through the inlined code.
Anders Hejlsberg: Oh, yes. You can optimize for the case you saw last time and check whether it is the same as the last one, and then you just jump straight there....
Not only is Anders being handed his hat by the interviewer, but he doesn't even realize that for almost ten years all Java methods have been effectively final until overridden, doing exactly that which he says is impossible. There is no 'same as last time' check since it is compiled as if there was one function. There is no 'jump straight there' when the method is inlined, and no performance lost from virtual methods that are not overridden. In contrast,.NET could not even inline more than one method deep, or methods with over 32 bytecodes, or methods with any flow control whereas Java was inlining virtual methods as much as 5 calls deep.
None these guys on the core C# team were anywhere close to the same level as say Joy or Bracha, and it shows. Yeah, if you're coming from Win32 and MFC then C#/.net seems pretty awesome, but it's not. They made a lot of really bad design decisions that make it really suck compared to what it could be and what they ripped it off from. So it kind of depresses me a little bit when people gush quixotic about how great.NET is and how awesome the designers are -- it isn't, and they aren't.
Personally, I find this to be the most interesting and newsworthy item I've seen on Slashdot for some time -- but I'm a long-time Gentoo user with an interest in these sorts of things. I'm in the same boat, but really the only things as a gentoo user that I find to be problems are:
1) Portage/ takes up 500mb and uses 125k files. That's a giant 'FU' to any filesystem. 2) Updating the portage tree takes forever. 3) Emerge takes forever to figure out what to do.
The first two can be solved easily by using a.zip file to store the portage files, and python has built in support for zip. An uncompressed zip file can work better with xdelta/rsync than a bunch of tiny files, depending on how it is created/updated. Even a compressed one can work great with xdelta with a just little bit of ZIP magic when creating a new archive. This solves #1 and #2. FYI, tar.gz and most other modern archives cannot be used because they don't have an index and are not random access.
#3 can mostly be achieved with some kind of database that stores the results from last time, instead of 'rescanning' the world every time emerge runs. Even if portage is too hairy to actually improve this, just having files come from a zip instead of being scattered all over will improve the performance a lot. Probably enough to make it 'ok' again.
So as a user I don't think a new distro is actually needed, and gentoo could be 'fixed' with just a few changes.
The only real measure of code is the pure and simple darwinian test of survival. If it lasts and works, its good code. If it is constantly being rewritten or is tossed, it is bad code. For me, good code is really easy to modify and update and fix problems and add to. So people actually do these things, and the result is that good code gets rewritten and 'tossed' a lot.
On the other hand, take things like ld (and friends) which iirc has code in "func(int) int param; { body }" style... which hasn't been used for what 20+ years? There are so many improvements I would like to make to it, but the code is too crusty to easily make them. I'd call that bad code... even though it 'works' just fine and has been around basically since the epoch. No offense to the people who wrote it, and it's very possible for linking there is no such thing as 'good' code;-P
Yes I'm aware that people are updating these programs... but how many people on earth actually understand ld source? 10? 100?
Only remember the passphrase in one of your multiple personalities, preferably 'Angry Steve'. Hey, if they want to mess with angry Steve, well... you did warn them.
Actually it looks like valgrind was just confused about whether the buffer was initialized. The openssl code for the edg swaps a pointer to be an uninitialized buffer right before calling read with it... maybe this kind of code confused valgrind.
It isn't easy to find where the function they changed is actually called... it gets added to an array of function pointers and then a static variable is set to it, and then there are various macros that can obtain it. I can see how valgrind could be confused, but in any case there is a function that takes a buffer and adds it as randomness and they nuked it. They totally screwed up because they assumed that valgrind was perfect at figuring out what memory was initialized.
There is no simple excuse like 'it was uninitialized wanyway', the debian openssl team just blew it, big time.
As a programmer, what pisses me off most about subversion is... well just check out their codebase and look around a bit. Yeah, it works and it does 90% of what people want it to, but the code is a giant piece of shit. That svn has been developed as a total hack job and they seemingly have spent no effort over time trying to clean it up, as a programmer, offends me. I don't know how anybody can have confidence in svn when they can't even do simple changes to it.
They've been working for years to do simple things like just updating their folder structure so it doesn't leave ".svn" folders everywhere. Or just providing an option to not store a second copy of your 2 gig repository just so you can do restore to Head (and that's all) without asking the svn server which is probably over in the closet on the gigabit ethernet anyway. They can't do this with their current code... it's so bad that they are trying to scrap the local store code entirely.
... and then there are the even simpler things like why tf can't I say "svn mv *.[ch] newfolder/" or any of the other commands that you have to use shell scripting to accomplish? That kind of thing should be simple. There are a lot of these kinds of problems in svn that never gets fixed (despite having a guy at google that is apparently paid to hack on svn).
Have you guys actually ever tried to port a Win32 application to anything else? It's a nightmare. Even their C library isn't standards compliant (see sprintf for instance), let alone that their APIs don't map cleanly to anything else becuase they are all twisted and distorted by 15 years of being faithful to bad designs.
I don't think you guys understand that none of their applications can be ported to other systems without a herculean effort. They are all inextricably tied to windows, by design.
It is fundamental. It's called secure input handling, or sanitizing input. Actually no, it's the output that needs to be sanitized. It's just that it's often easier to sanitize the input since formatting output is often already a complicated mishmash anyway.
Also if HTML did not have inline scripts, if they had to be defined before body and referred to by an ID, this would eliminate even the possibility of the vast majority of xss. The rendering could get messed up, or scripts run when they weren't supposed to be, but only arbitrary code if making substitutions in the actual scripts.
Unless the cell phones present a safety concern, I don't see any reason whatsoever for the government to be involved in banning in-flight cell phone use. After hearing the "brrr brrr br br br br" come from all sorts of speakers -- even with the phone several feet away -- I feel like just having the battery in a cell phone is unsafe. Plane or not.
Complaining about exterminating animal species is really quite selfish; people want to preserve them so there is more to look at in TV shows, zoos, more stuff to eat, etc. etc. I want to not purposely destroy the alligators, crocodiles, and related animals (which I call 'crocolisks') on principle that we should not use our great intellect to destroy something that has lasted hundreds of millions of years purely because we were so short-sighted and stupid as to piss away what we already had.
If actually you think giving up a medical cure that could possibly save myself or members of my family is selfish because it is outweighed by having 'more to look at' then what can I say... apparently the superficial outweighs the mortal for you -- that's kind of a fucked up mentality.
Learn to quit worrying and love the bomb! That movie was intended as satire, you know(?). What you were supposed to learn from it is exactly the opposite.
Of course it will "probably" be more practical to produce the antibiotics in some way other than making huge alligator farms. That's pretty obvious.
What's also obvious is that a bacteria that can invade a single alligator does not get much benefit in terms of survival of those genes that enable it to. But when the antibiotic is found literally everywhere in the ecosystem, like our current antibiotics are, then having a gene that enables it to survive the antibiotic is a huge benefit for its survival. Thus, a superbug that can kill 'crocolisks'. That's what I was talking about and that should also be obvious to any educated person.
Also, it is not hypocrisy to complain about comcast cable when there are not other viable choices for customers (ie monopoly). It's not hypocrisy to use electricity when it is necessary. Running a big pharma chicken factory and complaining about killing off all 'crocolisks' to make new antibiotics -- that's hypocrisy. I think there is a lot you need to reflect on, sir.
What it boils down to is that this reasearch is going to end up killing alligators by making immune germs so that we can raise pigs and chickens under worse conditions. That's what we are talking about really.
Humans need newer antibiotics because we wasted them growing pigs and chickens, and reducing the puss in milk from overproducing cows. Also, even if this 'cures' HIV the benefit is not so much in saving lives but more in protecting a social order that allows it to spread.
This will certainly result in a sad reflection on our society, that we would contribute to the destruction of animals that have been around for hundreds of millions of years. So we can have our pork sandwich for lunch for $0.50 less. But hey since we're giving a collective 'fuck you' to the world anyway, why not?
Slashdot Mirror
The average collection time using openoffice to load and edit a document was 0.0018 seconds and max 0.004 on a pretty old pentium 4 system. Java 7 (ie openjdk) allocates objects on the stack using escape analysis. Malloc/free are often slower overall than gc unless you can allocate more than one object at a time, which for a lot of requests won't be the case.
Have you guys ever actually tried Looking Glass? It doesn't stutter. There is no reason not to use Java for something like this except prejudice.
The X server should be mostly scrapped and rewritten in Java. Java is a language that is suited for managing information like that, while still being high-performance (enough). The server could be rewritten in C++, but C++ is messy and is a complicated and archaic language at this point anyway.
Take a look at for instance weirdx which basically one person did. It handles most of the core functions of X and plenty fast (of course it is incomplete since it is one person's hobby). Or see Sun's Project Looking Glass, an opengl X server written in Java -- that was also written in one guy's spare time. With more development on these they could be real competitors to X.org while being more approachable, and I'll bet faster than the C code.
I would like to contribute to the X, but mostly what stops me is that the code is written for the 80s. Lots of internals are using macros and bit values and optimization hacks, and directly 'speaking' X11 protocol. The code is disorganized, with files in weird locations and with two-letter names. I'm not blaming the developers, because in the 80s this is what had to be done. And they are making huge progress making it modular and organizing the code. But it's still not an attractive codebase to dig into.
Then, once you have decided to work on it and have fully absorbed X11 protocol into your being, you basically need a vmware license in order to develop. It's almost as hard to try out the changes you made as it is for kernel developers... slightly easier, especially for debugging, but you still need to either shut down everything you are doing to run a new build or have multiple development systems.
So basically it is a really step hill to overcome just to start developing X. Perhaps steeper since the kernel at least has excellent, 'simple', modular code to work with.
QM conflicts with GR in the same way that for example scan-converting a line segment produces a solid line when you step back, but produces "ladders" and "jaggies" at a pixel scale. You can generalize about formulas for lines, but that is not going to explain the value of a particular pixel.
But more to the point, entanglement is like a pointer. If you have "p = q = &val" and send p to the space station and q on earth and measure *p and *q there are no superposition of states or multiple universes or faster than light travel. There is only the dereference.
Ok sure the 'universe is a simulation' may not be predictive, but as a mental framework maybe it helps to make sense of QM. Like particles being miniature solar systems did until we learned more.
Uh.. what? JavaScript has a Pascal/Algol/C style syntax (never mind that those are all Algol style). Ruby is very close to Smalltalk syntax except for a few minor points.
... } all over is hardly better than looking at LISP code, and as annoying to write. And of course people use one-letter parameter names since Ruby code is so 'small' and 'elegant'. It's bs. Smalltalk and Ruby syntax both suck, and JavaScript is here to stay.
Which is of course the problem with Ruby. Staring at code with a bunch of { |a,b,c|
VI lost the editor war early on. Its focus on text files with little to no support for email or shell prompts or playing text-mode hangman made it unpopular. That's a situation that has changed (somewhat), but the stigma is still attached to it. Which is not really a problem. VI was developed to meet the needs of text editing. If it happens to meet the needs of other activities, great. If it doesn't, that's just as fine.
In any case, EMACS ended up being the "best of breed" solution. It offered all the features of the competing editors, was portable across platforms, had a significant tools (and games) appear practically overnight, and is used by HUGE OSS icons like RMS. I've used it in my own projects and have found that it is much easier and more dynamic than the classic, command/insert model of VI.
har, har...
We obviously differ, because in my mind Java is one of the best languages yet made often precisely for those reasons that annoy people. Let me explain.
/. if you want to continue please post someplace to do it. I don't have a web presence or blog to use.
The 11 methods on Java Object are not some kind of golden ratio, but a reflection of the philosophy of the language. Java platform forms an (inverted) food pyramid with layers core classes, standard library, and then applications. Standard library never changes anything in core classes. Applications never change anything in standard library or core classes. The re are 4k classes in the standard library alone and once you learn a class once it is always the same, and this builds a common base of knowledge shared by all developers. A solid ground to work from.
It takes roughly 80x as long to learn something correctly after learning it 'wrong'. So when you have code that says "well in this program Object behaves completely differently in this context" because you have to unlearn what you learned before. So having a changeable core classes is a real problem imo. Most of the benefit from a dynamically typed language comes from not being verbose and being able to substitute objects that have the same methods and not from changeable classes. For instance, you can't change the core functions of perl yet perl is a widely successful dynamic language. For instance SmallScript improved on this slightly because at least when you change a core class the change is only visible in the same namespace. This segments the 'unlearning' to a single package, but it still doesn't really fix the problem.
Take the great example of the tax code for instance. Printed out it is what, tens of thousands of pages?, and filled with all sorts of exceptions and loopholes. So it's complex by any definition, but what makes it difficult is that it changes. If it were not changing then it might take a while, but eventually turbotax would 'understand' the whole code and then calculating the tax would actually be easier than a far simpler code, but one that changed every year. So, yes, Java methods are 'longer' and 'more complicated'. But they don't change often and this makes them so useful.
Files are great because you can do so many things (crudely) with so little effort. Like search: "grep -r somepattern src". Or zip, or svn, or edit them with vim, or email them, etc. Yes, I know there are Smalltalk specific ways to do these things within the image which are different but 'better'. Or you can 'export everything to files', then use file tools, then import the results -- but it's really cumbersome to do this. Consider how you check your changes in smalltalk into a subversion repository... you use some widget somebody wrote to interface Smalltalk to svn in some way (an export script, an adapter, etc) but ultimately somebody had to do some work to accomplish this. And then more work has to be done in order to support monotone, mercurial, git, darcs, etc. The point being that the images makes you need extra work for each and every way you would want to interact with other file-based programs. And there are so many existing programs that are file-based, and in real life you have to interact with them. So this is another way that Smalltalk fails, because it has to reinvent everything -- even though it's reinventions are typically better they only apply to Smalltalk.
Yes, I know you would never check changes into subversion except sometimes you have to for whatever reason. And it is these all-too-common stupid situations where you need to interact with the non-smalltalk world that make the image fail so badly.
So what makes javascript so successful (aside from the more natural algol syntax) vs smalltalk is mostly that it is file based and it is used for throw-away things like web pages. An image make both of those harder.
Anyway this topic is dead on
The point I am trying to make is that these things you mention that make up the blend that you like about Smalltalk are not signs of success but of failure. I might call Smalltalk successful at demonstrating what not to do in a language but that's all.
For instance talking about simplicity, Java's Object has 11 methods whereas Smalltalk's has generally over 100 methods -- Smalltalk is not simpler, it's just complex in different ways. If one could load all Smalltalk classes ever written Object would have thousands if not tens or even hundreds of thousands of methods. And I say 'could' because version conflicts make this impossible to do. Java would still have 11 methods on Object and can in fact load all classes from all programs ever written -- the mutable classes of smalltalk that let you do 'great work' inhibit the collective Smalltalk ecosystem from doing 'great work'.
Lacking files, the image (which you call a VM), lack of keywords, lack of operator precedence, etc have been selected out by industry, and it shows by the increased adoption of those language that have attempted to drop out these so-called features. For instance, SmallScript created added more syntax complexity, added files, added namespaces, dropped the image, etc, and this worked well for it -- but then it wasn't special enough to make it worth using over say Visual Basic. Ruby did some of the same things, like adding sane precedence, but again it didn't drop enough of the defects of Smalltalk to make it successful.
The blend of Smalltalk can be seen as essentially combining the Simula (object oriented) and LISP (prototype) lines, but it fails terribly at this. Javascript also combines Simula and LISP lines and is capable of all the same power as Smalltalk that helps you 'do great work', yet it is a very successful language. Javascript deserves a lot of credit as a successful blend and, IMHO, Smalltalk deserves very little -- although I concede that this is not the conventional wisdom.
First, all widely successful object-oriented languages are derived from Simula 67 not Smalltalk (C++, Java, C#, and many of the other 'substantial' ones) -- yet Smalltalk somehow gets credit with the masses for being the 'father of OO'. Even Java concepts like inner classes map directly to features in Simula. Second, the other features you imply like closures for instance and syntax simplicity, and most design patterns used heavily in Smalltalk were first perfected by LISP. Yet Smalltalk gets the credit for these things.
Frankly, "Smalltalk is successful" is nothing more than a sham. You yourself listed 12+ 'language killer' problems with Smalltalk, agree that basically nobody ever used it and that it is old and outdated... but you still call it a 'success'? !
But more to the point, inlining a function is more than just about changing a jump into a compare. It is also about the code matching up with the caller so that registers are not shuffled around and whatnot. It's about determining that the object allocated by the caller and then passed down three levels of function calls never has a reference taken so it can be allocated on the stack.
If you think inlining means 'just avoiding a jump' then you couldn't be more wrong. But what Anders said does accurately describe CLR... it will never be able to inline effectively due to its type system ('real' generics) and bytecode (have to track types, no interpreting) and other defects conspiring to make deep inlining mostly impossible. CLR is always going to be slow at running 'safe' code because it was designed on false assumptions like 'no final == slow'. [anders:] You can optimize for the case you saw last time and check whether it is the same as the last one, and then you just jump straight there Which is not the same thing as inlining, it's memoizing. So not only was Anders wrong initially, wrong to say inlining 'can never' be done, but he did not understand what the JVM does even after the interviewer explained it to him. This is your design hero?
After reading the interviews on artima.com with Anders it's pretty clear that he's mostly a blowhard -- like Beck, all style and no substance. Take this for example:
Bill Venners:
Anders Hejlsberg: They can never inline a virtual method invocation.
Bill Venners: My understanding is that these JVM's first check if the type of the object on which a virtual method call is about to be made is the same as the one or two they expect, and if so, they can just plow on ahead through the inlined code.
Anders Hejlsberg: Oh, yes. You can optimize for the case you saw last time and check whether it is the same as the last one, and then you just jump straight there.
Not only is Anders being handed his hat by the interviewer, but he doesn't even realize that for almost ten years all Java methods have been effectively final until overridden, doing exactly that which he says is impossible. There is no 'same as last time' check since it is compiled as if there was one function. There is no 'jump straight there' when the method is inlined, and no performance lost from virtual methods that are not overridden. In contrast,
None these guys on the core C# team were anywhere close to the same level as say Joy or Bracha, and it shows. Yeah, if you're coming from Win32 and MFC then C#/.net seems pretty awesome, but it's not. They made a lot of really bad design decisions that make it really suck compared to what it could be and what they ripped it off from. So it kind of depresses me a little bit when people gush quixotic about how great
1) Portage/ takes up 500mb and uses 125k files. That's a giant 'FU' to any filesystem.
2) Updating the portage tree takes forever.
3) Emerge takes forever to figure out what to do.
The first two can be solved easily by using a
#3 can mostly be achieved with some kind of database that stores the results from last time, instead of 'rescanning' the world every time emerge runs. Even if portage is too hairy to actually improve this, just having files come from a zip instead of being scattered all over will improve the performance a lot. Probably enough to make it 'ok' again.
So as a user I don't think a new distro is actually needed, and gentoo could be 'fixed' with just a few changes.
On the other hand, take things like ld (and friends) which iirc has code in "func(int) int param; { body }" style... which hasn't been used for what 20+ years? There are so many improvements I would like to make to it, but the code is too crusty to easily make them. I'd call that bad code... even though it 'works' just fine and has been around basically since the epoch. No offense to the people who wrote it, and it's very possible for linking there is no such thing as 'good' code
Yes I'm aware that people are updating these programs... but how many people on earth actually understand ld source? 10? 100?
Only remember the passphrase in one of your multiple personalities, preferably 'Angry Steve'. Hey, if they want to mess with angry Steve, well... you did warn them.
Actually it looks like valgrind was just confused about whether the buffer was initialized. The openssl code for the edg swaps a pointer to be an uninitialized buffer right before calling read with it... maybe this kind of code confused valgrind.
It isn't easy to find where the function they changed is actually called... it gets added to an array of function pointers and then a static variable is set to it, and then there are various macros that can obtain it. I can see how valgrind could be confused, but in any case there is a function that takes a buffer and adds it as randomness and they nuked it. They totally screwed up because they assumed that valgrind was perfect at figuring out what memory was initialized.
There is no simple excuse like 'it was uninitialized wanyway', the debian openssl team just blew it, big time.
As a programmer, what pisses me off most about subversion is... well just check out their codebase and look around a bit. Yeah, it works and it does 90% of what people want it to, but the code is a giant piece of shit. That svn has been developed as a total hack job and they seemingly have spent no effort over time trying to clean it up, as a programmer, offends me. I don't know how anybody can have confidence in svn when they can't even do simple changes to it.
They've been working for years to do simple things like just updating their folder structure so it doesn't leave ".svn" folders everywhere. Or just providing an option to not store a second copy of your 2 gig repository just so you can do restore to Head (and that's all) without asking the svn server which is probably over in the closet on the gigabit ethernet anyway. They can't do this with their current code... it's so bad that they are trying to scrap the local store code entirely.
... and then there are the even simpler things like why tf can't I say "svn mv *.[ch] newfolder/" or any of the other commands that you have to use shell scripting to accomplish? That kind of thing should be simple. There are a lot of these kinds of problems in svn that never gets fixed (despite having a guy at google that is apparently paid to hack on svn).
Have you guys actually ever tried to port a Win32 application to anything else? It's a nightmare. Even their C library isn't standards compliant (see sprintf for instance), let alone that their APIs don't map cleanly to anything else becuase they are all twisted and distorted by 15 years of being faithful to bad designs.
I don't think you guys understand that none of their applications can be ported to other systems without a herculean effort. They are all inextricably tied to windows, by design.
Also if HTML did not have inline scripts, if they had to be defined before body and referred to by an ID, this would eliminate even the possibility of the vast majority of xss. The rendering could get messed up, or scripts run when they weren't supposed to be, but only arbitrary code if making substitutions in the actual scripts.
If actually you think giving up a medical cure that could possibly save myself or members of my family is selfish because it is outweighed by having 'more to look at' then what can I say... apparently the superficial outweighs the mortal for you -- that's kind of a fucked up mentality. Learn to quit worrying and love the bomb! That movie was intended as satire, you know(?). What you were supposed to learn from it is exactly the opposite.
Of course it will "probably" be more practical to produce the antibiotics in some way other than making huge alligator farms. That's pretty obvious.
What's also obvious is that a bacteria that can invade a single alligator does not get much benefit in terms of survival of those genes that enable it to. But when the antibiotic is found literally everywhere in the ecosystem, like our current antibiotics are, then having a gene that enables it to survive the antibiotic is a huge benefit for its survival. Thus, a superbug that can kill 'crocolisks'. That's what I was talking about and that should also be obvious to any educated person.
Also, it is not hypocrisy to complain about comcast cable when there are not other viable choices for customers (ie monopoly). It's not hypocrisy to use electricity when it is necessary. Running a big pharma chicken factory and complaining about killing off all 'crocolisks' to make new antibiotics -- that's hypocrisy. I think there is a lot you need to reflect on, sir.
Their immune system kills HIV because it kills everything... viruses, bacteria, normal cells, ... spare tires.
If it wasn't for their wolverine-esque regenerative powers their blood would instantly dissolve their own selves, like so much molecular acid.
What it boils down to is that this reasearch is going to end up killing alligators by making immune germs so that we can raise pigs and chickens under worse conditions. That's what we are talking about really.
Humans need newer antibiotics because we wasted them growing pigs and chickens, and reducing the puss in milk from overproducing cows. Also, even if this 'cures' HIV the benefit is not so much in saving lives but more in protecting a social order that allows it to spread.
This will certainly result in a sad reflection on our society, that we would contribute to the destruction of animals that have been around for hundreds of millions of years. So we can have our pork sandwich for lunch for $0.50 less. But hey since we're giving a collective 'fuck you' to the world anyway, why not?