Linux-Development-Sys Digest #607, Volume #6 Fri, 9 Apr 99 21:14:15 EDT
Contents:
Re: Sockets? connect? (Sami Tikka)
Re: CodeWarror for Linux (was: Re: Programming tools for ...) (Mike McDonald)
Re: CodeWarror for Linux (was: Re: Programming tools for ...) (Alastair)
Re: specs for HP Ergo 1024 monitor? (Petter Reinholdtsen)
RH5.2, Solaris and NFS (Marv Nachatelo)
Re: CodeWarror for Linux (was: Re: Programming tools for ...) (Alastair)
Re: CodeWarror for Linux (was: Re: Programming tools for ...) (Sam Holden)
Re: CodeWarror for Linux (was: Re: Programming tools for ...) (Sam Holden)
----------------------------------------------------------------------------
From: Sami Tikka <[EMAIL PROTECTED]>
Subject: Re: Sockets? connect?
Date: 10 Apr 1999 00:33:01 +0300
Furthermore, when you assign the port (a 16-bit number) to the
sin_port field, it must be stored in network byte-order. On some hosts
the native byte-order is different from the network byte-order. Use
htons() in the assignment. (xxx.sin_port = htons(port))
--
Sami Tikka, [EMAIL PROTECTED], http://www.iki.fi/sti/
------------------------------
From: [EMAIL PROTECTED] (Mike McDonald)
Crossposted-To:
comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.help,comp.unix.programmer
Subject: Re: CodeWarror for Linux (was: Re: Programming tools for ...)
Date: 9 Apr 1999 20:54:19 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] writes:
> That's exactly what's hard to see: why the fundamentals of process
> improvement haven't been accepted.
Who hasn't accepted which "fundamentals of process improvement"?
>> The difference in
>> motivations and payoffs and intended user community should be
>> pretty clear.
>
> Nope, not at all. How would having a decent IDE hurt??
It probably wouldn't hurt but I don't believe it's a necessity either.
>> The phenomenon of masses of volunteers creating
>> novice-friendly applications for Linux due to altruistic motives or
>> a desire to see a free software platform succeed is a relatively recent
>> phenomenon, and the efforts of these intentions haven't been fully
>> realized yet.
>
> Probably because the tools suck!
Well, that's your opinion. I'd guess that most of the people using them
wouldn't classify them as "suck".
>> Another issue with Unix software is that graphical
>> apps make demands on the availability of X Windows running and
>> on bandwidth of a network connection that prohibit work in
>> many situations, so people typically refrain from doing something
>> that only pays off in eye candy rather than functionality if
>> it is going to be useful in fewer circumstances.
>
> Yeah right, like people develop over a LAN or WAN. Give me a break.
> Your child-like resistance is noted in your use of "eye candy" and
> dropped your case to ground zero.
Well, around here, that's how we do our developement. For instance, I
typically have xterms open to 5 other machines for developement and testing.
My editor (Xemacs) runs on my local workstation and I do compiles or testing
on the other five machines. I never compile on the machine that I edit on.
Developing over a LAN may not be common with WinDoze programmers, but it is
not unusual for Unix developers.
>> There is one part of the quoted text above that does hit near the
>> truth, I think - the libraries for creating GUI apps on
>> Unix were traditionally too hard to use. For example, I recently
>> worked at a software company where the main development environment
>> was HP-UX, and I found myself far and away preferring the character
>> based version of their debugger to the graphical one, even when
>> I was sitting at an X station, because the character based one
>> offered more functionality. It was obvious that so much effort
>> had gone into the initial production of the Motif GUI for the
>> visual one that access to functionality and bug fixes had
>> gotten left on, even though the underlying internals of the
>> debuggers were identical. This library situation is changing
>> rapidly.
>
> Agreed, X sucks.
No, he said Motif sucks. Big difference!
>> This is partly
>> historical accident (generalizing from the transition
>> of MS-Dos to MS-Windows), partly socialization (Windows
>> users are trained to be application oriented rather
>> than tool and data format oriented and trained to learn
>> by trial and error rather than by reading documentation),
>
> That's not a particular correct way to state it. The fundamental
> principle is that people can relate to pushing buttons and such just like
> most can use a stereo system.
And most people can't operate their VCR for anything other than straight
playback either. Single examples don't prove much of anything.
> I think the defensive posture taken by your kind is probably because you
> just don't have a GUI that is useful or elegant (X sucks) so you have to
> patronize yourselves. Right?
Can you name this "useful or elegant" GUI? (Opening myself up to the Mac
fanatics!) It sure isn't WinDoze for the types of activities I use a computer
for.
> There's no reason why a program couldn't
> be offered with dual interfaces (GUI and CLI), the problem is that X
> means the GUI monolith is more trouble than it's worth because some
> comittee tried to make it all things to all people (kinda in the style of
> today's free UNIX?)
>
> Don
X doesn't try to be "all things to all people". It's a "network-transparent
window system"(1). At that, it does quite well.
Mike McDonald
[EMAIL PROTECTED]
1: X Window System by Robert W. Scheifler & James Getty
page 1, line 1
Digital Press, 1990 ISBN 1-55558-050-5
------------------------------
From: [EMAIL PROTECTED] (Alastair)
Crossposted-To:
comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.help,comp.unix.programmer
Subject: Re: CodeWarror for Linux (was: Re: Programming tools for ...)
Date: Fri, 09 Apr 1999 23:49:48 GMT
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>UNIX monolith + X Windows monolith = a source code junk yard?
Bullshit. Please stop cross posting your FUD.
Followups set.
--
Alastair
work : [EMAIL PROTECTED]
home : [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Petter Reinholdtsen)
Subject: Re: specs for HP Ergo 1024 monitor?
Date: 9 Apr 1999 21:46:40 GMT
[Hugh A. Smith]
> Anyone have the specs for the HP Ergo 1024 (D2805A) 14"
> monitor (needed so I can get out of 640x480 land)
Check <URL:http://www.netmaster.ca/fvlug/monitor/>, the
Linux/XFree86 Monitor Database. If it isn't there, you should add
it if you find info about it.
--
##> Petter Reinholdtsen <## | [EMAIL PROTECTED]
------------------------------
From: Marv Nachatelo <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.networking
Subject: RH5.2, Solaris and NFS
Date: Fri, 09 Apr 1999 17:19:19 -0400
Any help is deeply appreciated. Note, I have contacted Sun. A call
was placed to them
back in December. After investigating with the customer, the call was
closed with no
solution found.
Hardware/OS
===========
PII 450, 256MB, 8GB disk - RH 5.2 Installed
EtherExpress Pro 10/100
Sun Ultra60 - Solaris 2.6 all recommend patches
Sun ultra2 - Solaris 2.6 all recommend patches
Additional hardware was used during the discovery phase. The three
components
listed remained the same. See below.
Problem
=======
Unable to perform more than one build from a Sun client to a NFS RH
fileserver.
I am also able to cause NFS problems when building gnu products, during
the ./configure stage.
When running builds with two Sun clients to the RH server the following
different
error occurs :
SOLARIS/nfstest.o: Is a directory
/var/tmp/cc9lq.S_.s: Assembler messages:
/var/tmp/cc9lq.S_.s:20315: FATAL: Can't close SOLARIS/nfstest.o
: Is a directory
make[1]: *** [SOLARIS/nfstest.o] Error 1
make: *** [bldrel] Error 2
OR
In file included from nfsbld.c:65:
optscn.h:225: parse error at null character
In file included from nfsbld.c:68:
nfsspbld.h:878: parse error at null character
In file included from nfsbld.c:70:
Problem is consistent.
When errors occur, random files within the filesystem (directory) being
accessed
get corrupted. Null characters are randomly inserted into files.
Discovery Stage
===============
1. RH5.2 NFS server to three different HPUX 10.x, 11.x nodes. No
problems.
2. RH5.2 NFS server to two different AIX 4.2.x, 4.3.x nodes. No
problems.
3. RH 4.x NFS server to the two Sun clients. No problems.
4. Tested from Sun NFS server to HP clients. No problems.
5. Tested from Sun NFS server to AIX clients. No problems.
6. Rebuilt nfs-server-2.2beta40. NFS Failure.
7. Rebuilt nfs-server-2.2beta40 with inode numbering sequence ON. NFS
Failure.
8. Tested from a RH5.2 NFS file server at 3.1GB to Suns. NFS Failure.
9. RH5.2 NFS server to one Sun 2.6 and another OS. NFS Failure.
10. RH5.2 server to Sun client 2.6 and Sun client 2.5.1. rpc.nfsd dies.
11. Source/build issue. I attempted building cvs-1.10 from two Sun
clients
to two different directories on the RH5.2 server.
- NFS server not responding errors.
- One "./configure" did not complete.
- after several attempts, had to reboot RH5.2 server.
Actions Taken
=============
1. Rebuilt nfs-server-2.2beta40.
2. upgraded to kernel 2.2.5 with latest nfs-server-2.2beta40.
3. Contacted SunSolve. They had one ticket that referenced this
product. The customer closed it with mention of upgrading
Linux to 2.1.x kernel. Unable to find out who the customer is.
4. Calling for help from anybody.
Please also send any replies directly.
Marv Nachatelo
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Alastair)
Crossposted-To:
comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.help,comp.unix.programmer
Subject: Re: CodeWarror for Linux (was: Re: Programming tools for ...)
Date: Sat, 10 Apr 1999 00:48:05 GMT
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>No, perhaps to enlighten. But actually, I wish good tools WERE available
>so then I'd have another deployment choice (probably not anyway since the
>whole design of UNIX doesn't sit well with me).
Then go away. Why bother arguing in unix newsgroups?
>Your approach is wasteful of brain power. It deals with the finest grain
>of detail too much and on a daily basis. The only ones who need to know
>the intracies of make (and that's NOT a call to make it intricate!)
>should be the tool makers.
Is this a call to 'dumb down'?
>
>> I have an IDE. I use an IDE. It's called Unix.
>
>That's not the commonly accepted definition of IDE.
Yes it is. Quite common. Unix is a toolbox for programmers. That's why it became
so popular.
>Again, I started with X sucks so it would more easily follow that sucky
>software is developed upon other sucky software.
Go away then. This is trolling.
Also, please stop cross-posting. Followups set (again).
--
Alastair
work : [EMAIL PROTECTED]
home : [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Sam Holden)
Crossposted-To:
comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.help,comp.unix.programmer
Subject: Re: CodeWarror for Linux (was: Re: Programming tools for ...)
Date: 9 Apr 1999 23:37:12 GMT
Reply-To: [EMAIL PROTECTED]
On Fri, 9 Apr 1999 18:14:25 -0500, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>In article <7elpdr$hg0$[EMAIL PROTECTED]>,
>[EMAIL PROTECTED] says...
>> In article <[EMAIL PROTECTED]>,
>> [EMAIL PROTECTED] writes:
>>
>
>> >> The difference in
>> >> motivations and payoffs and intended user community should be
>> >> pretty clear.
>> >
>> > Nope, not at all. How would having a decent IDE hurt??
>>
>> It probably wouldn't hurt but I don't believe it's a necessity either.
>
>Except to the thousands or millions who WOULD use them and program for
>the OS if they existed.
I guess we lose those programmers who can't work out how to use
make. Oh well no big loss.
There appears to be just as much quality software out there for these
Unix environments then for these MS Windows type environments.
Maybe that's because once someone bothers to learn how to use a
few simple tools properly they can do everything an IDE does.
And those people that can't be bothered learning because they
assume that a bunch of old command line character stream based
tools are too cryptic and useless to bother with won't be
missed anyway.
Nothing worse than a programmer who can't be bothered spending
some time learning a few tools.
Feel free to use your IDE. Feel free to write an IDE. You could
prove me wrong, but it would appear you are just here to argue.
If someone creates an IDE that makes me more efficient I will
use it. I changed editors a few years ago for that very reason.
My experience tells me that Unix is more powerful than an IDE.
Software I haven't seen could change my opinion. Your arguments
haven't.
>
>> >> The phenomenon of masses of volunteers creating
>> >> novice-friendly applications for Linux due to altruistic motives or
>> >> a desire to see a free software platform succeed is a relatively recent
>> >> phenomenon, and the efforts of these intentions haven't been fully
>> >> realized yet.
>> >
>> > Probably because the tools suck!
>>
>> Well, that's your opinion. I'd guess that most of the people using them
>> wouldn't classify them as "suck".
>
>My point was the _potential_ users that are scared away (pushed to
>Windows because they have no choice?) think they suck.
>
>> >> Another issue with Unix software is that graphical
>> >> apps make demands on the availability of X Windows running and
>> >> on bandwidth of a network connection that prohibit work in
>> >> many situations, so people typically refrain from doing something
>> >> that only pays off in eye candy rather than functionality if
>> >> it is going to be useful in fewer circumstances.
>> >
>> > Yeah right, like people develop over a LAN or WAN. Give me a break.
>> > Your child-like resistance is noted in your use of "eye candy" and
>> > dropped your case to ground zero.
>>
>> Well, around here, that's how we do our developement. For instance, I
>> typically have xterms open to 5 other machines for developement and testing.
>> My editor (Xemacs) runs on my local workstation and I do compiles or testing
>> on the other five machines. I never compile on the machine that I edit on.
>> Developing over a LAN may not be common with WinDoze programmers, but it is
>> not unusual for Unix developers.
>
>K, I can see that. But it hardly makes a case for "you can't do that
>with an IDE". Rather that complexity BEGS for an IDE.
I have an IDE. I use an IDE. It's called Unix.
Does your IDE let you work on multiple machines at the same time?
Or are you restricted to compiling on the machine you edit on, which
is also the machine you run the produced binary on?
>
>> > Agreed, X sucks.
>>
>> No, he said Motif sucks. Big difference!
>
>If the foundation is weak, why would the higher level abstractions be any
>better?
Motif _is_ the higher level abstraction (in some strange sense of the word)
since it sits on top of X. Motif sucks. That doesn't mean X sucks though.
Just like I've seen many crappy programs written for MacOS, doesn't
mean MacOS sucks though...
--
Sam
Every human culture has good and bad points. Every computer program has
Eveone more bug. Even Perl.
--Larry Wall
------------------------------
From: [EMAIL PROTECTED] (Sam Holden)
Crossposted-To:
comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.help,comp.unix.programmer
Subject: Re: CodeWarror for Linux (was: Re: Programming tools for ...)
Date: 9 Apr 1999 20:58:51 GMT
Reply-To: [EMAIL PROTECTED]
On Fri, 9 Apr 1999 14:57:27 -0500, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>In article <GbgP2.902$[EMAIL PROTECTED]>,
>[EMAIL PROTECTED] says...
>> <[EMAIL PROTECTED]> wrote:
>>
>> >What I don't understand is why the low level syntax of, say, make hasn't
>> >been used as a foundation to build upon in an IDE. Most professional
>> >developers would then use IDEs that are based upon an open standard so no
>> >proprietary lock-in could occur (many IDEs would be available that
>> >basically just produce a make file and interface gcc and RCS e.g.).
>> >Personally, I think UNIX people like things complex for job security or
>> >some bull like that. Perhaps it just goes back to the failing of UNIX:
>> >no simple GUI std??
There is enough GUI software for Unix to show that GUI stuff is possible. If
programmers really thought an IDE would be such a great benefit they would
do it. However, since they are on Unix already, they know thet the Unix shell
is as good an IDE as you can get. Until we start writing code that isn't
text of course. For editing plain old text the Unix tools approach is about
as good as it gets. Amazing amounts of reuse. Amazing expressive power.
>>
>> I think you are barking up the wrong tree. Let me explain.
>> Make is used as a foundation for more powerful tools such as
>> autoconf, imake, automake, etc. These are not GUI tools for an IDE, but
>> rather character app based tools that get jobs done for people that
>> need to do them. So the premise that nobody builds on top of make
>> is for Unix is wrong. The hypothesis that people prefer tools that
>> are not novice-friendly for job security is also wrong.
>
>> It shouldn't
>> be hard to see that there is going to be a big difference in the
>> typical style of free software applications that are created or enhanced
>> by individuals, to personally help them get their work done vs.
>> the style of a commercial application that is developed by a software
>> company to sell to the largest number of users.
>
>That's exactly what's hard to see: why the fundamentals of process
>improvement haven't been accepted.
>
>> The difference in
>> motivations and payoffs and intended user community should be
>> pretty clear.
>
>Nope, not at all. How would having a decent IDE hurt??
It wouldn't but the time it would take to develop has instead been put
into developing better tools based development approaches. Emacs is an IDE.
GUI construction tools are missing currently, but again that's because no
one has really needed them enough to write them (but that is changing)...
For writing code, a GUI doesn't win you much. For writing letters and
invitations, and greeting cards a GUI wins you a lot. Being able to see bold
text on the screen is much better than seeing <bold> tags or whatever. But code
is just plain old text. There's syntax highlighting but that by definition
is done by the editor not by the user and is just a display issue and
vim does colours just as well as anything else...
>
>> The phenomenon of masses of volunteers creating
>> novice-friendly applications for Linux due to altruistic motives or
>> a desire to see a free software platform succeed is a relatively recent
>> phenomenon, and the efforts of these intentions haven't been fully
>> realized yet.
>
>Probably because the tools suck!
More likely because it is a new thing, and things take time to get up
to speed. Until very recently, the vast majority of linux developers have
been developing for other developers. Other Unix developers...
Also because the people that write the code didn't want them.
>
>> Another issue with Unix software is that graphical
>> apps make demands on the availability of X Windows running and
>> on bandwidth of a network connection that prohibit work in
>> many situations, so people typically refrain from doing something
>> that only pays off in eye candy rather than functionality if
>> it is going to be useful in fewer circumstances.
>
>Yeah right, like people develop over a LAN or WAN. Give me a break.
>Your child-like resistance is noted in your use of "eye candy" and
>dropped your case to ground zero.
I have developed code across a telnet session a lot. I use the consoles on
my linux box as much as I use X (easier on my eyes sometimes). I don't think
I'm that much of an exception.
I almost always write code over a LAN (seeing thos X Terminals don't run
anything except X).
A developer can spend a week writing a GUI or they can spend the week adding
some other feature to the code. Since they probably have much more training
and/or experience at coding then designing user interfaces, the most
efficient choice is not hard for them to see. Plus they have learnt to
code without a pretty GUI. They see the command line as being more powerful.
Whether it is more powerful or not is irrelevant. Perception is what matters.
If the GUI can be done quickly by some GUI builder tool. Then the author
can spend maybe an hour or two doing a GUI, or they can spend an hour
or two doing something else. A lot of people seem to choose to do
something else...
>
>> There is one part of the quoted text above that does hit near the
>> truth, I think - the libraries for creating GUI apps on
>> Unix were traditionally too hard to use. For example, I recently
>> worked at a software company where the main development environment
>> was HP-UX, and I found myself far and away preferring the character
>> based version of their debugger to the graphical one, even when
>> I was sitting at an X station, because the character based one
>> offered more functionality. It was obvious that so much effort
>> had gone into the initial production of the Motif GUI for the
>> visual one that access to functionality and bug fixes had
>> gotten left on, even though the underlying internals of the
>> debuggers were identical. This library situation is changing
>> rapidly.
>
>Agreed, X sucks.
>
>> All of this is just by way of explanation. There are good
>> reasons to create user friendly GUIs and, ultimately for
>> IDEs (though many of the reasons are different).
>
>Now you're being rational.
>
>> But I
>> think there is also a lot of conditioned bias in people
>> coming from Windows to think that the more graphical and
>> integrated apps are more powerful.
>
>They are. Instant productivity. It's the basis of why Windows took over
>the world and why UNIX failed: it was the GUI that made the environment
>accessible to people who wanted to USE the computer to work rather than
>work on the computer itself (configuring it etc). (I know I'm not saying
>anything new here, but it would appear that all the UNIX folks probably
>need to play subliminal tapes or something while they're going to sleep
>to get it into their brains).
Ease of use does not mean better. Faster to start with does not mean better.
The reason 'Windows took over the world' is because it had very good marketting
and it allowed every day people to use a computer. It made it much easier to,
for example, create a word processor document. You didn't have to read the
manual and discover all the strange key codes. You just clicked on the
menus and icons and stuff.
However, programmers are not every day people when it comes to computers.
They aren't afraid of braking the computer if they type something wrong. They
have a better idea of how the things work and so have less to fear. They spend
their time editing plain old ASCII text and not bold, underlined, coloured
business reports.
Unix and linux is a system for programmers to program on. It is not an OS for
the every day user. The tools approach, however, is vastly superior to the all
in one approach if you know your tools. I use make for example and I use RCS.
I started using them with C programs. I use the same programs with my Java
code, and my C++ code and my perl code (well I don't use make so much). I
use jikes as a java compiler and Kaffe as a JVM. I didn't have to change
anything except to make a symlink point to a different file. When I decide to
use a different language by a completely different vendor, I will use the
same supporting tools.
I use grep to find things in my code. I use sed to make global changes. I use
sed to indent and 'undent' sections of code at the click of a mouse button.
I use sed to comment junks of code out at the click of a mouse button. I check
the man page on whatever I'm having trouble with with three clicks. I paste in
some code from the manpage with a sweep and a chord with the mouse.
All of this translates simply to the next language I use. I don't have to
learn a new IDE. When I'm on a different system and my editor isn't installed
I use vi. All my tools work the same way (I just have top type lots of
<address>! sequences instead of using the mouse). The fact that the editor I
use is a <100k binary means I'll probably just copy it across if I'm
using linux on a 386 or solaris on a sparc...
When a better compiler is released I just frop it in and replace the old
compiler. Doesn't matter which companies compiler it is. I don't need to
go and find some preference in my IDE, I just move a symlink.
When I read and compose mail, or read and post news I use the same tools
to do a different job. It's still just plain text after all.
I use the same tools (make, rcs, grep, sed, perl) to manage web pages and
CGI scripts (does your IDE work just as well authoring HTML, or do you need
a seperate program with all that functionality built into it too?).
All an IDE would buy me is someone elses ideas for how all my tools should
be grafted together. I'm happy with my way thanks. All a GUI IDE would buy
me is the same thing with a restriction that I can't use it on those
dumb terminals and telnet connections.
An IDE is a good thing, provided the components are actually seperate
programs. That way I don't have to learn a new bunch of options and ways
of doing things for every language or vendor that I use.
A GUI IDE (like VB) in which I can draw my GUI and add in some code to call
my backend would be useful. But I'd rather a tool that let me draw the
interface and then called $EDITOR when I needed to write some code.
>
>> This is partly
>> historical accident (generalizing from the transition
>> of MS-Dos to MS-Windows), partly socialization (Windows
>> users are trained to be application oriented rather
>> than tool and data format oriented and trained to learn
>> by trial and error rather than by reading documentation),
>
>That's not a particular correct way to state it. The fundamental
>principle is that people can relate to pushing buttons and such just like
>most can use a stereo system. UNIX, to continue the analogy, is like a
>stereo system without the front panel and all the circuits exposed: you
>have to solder something just to turn it on!
A bad analogy really. People can relate to pushing buttons. It only takes
a little bit of training to learn that typing a command is just the same. I
click the mouse on my commands - very button like. Unix isn't like having
to solder, is like having more knobs that do things and less lights that
show what is happening...
Commands line interfaces give you more control. It is easier to express
yourself by typing words, then by clicking buttons. Most people have two
arms, which makes it hard to type and press buttons at the same time as well.
I don't care if people can't relate to the development tools I use. All I care
is that they are the best tools for the job. If a GUI IDE was better I would
use it (I'm young enough that I used A Mac and Windows 3.1 before I ever
used Unix), but a GUI IDE is restrictive and it doesn't let me use all the
knowledge and skill I have using command line tools.
A small tool that does one job well will have less bugs in it than a monolithic
IDE that does everything. Less interactions between code means less bugs.
If you prefer a GUI IDE then by all means use one. I won't stop you. I will
rant and rave like I have in this post though, since I honestly believe you
will be more efficient if you use better tools for the job.
Any function that your IDE does that makes writing code better, my collection
of tools can do too. If there is something you find amazingly useful, then
let me know so I can add it to my collection of techniques.
>
>> and
>> partly the effect of marketing and being used to a world
>> were mass producers of software that took hundreds of
>> thousands of person-hours to produce pay for shelf space
>> at CompUSA to sell their stuff to technoogical illiterates.
>> I think that both cultures need to work harder to see
>> the limitations of their own historical experiences and
>> biases.
>
>You're in the stone age obviously. Giving CLI equal credibility in the
>old CLI vs. GUI debate lessens YOUR credibility for engineering common
>sense. Just calling em like I see em.
>
>I think the defensive posture taken by your kind is probably because you
>just don't have a GUI that is useful or elegant (X sucks) so you have to
>patronize yourselves. Right? There's no reason why a program couldn't
>be offered with dual interfaces (GUI and CLI), the problem is that X
>means the GUI monolith is more trouble than it's worth because some
>comittee tried to make it all things to all people (kinda in the style of
>today's free UNIX?)
I've used things other than X. I don't care if X sucks. I use more code than
I write. If GUIs were better then I would prefer using them. What can a GUI
do that a CLI can't? Nothing obviously (except draw pretty pictures on the
screen).
So what does a GUI do that is better than CLI? Other than building another
GUI (which a GUI system is better for, I'd rather draw my interface then
write lots of 'new Button()' code).
searching text, replacing text, revision control, building - all
those things seem to be harder to do with a GUI.
Programming is basically editing text. You don't need a GUI to simply edit
text. In fact it just gets in the way. At best it just takes up some more
space on the screen that could contain some more code context.
--
Sam
Even if you aren't in doubt, consider the mental welfare of the person
who has to maintain the code after you, and who will probably put parens
in the wrong place. --Larry Wall
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
