Thursday, November 15, 2007
The next browser must be written in Eiffel
The browser isn't a stable platform:
Yes, and why isn't it stable? It is extremely hard to write a large scale C++ application.
Take for example memory fragmentation. How do you solve that? Add another layer of manual memory management? Things like that are simply not an issue with ISE Eiffel because it has a moving garbage collector, so the heap is continually compacted.
And yes, VCs email me if you think a stable browser is a market :-)
Now I fear history may be repeating itself. Yesterday, I had Firefox 2 for linux crash 5 times, and IE7 for XP crash 7 times. The cause? Too many fat Ajax applications. Zimbra, the whole Google bestiary of applications, Yahoo Mail, etc.. These are all long running applications that I keep open for most of the day. Then all of a sudden the Browser is gone and I have to relaunch and login all over again.
Yes, and why isn't it stable? It is extremely hard to write a large scale C++ application.
Take for example memory fragmentation. How do you solve that? Add another layer of manual memory management? Things like that are simply not an issue with ISE Eiffel because it has a moving garbage collector, so the heap is continually compacted.
And yes, VCs email me if you think a stable browser is a market :-)
Comments:
<< Home
It does seem that the terminal decline of C++ is now underway, and not before its time. It's going to be a slow decline though. For example, the preferred languages at Google are currently Java, C++, Python and Javascript.
The next browser should be written in a typesafe, garbage-collected language, that's for sure.
But that language is unfortunately not Eiffel. Full type safety for Eiffel is "just around the corner", but it has been "just around the corner" since the type holes became widely known around 1991.
There is some handwaving in the ECMA document about an automagical interplay between covariance and attached types, and there are a bunch of other proposals being bandied around at ETH and elsewhere. At best, a solution is still years away.
Even with a garbage collected language, if you write a large application you still need to be rigorous about object management. You need to make sure that useless objects do actually become unreachable and therefore collectable, and one way to do that is to add an extra abstraction layer (much as you might do in the equivalent C++ application anyway).
These issues aside, a modern browser platform is an enormous piece of software. Could ISE Eiffel even compile such a large application within the capacity of a typical hard drive?
The next browser should be written in a typesafe, garbage-collected language, that's for sure.
But that language is unfortunately not Eiffel. Full type safety for Eiffel is "just around the corner", but it has been "just around the corner" since the type holes became widely known around 1991.
There is some handwaving in the ECMA document about an automagical interplay between covariance and attached types, and there are a bunch of other proposals being bandied around at ETH and elsewhere. At best, a solution is still years away.
Even with a garbage collected language, if you write a large application you still need to be rigorous about object management. You need to make sure that useless objects do actually become unreachable and therefore collectable, and one way to do that is to add an extra abstraction layer (much as you might do in the equivalent C++ application anyway).
These issues aside, a modern browser platform is an enormous piece of software. Could ISE Eiffel even compile such a large application within the capacity of a typical hard drive?
I could not agree more with Berend. I would love to do/see that.
But I clearly don't understand your remark Roger. EiffelStudio can compile 2M lines of code without any problem. Compare this with other environments where they actually cannot do that. They create binary components to work around those compile limitation.
Eiffel is much better than anything else and if everyone was to use it instead of downsizing it all the time, the software world would be in a better shape.
Regards,
Manu
But I clearly don't understand your remark Roger. EiffelStudio can compile 2M lines of code without any problem. Compare this with other environments where they actually cannot do that. They create binary components to work around those compile limitation.
Eiffel is much better than anything else and if everyone was to use it instead of downsizing it all the time, the software world would be in a better shape.
Regards,
Manu
Manu, Firefox is over 6 million lines of C++. Maybe that would be 20 million lines of Eiffel.
Binary components were invented as a software reuse mechanism, not to work around compiler limitations.
I would LOVE to be able to use Eiffel for projects such as this. But seriously, can you imagine how big the executable would be? Can you imagine how slowly it would run compared to Firefox?
It could (should) have been different. Some poor decisions were made that "painted Eiffel into a corner". Maybe I'll blog about those another time - but I'm trying to alternate positive and negative blog posts, it'll have to wait.
Binary components were invented as a software reuse mechanism, not to work around compiler limitations.
I would LOVE to be able to use Eiffel for projects such as this. But seriously, can you imagine how big the executable would be? Can you imagine how slowly it would run compared to Firefox?
It could (should) have been different. Some poor decisions were made that "painted Eiffel into a corner". Maybe I'll blog about those another time - but I'm trying to alternate positive and negative blog posts, it'll have to wait.
Roger, a C/C++ application is usually more verbose: you have to define your functions twice for example.
So don't know if Eiffel actually expands in more lines of code than C++.
I don't see your point about making sure useless objects become unreachable. That's only an issue if you cache things. Else it happens automatically.
And the typing issue: gelint issues warnings for these, so we have the tools to detect, at compile time, any possible issues.
So don't know if Eiffel actually expands in more lines of code than C++.
I don't see your point about making sure useless objects become unreachable. That's only an issue if you cache things. Else it happens automatically.
And the typing issue: gelint issues warnings for these, so we have the tools to detect, at compile time, any possible issues.
Q. So who is going to do it?
A. Noone.
And personally, I think Firefox is quite good. What I would like to do is to replace its built-in XSLT transformer (tranformiix) with Gestalt (it would then be the first browser in the world to have built-in XSLT 2.0 using the xml-stylesheet processing instruction i.e. without have to code javascript).
But I don't think there is a hook to do this.
Colin
A. Noone.
And personally, I think Firefox is quite good. What I would like to do is to replace its built-in XSLT transformer (tranformiix) with Gestalt (it would then be the first browser in the world to have built-in XSLT 2.0 using the xml-stylesheet processing instruction i.e. without have to code javascript).
But I don't think there is a hook to do this.
Colin
Berend suggested that "a C/C++ application is usually more verbose". I haven't heard anyone suggest that before!
I don't know any really large application that has been written in both C++ and Eiffel. The "99 Bottles of Beer" application has been written for over a thousand programming languages, and the Eiffel version is 110 lines long.
There are seven different C++ versions, each with a different emphasis, but we can ignore the "extreme template metaprogramming" and "preprocessor only" versions which are intended as jokes. That leaves:
- metaprogramming (25 lines),
- hacking style (17 lines),
- object-oriented (41 lines),
- obfuscated (30 lines), and
- GUI version (68 lines)
On this limited evidence, C++ does seem a much more compact notation.
Next stop was the Alioth Shootout. Of the seventeen benchmarks for which there were C++ and Eiffel implementations, the C++ version was shorter in 14 cases, and the Eiffel version was shorter in 3 cases.
I don't pretend that these figures are rigorous, but they are enough that I'll continue to think of Eiffel as being generally more verbose than C++. That's not necessarily a bad thing, of course, when it comes to readability.
Regarding the gelint tool, Berend suggests that it can warn about "all possible" type errors. Even those caused by the interaction of covariance and agents?
I don't know any really large application that has been written in both C++ and Eiffel. The "99 Bottles of Beer" application has been written for over a thousand programming languages, and the Eiffel version is 110 lines long.
There are seven different C++ versions, each with a different emphasis, but we can ignore the "extreme template metaprogramming" and "preprocessor only" versions which are intended as jokes. That leaves:
- metaprogramming (25 lines),
- hacking style (17 lines),
- object-oriented (41 lines),
- obfuscated (30 lines), and
- GUI version (68 lines)
On this limited evidence, C++ does seem a much more compact notation.
Next stop was the Alioth Shootout. Of the seventeen benchmarks for which there were C++ and Eiffel implementations, the C++ version was shorter in 14 cases, and the Eiffel version was shorter in 3 cases.
I don't pretend that these figures are rigorous, but they are enough that I'll continue to think of Eiffel as being generally more verbose than C++. That's not necessarily a bad thing, of course, when it comes to readability.
Regarding the gelint tool, Berend suggests that it can warn about "all possible" type errors. Even those caused by the interaction of covariance and agents?
Berend wrote: "I don't see your point about making sure useless objects become unreachable."
The point is that in large software systems, you need to take care to set references to 'void' after the objects they reference are no longer needed. Otherwise, your app runs out of memory and crashes. There's some interesting discussion at this wiki page. Here's an excerpt (which addresses Java, but is equally applicable to Eiffel):
"The GarbageCollector will reclaim every object that is not reachable anymore. Great! But do you know every reference there exists to your wonderful MyJTabbedPanel? Well, the parent JFrame, sure, but it is also a listener to some other widgets. Also, since you're using ModelViewController, the panel, which happens to be the view, is also listening on the model. That makes a reference, right? Then don't forget about that nice popup menu that was created long, long ago and that is holding a reference to some JList sitting within your MyJTabbedPanel. Does that count? Maybe, maybe not, the JList could hold a reference to its parent.
"So when the user decides it is not interested into your nice panel anymore, you will remove it from the shell. And you will forget to unregister the panel from the model, and you will forget about this KeyListener?, and you will forget about this popup menu, and you will forget about everything else: why should you bother unititialise all that mess since there is a GarbageCollector that will, eventually, clean everything up?
"Ergo, your MyJTabbedPanel is still hanging around in the memory. Of course, that panel is holding a lot of strong references to other data, such as this three-megabyte background image..."
The point is that in large software systems, you need to take care to set references to 'void' after the objects they reference are no longer needed. Otherwise, your app runs out of memory and crashes. There's some interesting discussion at this wiki page. Here's an excerpt (which addresses Java, but is equally applicable to Eiffel):
"The GarbageCollector will reclaim every object that is not reachable anymore. Great! But do you know every reference there exists to your wonderful MyJTabbedPanel? Well, the parent JFrame, sure, but it is also a listener to some other widgets. Also, since you're using ModelViewController, the panel, which happens to be the view, is also listening on the model. That makes a reference, right? Then don't forget about that nice popup menu that was created long, long ago and that is holding a reference to some JList sitting within your MyJTabbedPanel. Does that count? Maybe, maybe not, the JList could hold a reference to its parent.
"So when the user decides it is not interested into your nice panel anymore, you will remove it from the shell. And you will forget to unregister the panel from the model, and you will forget about this KeyListener?, and you will forget about this popup menu, and you will forget about everything else: why should you bother unititialise all that mess since there is a GarbageCollector that will, eventually, clean everything up?
"Ergo, your MyJTabbedPanel is still hanging around in the memory. Of course, that panel is holding a lot of strong references to other data, such as this three-megabyte background image..."
"Binary components were invented as a software reuse mechanism, not to work around compiler limitations."
When I see how hard it is to get the versionning right for deployment I don't think it helps with code reuse. And for sure now that a C/C++ compiler cannot handle large amount of code. If there was a conspiracy theory, I'm sure they would be behind the DLL/so hell :-)
Firefox 1.5 was 2M lines of code (see http://tinyurl.com/2cbmbb). I'm not sure how it jumped to 6M since 2.0 does not bring major visible changes. In any case having something like Firefox 1.5 less the bugs would have the same size as EiffelStudio 6.1 now.
This is more than doable.
Unfortunately as Colin pointed out, this needs to be done by someone who has enough time and does need money to pay his mortgage, or to get paid doing it. I would not mind the later.
When I see how hard it is to get the versionning right for deployment I don't think it helps with code reuse. And for sure now that a C/C++ compiler cannot handle large amount of code. If there was a conspiracy theory, I'm sure they would be behind the DLL/so hell :-)
Firefox 1.5 was 2M lines of code (see http://tinyurl.com/2cbmbb). I'm not sure how it jumped to 6M since 2.0 does not bring major visible changes. In any case having something like Firefox 1.5 less the bugs would have the same size as EiffelStudio 6.1 now.
This is more than doable.
Unfortunately as Colin pointed out, this needs to be done by someone who has enough time and does need money to pay his mortgage, or to get paid doing it. I would not mind the later.
Roger Browne: "Regarding the gelint tool, Berend suggests that it can warn about "all possible" type errors. Even those caused by the interaction of covariance and agents?"
Eric Bezault: Yes. I showed an example on SE's mailing list a couple of years ago when there was this discussion about the conformance directions for Agents.
Eric Bezault: Yes. I showed an example on SE's mailing list a couple of years ago when there was this discussion about the conformance directions for Agents.
Roger, hopefully an Eiffel person will write the requires and ensures so if you take that into account, Eiffel might have more lines.
But compare a typical if:
if (a == b) {
something();
}
else {
another_thing();
}
6 lines. In Eiffel:
if a = b then
something
else
another_thing
end
5 lines. Eiffel: no semicolons, no need to append () to empty function calls. No need to repeat function declarations.
Eiffel programmers tend to write their for loops with more lines.
And tend to use better names. And as I said, tend to have their DbC written out instead of left hanging in the comments, if at all.
But given equal code? I'm not so sure there's a huge difference.
Post a Comment
But compare a typical if:
if (a == b) {
something();
}
else {
another_thing();
}
6 lines. In Eiffel:
if a = b then
something
else
another_thing
end
5 lines. Eiffel: no semicolons, no need to append () to empty function calls. No need to repeat function declarations.
Eiffel programmers tend to write their for loops with more lines.
And tend to use better names. And as I said, tend to have their DbC written out instead of left hanging in the comments, if at all.
But given equal code? I'm not so sure there's a huge difference.
<< Home