| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| subject: | gcc/java |
hi, there! 26 Jan 03 09:35, Gerrit Kuehn wrote to Max Khon: GK>>> I've already thought about that several times. But I think it would GK>>> require too GK>>> much manpower to rewrite in Java, although there would be some GK>>> advantages. MK>> which ones? GK> The usual ones: better and easier to port, safer programs, less GK> coredumps, less coredumps for more unhandled exceptions GK> easier to work on with a group of people, GK> easier to extend and reuse existing code. There are more. both of these statements are moot. MK>> Java is a good language and programming platform but MK>> using it for tossing mail is pretty useless. Just imagine hpt eating MK>> 70-100M. It does not worth it. GK> Well, the tosser is probably not the best example, for sure. I was GK> more GK> thinking about front- and backend parts, the editor/viewer and so on. GK> Implementing new features and new technology like the sql-backend you GK> recently GK> talked about would imho be much easier with java. libodbc++ is not any more complicated and hard to learn than JDBC heck, plain ODBC if used correctly can be very easy. I am not against having message editor written in Java, but hpt written in Java will be an overkill. GK> Of course it *does* cost: GK> first of all memory, sometimes cpu cycles. On the other hand, people GK> like me, GK> who are running a mailer on a 16MB 486, seem to be dying out... :) usually you care about amount of memory your programs eat less when you are on desktop than if you are running fido station on server. /fjoe --- Msged/BSD 6.0.1* Origin: the number of the beast is vi vi vi (2:5000/79.666) SEEN-BY: 633/267 270 @PATH: 5000/79 26 76 2476/418 140/1 106/2000 1 379/1 633/267 |
|
| SOURCE: echomail via fidonet.ozzmosis.com | |
Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.