Thread: Re: [GD-General] Eiffel
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-general
|
From: J C L. <cl...@ka...> - 2001-12-20 01:01:09
|
On Wed, 19 Dec 2001 16:13:35 -0800 Brian Hook <bri...@py...> wrote: > The common complaint against this is that people wedded to Emacs, > make, grep, perl, etc. will find themselves at the mercy of > whatever environment is provided. I don't have a problem with > this -- I'm completely comfortable in MSDEV, ProjectBuilder, etc. > I can make them do what I need them to do, warts and all. But I > do at least understand their concerns, even if I do find them > misguided =) Its the same argument that surrounds unified APIs versus atomic approaches. Some swear by unified APIs. Some swear at them. Some grumble, and write atomic wrappers atop the unified API so they have a system they feel they can work with. Others grumble and write unified APIs to wrap atomic function sets. Its about levels of and tolerance for abstraction. <<And yes, there have been Smalltalk-like modes for (X)Emacs as well as having XEmacs integrated/embedded as an editor within Smalltalk IDEs, but I'll leave that for another to post>> -- 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-20 18:51:22
|
> But I've jumped on the flavor-of-the-month before (Icon, > Smalltalk...got into C++ in 1988, which was at least 5 years > too early, maybe 10...got into Java in 1995, which was again > too early...) and now I'm wary of language and development > platforms that don't have enough general interest to sustain > a business. I might even go back and look at Smalltalk again > -- there are some grownup versions of it around now. I think Eiffel is fairly mature -- there are multiple free and commercial compilers and environments for it. That was what made me more interested -- I managed to avoid C++ in the CFront days, but somehow managed to get sucked in with Borland's first offering. However, I'm finding that Eiffel does, in fact, have a couple warts. The biggest is that there is no single implementation that has the entire language implemented. Sound familiar? =) However, this seems to be a temporary problem and can be worked around. Hopefully it stabilizes relatively soon. The other big problem is that there's no STL that is part of the spec. Each vendor implements their own container class libraries. However, there is an open-source STL-like library called GOBO that is portable among all the variants out today. Amusingly enough, to accomplish this they required a preprocessor, gepp, that supports #if, #define, #undef, etc. So much for "get rid fo the preprocessor". > Whoever made the comment about "it's a poor workman who > blames his tools" -- there's a HUGE difference between > blaming your tools for poor results and wanting sharper > tools. Well said. > question to me has always been whether that productivity on > an individual workstation can translate effectively into > productivity for delivery of a shippable consumer product. I think so. My Cocoa/Obj-C experience, which I've harped upon now a zillion times, was an eye opener for how much better the process can be. And that was mostly by leveraging slightly better tools (IB), frameworks (Cocoa) and a language (Obj-C) -- ProjectBuilder isn't that good an IDE. > And just to get in my shot...to me, using emacs is like > asking for a car and being told "here's a pickup truck full > of spare parts -- if it doesn't meet your needs, you can take > it apart and rebuild it all by yourself!" I don't have time > for that much freedom. Oh crap, now you've done it. Brian "Curse you freedom, CURSE YOU!" Hook |
|
From: <phi...@pl...> - 2001-12-20 19:00:03
|
"Thatcher Ulrich" <tu...@tu...>: > If you just write everything in elisp, then you've already got this magical environment :) I'm not seriously saying that's the way to go (I'm not even thinking it this time :). There's a BIG PS2 game out at the moment that was written almost entirely in lisp, including the VU code. They wrote their own compiler, and apparently have the full rewrite-while-executing environment going as well. Cheers, Phil |
|
From: Thatcher U. <tu...@tu...> - 2001-12-21 00:21:37
|
On Dec 20, 2001 at 10:56 -0800, phi...@pl... wrote: > > There's a BIG PS2 game out at the moment that was written almost > entirely in lisp, including the VU code. They wrote their own > compiler, and apparently have the full rewrite-while-executing > environment going as well. Cool, I think I know the one you mean. I'd love to know more details... is there any public info about their environment? -- Thatcher Ulrich <tu...@tu...> http://tulrich.com |
|
From: <phi...@pl...> - 2001-12-20 23:16:57
|
J C Lawrence <cl...@ka...>: >Thatcher Ulrich <tu...@tu...> wrote: >> These days emacs knows a lot, straight out of the box. It knows >> about RCS and CVS, it knows how to indent and highlight various >> languages, how to run a build tool and bring you to the errors, >> how to run a source-level debugger, how to auto-complete. It's >> got rectangle modes, outline modes, text modes, spell checkers, >> yadda yadda. >FWLIW those things have been true for at least 6 years, and I think >closer to 8. At least 13. I used to live in emacs, read mail, news, code, debug, everything. > Conversely, my approach is to make the tools adapt to me. Which is fine, right up until the point where you have to some work on someone elses machine, or vice versa. Cheers, Phil |
|
From: J C L. <cl...@ka...> - 2001-12-20 23:39:51
|
On Thu, 20 Dec 2001 15:13:32 -0800 phil wilkins <phi...@pl...> wrote: > J C Lawrence <cl...@ka...>: >> Thatcher Ulrich <tu...@tu...> wrote: >>> These days emacs knows a lot, straight out of the box. It knows >>> about RCS and CVS, it knows how to indent and highlight various >>> languages, how to run a build tool and bring you to the errors, >>> how to run a source-level debugger, how to auto-complete. It's >>> got rectangle modes, outline modes, text modes, spell checkers, >>> yadda yadda. >> FWLIW those things have been true for at least 6 years, and I >> think closer to 8. > At least 13. I used to live in emacs, read mail, news, code, > debug, everything. Yup. I know most of it is close to 15 years old -- going back almost to the old TECO days. I thought some of the code highlighting and syntax detection and such was a bit younger tho. I'm pretty sure much of the more interesting ispell/aspell integration was only done around 5 or 6 years ago. <shrug> >> Conversely, my approach is to make the tools adapt to me. > Which is fine, right up until the point where you have to some > work on someone elses machine, or vice versa. I remember enough of the defaults to work on a base system, if somewhat haltingly. If I really have to work on another's system I bring over my environment (remember its under source control and accessible from anywhere, or I just SSH back to my own box). Then again, why would you ever have to work on someone else's machine? (Note: It hasn't happened to me for at least 3 years, probably longer) Given decent network transparent tools it almost never happens. About the only reason you should ever need to leave your own system (and thus stop your but growing that attractive secretarial spread) is if you need physical hardware access to the target box or something attached to it. You've got the network. Use it. SSH X11 forwarding and X11's native network transparency make this all particularly easy. If you want a bit more portability (and have a somewhat trusted network) use XDM chooser. Don't have to kick anybody off. Just run XDM on a couple of VTs letting the main user use the default and leaving :1 open for drop-ins. -- 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: <phi...@pl...> - 2001-12-21 00:07:01
|
J C Lawrence <cl...@ka...>: > Yup. I know most of it is close to 15 years old -- going back > almost to the old TECO days. I thought some of the code > highlighting and syntax detection and such was a bit younger tho. Possibly, I was using a dumb terminal at the time. The only colour being green. > I'm pretty sure much of the more interesting ispell/aspell > integration was only done around 5 or 6 years ago. I remember playing with ispell, but IIRC it was fairly flakey at the time. ... > Then again, why would you ever have to work on someone else's machine? Debugging code they haven't checked in yet. Tracking bugs that only manifest reliably on their system. Sporadic occurences of pair programming. It happens. > You've got the network. Use it. We have a windows network. Nuff said. Cheers, Phil |
|
From: J C L. <cl...@ka...> - 2001-12-21 00:51:38
|
On Thu, 20 Dec 2001 16:03:36 -0800 phil wilkins <phi...@pl...> wrote: > J C Lawrence <cl...@ka...>: >> Yup. I know most of it is close to 15 years old -- going back >> almost to the old TECO days. I thought some of the code >> highlighting and syntax detection and such was a bit younger tho. > Possibly, I was using a dumb terminal at the time. The only colour > being green. Amber! Amber! Green was for weenies...and don't get me started on white. >> Then again, why would you ever have to work on someone else's >> machine? > Debugging code they haven't checked in yet. Tracking bugs that > only manifest reliably on their system. Sporadic occurences of > pair programming. It happens. <shrug> In the old days I'd use ange-ftp (Emacs package to edit remote files, now replaced by TRAMP) and telnet/SSH for that sort of thing. Sit on your own machine, drive their machine. Now I use TRAMP and SSH/XDM etc to the same end. >> You've got the network. Use it. > We have a windows network. Nuff said. Ahh. I try to avoid those monstrosities. Happily Cygwin seems to do a moderately useful job of fixing them. You get bash, an SSH daemon, Xfree86, rxvt (xterm analogue), etc. 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. -- 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-21 00:20:20
|
> Hey Brian you're selling this pretty well. I'm about ready to > go out and buy a Mac. :) Seriously though if you're this > excited about something, and it's got Apple's full weight > behind it, I'd like to check it out, if for no other reason > than to have something to copy in my own designs. Go check out developer.apple.com for all the blurbs and background information on Cocoa and Obj-C. Pick up a book like "Learning Cocoa" or something similar. The book "Object Oriented Programming and the Objective-C Language" is a good place too, and I think it's in PDF form on their Web site. I'll warn you now though, you won't be able to copy much of the designs because much of Cocoa's power comes from the way IB, Cocoa and Obj-C interact, and Obj-C is just a radically different way of thinking than C++ (dynamic typing with optional static type checking). > How did you get into Cocoa/Obj-C and what tools do you need for it? I've been a NextStep fan boy for ages, but Cocoa was the first time I got to really use it. By the time I had the means and time to use NS, OpenStep was out and not very stable or fast on NT. Since our games are going to be running no a Mac, I had to buy a PowerMac anyway. Just for grins I loaded up PB and tried to write a little OpenGL visualization tool. With NO prior Cocoa/Obj-C programming experience, I got a fractal terrain generator visualization tool, with UI, working in about 6 hours. If I had to do it again, more like 45 minutes. I haven't had much time to mess with it anymore, but I plan on getting back into it on our later projects that will require tools. > to give any specifics? Or should I simply go to the Apple dev > site and read some glossies? :) Here's the best part -- the dev tools are FREE. ProjectBuilder, the compiler (gcc), Interface Builder, libs, everything are freely downloadable (and come with the OS X retail CDs, although not with OS X on pre-installed machines). It's a Better Way of Doing Things. Unfortunately, it's limited to OS X. Brian |
|
From: Brian H. <bri...@py...> - 2001-12-21 00:56:35
|
> analogue), etc. 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? 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). There's nothing wrong with that, mind you, so long as you're in a position to make those demands. Brian |
|
From: Jamie F. <ja...@qu...> - 2001-12-21 10:55:37
|
BION, we had one guy threaten to resign rather than use a tab length he was unfamiliar with. Funnily enough, he didn't stay long.... Jamie -----Original Message----- From: gam...@li... [mailto:gam...@li...]On Behalf Of Brian Hook Sent: 21 December 2001 00:58 To: gam...@li... Subject: RE: [GD-General] Eiffel > analogue), etc. 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? 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). There's nothing wrong with that, mind you, so long as you're in a position to make those demands. Brian _______________________________________________ Gamedevlists-general mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-general |
|
From: <phi...@pl...> - 2001-12-21 01:54:17
|
Not as far as I'm aware. I only mention it because I figure it's
interesting to know that that sort of thing is actually being done on high
profile titles.
"Thatcher Ulrich" <tu...@tu...>
Sent by: To:
gam...@li...urc gam...@li...
eforge.net cc:
Subject: Re: [GD-General] Eiffel
12/20/2001 04:23 PM
On Dec 20, 2001 at 10:56 -0800, phi...@pl... wrote:
>
> There's a BIG PS2 game out at the moment that was written almost
> entirely in lisp, including the VU code. They wrote their own
> compiler, and apparently have the full rewrite-while-executing
> environment going as well.
Cool, I think I know the one you mean. I'd love to know more
details... is there any public info about their environment?
--
Thatcher Ulrich <tu...@tu...>
http://tulrich.com
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
|
|
From: Thatcher U. <tu...@tu...> - 2001-12-21 19:38:32
|
> > There's a BIG PS2 game out at the moment that was written almost > > entirely in lisp, including the VU code. They wrote their own > > compiler, and apparently have the full rewrite-while-executing > > environment going as well. Here's some info re: the older Crash games (look under "GOOL" for the Lisp stuff): http://www.gamasutra.com/features/19991112/GavinWhite_03.htm -- Thatcher Ulrich <tu...@tu...> http://tulrich.com |
|
From: Sergei M. <se...@ha...> - 2001-12-22 13:13:31
|
Very interesting link, I'll even suggest to all the tech people here to take a look on it. These guys really push the limits of the hardware, as I read it and use rather sophisticated toolset for processing their data... and they are only 3-4 programmers! Reading that link arises some questions in my head, like: "My god, why creation of one damn game must be such trip into technical depths of the hardware and algorithmical complexities... Yes, I would enjoy it, but looking at it from a non-programmer point of view it seems as a lot of efford put into a single CD that bring to life one little orange dog... And what if these same guys worked over the cure for the cancer and don't spending their brainpower for people's entertainment ?". Maybe the answer is obvous, but I mean that the process of creating today's games evolved into a very complex challenge taking years. And for almost every single game that process is started from the scratch! (Although these same guys are one excellent example of reusing their previous work). It seems that in our world today one single piece of entertainment is fun when it is complex (besides Tetris maybe) - complex environment, compex level geometry, complex animations, textures and effects, complex behaviour, dialogues and storyline. Books, movies, games... I remember that eating mammoths and living in caves wasn't such bad at the end... :) ... (now I'm back to earth) Besides all the stuff they write (Naughty Dog's guys) I was excited to see a tool that rearanges the data to optimize data flow... Would any PC developer bother with that? These people use that because of inadequate hardware, but I havent't heard of PC developer to use such thing (I'll be happy if somebody prove that I'm wrong!) - maybe we trust too much in the OS features that lacks on consoles..? What do you think about that? From: "Thatcher Ulrich" <tu...@tu...> > > > There's a BIG PS2 game out at the moment that was written almost > > > entirely in lisp, including the VU code. They wrote their own > > > compiler, and apparently have the full rewrite-while-executing > > > environment going as well. > > Here's some info re: the older Crash games (look under "GOOL" for the > Lisp stuff): > > http://www.gamasutra.com/features/19991112/GavinWhite_03.htm > |
|
From: Paul B. <pa...@mi...> - 2001-12-21 15:50:40
|
> -----Original Message----- > From: Kent Quirk [mailto:ken...@co...]=20 > Subject: Re: [GD-General] Eiffel >=20 > I'd really like to find a language that makes more sense in a=20 > production environment than C++ or Java.=20 >=20 > C: "You can do whatever you want." > C++: "You can do whatever you want, if you can figure out how." > Java: "You can do whatever you want that's safe." > Perl: "You can do whatever you want any way you want, and=20 > preferably not > the same way twice." > Pascal: "You can't do anything." > Eiffel: "You can do whatever we want." > Python: "Whatever." >=20 > Any counterarguments? What does "Whatever." mean for Python? We use Python "in a production" environment all the time. We have about one or two dozen tools written in Python. =20 One thing that I see a lot is the attitude that "we use C++ for the engine, so I guess we gotta use it everywhere." I agree with one of Brian's original statements: if I never=20 have to write a tool in C++ again, I can die a happy man. I'm at the point where C++ just doesn't buy me anything for most of our toolset. =20 Our main uber editor is still C++, but that is for legacy=20 reasons. I am pretty sure UberEditor 2.x will not be C++. =20 More than likely it will either be C# or Python. Nothing other=20 than C++ or Perl really has the runtime/module support that we=20 would want. Perl is out because Perl source code looks like=20 dropped carrier garbage. Paul |
|
From: Brian H. <bri...@py...> - 2001-12-22 17:20:13
|
At 09:50 AM 12/21/2001 -0600, Paul Bleisch wrote: >One thing that I see a lot is the attitude that "we use C++ >for the engine, so I guess we gotta use it everywhere." I use C++ because the subset of the language I use is portable and will generate a binary on any platform I care to support. That's a pretty important consideration. Odder languages like Eiffel or Obj-C are a bit more problematic and may lack many of the ancillary tools that people find necessary for development. Another thing pushing me away from Eiffel is that I have a huge amount of code written in C++ that I don't feel like rewriting or bridging to. This is just inertia working against ostensibly better languages. And people write tools in what they feel is the most effective fashion possible. For many people, it's a huge assumption that it's faster to write a tool with C++ and MFC than it is to learn a new language/environment. Fair assumption, but in the case of Obj-C/Cocoa, dead wrong. I'm leaning back towards Obj-C for a server program I'm working on simply because the latest version of GCC supports Obj-C++, which allows me to use Obj-C for all my core stuff and still call out to my C++ frameworks for stuff I may need. Brian |
|
From: Brian H. <bri...@py...> - 2001-12-23 19:35:13
|
At 09:14 AM 12/22/2001 -0800, Brian Hook wrote: >Another thing pushing me away from Eiffel is that I have a huge amount of >code written in C++ that I don't feel like rewriting or bridging to. This >is just inertia working against ostensibly better languages. Oh, and I just found out that Eiffel doesn't support hexadecimal constants because they're "not portable". That brought my interest to a screeching halt. Brian |
|
From: Philip H. <ph...@me...> - 2001-12-23 11:01:25
|
> Unusable UI (just try getting a decent window manager/GUI on > Windows...), excessive difficulty or inability to=20 > tailor/replace to personal preferences (eg I don't allow=20 > icons on any system I run), poor process model (eg no=20 > UI-exposed generic process IPC/sequencing ala forks/pipes),=20 > unusable shell (even Cygwin's bash is crippled), CLI opaque,=20 > single-user, intransigent authentication schema, poor interop=20 > and integration with foreign systems (eg NFS, AFS, LDAP,=20 > Kerberos, PAM, etc), fundamentally broken SMTP support (list=20 > owner beef), interop unfriendly internal security semantics=20 > (eg ACLs on dirs not files), end results of=20 > embrace-and-extend run rampant, incompleat syscall interface,=20 > broken/unreliable POSIX supports, consistent and uneditable=20 > RFC violations, network opaque at the host and GUI and=20 > application level, poor tools (that (X)Emacs even runs is a=20 > miracle), untrustable kernel, difficult and unfriendly to=20 > automation, monolithic unified opaque API interfaces, code=20 > porting unfriendly, resource consumptive, operation requires=20 > you to put your body in front of the machine (side effect of=20 > being network opaque), consistent assumption that the user=20 > will work and operate in the manner and with approaches=20 > envisioned by MS (I don't). That's a great list of problems with Windows but the majority if not all of them only apply to 99.99% of users. 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. > and ease of building new tools. We're engineers -- that's > what we do: build and use tools. Windows tends to assume=20 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. 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. 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. 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. 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. 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. Once I have the solution I'm going to sit down with my editor and write some code. Windows still isn't going to get in the way. If I was using Emacs under UNIX the process would be virtually the same. 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. But that doesn't make Windows "excessively difficult to be productive under". Phil |
|
From: Brian H. <bri...@py...> - 2001-12-24 02:57:38
|
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. 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. >>> Intelligent discussion A. Unix provides me many more options when it comes to configuring and maintaining my tool set. >>> Entering danger zone, but still okay B. Windows just isn't a productive work environment [for me]. I'm far more productive, and everyone else I know, are far more productive in the Unix environment because we have it configured to increase our workflow tremendously. [Note: the danger here is because there is an implicit 'and everyone else using Windows isn't as productive' in there that often gets initial feathers ruffled]. >>> Flame fest! C. So all you Windows people are small minded idiots that don't have the ability to manage a real operating system. I have no idea how anyone gets Windows to work in the first place. Back to my musical instrument analogies, it's a lot like Fender vs. Gibson. Different instruments with different characters, but "better" would be entirely determined by your own personal criteria. Windows is a "better" environment than Unix for many different reasons, but many of which won't be valid for everyone. Brian |
|
From: J C L. <cl...@ka...> - 2001-12-24 02:41:21
|
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 arent 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.
|
|
From: Philip H. <ph...@me...> - 2001-12-24 11:46:32
|
> > 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. :-) Well, at least someone's sure. > 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 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. It's interesting (at least to me) that you find that sort of environment so efficient. 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... > 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. Obviously your approach works very well for you. Do you know of other people who work the same way? Is it an apporach you've been using a long time or it still evolving? Note, I'm not suggesting that Windows is the magic efficiency bullet, or that you should even consider using it. I'm just interested because that sort of approach doesn't seem efficient to me at all. Phil |
|
From: J C L. <cl...@ka...> - 2001-12-22 20:46:54
|
On Fri, 21 Dec 2001 23:37:38 -0000 Philip Harris <ph...@me...> wrote: >> 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? Unusable UI (just try getting a decent window manager/GUI on Windows...), excessive difficulty or inability to tailor/replace to personal preferences (eg I don't allow icons on any system I run), poor process model (eg no UI-exposed generic process IPC/sequencing ala forks/pipes), unusable shell (even Cygwin's bash is crippled), CLI opaque, single-user, intransigent authentication schema, poor interop and integration with foreign systems (eg NFS, AFS, LDAP, Kerberos, PAM, etc), fundamentally broken SMTP support (list owner beef), interop unfriendly internal security semantics (eg ACLs on dirs not files), end results of embrace-and-extend run rampant, incompleat syscall interface, broken/unreliable POSIX supports, consistent and uneditable RFC violations, network opaque at the host and GUI and application level, poor tools (that (X)Emacs even runs is a miracle), untrustable kernel, difficult and unfriendly to automation, monolithic unified opaque API interfaces, code porting unfriendly, resource consumptive, operation requires you to put your body in front of the machine (side effect of being network opaque), consistent assumption that the user will work and operate in the manner and with approaches envisioned by MS (I don't). A computer, and especially an OS is a tool. Somewhere that got lost, especially from an engineering viewpoint. More exactly it is a collection of tools and the capability and ease of building new tools. We're engineers -- that's what we do: build and use tools. Windows tends to assume that it is the tool, singular. I don't want a single tool -- that's a useless Swiss army knife that does nothing well. What I do want is a well built easily operated tool box which makes it as easy if not easier to create and use new tools as it is to use tools already in the box -- and specifically one where the tool box is itself one of those tools and is just as easily changed/replaced/rebuilt as an other tool in the box. If what I do is to build and use tools, surely my tools should support those activities? Go into any good cabinet maker and you'll find that a large percentage of the tools were built right there by the cabinet maker for himself. Ditto for a tool and die maker. Even ditto for the North Sea fisherman I worked with as a lad, or the sailors crewing the yachts in the harbour. Trying to leverage that (to me obvious and how-could-you-do-otherwise) approach on Windows (when I've tried or watched others try) has always been a recipe for disaster and pain. -- 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:29:09
|
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. |
|
From: Jamie F. <ja...@qu...> - 2002-01-02 14:56:30
|
<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 |
|
From: J C L. <cl...@ka...> - 2002-01-02 17:06:35
|
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. |
×
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