Thread: RE: [GD-General] Eiffel (Page 2)
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-general
|
From: Jamie F. <ja...@qu...> - 2002-01-02 17:09:50
|
Indeed; but it would be nice to have an OS that 'just did it' (as many laptops are supposed to be able to do, but it's not exactly robust in my experience), without having to have it implemented on a per-application basis. Jamie -----Original Message----- From: J C Lawrence [mailto:cl...@ka...] Sent: 02 January 2002 17:07 To: Jamie Fowlston Cc: gam...@li... Subject: Re: [GD-General] Eiffel On Wed, 2 Jan 2002 14:56:23 -0000 Jamie Fowlston <ja...@qu...> wrote: > Although it would be nice to have a system where such things are > persistent regardless of whether or not you leave the machine on. Some tools do offer that. (X)Emacs does this if you enable session support, as does Galeon (web browser) does, as it saves the state of all windows and visible URLs as it goes along with a restart restoring the previous state. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. cl...@ka... He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. |
|
From: J C L. <cl...@ka...> - 2002-01-02 17:31:51
|
On Wed, 2 Jan 2002 17:09:43 -0000 Jamie Fowlston <ja...@qu...> wrote: > Indeed; but it would be nice to have an OS that 'just did it' (as > many laptops are supposed to be able to do, but it's not exactly > robust in my experience), without having to have it implemented on > a per-application basis. Laptops only offer this support in the guise of extended runtimes for a given OS boot. I'd though you were considering context extension across multiple boots, where each reboot may be to a different (version of) an OS. For this latter case (X)Emacs, Galeon, and a very few others offer some support. -- and it would be great to see such being more common. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. cl...@ka... He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. |
|
From: Jamie F. <ja...@qu...> - 2002-01-02 17:40:32
|
That would be nice, but most people I know stick to one OS (per machine, at least), so I'd consider it less important for it to work across OSs. And I like to turn machines off :) Jamie -----Original Message----- From: J C Lawrence [mailto:cl...@ka...] Sent: 02 January 2002 17:32 To: Jamie Fowlston Cc: gam...@li... Subject: Re: [GD-General] Eiffel On Wed, 2 Jan 2002 17:09:43 -0000 Jamie Fowlston <ja...@qu...> wrote: > Indeed; but it would be nice to have an OS that 'just did it' (as > many laptops are supposed to be able to do, but it's not exactly > robust in my experience), without having to have it implemented on > a per-application basis. Laptops only offer this support in the guise of extended runtimes for a given OS boot. I'd though you were considering context extension across multiple boots, where each reboot may be to a different (version of) an OS. For this latter case (X)Emacs, Galeon, and a very few others offer some support. -- and it would be great to see such being more common. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. cl...@ka... He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. |
|
From: J C L. <cl...@ka...> - 2002-01-02 18:00:12
|
On Wed, 2 Jan 2002 17:40:26 -0000 Jamie Fowlston <ja...@qu...> wrote: > That would be nice, but most people I know stick to one OS (per > machine, at least) so I'd consider it less important for it to > work across OSs. As I only reboot (or take a system down) to do OS/kernel upgrades, so that's the interesting point. For me a reboot does mean a new OS. Beyond that as a feature it gets used (in the Galeon and XEmacs cases in particular) as their versions increment much more rapidly than my installed kernels) -- so I'll upgrade Galeon, kill the running instance, and then restart Galeon and restore the prior session to be back where I was. > And I like to turn machines off :) Ahh, a related but somewhat different problem. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. cl...@ka... He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. |
|
From: Matt D. <ma...@co...> - 2002-01-02 17:21:52
|
You can, sort of, with Windows 2000 by using the Hibernate shutdown option. Wished Linux had that. Matt Davies Programmer, Confounding Factor ma...@co... www.confounding-factor.com -----Original Message----- From: gam...@li... [mailto:gam...@li...]On Behalf Of Jamie Fowlston Sent: 02 January 2002 14:56 To: gam...@li... Subject: RE: [GD-General] Eiffel <Snip> ObNote: My work system is inherently built on the assumption that my systems will have uptimes measured in months. As such I can establish and preserve such "work contexts" for extended periods, building and maintaining their value. Typically I log into my desktop once and then don't log back out again until I install a new kernel (once or twice a year). </Snip> Although it would be nice to have a system where such things are persistent regardless of whether or not you leave the machine on. Jamie -----Original Message----- From: gam...@li... [mailto:gam...@li...]On Behalf Of J C Lawrence Sent: 24 December 2001 20:29 To: ph...@me... Cc: gam...@li... Subject: Re: [GD-General] Eiffel On Mon, 24 Dec 2001 11:50:26 -0000 Philip Harris <ph...@me...> wrote: > I can see why that would cause problems under windows although I > would guess that your multiple Emacs frames would be one window > with a lot of children on Windows. Ahh, MDI. <retch> I tend to run windows in terms of contexts. A virtual desktop will have a number of windows on it, all applying or related to a given task. Typically this will mean a few XEMacs frames, a few xterms, a few browser windows, etc. Then repeat that on the next desktop for the next task (more accurately "frame of mind"). Sometimes its system based. Currently I have a desktop devoted to some IPSec work I'm doing on Alice (system name), another devoted to some InterMezzo stuff going on on Koala, a desktop for root sessions on various machines (grouped for security reminders), one devoted to some work stuff I'm doing locally on a protocol stack, another for a private PHP project, etc > It's interesting (at least to me) that you find that sort of > environment so efficient. I got used to it -- started with the approach roughly 14 years ago and have never looked back. > I tend to work the opposite way, the less windows, files and apps > open at any one time the quicker things move along. Perhaps it's > Windows imposing its will on me... At any given time I'll tend to work only on a small subset. But then I change subsets fairly regularly. It might take me several days, occasionally more than a month, to get back to any particular context set (private projects particularly tend to suffer such long gaps), but when I do everything is still there ready and waiting in the exact same relationship, with the exact same XEmacs edit history and internal context etc as it had the instant I stopped working on it -- easy for the mental gears to click back into and start up again. ObNote: My work system is inherently built on the assumption that my systems will have uptimes measured in months. As such I can establish and preserve such "work contexts" for extended periods, building and maintaining their value. Typically I log into my desktop once and then don't log back out again until I install a new kernel (once or twice a year). Yeah, its Linux, so I tend to follow the hectic kernel upgrade path. I'd rather do upgrades, and thus reboots, every other year, but there are always too many interesting things depending on some new kernel rev to tempt me away to upgrading. > Obviously your approach works very well for you. Do you know of > other people who work the same way? I know of a few (perhaps a half dozen), not that many. Of course a few of them have copied from me -- usually after having copied my FVWM RC (which seems to be a viral meme in its own right). > Is it an apporach you've been using a long time or it still > evolving? At the low level it evolves constantly as I adopt new tools and changes smaller practices. As you can see from the screenshots directory I posted a while back, its wasn't that long ago I finally decided that icons were evil and evicted them from my system. Similarly I recently moved from Netscape to Galeon (a Gecko based browser which supports a number of useful UI features such as being able to restart with all the same windows open and all the same pages loaded as it had when it was brought down). My browsing habits haven't changed in detail. I still follow the same pattern of reading a page and opening a new window (or TAB in Galeon's case) on every interesting link as I go along (I almost never use the forward/back buttons), but now I tend to group pages in Galeon Windows on a task, character, and interest basis. As such I have a Galeon window each containing multiple TABs devoted only to pages which will require long term study research (typically online books), another to firewall research, another to IPSec, another to MUD-Dev, another to blogs, another to performance metrics, another to Kanga.Nu, another to temp/trash stuff...etc. > I'm just interested because that sort of approach doesn't seem > efficient to me at all. I suspect our work methods are not that different within a single given project. In any given contenxt I usually have little going on (a couple XEmacs frames, a few xterms, a browser or two, a couple supporting apps, and that's about it). The likely difference is that I maintain state and context for many projects and sub-projects as I go along, that I expect to keep them (and do) for variously long periods, that I fork such contexts regularly, and that I pop among them easily. I get a lot of startled looks from passersby. The ticket is not trying to work with them all at once, but building and storing work contexts such that they're easily context shiftable among. Easy support for mental context shifting is the basic assumption of this work method. My problem now, and my current big interest in XEMacs UI development, is seeing how I can shove that same work process down into editing sessions within XEmacs on a large project. Too often I get into a "What is this token and why is it being used quite like this?" research project, which of course recursively forks as I dig down into other identical researches on other tokens. I need a way to tag and lock context frames on those investigations so that I can later pop back to them, and then usefully pop about among them, possibly with a matching annotation system. Barry Warsaw's WinRing elisp looks very useful as a component for this, but I haven't settled on a basic approach yet. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. cl...@ka... He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. _______________________________________________ Gamedevlists-general mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-general _______________________________________________ Gamedevlists-general mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-general |
|
From: Jamie F. <ja...@qu...> - 2002-01-02 17:22:30
|
Aha! Never knew about that one. Ta. Shall see how well it works :) Jamie -----Original Message----- From: Matt Davies [mailto:ma...@co...] Sent: 02 January 2002 17:19 To: Jamie Fowlston; gam...@li... Subject: RE: [GD-General] Eiffel You can, sort of, with Windows 2000 by using the Hibernate shutdown option. Wished Linux had that. Matt Davies Programmer, Confounding Factor ma...@co... www.confounding-factor.com -----Original Message----- From: gam...@li... [mailto:gam...@li...]On Behalf Of Jamie Fowlston Sent: 02 January 2002 14:56 To: gam...@li... Subject: RE: [GD-General] Eiffel <Snip> ObNote: My work system is inherently built on the assumption that my systems will have uptimes measured in months. As such I can establish and preserve such "work contexts" for extended periods, building and maintaining their value. Typically I log into my desktop once and then don't log back out again until I install a new kernel (once or twice a year). </Snip> Although it would be nice to have a system where such things are persistent regardless of whether or not you leave the machine on. Jamie -----Original Message----- From: gam...@li... [mailto:gam...@li...]On Behalf Of J C Lawrence Sent: 24 December 2001 20:29 To: ph...@me... Cc: gam...@li... Subject: Re: [GD-General] Eiffel On Mon, 24 Dec 2001 11:50:26 -0000 Philip Harris <ph...@me...> wrote: > I can see why that would cause problems under windows although I > would guess that your multiple Emacs frames would be one window > with a lot of children on Windows. Ahh, MDI. <retch> I tend to run windows in terms of contexts. A virtual desktop will have a number of windows on it, all applying or related to a given task. Typically this will mean a few XEMacs frames, a few xterms, a few browser windows, etc. Then repeat that on the next desktop for the next task (more accurately "frame of mind"). Sometimes its system based. Currently I have a desktop devoted to some IPSec work I'm doing on Alice (system name), another devoted to some InterMezzo stuff going on on Koala, a desktop for root sessions on various machines (grouped for security reminders), one devoted to some work stuff I'm doing locally on a protocol stack, another for a private PHP project, etc > It's interesting (at least to me) that you find that sort of > environment so efficient. I got used to it -- started with the approach roughly 14 years ago and have never looked back. > I tend to work the opposite way, the less windows, files and apps > open at any one time the quicker things move along. Perhaps it's > Windows imposing its will on me... At any given time I'll tend to work only on a small subset. But then I change subsets fairly regularly. It might take me several days, occasionally more than a month, to get back to any particular context set (private projects particularly tend to suffer such long gaps), but when I do everything is still there ready and waiting in the exact same relationship, with the exact same XEmacs edit history and internal context etc as it had the instant I stopped working on it -- easy for the mental gears to click back into and start up again. ObNote: My work system is inherently built on the assumption that my systems will have uptimes measured in months. As such I can establish and preserve such "work contexts" for extended periods, building and maintaining their value. Typically I log into my desktop once and then don't log back out again until I install a new kernel (once or twice a year). Yeah, its Linux, so I tend to follow the hectic kernel upgrade path. I'd rather do upgrades, and thus reboots, every other year, but there are always too many interesting things depending on some new kernel rev to tempt me away to upgrading. > Obviously your approach works very well for you. Do you know of > other people who work the same way? I know of a few (perhaps a half dozen), not that many. Of course a few of them have copied from me -- usually after having copied my FVWM RC (which seems to be a viral meme in its own right). > Is it an apporach you've been using a long time or it still > evolving? At the low level it evolves constantly as I adopt new tools and changes smaller practices. As you can see from the screenshots directory I posted a while back, its wasn't that long ago I finally decided that icons were evil and evicted them from my system. Similarly I recently moved from Netscape to Galeon (a Gecko based browser which supports a number of useful UI features such as being able to restart with all the same windows open and all the same pages loaded as it had when it was brought down). My browsing habits haven't changed in detail. I still follow the same pattern of reading a page and opening a new window (or TAB in Galeon's case) on every interesting link as I go along (I almost never use the forward/back buttons), but now I tend to group pages in Galeon Windows on a task, character, and interest basis. As such I have a Galeon window each containing multiple TABs devoted only to pages which will require long term study research (typically online books), another to firewall research, another to IPSec, another to MUD-Dev, another to blogs, another to performance metrics, another to Kanga.Nu, another to temp/trash stuff...etc. > I'm just interested because that sort of approach doesn't seem > efficient to me at all. I suspect our work methods are not that different within a single given project. In any given contenxt I usually have little going on (a couple XEmacs frames, a few xterms, a browser or two, a couple supporting apps, and that's about it). The likely difference is that I maintain state and context for many projects and sub-projects as I go along, that I expect to keep them (and do) for variously long periods, that I fork such contexts regularly, and that I pop among them easily. I get a lot of startled looks from passersby. The ticket is not trying to work with them all at once, but building and storing work contexts such that they're easily context shiftable among. Easy support for mental context shifting is the basic assumption of this work method. My problem now, and my current big interest in XEMacs UI development, is seeing how I can shove that same work process down into editing sessions within XEmacs on a large project. Too often I get into a "What is this token and why is it being used quite like this?" research project, which of course recursively forks as I dig down into other identical researches on other tokens. I need a way to tag and lock context frames on those investigations so that I can later pop back to them, and then usefully pop about among them, possibly with a matching annotation system. Barry Warsaw's WinRing elisp looks very useful as a component for this, but I haven't settled on a basic approach yet. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. cl...@ka... He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. _______________________________________________ Gamedevlists-general mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-general _______________________________________________ Gamedevlists-general mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-general |
|
From: Matt D. <ma...@co...> - 2002-01-03 09:56:53
|
On many laptops you can set it up so that on shutting the lid, Windows 2000 (if you're running it) will go straight into hibernate mode. What this means is that it dumps the complete memory contents to harddisk and shuts down. On booting up it just loads back in the memory dump and asks you for your password. Word of warning - don't use it if you plan to change your hardware configuration. While we on the subject, can you get Linux to do the same? E-mail me privately please as I'm entering the realms of OT. I, for one, do not like leaving my machine on. Cheers! Matt Davies Programmer, Confounding Factor ma...@co... www.confounding-factor.com -----Original Message----- From: gam...@li... [mailto:gam...@li...]On Behalf Of Jamie Fowlston Sent: 02 January 2002 17:22 To: gam...@li... Subject: RE: [GD-General] Eiffel Aha! Never knew about that one. Ta. Shall see how well it works :) Jamie -----Original Message----- From: Matt Davies [mailto:ma...@co...] Sent: 02 January 2002 17:19 To: Jamie Fowlston; gam...@li... Subject: RE: [GD-General] Eiffel You can, sort of, with Windows 2000 by using the Hibernate shutdown option. Wished Linux had that. Matt Davies Programmer, Confounding Factor ma...@co... www.confounding-factor.com -----Original Message----- From: gam...@li... [mailto:gam...@li...]On Behalf Of Jamie Fowlston Sent: 02 January 2002 14:56 To: gam...@li... Subject: RE: [GD-General] Eiffel <Snip> ObNote: My work system is inherently built on the assumption that my systems will have uptimes measured in months. As such I can establish and preserve such "work contexts" for extended periods, building and maintaining their value. Typically I log into my desktop once and then don't log back out again until I install a new kernel (once or twice a year). </Snip> Although it would be nice to have a system where such things are persistent regardless of whether or not you leave the machine on. Jamie -----Original Message----- From: gam...@li... [mailto:gam...@li...]On Behalf Of J C Lawrence Sent: 24 December 2001 20:29 To: ph...@me... Cc: gam...@li... Subject: Re: [GD-General] Eiffel On Mon, 24 Dec 2001 11:50:26 -0000 Philip Harris <ph...@me...> wrote: > I can see why that would cause problems under windows although I > would guess that your multiple Emacs frames would be one window > with a lot of children on Windows. Ahh, MDI. <retch> I tend to run windows in terms of contexts. A virtual desktop will have a number of windows on it, all applying or related to a given task. Typically this will mean a few XEMacs frames, a few xterms, a few browser windows, etc. Then repeat that on the next desktop for the next task (more accurately "frame of mind"). Sometimes its system based. Currently I have a desktop devoted to some IPSec work I'm doing on Alice (system name), another devoted to some InterMezzo stuff going on on Koala, a desktop for root sessions on various machines (grouped for security reminders), one devoted to some work stuff I'm doing locally on a protocol stack, another for a private PHP project, etc > It's interesting (at least to me) that you find that sort of > environment so efficient. I got used to it -- started with the approach roughly 14 years ago and have never looked back. > I tend to work the opposite way, the less windows, files and apps > open at any one time the quicker things move along. Perhaps it's > Windows imposing its will on me... At any given time I'll tend to work only on a small subset. But then I change subsets fairly regularly. It might take me several days, occasionally more than a month, to get back to any particular context set (private projects particularly tend to suffer such long gaps), but when I do everything is still there ready and waiting in the exact same relationship, with the exact same XEmacs edit history and internal context etc as it had the instant I stopped working on it -- easy for the mental gears to click back into and start up again. ObNote: My work system is inherently built on the assumption that my systems will have uptimes measured in months. As such I can establish and preserve such "work contexts" for extended periods, building and maintaining their value. Typically I log into my desktop once and then don't log back out again until I install a new kernel (once or twice a year). Yeah, its Linux, so I tend to follow the hectic kernel upgrade path. I'd rather do upgrades, and thus reboots, every other year, but there are always too many interesting things depending on some new kernel rev to tempt me away to upgrading. > Obviously your approach works very well for you. Do you know of > other people who work the same way? I know of a few (perhaps a half dozen), not that many. Of course a few of them have copied from me -- usually after having copied my FVWM RC (which seems to be a viral meme in its own right). > Is it an apporach you've been using a long time or it still > evolving? At the low level it evolves constantly as I adopt new tools and changes smaller practices. As you can see from the screenshots directory I posted a while back, its wasn't that long ago I finally decided that icons were evil and evicted them from my system. Similarly I recently moved from Netscape to Galeon (a Gecko based browser which supports a number of useful UI features such as being able to restart with all the same windows open and all the same pages loaded as it had when it was brought down). My browsing habits haven't changed in detail. I still follow the same pattern of reading a page and opening a new window (or TAB in Galeon's case) on every interesting link as I go along (I almost never use the forward/back buttons), but now I tend to group pages in Galeon Windows on a task, character, and interest basis. As such I have a Galeon window each containing multiple TABs devoted only to pages which will require long term study research (typically online books), another to firewall research, another to IPSec, another to MUD-Dev, another to blogs, another to performance metrics, another to Kanga.Nu, another to temp/trash stuff...etc. > I'm just interested because that sort of approach doesn't seem > efficient to me at all. I suspect our work methods are not that different within a single given project. In any given contenxt I usually have little going on (a couple XEmacs frames, a few xterms, a browser or two, a couple supporting apps, and that's about it). The likely difference is that I maintain state and context for many projects and sub-projects as I go along, that I expect to keep them (and do) for variously long periods, that I fork such contexts regularly, and that I pop among them easily. I get a lot of startled looks from passersby. The ticket is not trying to work with them all at once, but building and storing work contexts such that they're easily context shiftable among. Easy support for mental context shifting is the basic assumption of this work method. My problem now, and my current big interest in XEMacs UI development, is seeing how I can shove that same work process down into editing sessions within XEmacs on a large project. Too often I get into a "What is this token and why is it being used quite like this?" research project, which of course recursively forks as I dig down into other identical researches on other tokens. I need a way to tag and lock context frames on those investigations so that I can later pop back to them, and then usefully pop about among them, possibly with a matching annotation system. Barry Warsaw's WinRing elisp looks very useful as a component for this, but I haven't settled on a basic approach yet. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. cl...@ka... He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. _______________________________________________ Gamedevlists-general mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-general _______________________________________________ Gamedevlists-general mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-general _______________________________________________ Gamedevlists-general mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-general |
|
From: J C L. <cl...@ka...> - 2001-12-24 03:19:03
|
On Sun, 23 Dec 2001 18:57:19 -0800 Brian Hook <bri...@py...> wrote: > At 06:41 PM 12/23/2001 -0800, J C Lawrence wrote: >> It is implicitly a subjective thing. > Bingo. There are sane and intelligent reasons that Windows and > Unix suck in different ways for different users. http://www.jwz.org/doc/linux.html http://catalog.com/hopkins/unix-haters/handbook.html > But there are a whole gamut of areas where you cannot objectively > point and say "This sucks in an absolute sense". This is the fine > line between intelligent discussion and flamefest. I would like to think that I've steered clear of those uglier bits, tho the discussion has become rather noisier than I'd like. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. cl...@ka... He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. |
|
From: Brian H. <bri...@py...> - 2001-12-24 03:26:06
|
At 07:19 PM 12/23/2001 -0800, J C Lawrence wrote: >I would like to think that I've steered clear of those uglier bits, >tho the discussion has become rather noisier than I'd like. Oh, absolutely, I didn't mean to imply that anyone had gone overboard. In fact, that's why I specifically stated that I think these types of discussions so far have been very good. The Windows/Unix argument isn't as interesting to me because, well, I've been through that enough for 10 years =) However, C++ vs. [insert alternative language here] debates are interesting to me since there are so many new languages that I have either no or minimal familiarity with that I stand to learn a lot. BETA, OCaml, Haskell, Dylan, Ruby, SmallTalk, Eiffel, Python, Lua, etc. all come under these classification. Brian |
|
From: Patrick M D. <pa...@wa...> - 2001-12-24 04:20:44
|
On Sun, 23 Dec 2001, Brian Hook wrote: > However, C++ vs. [insert alternative language here] debates are interesting > to me since there are so many new languages that I have either no or > minimal familiarity with that I stand to learn a lot. BETA, OCaml, > Haskell, Dylan, Ruby, SmallTalk, Eiffel, Python, Lua, etc. all come under > these classification. Perhaps it would be interesting to come up with a few small programs or algorithms and see how they are implemented in various languages. That might make learning these languages easier. Any thoughts? |
|
From: Brian H. <bri...@py...> - 2001-12-24 04:45:31
|
At 11:20 PM 12/23/2001 -0500, Patrick M Doane wrote: >Perhaps it would be interesting to come up with a few small programs or >algorithms and see how they are implemented in various languages. That >might make learning these languages easier. Any thoughts? Actually, that's been done before (sort of) in the Great Computer Language Shootout. A pretty nifty article that covers the performance aspects. The problem is that small programs don't tell you that much. You really need a large body of experience to give you the nitty gritty details about, say, the pros and cons of using Lisp vs. Lua vs. Ruby vs. Python for a game extension language. Very few people have the depth of experience in all three to make a real valid comparison. At a high level, there is C vs. C++ vs. Obj-C vs. Java vs. Eiffel, and once again a small program doesn't necessarily take into account. Just reading about Eiffel taught me a lot (both about it and C++), and it wasn't until I started getting into the grittier details that some of the warts started to show up. I still think it's a cool language, but for games specifically it may not be ideal (no real bit twiddling, no hex constants) without calling out to C/C++ constantly to do real work. The environments and libraries also have their own set of issues. And, of course, there are GUI tools, command line tools, text processors, etc. all of which can be implemented in many different appropriate languages. That's why listening to informed opinions is fascinating to me, and unfortunately real good comparisons are hard to come by. I'm still very impressed by Ian Joyner's relatively objective analysis of Java vs. C++ vs. Eiffel in "Objects Unencapsulated". There's another book I just ordered that talks about OOP in terms of C++, Obj-C, Object Pascal and, I believe, SmallTalk. Brian |
|
From: Patrick M D. <pa...@wa...> - 2001-12-24 05:20:24
|
On Sun, 23 Dec 2001, Brian Hook wrote: > At 11:20 PM 12/23/2001 -0500, Patrick M Doane wrote: > >Perhaps it would be interesting to come up with a few small programs or > >algorithms and see how they are implemented in various languages. That > >might make learning these languages easier. Any thoughts? > > Actually, that's been done before (sort of) in the Great Computer Language > Shootout. A pretty nifty article that covers the performance aspects. I was thinking more from the perspective of what might be useful to game developers. The programs in Doug's shootout are way too small. Here are some examples of the scope I was thinking about: - MUD server - ray tracer - AI algorithms, e.g: best paths, neural networks Some of these could obviously get complex, but there should be simple implementations to make all of these approachable. > The problem is that small programs don't tell you that much. Absolutely - that's why I was thinking of slightly more complicated examples. > At a high level, there is C vs. C++ vs. Obj-C vs. Java vs. Eiffel, and once > again a small program doesn't necessarily take into account. I'm not sure I understand what you're saying here. > Just reading about Eiffel taught me a lot (both about it and C++), and > it wasn't until I started getting into the grittier details that some > of the warts started to show up. I still think it's a cool language, > but for games specifically it may not be ideal (no real bit twiddling, > no hex constants) without calling out to C/C++ constantly to do real > work. The environments and libraries also have their own set of > issues. If issues like bit-twiddling and hex constants are keeping you from using Eiffel, then use a preprocessor to begin with, and if these functions still seem very important, extending the language should be easy enough. Environments and libraries are a little harder to deal with of course. > That's why listening to informed opinions is fascinating to me, and > unfortunately real good comparisons are hard to come by. I'm still very > impressed by Ian Joyner's relatively objective analysis of Java vs. C++ vs. > Eiffel in "Objects Unencapsulated". There's another book I just ordered > that talks about OOP in terms of C++, Obj-C, Object Pascal and, I believe, > SmallTalk. You also might find "A Theory of Objects" by Abadi & Cardelli to be interesting. The first 5 chapters review object oriented features and do a good job of separating concepts like inheritance and subsumption. The authors are also very aware of the wide variety of OOP languages that exist -- at least 20 different programming languages are explicitly mentioned in the text. Note that the majority of the book focuses on developing a theory of objects that could serve as a foundation for all OOP languages. In effect, they are trying to establish what lambda calculus did for procedural languages. So, I would really only recommend reading it if you are interested in learning more about progamming language theory. Patrick |
|
From: Brian H. <bri...@py...> - 2001-12-24 05:45:03
|
At 12:20 AM 12/24/2001 -0500, Patrick M Doane wrote: >I was thinking more from the perspective of what might be useful to game >developers. The programs in Doug's shootout are way too small. Here are >some examples of the scope I was thinking about: > > - MUD server > - ray tracer > - AI algorithms, e.g: best paths, neural networks Those would be good samples, and I'm pretty certain that there are MUD servers written in about every language imaginable we could probably at least look at. I know there's at least one prototype MUD server written in Lua, called Lune. Pretty clean code. > > At a high level, there is C vs. C++ vs. Obj-C vs. Java vs. Eiffel, and once > > again a small program doesn't necessarily take into account. > >I'm not sure I understand what you're saying here. Sorry, half-finished though. Basically, I was trying to say "a small program doesn't necessarily take into account the complexities of building a larger system". Yeah, duh =) >If issues like bit-twiddling and hex constants are keeping you from using >Eiffel, then use a preprocessor to begin with, and if these functions >still seem very important, extending the language should be easy >enough. Well, language designers have (theoretically) spent far more time thinking about language issues than I have. When I go in and start dicking with a language by extending it, then I've probably already entered the domain of diminishing returns. Although I'm sorely tempted to hack my Lua distribution to support '//' style comments instead of the Eiffel like '--' comments. =) I'd like to avoid a preprocessor as much as possible, but I'm still baffled why modern language designers adamantly refuse to put in block comments. Eiffel lacks block comments, so special preprocessors have to be written (gepp?) to support #if 0/#endif mechanisms. Same problem applies to Lua. Just wish people would make it a part of the language proper and save us headaches in the real world. GOBO is strewn with #ifdefs to make it work with the various Eiffel implementations, unfortunately they had to do their own #ifdef architecture IIRC. >Environments and libraries are a little harder to deal with of course. Yes, as are other things like language integration and extension. For example, Lua just drops in beautifully. It's amazingly easy to integrate into a C program as an extension language, and this is something you only learn through experience. You can read the language spec to understand the language's coolness, but it takes doing it to learn the nice parts of implementation with the language. License issues can be a potential gotcha -- things would look radically different if many languages were GPLed (or if their libs were). Brian |
|
From: Idahosa E. <ida...@sw...> - 2001-12-24 15:12:39
|
You tried that under like windows? Like 95? Maybe NT would give bette=
r
results? Or not, who cares use UNIX...
-----Original Message-----
=46rom: gam...@li...
[mailto:gam...@li...]On Behalf Of=
J
C Lawrence
Sent: Sunday, December 23, 2001 8:41 PM
To: ph...@me...
Cc: gam...@li...
Subject: Re: [GD-General] Eiffel
On Sun, 23 Dec 2001 11:06:55 -0000
Philip Harris <ph...@me...> wrote:
> That's a great list of problems with Windows but the majority if
> not all of them only apply to 99.99% of users.
I'm fairly sure that's not what you meant.
> The fact that the kernel is untrustable and that is has an
> incomplete syscall interface makes no difference to my
> productivity and I spend roughly 75% of my time developing
> software.
<shrug> It depends on what you do. What I don't have is a single
point, which if fixed, would instantly make everything better. It
seems to be endemic. Or more castigatingly, Windows seems to be
designed to make working in the manner I consider efficient and
effective deliberately difficult, so I don't.
Small trivial example, which is rather outside of my GUI preferences
(eg no icons). My typical idle state has ~20 windows on my desktop.
When actively working that tends to rise quickly to 50+ with values
close to 100 not being unseen. This is a side effect of a way of
working that I find very easy and efficient (and is FWVLIW what
initially drive me to Software Carousel from DOS, and thence to
DesqView, and thence to OS/2 and thence to the *nix world). Its
also a work approach which Windows suffers under (eg I currently
have (counting) 28 browser windows open, 9 xterms, 18 XEmacs frames,
and 15 other odd/assorted applications). This is work method, which
is in itself a tool, is something that my current toolset and
environment handles trivially. I've attempted a couple times to
transplant it to Windows ('92, '95, and '99) to transplant that to
Windows, each time with glaring lack of success (much of which was
my fault).
Wander about the shorts (variously old) at for an idea:
ftp://ftp.kanga.nu/pub/users/claw/screenshots/Desktop/
>> and ease of building new tools. We're engineers -- that's what
>> we do: build and use tools. Windows tends to assume
> That's not how I see it at all, yes we use tools, we probably
> build our own tools as well, but they are just tools. What matters
> is the results, specifically are they the results our customers
> want.
Yup. In the end we solve problems. There's a logical sequence
there starting with solving problems, then solving problems with
tools, then solving problems with tools we build and use, etc. It
all rests on solving a problem with the latter step defining the job
of an engineer. I skipped the lower foundations as assumable.
> I really don't care whether the cabinet maker has his own tools
> are simply uses his teeth, all I'm interested in is whether the
> cabinets are good and can he deliver what I've ordered when he
> says.
Bingo.
> Now if Windows actually stops you producing those results then
> that's a problem but for the majority of people that is not going
> to be the case.
Hehn. Not a question of stopping, but a question of difficulty
versus reward for the sorts of problems I consider interesting for
me to solve. Within that space Windows doesn't win, and most
specifically, seems to enforce unacceptable contortions without
delivering any increased productivity, value, insight,
effectiveness, or anything else of value (to me) for the trouble.
Yes, I can build a cabinet, yes I can build a cabinet with someone
else's tools, and yes I can build a cabinet with my own selection
and preference in tools. Guess which set I'll be most effective,
productive, and efficient with? Guess which set will distract me
least from the problem I'm actually working on? Guess which set I'd
prefer to work with?
> The work I do (and I'm sure this applies to a lot of people, even
> if you aren=92t one of them) the vast majority of my time is
> centered around solving a problem.
<nod>
> At the moment it's behaviour AI and the solution does not depend
> on Windows and Windows has no effect on how efficiently I solve
> that problem.
Good design can be implemented anywhere. Every platform at the
implementation level comes with certain compromises, usually labeled
under "architectual model" such as thread models, IPC models, memory
models, RPC models, VM models, etc. 90+% of my code and designs
could be fairly easily implemented under Plan9, *nix, Windows,
VAX/VMS, or OS9 (the rest being designed against a given platforms
intricacies). Efficiency of the implementation is not in question.
Efficiency in _producing_ the final implementation is in question.
> Nor do the tools for that matter, C++ affects the implementation
> but actually solving the problem and getting the behaviour I want
> has nothing to do with OS or language or tools or RFC compliance.
Precisely. Ignoring the fact that I tend to work in arenas where
RFC compliance is significant (ie multi-system and 'net related
stuff), the *ability* of an arbitrary OS to support or implement the
solutions I render is not in question, nor is the ability of the OS
to do such a thing efficiently. My point rests solely on my
efficiency in producing those solutions -- an efficiency which I'm
paid for.
> I'm guessing that you do a lot of UNIX system level type stuff in
> which case Windows isn't going to provide what your looking for
> but then it isn't supposed to.
I do a fair bit of systems work. Most of what I do sits between the
upper levels of the kernel and the lower levels of applications. As
such I dally just above hardware drivers and skulk just under
user-application logic the majority of the time. Not quite
middleware, as I don't tend to get involved in middleware rules and
logics. I guess a lot of it would end up being called, "system
infrastructure", "libraries", "integration protocols" and the like.
> But that doesn't make Windows "excessively difficult to be
> productive under".
There's an implicit phrase there of, "for me and what I do." I've
not said that the same evaluation applies to everyone, as it
manifestly doesn't.
Requoting my initial statement:
I won't work under Windows. Not worth my time. Not worth my
employer's time. Can't see a reason to bother. Not a religious
thing -- its just an environment which I consider and find
excessively difficult to be productive under, and without any
return value for that difficulty.
It is implicitly a subjective thing.
--
J C Lawrence
---------(*) Satan, oscillate my metallic sonatas.
cl...@ka... He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
|
|
From: Brian S. <bs...@mi...> - 2001-12-24 18:55:03
|
Additionally, I think it's funny how most people who dislike STL say = that it's "too hard to debug". =20 I've often thought that you could take Elisabeth Kubler-Ross' five = stages of dying (denial, anger, bargaining, depression, and acceptance) = and map it pretty well to process of learning the STL. The earliest is = denial - the idea that the problem lies within STL rather than your own = code. =20 In the early stages, everyone gets bit by some aspect of STL. Example: = erasing items from containers can invalidate iterators. Let's say you = make that mistake. So you spend time trolling through obfuscated = template code trying to figure out what stupid mistake was made in the = STL, because God knows there's no bugs in your code. After you figure = out the problem, you might read the documentation and find that the = container is behaving exactly as advertised. =20 Or you might decide that you've had it at that point. I suspect that's = where a lot of people bail out. But the notion that the STL needs much debugging, or any really, is a = fallacy in my opinion. It can be hard to look at the code and figure = out what you're doing wrong, but I've never seen anyone in the denial = stage actually find a bug in it. --brian (not on the VC++ team, have never met Plauger, and am in no way = defending his coding style) -----Original Message----- From: Kent Quirk [mailto:ken...@co...] Sent: Mon 12/24/2001 8:15 AM To: Brian Hook Cc: gam...@li... Subject: Re: [GD-General] Eiffel I *really* have to disagree here.=20 The DESIGN of the STL is absolutely gorgeous. I have never seen another container library that has such a neat separation of containers, iterators, algorithms, and data. The more I use the STL the more I love its design.=20 Yes, there are warts on the usage of the STL that mostly come from limitations in C++. Plauger's implementation (for Microsoft) is appalling in its use of (nearly) obfuscated variable names, etc. But I have found that idiomatic use of the STL drastically reduces both the amount of code I have to write and the number of errors I make in that code. One of my frustrations with Java is the lack of ability to write anything like the STL in it. It's a frustration because I otherwise like it a great deal. STLPort fixes a lot of the problems with MS's version, btw, though it's still not perfect. Kent Brian Hook wrote: >=20 > At 10:08 AM 12/21/2001 -0500, Thatcher Ulrich wrote: > >but IMHO the STL stinks as far as usability goes. >=20 > THANK you for saying that. I'm so tired of people going on and on = about > how great STL is (it's probably the #1 validation of C++ and templates = I've > seen), when in fact IT'S NOT THAT GOOD. It's convoluted, difficult to > debug, has bizarre syntax, takes forever to compile, generates tons of > warnings, requires third party implementations for stability. The = only > reason people dig on it is that they didn't have to write it. >=20 > Someone should sift through the STL source code some time then come = back > and tell me it's GOOD. >=20 > The primary advantage is that if you need a List or a Map you can just = use > STL without having to reroll it, but since I have that stuff lying = around > anyway, it doesn't bother me. --=20 ----------------------------------------------------------------------- Kent Quirk | MindRover: "Astonishingly creative." Game Architect | Check it out! ken...@co... | http://www.mindrover.com/ _____________________________|_________________________________________ _______________________________________________ Gamedevlists-general mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-general |
|
From: Brian H. <bri...@py...> - 2001-12-24 19:14:05
|
> Behalf Of Brian Sharon > Additionally, I think it's funny how most people who dislike > STL say that it's "too hard to debug". A well designed class library and API provides assertion mechanisms to help users detect their own errors. By that logic, DX or Win32 shouldn't return error codes, because hey, it's the user's bugs that are causing the problems. To which I say, "Duh" =) But a key part of ANY reusable code is making sure that it provides competent debugging assistance. ESPECIALLY when that API is difficult to grasp initially. > The earliest is denial - the idea that the problem > lies within STL rather than your own code. No, I would just like it if I knew what I did wrong when everything explodes, instead of being stuck looking at some variable like "___p". > In the early stages, everyone gets bit by some aspect of STL. Which is a pretty strong indicator that STL could use some tightening up in its design or, alternatively, that implementation should provide basic pre and post-condition checking. DirectX provides this, one of the areas I think it does a better job than OpenGL. > But the notion that the STL needs much debugging, or any > really, is a fallacy in my opinion. You just spent an e-mail discussing how "everyone gets bit by some aspect of STL" then go on to say that the STL needs much debugging is a fallacy? > It can be hard to look > at the code and figure out what you're doing wrong, but I've > never seen anyone in the denial stage actually find a bug in it. My mistake. I said "STL was difficult to debug" when, in fact, I meant "debugging STL programs is difficult". Subtle but important distinction. As a professional software developer for many years now, I'm well aware most problems I encounter are self-inflicted =) But part of software engineering is finding tools that help the programmer find and fix what is now trendily called "software defects". Just dumping that onus on the programmer rather flies in the face of what many in the software engineering world are trying to push -- better software through better tools and development methodologies, instead of relying entirely on programmer studliness. Brian |
|
From: Brian H. <bri...@py...> - 2001-12-24 19:20:13
|
> Obviously your approach works very well for you. Do you know > of other people who work the same way? Tons. TONS. Back when I was in college, I religiously used Unix and tvtwm. The idea of using anything other than Emacs, focus-follows-mouse, tcsh and a virtual desktop manager was mind bogglingly hideous to me. I couldn't imagine how others that needed to get work done could possibly survive in a Windows environment. Of course, I got over that =) Now I realize that when doing what is fundamentally text editing that I can survive in just about any environment because the real work is between my ears, not at my fingertips. My earlier argument for better environments isn't so much about getting better, monolithic text editing environments, but eschewing text editing as the fundamental interface we do things. If programming ends up being nothing but generating syntax for a set of external tools, then using Emacs or MSDEV shouldn't matter, it's just a personal choice. I just think that the next logical step is to have tools that are fully integrated and look at things as classes, hierarchies, interfaces, etc. instead of whitespace and keywords and identifiers and files. The one user-interface concession I still won't make is the placement of control key. I just purchased a nextstep ADB keyboard for my PowerMac simply because I get CTS if the control key is located in the standard position. Brian |
|
From: J C L. <cl...@ka...> - 2001-12-21 01:41:05
|
On Thu, 20 Dec 2001 16:57:37 -0800 Brian Hook <bri...@py...> wrote: >> At my last job (yeah, I'm hunting) the tool chain was Windows >> only so until we got everything running under WINE under Linux >> (which ran it faster than native Windows on the same box) I did >> all my compiles under SSH to a Windows box. Worked fairly nicely >> too. > So I'm assuming you don't pursue jobs where you're required to use > their tool chain, no exceptions? Depends on what you mean by toolchain. Compilers, linkers, etc -- things that actually produce the product they're paying me for -- that's the employer's purview and is part of the product definition. Toolchains in terms of editors, tools, systems, etc, has nothing to do with my employer (tho maybe something to do with IS). Then again, I don't think I've seen a company that asked let alone required their employees to all use the same editor/tool/system etc since 1988 (I hear they still exist) -- well, not outside places like Sun/SGI/HP asking you to use Solaris/IRIX/HP-UX as the base OS (ie eat your own dogfood -- and they didn't insist and made no mention as to what you ran atop that). They just want to know that what you produce works in the product and can be worked with by everyone else in the team/group. > I've actually interviewed people before that said they wouldn't, > for example, use Windows (or give up Emacs...or use Visual Source > Safe..or conform to other people's coding styles). I won't work under Windows. Not worth my time. Not worth my employer's time. Can't see a reason to bother. Not a religious thing -- its just an environment which I consider and find excessively difficult to be productive under, and without any return value for that difficulty. Much like a carpenter or mechanic brings his own tools with him to the job, I bring my own tools with me to my job as a developer. What I will do is adapt/conform on my interfaces to the rest of the company and the people and systems I work with. If there are shared/communal systems/approaches which are required, that's not a problem. I'll plug into their source control system, their coding styles, their shared file systems, etc. No problem. If the local coding is too much of a pain and difficult for me to read/work with, well, then that's what software is for; it covers up the gaps and handles the translations (wrap a copy of indent around the check-in process). ObNote: Most of the better shops I've been at have adopted the coding format of: -- Everything within a given file must use the same style. If you edit a file, copy what's there. -- Everything within a directory/module should use the same style. If you add a file, copy what's there already. -- If you do something new, write your own module ets, use whatever you want so long as its consistent. -- We like it if you use JavaDoc or (insert comment documentation system). This is especially nice when they also embed the coding style in a modeline comment so that your editor can pickup and reconfigure itself for the local style transparently as you enter each file. > There's nothing wrong with that, mind you, so long as you're in a > position to make those demands. I suspect this is a demographic difference between Windows and *nix oriented shops. I hear/read about Windows shops attempting to dictate use of developer tools like editors, IDEs, and the like. I just haven't seen or heard that in any world I work in for a very long time (and have a hard time understanding why they'd bother). -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. cl...@ka... He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. |
|
From: Philip H. <ph...@me...> - 2001-12-21 23:32:20
|
> I won't work under Windows. Not worth my time. Not worth my > employer's time. Can't see a reason to bother. Not a > religious thing -- its just an environment which I consider > and find excessively difficult to be productive under, and > without any return value for that difficulty. Interesting, what in particular do you find so massively inefficienr? Phil |
|
From: J C L. <cl...@ka...> - 2001-12-22 20:16:39
|
On Fri, 21 Dec 2001 15:42:49 -0800 Brian Hook <bri...@py...> wrote: > ...1600x1024 resolution, etc. Which is getting pretty mid-range these days. I've been running 1920x1440 for the last couple years on a Matrox G200, and its pretty trivial to get 2048x1536 or larger with more modern cards (the G200 was discontinued a year or more ago). -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. cl...@ka... He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. |
|
From: J C L. <cl...@ka...> - 2001-12-24 06:29:22
|
On Sun, 23 Dec 2001 20:45:08 -0800 Brian Hook <bri...@py...> wrote: > That's why listening to informed opinions is fascinating to me, > and unfortunately real good comparisons are hard to come by. I'm > still very impressed by Ian Joyner's relatively objective analysis > of Java vs. C++ vs. Eiffel in "Objects Unencapsulated". There's > another book I just ordered that talks about OOP in terms of C++, > Obj-C, Object Pascal and, I believe, SmallTalk. I presume you're familiar with LambdaTheUltimate then. http://lambda.weblogs.com/ -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. cl...@ka... He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. |
|
From: J C L. <cl...@ka...> - 2001-12-24 20:36:45
|
On Mon, 24 Dec 2001 11:20:18 -0800 Brian Hook <bri...@py...> wrote: > The one user-interface concession I still won't make is the > placement of control key. I just purchased a nextstep ADB > keyboard for my PowerMac simply because I get CTS if the control > key is located in the standard position. Oddly enough I refuse to work on anything but buckling spring keyboards (with IBM Model M preferred in particular). So, I bring one with me to every job. Happily they are cheap and readily available at second hand stores. For those not in the know, The Model M was the standard keyboard on IBM PS/2 systems. Its mostly known for having a 5lb metal plate in the bottom, and a loud clacky noise when used. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. cl...@ka... He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. |
|
From: J C L. <cl...@ka...> - 2001-12-24 20:45:24
|
On Mon, 24 Dec 2001 11:20:18 -0800 Brian Hook <bri...@py...> wrote: >> Obviously your approach works very well for you. Do you know of >> other people who work the same way? > Tons. TONS. > Back when I was in college, I religiously used Unix and tvtwm. > The idea of using anything other than Emacs, focus-follows-mouse, > tcsh and a virtual desktop manager was mind bogglingly hideous to > me. I couldn't imagine how others that needed to get work done > could possibly survive in a Windows environment. > Of course, I got over that =) > Now I realize that when doing what is fundamentally text editing > that I can survive in just about any environment because the real > work is between my ears, not at my fingertips. Part of the deal for me is attempting to export as much as I can of that gooey stuff between my ears out onto the screen. I try to build an interface that my mind automatically reacts to by adopting the appropriate context, frameset, set of recollections, etc just upon seeing in. The, "Oh yeah, I was ... and now lets see where that lead..." ideally needs to happen in less than a second after I switch contexts. > My earlier argument for better environments isn't so much about > getting better, monolithic text editing environments, but > eschewing text editing as the fundamental interface we do things. In contrast I tend to devolve everything to text. Its more data dense at the human UI level. > I just think that the next logical step is to have tools that are > fully integrated and look at things as classes, hierarchies, > interfaces, etc. instead of whitespace and keywords and > identifiers and files. Fair dinkum, and I'd probably use and like them if they weren't monolithic, could be easily disassembled and rebuilt/replugged in personally suiting patterns, etc. One of the basic bits about the MS approach to development which bugs me is that assumption that you're going to use the MS tools everywhere. Why can't I rip out the MS editor and replace it transparently with MultiEdit, QEditPro, SlickEdit, XEMacs, or something else? (Apocryphal question) Why isn't the system built with cleanly drawn interfaces so I can rip out and replace any other component as well, replacing the compiler, replacing the debugger, replacing the linker, replacing the tag tracking system, etc. Components and interfaces damnit. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. cl...@ka... He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. |
|
From: Brian S. <bs...@mi...> - 2001-12-24 20:50:53
|
> You just spent an e-mail discussing how "everyone gets bit by some > aspect of STL" then go on to say that the STL needs much debugging is = a > fallacy? Near the end of your email, I think you made the right distinction = between debugging STL (which I'm arguing is a distraction at best) and = debuggable STL programs (which no one in their right mind is against). So - given that I was talking about debugging STL in that bit you = excerpted - what's the contradiction? Anyone can get bit by a thing = they didn't expect in a library or language they're unfamiliar with. I = can certainly remember vividly the first time I learned about C struct = packing, and when I discovered that I couldn't free() something twice. = It's just that competent people - what I assume we all are - don't KEEP = getting bit by these things, repeatedly, daily. Once you spend a few = hours debugging your early programs, those lessons are deeply ingrained. = So since I never free things twice any longer, does that mean free() is = badly designed? I would argue my expectations were badly formed. Does that mean I'm saying we should just count on studly programmers to = fix all their bugs alone? Hell no, no way, never. We all have enough = sense to run things like debug heaps to catch memory leaks, even though = we know what causes memory leaks and theoretically should never let one = come into a program. After all, none of us are programming = theoretically - we're out in the real world where people do make = mistakes. For STL, the STLPort implementation (http://www.stlport.org) = has a debugging mode that catches lots of misuses, and if you're looking = for a version with iterators that will slap you cross the face and say = in a Mr. T voice, "I pity the fool who uses this invalid iterator", = that's your baby. But you can't argue that STL is badly designed = because Plauger's implementation does no input validation or debug = checking. You might be able to argue it from other standpoints, but not = from that one. The good thing is that awareness that most of your problems are = self-inflicted means you're beyond the denial stage...next stop anger :) --brian p.s. sorry if I got anyone's hopes up too high, the STLPort iterators do = NOT actually use Mr. T voices. -----Original Message----- From: Brian Hook [mailto:bri...@py...] Sent: Mon 12/24/2001 11:14 AM To: gam...@li... Cc:=09 Subject: RE: [GD-General] Eiffel > Behalf Of Brian Sharon =20 > Additionally, I think it's funny how most people who dislike=20 > STL say that it's "too hard to debug". =20 A well designed class library and API provides assertion mechanisms to help users detect their own errors. By that logic, DX or Win32 shouldn't return error codes, because hey, it's the user's bugs that are causing the problems. To which I say, "Duh" =3D) But a key part of ANY reusable code is = making sure that it provides competent debugging assistance. ESPECIALLY when that API is difficult to grasp initially. > The earliest is denial - the idea that the problem=20 > lies within STL rather than your own code. =20 No, I would just like it if I knew what I did wrong when everything explodes, instead of being stuck looking at some variable like "___p". =20 > In the early stages, everyone gets bit by some aspect of STL.=20 Which is a pretty strong indicator that STL could use some tightening up in its design or, alternatively, that implementation should provide basic pre and post-condition checking. DirectX provides this, one of the areas I think it does a better job than OpenGL. > But the notion that the STL needs much debugging, or any=20 > really, is a fallacy in my opinion. You just spent an e-mail discussing how "everyone gets bit by some aspect of STL" then go on to say that the STL needs much debugging is a fallacy? > It can be hard to look=20 > at the code and figure out what you're doing wrong, but I've=20 > never seen anyone in the denial stage actually find a bug in it. My mistake. I said "STL was difficult to debug" when, in fact, I meant "debugging STL programs is difficult". Subtle but important distinction. As a professional software developer for many years now, I'm well aware most problems I encounter are self-inflicted =3D) But = part of software engineering is finding tools that help the programmer find and fix what is now trendily called "software defects". Just dumping that onus on the programmer rather flies in the face of what many in the software engineering world are trying to push -- better software through better tools and development methodologies, instead of relying entirely on programmer studliness. Brian _______________________________________________ Gamedevlists-general mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-general |
|
From: Brian H. <bri...@py...> - 2001-12-24 20:58:51
|
> Near the end of your email, I think you made the right > distinction between debugging STL (which I'm arguing is a > distraction at best) More generally, debugging a third party set of reusable code should be a distraction at best. > So - given that I was talking about debugging STL in that bit > you excerpted - what's the contradiction? It seemed to me that the bulk of your e-mail was raging against the notion of "debugging STL", I was merely stating that no one said as much (i.e. my complaints were on the "debuggability of programs that use STL"). > lessons are deeply ingrained. So since I never free things > twice any longer, does that mean free() is badly designed? Yes, in fact, it does. The CRTL is not what I consider an example of good library design. A library that allows, for lack of a better phrase, "intuitive but incorrect usage", is probably poorly implemented (maybe not designed, but once again, I'm not against STL's design -- I haven't used it enough to really judge -- but I am against the implementations). > that's your baby. But you can't argue that STL is badly > designed because Plauger's implementation does no input > validation or debug checking. You might be able to argue it > from other standpoints, but not from that one. Which is good, because I don't think that's what I said =) > p.s. sorry if I got anyone's hopes up too high, the STLPort > iterators do NOT actually use Mr. T voices. Well crap, I guess I'm cancelling that download now. Brian |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X