Developers switching back to Windows. Is Linux falling behind?
vat...@yahoo.com
"
I switched to Windows, because it does not get in my way all the time.
I like being able to buy a new webcam or a scanner without researching
for hours whether it will work on Linux, and then start applying
strange
kernel patches in the hope to get it stable. And I don't agree with
KDE's general philosophy anymore, implementing a desktop in C++, and
ignoring all software development progress of the last 20 years. If KDE
wants to win the war against Windows or Mac OS X, they need a
development platform that's far superior. And there is no realistic
chance of achieving that when the developers use tools from the
computing stone age (the Gnome/Mono guys have understood this, but
their implementation is years behind Microsoft's, and the gap is
getting
wider).
"
He wrote a linux program I use very often, so I think he is a capable
developer.
I don't know anything about developers philosophies, which programs or
better in Windows or in Linux. I can't understand or verify his
statements. Where do I find this kind of info? In This newsgroup?
What does he mean with KDE developed in C++? I thought C++ was a good
programming language.
Does KDE ignore "all software development progress of the last 20
years"?
Why do they need "a development platform that's far superior"?
Do KDE developers "use tools from the computing stone age"?
And what does he mean with "the gap is getting wider"?
vatbier
Linonut
Who knows? He is from the Twilight Zone as far as I am concerned.
Windows TZ? <cue weird theme music>
--
MP3 is not a crime!
Shmuel (Seymour J.) Metz
08/30/2006
at 02:15 AM, vat...@yahoo.com said:
>A developer told this to me:
Absolute BS.
>kernel patches
NFW.
>And I don't agree with KDE's general philosophy anymore,
>implementing a desktop in C++, and ignoring all software
>development progress of the last 20 years.
ROTF,LMAO! They don't have to run faster than the bear, they just have
to run faster than m$.
>If KDE wants to win the war against Windows or Mac OS X, they need a
>development platform that's far superior. And there is no realistic
>chance of achieving that when the developers use tools from the
>computing stone age
You mean like BASIC and C?
>the Gnome/Mono guys have understood this,
Mono is a disease. C## is an attempt to derail Java, not an advance in
the state of the art.
>What does he mean with KDE developed in C++?
He means that C++ is 20 years behind C, which is blatant nonsense.
>Does KDE ignore "all software development progress of the last 20
>years"?
No, but m$ does.
>Why do they need "a development platform that's far superior"?
Because she/he/it says they do.
>Do KDE developers "use tools from the computing stone age"?
No.
>And what does he mean with "the gap is getting wider"?
Wishful thinking.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org
BearItAll
> A developer told this to me:
> "
> I switched to Windows, because it does not get in my way all the time.
You've done your home work, then switched it around. That is the very line
that was used over and over as the reason why UNIX programmers were
reluctant to develope for MS Windows. 'Windows just gets in the way'.
In Linux you can be much closer to the machine in your code. Still true to
the shared OS, but no multi layers of junk to pickaxe your way through.
MS got it seriously wrong when they designed for a shared resource OS,
because there is no need to deny access to the resources just because it is
a shared environment. UNIX has always known that and Linux followed suit,
OS2 knew it too by the way. So despite being surrounded by OS's that knew
how to share resources, MS did it another way and made it difficult even
for themselves, they have to break their own API to get good response.
> kernel patches in the hope to get it stable. And I don't agree with
> KDE's general philosophy anymore, implementing a desktop in C++, and
> ignoring all software development progress of the last 20 years. If KDE
>
I haven't patched a kernel for years and Linux is the only OS I have used
for years, other than looking after my users PCs.
> wants to win the war against Windows or Mac OS X, they need a
> development platform that's far superior.
Yes, that part is already done. It is generally called Linux.
> computing stone age (the Gnome/Mono guys have understood this, but
> their implementation is years behind Microsoft's, and the gap is
> getting
.net2 is very good. But you have to concider what it actually is. What is
really happening that gives you the fast design-to-product and what is
making the interaction actually work.
Well the fast design-to-product comes from the fact that MS have given a
very good tool to develope .net2 on. You get a wizzy wig of cause, along
with a lot of wizards that put ready made code where it should be. Then,
other than hitting the sides of the wall a few times because .net2
developer program constraints are very tight, you end up with a product
that you were hearded towards. A lot of code that you didn't write, nor
asked to be included with your project. So yes you do get a fast project,
so long as you don't intend straying off the narrow road.
Then what gives you that interaction that is .net2's real selling point? It
is java code.
So yes the .net2 idea was good, but the real place for it isn't in the
constraints of MS's .net2 developer program, the real power of .net2 comes
from php or rubyrails or perl-cgi along with java on the clients.
Have no doubt, mono is well set to knock the cap off .net2.
> He wrote a linux program I use very often, so I think he is a capable
> developer.
I've written lots of those therefore I must be capable too.
> I don't know anything about developers philosophies, which programs or
> better in Windows or in Linux. I can't understand or verify his
> statements. Where do I find this kind of info? In This newsgroup?
> What does he mean with KDE developed in C++? I thought C++ was a good
> programming language.
> Does KDE ignore "all software development progress of the last 20
> years"?
You mean c#. C# is just visual basic with a C++ like syntax to make it more
attractive to C++ developers. Trouble is, they aren't fooled by this.
Niether are other language developers because they haven't been lots of c#
compilers turning up over the last, is it ten years since c# turned up?
Don't be fooled with c#, it isn't pushing programmers forward, it is
constraining those that took it up to the MS way of doing things.
Which in this case is heading for a very static computing world.
> Why do they need "a development platform that's far superior"?
> Do KDE developers "use tools from the computing stone age"?
> And what does he mean with "the gap is getting wider"?
>
What MS programmers tend to mean by the stoneage Linux developing
environment is that less is done for you, you have to do it yourself.
Ok, it would be nice to have the lazy life, click a wizard and the function
is written for you. But the real world can't be like that, wizards don't
exist, all a wizard is is a means of inserting ready written snippets of
code. What the UNIX/Linux developer might call cut-n-paste. In the real
world you have to write your functions yourself. Then when your product is
finished it is nice to know that there is no hidden code that will add to
the bugs list when your program is running live. Just your own code and
calls to safe proven libs.
It is altogether cleaner and much much easier for the new programmer to
learn on.
vat...@yahoo.com
> A developer told this to me:
> "
> I switched to Windows, because it does not get in my way all the time.
> I like being able to buy a new webcam or a scanner without researching
> for hours whether it will work on Linux,
This weekend at my parents home I tried to use a Logitech QuickCam
Fusion webcam on Mandriva Linux 2006 inside VMware Workstation on
WinXP. I had fun installing all sorts of rpms of cooker development
ML2007 and compiling uvcvideo driver (I don't mind researching for
hours). Eventually I only once managed to get video on Ekiga 2.0.2
(video-conferencing) but the framerate was terrible slow. After I
couldn't get it to work anymore.
The built-in microphone of the usb webcam didn't work either. And I
don't like headset microphones.
So I've installed cooker development ML2007 on my computer which still
has lots of bugs but is usable.Next week I can borrow that webcam and
try it, I'm praying that Ekiga will run with perfect video, working
built-in microphone and that I'm able to connect to my sister using sip
capable X-Lite on WinXP. Wish me luck.
If it won't work, I'll wait till the developers solve it (hopefully
this year). But I can wait, I'm sure eventually I can have decent voip
software between my Linux system and my sister's WinXP. But webcams
have been around now for several years, shame that only now we have
something like Ekiga working.
Skype on WinXP has better features than Ekiga (full screen video, file
transfer). I hope Ekiga will improve, but I fear that Ekiga only has
one developer.
> He wrote a linux program I use very often, so I think he is a capable
> developer.
I'm very fond of that KDE program that he made.
Reading the comments you all made I'm reassurred that his statements
are not of the same quality as his program. Strange.
Thanks
vatbier
vat...@yahoo.com
> A developer told this to me:
> "
> I switched to Windows, because it does not get in my way all the time.
> I like being able to buy a new webcam or a scanner without researching
> for hours whether it will work on Linux,
This weekend at my parents home I tried to use a Logitech QuickCam
Fusion webcam on Mandriva Linux 2006 inside VMware Workstation on
WinXP. I had fun installing all sorts of rpms of cooker development
ML2007 and compiling uvcvideo driver (I don't mind researching for
hours). Eventually I only once managed to get video on Ekiga 2.0.2
(video-conferencing) but the framerate was terrible slow. After I
couldn't get it to work anymore.
The built-in microphone of the usb webcam didn't work either. And I
don't like headset microphones.
So I've installed cooker development ML2007 on my computer which still
has lots of bugs but is usable.Next week I can borrow that webcam and
try it, I'm praying that Ekiga will run with perfect video, working
built-in microphone and that I'm able to connect to my sister using sip
capable X-Lite on WinXP. Wish me luck.
If it won't work, I'll wait till the developers solve it (hopefully
this year). But I can wait, I'm sure eventually I can have decent voip
software between my Linux system and my sister's WinXP. But webcams
have been around now for several years, shame that only now we have
something like Ekiga working.
Skype on WinXP has better features than Ekiga (full screen video, file
transfer). I hope Ekiga will improve, but I fear that Ekiga only has
one developer.
> He wrote a linux program I use very often, so I think he is a capable
> developer.
I'm very fond of that KDE program that he made.
The Ghost In The Machine
<vat...@yahoo.com>
wrote
on 30 Aug 2006 02:15:12 -0700
<1156929312....@i42g2000cwa.googlegroups.com>:
> A developer told this to me:
> "
> I switched to Windows, because it does not get in my way
> all the time.
Has he ever had to fuss with HTML and CSS? :-)
(Hmm...there's a thought: a rap song with computer
acronyms. It's been done -- "Silicon Valley Guy"
comes to mind -- although that predates rapping.)
> I like being able to buy a new webcam or a scanner without researching
> for hours whether it will work on Linux, and then start applying
> strange kernel patches in the hope to get it stable.
No comment since I have neither. I would suspect many such
devices nowadays are USB.
> And I don't agree with
> KDE's general philosophy anymore, implementing a desktop in C++,
As opposed to what? Java? C#? Assembly language? Bash?
C# is logical enough and PowerShell looks mildly interesting.
It might even "jump" over to Linux in some form. (There's
a few patent issues to worry about.)
> and
> ignoring all software development progress of the last 20 years.
Lessee...that would be 1986. X just got released on rather
expensive workstations (Desqview/X, had it come earlier,
might have headed off Windows, but Quarterdeck made some
odd decisions if I read the Wikipedia article correctly)
and Windows 1.03 might be running on a 33 MHz 386 DX,
275,000 transistors, 4-6 million ops/second and 4 kB cache.
EMS v3.2 had just been innovated [*] the prior year, and
allowed DOS to break the 640K barrier. The 3 1/2" floppy
format is almost brand new as well -- 720K. CDROMs and the
Amiga 1000 were also just released last year. Hard drives
might have been 50 MB at most (Google's being reticent),
though support for filesystems over 32 MB will not come
out until late next year. Disk drives might have been
50 MB or so at most, and multipartitionable.
CASE (Computer-Aided Software Engineering) was the buzzword
du jour. MS-DOS 3.2 was probably king. OS/2 is somewhere
in internal development (it comes out next year); Microsoft
and IBM hadn't had their tiff yet. The Mac Plus had 4 MB
of RAM and SCSI, and the Sinclair ZX Spectrum 128 joined
the ranks of machines.
No C++, Java, COOL, or C#; IBM Professional PASCAL was
available for the PC (and was moderately useful). The
'Net might have been accessible through rather expensive
dialup services.
"Cray" also had da buzz back then, as a superputer. Nowadays
a good desktop could probably run rings around it. :-)
> If KDE
> wants to win the war against Windows or Mac OS X, they need a
> development platform that's far superior.
s/far/obviously far/
and I'm not all that sure that's the case, unfortunately.
What has Windows got? Visual Studio, allowing one to draw
forms (Basic), compile (Basic, C++), and manage programs.
KDevelop for KDE can draw forms, compile, and manage
programs.
Hard to see a difference, although KDevelop is free and
based on standard technologies such as make. It's a
reasonably good product, AFAICT -- but it won't kill
Visual Studio.
For its part Gnome split the problem. Glade allows GUI
specification and sets up a project, but doesn't do builds.
Glade is intelligent enough not to muck up the callback
layer but otherwise doesn't really understand the issue
of how to build programs. Gnome won't kill VS either.
Eclipse is the king of Java at present. Eclipse might be
a threat to VS, but it's hard to tell at this point, and
it serves a different language -- Visual Studio having
gotten out of the J++ fiasco years back.
> And there is no realistic
> chance of achieving that when the developers use tools from the
> computing stone age (the Gnome/Mono guys have understood this, but
> their implementation is years behind Microsoft's, and the gap is
> getting wider).
"Stone age" is an odd way of putting it. Given the above
research in 1986, which is probably "stone age" nowadays to
a lot of people (wow, how did Reagan & Co. survive without
a Bluetooth in his ear and a Blackberry clipped to his
belt?) it's clear that computer technology is a dynamic
beast -- although for how long is an interesting question.
> "
> He wrote a linux program I use very often, so I think he is a capable
> developer.
Wow, such specifics. I wrote an Amiga program way back when.
(In fact, I wrote quite a few back then -- nothing commercial
although if anyone knows where my Eye went please let me know :-) ).
> I don't know anything about developers philosophies, which programs or
> better in Windows or in Linux.
Microsoft is da bomb and Linux is "stone age". You're right; you
don't know. (If it's any consolation I'm not sure I do either,
though I do find Eclipse powerful. However, I use it for Java,
not C#; at some point MonoDevelop and Eclipse may need to merge,
or maybe MonoDevelop swallowed. And I've not used the C# variant
of Visual Studio.)
> I can't understand or verify his statements.
That makes a few of us. :-)
> Where do I find this kind of info? In This newsgroup?
This newsgroup might have some nuggets of info swimming
around in a cesspool of vitriol, a brackish wash of
opinion, and a running stream of commentary. Happy
straining, though I for one find it interesting. :-)
> What does he mean with KDE developed in C++? I thought C++ was a good
> programming language.
C++ is reasonably good at that, used properly. You're
probably aware of such efforts as "the C Obfuscation
Contest" (?), which makes interesting messes with macros
and C++ constructs.
> Does KDE ignore "all software development progress of the last 20
> years"?
C++ didn't even *exist* 20 years ago. If memory serves
it first got inaugurated in about 1988-1989; I first ran
into it when I changed jobs back then. Prior to that,
it was a mix of Pascal, Fortran, C, and COBOL, on VMS
and Aegis (now DomainOS).
> Why do they need "a development platform that's far superior"?
Why do we need computers? :-) Presumably, a development
platform is a solution to a problem and a tradeoff; the
more expensive the platform, ideally, the faster one can
develop the solution.
In practice I don't think that's quite true.
> Do KDE developers "use tools from the computing stone age"?
Probably. For loops haven't changed much. :-) Those
and if statements are the equivalent of the wheel:
ancient, reliable, not really in need of much modification.
Your friend will have to be slightly more specific.
> And what does he mean with "the gap is getting wider"?
Good question. I wish I had an answer.
>
> vatbier
>
[*] LIM/EMS stands for Lotus, IBM, Microsoft Expanded
Memory Specification. It is apparently still with us
today, although the "EMS" has been largely forgotten (a
Google coughed up Emergency Medical Services instead --
logical enough, given the context of today's terrorists
and needs) and of course the old problem of "how DOS can
get at the RAM" has been long since solved.
--
#191, ewi...@earthlink.net
Windows Vista. Because it's time to refresh your hardware. Trust us.
Tim Smith
>>the Gnome/Mono guys have understood this,
>
> Mono is a disease. C## is an attempt to derail Java, not an advance in
> the state of the art.
Nonsense. Read this:
<http://archive.eiffel.com/doc/manuals/technology/bmarticles/sd/dotnet.html>
--
--Tim Smith
Bob Hauck
> This weekend at my parents home I tried to use a Logitech QuickCam
> Fusion webcam on Mandriva Linux 2006 inside VMware Workstation on
> WinXP.
...
> Eventually I only once managed to get video on Ekiga 2.0.2
> (video-conferencing) but the framerate was terrible slow.
You not only expected this to work, but you expected decent framerates
too? I must be a pessimist.
--
-| Bob Hauck
-| A proud member of the unhinged moonbat horde.
-| http://www.haucks.org/
OK
wrote:
You live in a different dimension.
JEDIDIAH
> vat...@yahoo.com schreef:
>> A developer told this to me:
>> "
>> I switched to Windows, because it does not get in my way all the time.
>> I like being able to buy a new webcam or a scanner without researching
>> for hours whether it will work on Linux,
>
> This weekend at my parents home I tried to use a Logitech QuickCam
> Fusion webcam on Mandriva Linux 2006 inside VMware Workstation on
> WinXP. I had fun installing all sorts of rpms of cooker development
Are seriously trying to claim that the results achieved with
an EMULATED copy of any OS has any general relevance?
Puuullleeze.
> ML2007 and compiling uvcvideo driver (I don't mind researching for
> hours). Eventually I only once managed to get video on Ekiga 2.0.2
> (video-conferencing) but the framerate was terrible slow. After I
Of course it's going to be slow you MORON, you're emulating
an entire damn computing architecture.
[deletia]
<shakes head>
--
Sure, I could use iTunes even under Linux. However, I have |||
better things to do with my time than deal with how iTunes doesn't / | \
want to play nicely with everyone else's data (namely mine). I'd
rather create a DVD using those Linux apps we're told don't exist.
Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com
Ian Hilliard
> What MS programmers tend to mean by the stoneage Linux developing
> environment is that less is done for you, you have to do it yourself.
>
> Ok, it would be nice to have the lazy life, click a wizard and the
> function is written for you. But the real world can't be like that,
> wizards don't exist, all a wizard is is a means of inserting ready written
> snippets of code. What the UNIX/Linux developer might call cut-n-paste. In
> the real world you have to write your functions yourself. Then when your
> product is finished it is nice to know that there is no hidden code that
> will add to the bugs list when your program is running live. Just your own
> code and calls to safe proven libs.
>
> It is altogether cleaner and much much easier for the new programmer to
> learn on.
There is an old adage in programming. "If you want to be more productive,
code less." The point of this statement is that there should be less new
code and more use of existing libraries.
Most senior programmers have a library of code that can be used to solve
most of the day to day problems in programming. This is one of the things
that makes a senior programmer much more productive than a junior
programmer. The other is the recognition of patterns of solutions to
particular patterns of problems.
Microsoft's wizards have been designed to match the solutions to the
problems and then provide particular library calls that are implimentations
of those solution patterns. The problem with the .Net2 framework is that
unlike the libraries that senior programmers have, these are mostly quite
new and have not yet had to withstand the test of time.
Of course, Microsoft is not providing these tools out of the goodness or
their hearts. Apart from having to pay for them, they guarantee that any
code you produce with them is absolutely non-portable, so that you could
never come to the silly idea of using a different platform, which may be
better suited to the task.
There is an alternative. That is the use of one of the many libraries which
is available in FOSS. The problem is that most of these libraries are
GPL'ed and most companies at the moment do not have a business plan that
could handle having to open source their own code. So, I guess that for the
next while there will be a lot of code produced that will just have to be
trashed at the point where Microsoft gets so greedy that even the PHB's of
the world will have to stand up and take notice.
Ian
The Ghost In The Machine
<sp...@rassler.co.uk>
wrote
on Wed, 30 Aug 2006 14:50:58 +0100
<115694585...@proxy01.news.clara.net>:
> vat...@yahoo.com wrote:
>
>> A developer told this to me:
>> "
>> I switched to Windows, because it does not get in my way all the time.
>
> You've done your home work, then switched it around. That is the very line
> that was used over and over as the reason why UNIX programmers were
> reluctant to develope for MS Windows. 'Windows just gets in the way'.
Windows doesn't "get in the way"; it is the *only* way to some. :-)
(One hopes the industry is in fact at a crossroads of some point,
and everyone turns onto FOSS Boulevard. :-) Unlikely, but one
can hope...)
>
> In Linux you can be much closer to the machine in your code. Still true to
> the shared OS, but no multi layers of junk to pickaxe your way through.
I'm not entirely sure what this means, but at least in Linux the layers
aren't too hard to identify. However, in /usr/lib I have 2,329 entries,
523 of which match the pattern *.so, and 454 of *those* are symbolic
links. All of these, hopefully, are accounted for (I tend not to dink
around with /usr/lib but let emerge and company manage it), but that's
quite a few libraries.
Fortunately, Linux is not restricted to the 8.3 naming convention of
oldstyle DOS which seems to hamper Windows, so stuff like
libgstreamer-0.10.so -> libgstreamer-0.10.so.0.8.0
libgstreamer-0.10.so.0 -> libgstreamer-0.10.so.0.8.0
is fairly common -- and the bits in the name are readily
identifiable. In fact, I also have
libgstreamer-0.8.so -> libgstreamer-0.8.so.1.4.0
libgstreamer-0.8.so.1 -> libgstreamer-0.8.so.1.4.0
which basically means that I've got some programs referring to the
older version. No DLL Hell here, just an older version, if the
program is referring to it as 'libgstreamer-0.8.so'. I don't
know at this point offhand without looking around. Of course
if I delete libgstreamer-0.8.so.1.4.0 some programs will probably
be rather unhappy. And mistakes do happen; IIRC there was a
version '62' I think of libc in a Redhat distro way back when.
Confused things for awhile.
(Gentoo provides 'revdep-rebuild' to try to identify and repair
such things. Also, when a new version is emerged it will attempt
to remove older versions after the new version is in place.)
>
> MS got it seriously wrong when they designed for a shared resource OS,
"Designed" is an interesting choice of terms in this context. :-)
Microsoft has several issues.
[1] Binary backward compatibility. SOL.EXE still works,
for example. Granted, there are issues if a program
depends on VxDs or TSRs.
[2] Cost reduction. Presumably, Microsoft skimped a bit on
engineering in a fair number of spots, and now is
paying for it. After all, NRE affects the bottom
line immediately as a cost, but might show up as a
revenue benefit later. (Or it might not. But quality
is probably appreciated by a discerning customer --
and crudware should, ideally, be despised by just
about everyone.)
[3] "We are the industry leaders." (The cliff is just ahead.)
[4] There are several problems with Win32 which never
really got addressed, just sort of hacked around.
(For starters, no network transparency or possibility
of extensions, though one can always add API "glue",
which is more or less what Microsoft did.)
> because there is no need to deny access to the resources
> just because it is a shared environment.
Possible counterexample: security issues. For example,
/dev/hda1 can only be accessed by root, since /etc/shadow
(the most obvious example) should not be read by the casual
user, as it contains passwords. Encrypted passwords,
to be sure, but passwords all the same. Of course casual
writing could destroy the volume organization.
Then again, that's a little more than "just because it's
shared".
If you're discussing file locking, though, it gets interesting.
flock() and lockf() are both available on Linux, though I'm not
sure how many programs actually use them. lockf() is a
simplified interface to fcntl(F_SETLK), apparently; there's
no separate manpage for it. Mandatory locking can be
enabled on a file-by-file basis by a chmod g-x+s, if I'm
reading the fcntl() manpage correctly.
I'll admit Microsoft botched it by requiring everybody to
honor "many-read/one-write", though -- though I don't know
precisely how /usr/bin/install works. A perusal of the
source code
(ebuild /usr/portage/sys-apps/coreutils/coreutils-5.94-r3.ebuild unpack)
indicates that it's pretty twisted in there -- though probably
also beaten to death from a time perspective. (The xterm
code is worse, though. :-) )
Apparently Microsoft also explicitly loads DLLs into
memory, and then keeps it in there. For its part Linux
also loads the file into memory but is apparently smart
enough to kill the cached pages if the file is deleted,
and modify the right pages if the file is overwritten.
DLLs get no real special treatment unless there's a read
lock somewhere that precludes writing. I'd have to look.
It's clear Unix and Linux are enablers, not restricters,
in this space -- and in Microsoft's case the hacks to
get around the restrictions get a bit horrid, requiring
among other things a reboot in order to allow access to
the new DLL. (AIUI, the new DLL is squirreled in a known
spot and actually put into replace after the shutdown,
early in the reboot. If the DLL was not in use during
the install, the file is simply overwritten -- which could
lead to "mixed version" problems if one is not sufficiently
conscientious. Linux does not have this problem, unless
an old version of a running daemon tries to execute a new
version of a needed subprogram which fails. Workaround:
stop and restart the affected daemon -- but just the daemon.)
> UNIX has always known that and Linux followed suit,
I'm not sure if Unix knew that or not during its inception
(the Incompatible Timesharing System and MULTICs are
mentioned in various spots -- MULTICs is usually credited
as being Unix's predecessor but Stephen Levy mentions ITS
in his book, "Hackers"). It's clear Unix didn't know about
sockets at first, and NFS has some strange design quirks.
However, it's also clear Unix has known about how to
resource share for a very long time. However, I for one
might put it as "KLSS" -- keep locks short and simple. :-)
> OS2 knew it too by the way. So despite being surrounded by OS's that knew
> how to share resources, MS did it another way and made it difficult even
> for themselves, they have to break their own API to get good response.
>
>> kernel patches in the hope to get it stable. And I don't agree with
>> KDE's general philosophy anymore, implementing a desktop in C++, and
>> ignoring all software development progress of the last 20 years. If KDE
>>
>
> I haven't patched a kernel for years and Linux is the only OS I have used
> for years, other than looking after my users PCs.
I for one hope you have the tear.c patch. :-) Other than
that, there's probably very few patches for the kernel
proper unless one counts the many patches for new devices
-- which for you (and me, for that matter) are probably
irrelevant unless you actually have an itch to go out and
grab one of them. :-)
>
>> wants to win the war against Windows or Mac OS X, they need a
>> development platform that's far superior.
>
> Yes, that part is already done. It is generally called Linux.
Pedant Point: Linux is not a development platform as such. I'm
old enough to remember pre-SDKs, and in any event one needs
at least a compiler and a set of headers. :-)
Of course Linux is an excellent *start* on a development platform;
it's stable, well-specified, and tends to degrade gracefully under
heavy load, as opposed to simply dropping dead. (There are
exceptions, such as running out of open file descriptors.)
>
>> computing stone age (the Gnome/Mono guys have understood this, but
>> their implementation is years behind Microsoft's, and the gap is
>> getting
>
> .net2 is very good. But you have to concider what it actually is. What is
> really happening that gives you the fast design-to-product and what is
> making the interaction actually work.
>
> Well the fast design-to-product comes from the fact that MS have given a
> very good tool to develope .net2 on. You get a wizzy wig of cause, along
> with a lot of wizards that put ready made code where it should be. Then,
> other than hitting the sides of the wall a few times because .net2
> developer program constraints are very tight, you end up with a product
> that you were hearded towards. A lot of code that you didn't write, nor
> asked to be included with your project. So yes you do get a fast project,
> so long as you don't intend straying off the narrow road.
>
> Then what gives you that interaction that is .net2's real selling point? It
> is java code.
Eh? Are you referring to:
[1] Java source code compiled down to JVM bytecode?
[2] Java source code compiled to MSIL?
[3] C# code converted to Java?
All of these are interesting and possible ([1] is Sun's
or maybe Blackdown's JVM; [2] is Java#, in some form; [3]
I'd have to look but in theory is possible given enough
machinery and some library routines).
>
> So yes the .net2 idea was good, but the real place for it isn't in the
> constraints of MS's .net2 developer program, the real power of .net2 comes
> from php or rubyrails or perl-cgi along with java on the clients.
Personally, I rather like the notion of Gtk# long-term. Short-term
there's some issues I have with MonoDevelop, mostly because Eclipse
has spoiled me rotten. :-)
>
> Have no doubt, mono is well set to knock the cap off .net2.
>
>> He wrote a linux program I use very often, so I think he is a capable
>> developer.
>
> I've written lots of those therefore I must be capable too.
>
>> I don't know anything about developers philosophies, which programs or
>> better in Windows or in Linux. I can't understand or verify his
>> statements. Where do I find this kind of info? In This newsgroup?
>> What does he mean with KDE developed in C++? I thought C++ was a good
>> programming language.
>> Does KDE ignore "all software development progress of the last 20
>> years"?
>
> You mean c#. C# is just visual basic with a C++ like syntax to make it more
> attractive to C++ developers.
Not sure if Visual Basic had strong typing, but I'll admit there
are some issues in C# that make it interesting (though not in
a good way) -- for example, autoconverting property settings
'a.b = c' to function calls 'a.setB(c)'.
> Trouble is, they aren't fooled by this.
> Niether are other language developers because they haven't been lots of c#
> compilers turning up over the last, is it ten years since c# turned up?
>
> Don't be fooled with c#, it isn't pushing programmers forward, it is
> constraining those that took it up to the MS way of doing things.
>
> Which in this case is heading for a very static computing world.
Well, gee, isn't everyone just supposed to stay with Microsoft anyway?
As opposed to going forward and innovating? :-)
>
>> Why do they need "a development platform that's far superior"?
>> Do KDE developers "use tools from the computing stone age"?
>> And what does he mean with "the gap is getting wider"?
>>
>
> What MS programmers tend to mean by the stoneage Linux developing
> environment is that less is done for you, you have to do it yourself.
>
> Ok, it would be nice to have the lazy life, click a wizard and the function
> is written for you.
Wizards -- or their KDE/Gnome counterparts -- do exist.
Gnome's Glade in particular writes a fair bit of code,
mostly to encapsulate the actual callbacks (the user still
has to write those) and to construct the GUI. I think it's
smart enough, however, not to *overwrite* the callback
stubs file (logically enough named 'callbacks.c', IIRC)
if it exists, though. Of course the callback stubs file
should probably call someone else; it's a glue layer,
after all.
Gtk is also reasonably well documented.
> But the real world can't be like that, wizards don't
> exist, all a wizard is is a means of inserting ready written snippets of
> code.
And then leaving the user to try to figure out what the
glop means. :-) Especially if the other description of the
GUI mutates in an incompatible fashion (in Glade's case,
that's XML; I don't know what KDevelop uses but I think
there's a xyzzy.form somewhere).
> What the UNIX/Linux developer might call cut-n-paste. In the real
> world you have to write your functions yourself. Then when your product is
> finished it is nice to know that there is no hidden code that will add to
> the bugs list when your program is running live. Just your own code and
> calls to safe proven libs.
>
> It is altogether cleaner and much much easier for the new programmer to
> learn on.
>
Tim Smith
> What MS programmers tend to mean by the stoneage Linux developing
> environment is that less is done for you, you have to do it yourself.
>
> Ok, it would be nice to have the lazy life, click a wizard and the
> function is written for you. But the real world can't be like that,
> wizards don't exist, all a wizard is is a means of inserting ready written
> snippets of code. What the UNIX/Linux developer might call cut-n-paste. In
> the real world you have to write your functions yourself. Then when your
> product is finished it is nice to know that there is no hidden code that
> will add to the bugs list when your program is running live. Just your own
> code and calls to safe proven libs.
>
> It is altogether cleaner and much much easier for the new programmer to
> learn on.
What about Ruby on Rails? It seems to be a rather effective counterexample
to this.
--
--Tim Smith
Hadron Quark
Would you seriously compare the C/C++ development tools on Linux with
those for Windows? By tools here I mean the IDEs & debuggers, not the
compiler itself. Eclipse is a step in the right direction : a lot of
the rest is half arsed. While the internals of GDB are powerful, the
interfaces to it are a disaster. DDD is about the best and even that
sucks compared to the Windows development equivalents - I use GDB-UI in
emacs. Its kind of nice & retro :-;
>
>>And what does he mean with "the gap is getting wider"?
>
> Wishful thinking.
>
The rest of what he said is blatant nonsense.
> --
> Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
>
> Unsolicited bulk E-mail subject to legal action. I reserve the
> right to publicly post or ridicule any abusive E-mail. Reply to
> domain Patriot dot net user shmuel+news to contact me. Do not
> reply to spam...@library.lspace.org
>
--
Ray Ingles
> He wrote a linux program I use very often...
Is there any reason why you are posting anonymously and concealing the
name of the developer and the program involved? And why does the title
say "developers" when only one is involved?
--
Sincerely,
Ray Ingles (313) 227-2317
"When a friend of mine quit his last job, the reason he gave in his
notice was 'because Dilbert isn't funny anymore.' In his exit
interview, he was asked what he meant by that." - Stefan Bethke
Peter Köhlmann
> On 2006-08-30, vat...@yahoo.com <vat...@yahoo.com> wrote:
>> A developer told this to me:
>> "I switched to Windows...
>> He wrote a linux program I use very often...
>
> Is there any reason why you are posting anonymously and concealing the
> name of the developer and the program involved? And why does the title
> say "developers" when only one is involved?
>
Well, lets guess: The story did not happen exactly as told
In fact, it did not happen at all. The "developer" does not exist
And the "narrator" of that sad story is as real as a stable windows
--
We may not return the affection of those who like us,
but we always respect their good judgement.
Mark Kent
Ian Hilliard <nos...@hilliardtech.com> espoused:
<snip description of the proprietary nature of .net, and it's
immaturity>
>
> There is an alternative. That is the use of one of the many libraries which
> is available in FOSS. The problem is that most of these libraries are
> GPL'ed and most companies at the moment do not have a business plan that
> could handle having to open source their own code. So, I guess that for the
> next while there will be a lot of code produced that will just have to be
> trashed at the point where Microsoft gets so greedy that even the PHB's of
> the world will have to stand up and take notice.
>
There's always an Oliver Wong or Tim Smith or Erik F in the wings,
though, waiting to be...
--
| Mark Kent -- mark at ellandroad dot demon dot co dot uk |
"Nuclear war would really set back cable."
- Ted Turner
chrisv
Ray Ingles
> Would you seriously compare the C/C++ development tools on Linux with
> those for Windows? By tools here I mean the IDEs & debuggers, not the
> compiler itself.
I would seriously compare the *development environment* on Linux to
that of Windows, and Linux wins.
One of the reasons that Windows has the kind of IDE and debugger
support that it 'enjoys' is because it *needs* it. Developing for
Windows is nearly unmanageable *without* that kind of support. The
Windows API is huge, complex, only occasionally and accidentally
orthogonal, and in my experience mostly very poorly documented.
http://charlespetzold.com/etc/DoesVisualStudioRotTheMind.html
"Today we are ready for the official release of the .NET Framework 2.0.
Tabulating only MSCORLIB.DLL and those assemblies that begin with word
System, we have over 5,000 public classes that include over 45,000
public methods and 15,000 public properties, not counting those methods
and properties that are inherited and not overridden. A book that simply
listed the names, return values, and arguments of these methods and
properties, one per line, would be about a thousand pages long.
If you wrote each of those 60,000 properties and methods on a 3-by-5
index card with a little description of what it did, you’d have a stack
that totaled 40 feet."
Meanwhile, the entire POSIX spec, suitable for *fully implementing* a
POSIX system *including the utility apps*, with *commentary* and
*rationales for design decisions*, fits in about two and a half feet of
binders.
Intellisense is practically *mandated* if you want to work with an
interface as baroque as Win32. And it's nice even when you're working
with your own defined classes and structures. But it has its own
drawbacks, as Petzold notes:
"For example, suppose you’re typing some code and you decide you need a
variable named id, and instead of defining it first, you start typing a
statement that begins with id and a space. I always type a space between
my variable and the equals sign. Because id is not defined anywhere,
IntelliSense will find something that begins with those two letters that
is syntactically correct in accordance with the references, namespaces,
and context of your code. In my particular case, IntelliSense decided
that I really wanted to define a variable of interface type
IDataGridColumnStyleEditingNotificationService, an interface I’ve never
had occasion to use."
He's got a lot of other complaints about Visual Studio, it's worth
reading that article.
> Eclipse is a step in the right direction : a lot of
> the rest is half arsed. While the internals of GDB are powerful, the
> interfaces to it are a disaster. DDD is about the best and even that
> sucks compared to the Windows development equivalents - I use GDB-UI in
> emacs. Its kind of nice & retro :-;
I develop for many platforms at work. It's a core part of my job. I
mostly enjoy writing code for Unixish platforms, and tolerate the
Windows stuff. The APIs on Unix are small, well-thought-out, have few if
any side effects, and tend to be thoroughly documented. I find very few
interfaces on Windows have even a majority of these traits, let alone
all of them.
I've rarely felt the need for more debugging support than Linux comes
with. The problems tend to be simpler and more easily uncovered. Eclipse
is nice, and appears to take many of the good things about Visual Studio
and leave much of the bad behind. For some projects, it's very useful.
For others, it's overkill.
Another item worth reading - the whole book, really - is here:
http://www.faqs.org/docs/artu/
For a Windows developer's perspective on the book:
http://www.joelonsoftware.com/articles/Biculturalism.html
Needless to say, I don't agree with everything he writes there, but you
might find it interesting.
--
Sincerely,
Ray Ingles (313) 227-2317
Microsoft Windows - Don't get frustrated without it.
Hadron Quark
> On 2006-08-30, Hadron Quark <hadro...@gmail.com> wrote:
>> Would you seriously compare the C/C++ development tools on Linux with
>> those for Windows? By tools here I mean the IDEs & debuggers, not the
>> compiler itself.
>
> I would seriously compare the *development environment* on Linux to
> that of Windows, and Linux wins.
Yuo are including and concentraing on the APIs. That wasnt my
intention. I have developed on multiple platforms and find the windows
IDEs to be incomparable. To be honest, the honest to god, basic win32
API was ok too. Personally I think C++ rot is setting in : classes to
fix classes etc : it sucks. How wonderful it seemed when we discovered
that an apple and orange were both fruits and could share a common base
class :)
re: http://www.faqs.org/docs/artu/
Good link.
Linonut
> On 2006-08-30, Hadron Quark <hadro...@gmail.com> wrote:
>> Would you seriously compare the C/C++ development tools on Linux with
>> those for Windows? By tools here I mean the IDEs & debuggers, not the
>> compiler itself.
>
> I would seriously compare the *development environment* on Linux to
> that of Windows, and Linux wins.
The big problem with Windows development is that it relies primarily on
Microsoft tools. The tool I use, Visual Studio, falters if you don't
let it control the project, and that brings in all sorts of shit such as
AFX headers and hard-to-read boilerplate. If you just code a basic
application or library and deliberately ignore that stuff, then VS has
problems sorting out dependencies. Hell, it may have problems even if
you let VS control things, for all I know.
Also, the project files have gotten away from makefiles, which work
pretty well for managing code, in favor of XML files.
As far as Hardon's juvenile rah-rah'ing for Microsoft GUI tools goes,
well, you can find a wide range of capable free products that are
comparable, should you wish to cripple yourself.
Frankly, for what I do, a couple of xterms and the command-line
tools work just fine, and they respond faster than any GUI tool.
--
:read ~/.signature
tha...@tux.glaci.remove-this.com
>
> There is an alternative. That is the use of one of the many libraries which
> is available in FOSS. The problem is that most of these libraries are
> GPL'ed and most companies at the moment do not have a business plan that
> could handle having to open source their own code. So, I guess that for the
> next while there will be a lot of code produced that will just have to be
> trashed at the point where Microsoft gets so greedy that even the PHB's of
> the world will have to stand up and take notice.
Actually, in my experience most libraries are released under the LGPL,
BSD, or some other license that allows proprietary closed source apps
to be developed and run on the libraries. In fact I've yet to encounter
one that was not. Do you have any examples?
Thanks,
Thad
Ray Ingles
> Ray Ingles <sorc...@localhost.localdomain> writes:
>> I would seriously compare the *development environment* on Linux to
>> that of Windows, and Linux wins.
>
> Yuo are including and concentraing on the APIs.
Not *just* the APIs, though since we're talking about programming
that's, um, kinda central. (If you're not using APIs, you're just
recording macros, or maybe using LabView.)
I also mentioned documentation and overall complexity (which is partly
driven by the APIs in use, of course, but not entirely). Windows seems
almost *designed* to tie the user interface into the guts of the
program. I find things work a lot better (are easier to design, debug,
maintain, and extend) when the engine of a program is separated from the
user interface. (This also enhances portability, but I'm not sure if
this is a deliberate goal of MS or just a side-effect of their own
disregard/disdain of that concept.)
> I have developed on multiple platforms and find the windows
> IDEs to be incomparable.
What, exactly, do you mean by "incomparable" here? What about it cannot
be compared to other IDEs? (I'm not asking this in a challenging tone,
mind you. I am really just asking for clarification.) What do you miss
going to other environments?
(I'll note in passing that the Linux develoment tools aren't standing
still. E.g. gdb's MI (machine interface). Look it up, you might like it.
Eclipse likes it. :-> )
--
Sincerely,
Ray Ingles (313) 227-2317
"I know you don't believe in God... but now you can try
Him risk-free for 30 days!" - Monica Ingles
Hadron Quark
> On 2006-08-31, Hadron Quark <hadro...@gmail.com> wrote:
>> Ray Ingles <sorc...@localhost.localdomain> writes:
>>> I would seriously compare the *development environment* on Linux to
>>> that of Windows, and Linux wins.
>>
>> Yuo are including and concentraing on the APIs.
>
> Not *just* the APIs, though since we're talking about programming
> that's, um, kinda central. (If you're not using APIs, you're just
> recording macros, or maybe using LabView.)
The IDEs interfaced well to the APIs in windows. That is excellent. JIT
compilie/debug too. Nice.
>
> I also mentioned documentation and overall complexity (which is partly
> driven by the APIs in use, of course, but not entirely). Windows seems
Windows API documentation was excellent, affordable and available. Did
you ever try and get IBM to sell you their redbooks or the OS/2 PM/GPI
manuals? Impossible. And expensive.
> almost *designed* to tie the user interface into the guts of the
> program. I find things work a lot better (are easier to design, debug,
Thats bullshit.
Windows has a simple enough message driven system which *can* control the
program - theres no "tie in" other than what the programmer decides. The
controls invariably have a pointer back to program specific (not UI
specific) data bindings/objects.
> maintain, and extend) when the engine of a program is separated from the
> user interface. (This also enhances portability, but I'm not sure if
> this is a deliberate goal of MS or just a side-effect of their own
> disregard/disdain of that concept.)
>
>> I have developed on multiple platforms and find the windows
>> IDEs to be incomparable.
>
> What, exactly, do you mean by "incomparable" here? What about it
> cannot
Slick, fast, well written, tied in withe API, Great browsers, graphers
etc. Compare ddd to tha? I dont think so. Admittedly I have no
experience of Code Warrior.
> be compared to other IDEs? (I'm not asking this in a challenging tone,
> mind you. I am really just asking for clarification.) What do you miss
> going to other environments?
Eclipse might be changing but much as it gives me a woody using gdb, its
pretty archaic compared to the visual studio debugger/development
environment. VS gave med define values in debugging, ability to use
symbolic values for message watch points etc. Maybe I missed something,
but gdb doesnt give me that.
>
> (I'll note in passing that the Linux develoment tools aren't standing
> still. E.g. gdb's MI (machine interface). Look it up, you might like
> it.
I tried. Do you have a link? I use gdb-ui : its ok, but basically pretty
crap comapared to even IBMs Visual Age.
> Eclipse likes it. :-> )
I need to look into eclipse some more but I have an inherent built in
disregard for anything written in Java :-;
>
> --
> Sincerely,
>
> Ray Ingles (313) 227-2317
>
> "I know you don't believe in God... but now you can try
> Him risk-free for 30 days!" - Monica Ingles
--
tha...@tux.glaci.remove-this.com
>
> Would you seriously compare the C/C++ development tools on Linux with
> those for Windows? By tools here I mean the IDEs & debuggers, not the
> compiler itself. Eclipse is a step in the right direction : a lot of
> the rest is half arsed. While the internals of GDB are powerful, the
> interfaces to it are a disaster. DDD is about the best and even that
> sucks compared to the Windows development equivalents - I use GDB-UI in
> emacs. Its kind of nice & retro :-;
I actually mostly agree with this assessment. Microsoft has done some
nice work with their IDE. Nevertheless, I have to give the edge to
linux because of access to operating system source code. This may not
seem an obvious benefit for those developers working on high level
application stuff... but the first time you are tracing an inscrutable
bug down into a windowing library or some such and hit that machine
code brick wall in the microsoft debugger... you'll understand what I
mean.
Thad
tha...@tux.glaci.remove-this.com
>
> Yuo are including and concentraing on the APIs. That wasnt my
> intention. I have developed on multiple platforms and find the windows
> IDEs to be incomparable. To be honest, the honest to god, basic win32
> API was ok too. Personally I think C++ rot is setting in : classes to
> fix classes etc : it sucks. How wonderful it seemed when we discovered
> that an apple and orange were both fruits and could share a common base
> class :)
Hah. I know what you mean. I've seen too many cases where people went
nuts with an object oriented approach just because they could, and did
not stop to think about if they should.
I used C++ and OO concepts in my Gridslammer game engine because it
made sense. Collision detection and such contained in a base class,
complex monsters inheriting from a primitive monster superclass...
the basic framework takes advantage of C++/OO features to be very
extensible. But for many other projects I still just code straight
C code, because thats all the job calls for.
Later,
Thad
tha...@tux.glaci.remove-this.com
>
> (I'll note in passing that the Linux develoment tools aren't standing
> still. E.g. gdb's MI (machine interface). Look it up, you might like it.
> Eclipse likes it. :-> )
completely like the UI design, but I can forgive that for some of
its niftier debugging features. Of course I'm still a VI heritic,
and never embraced the gospel of EMACS, so my views on user
interface matters should be taken with a grain of salt. :-/
Thad
Mark Kent
tha...@tux.glaci.remove-this.com <tha...@tux.glaci.remove-this.com> espoused:
The reason the Windows IDEs are as they are is a direct throwback from
DOS. Back in the DOS days, the introduction of the IDE (borland,
afairc) had a /massive/ impact on productivity, mainly because DOS was
so appallingly single-task.
Linux has not needed these fixes, so there has been little development.
I guess that if the Windows world starts to catch up with the Linux
world, maybe it could be considered, but at present, the gap is so huge,
I think it'll take more than a pretty IDE to get Windows something like
usable.
JEDIDIAH
>
>> On 2006-08-30, Hadron Quark <hadro...@gmail.com> wrote:
>>> Would you seriously compare the C/C++ development tools on Linux with
>>> those for Windows? By tools here I mean the IDEs & debuggers, not the
>>> compiler itself.
>>
>> I would seriously compare the *development environment* on Linux to
>> that of Windows, and Linux wins.
>
> Yuo are including and concentraing on the APIs. That wasnt my
> intention. I have developed on multiple platforms and find the windows
A good part of any sort of Engineering keeping the level of
chaos and complexity down. If your components merely add to the chaos
then it is going to be difficult to manage that even with speciality
tools specifically meant to help tame the chaos.
[deletia]
If you feel the need to use an IDE then the environment is
probably far too complex to be maintainable.
--
Nothing today, likely nothing since we tamed fire,
is genuinely new: culture, like science and |||
technology grows by accretion, each new creator / | \
building on the works of those that came before.
Judge Alex Kozinski
US Court of Appeals
9th Circuit
Hadron Quark
> Hadron Quark <hadro...@gmail.com> wrote:
>>
>> Would you seriously compare the C/C++ development tools on Linux with
>> those for Windows? By tools here I mean the IDEs & debuggers, not the
>> compiler itself. Eclipse is a step in the right direction : a lot of
>> the rest is half arsed. While the internals of GDB are powerful, the
>> interfaces to it are a disaster. DDD is about the best and even that
>> sucks compared to the Windows development equivalents - I use GDB-UI in
>> emacs. Its kind of nice & retro :-;
>
> I actually mostly agree with this assessment. Microsoft has done some
> nice work with their IDE. Nevertheless, I have to give the edge to
> linux because of access to operating system source code. This may not
That is nice. But to write *good* applications I think you should never
look at the underlying code. Why? Because you can code "workarounds". #1
rule : code to the API.
> seem an obvious benefit for those developers working on high level
> application stuff... but the first time you are tracing an inscrutable
> bug down into a windowing library or some such and hit that machine
> code brick wall in the microsoft debugger... you'll understand what I
> mean.
I do. But thats not the point.
>
> Thad
>
--
Hadron Quark
myFunc(&myObject, restOfDataPtr);
Done.
C++ is abused too often : because it can be.
Done right : fine. But how often is that the case?
I know.
>
> Later,
>
> Thad
>
--
tha...@tux.glaci.remove-this.com
>
> myFunc(&myObject, restOfDataPtr);
Yup, you see a lot of that sort of thing in the GTK source code. Its
fine in some cases but you can end up spending too much time managing
function pointers to make sure you running the right methods.
Thad
tha...@tux.glaci.remove-this.com
>
> That is nice. But to write *good* applications I think you should never
> look at the underlying code. Why? Because you can code "workarounds". #1
> rule : code to the API.
For me, its more a matter of having a complete understanding of what
is going on. Then when the framework spits back some incomprehensible
error message when I hand it a window object, I can actually know what
it is about that object that it did not like. In a perfect world the
API's would contain no bugs, actually work as documented, and the
documentation would explain all mysteries... but we both know that is
never the case.
Later,
Thad
Ray Ingles
> Ray Ingles <sorc...@localhost.localdomain> writes:
> The IDEs interfaced well to the APIs in windows. That is excellent. JIT
> compilie/debug too. Nice.
This isn't unique to Windows IDEs, though. And we're getting away from
my contention that such tools are less necessary under Linux...
> Windows API documentation was excellent, affordable and available. Did
> you ever try and get IBM to sell you their redbooks or the OS/2 PM/GPI
> manuals? Impossible. And expensive.
I'll cheerfully concede that Windows documentation was better and more
freely available than that for OS/2. Ya Got Me There.
Oh, wait, no you don't. I was comparing with *Linux*. You know, the OS
this newsgroup is about? :->
> Windows has a simple enough message driven system which *can* control the
> program - theres no "tie in" other than what the programmer decides. The
> controls invariably have a pointer back to program specific (not UI
> specific) data bindings/objects.
But, as the Petzold article I linked to notes, the IDE actively
discourages such separation.
> VS gave med define values in debugging, ability to use symbolic values
> for message watch points etc. Maybe I missed something, but gdb doesnt
> give me that.
You almost have something there. Eclipse will give you #define values,
and gdb has symbolic watchpoints, but the most recent version of the CDT
for Eclipse doesn't have symbolic watchpoints right now; you can drop
into the gdb console and set it yourself, though. I anticipate this
being resolved in the next release.
BTW, the gdb "machine interface" is specifically designed to make it
easier for programs (like Eclipse) to interact with gdb, bypassing the
human-readable interface.
> I need to look into eclipse some more but I have an inherent built in
> disregard for anything written in Java :-;
If you want to develop for Linux, and you like IDEs, I'd suggest
getting used to Eclipse. :->
--
Sincerely,
Ray Ingles (313) 227-2317
"There is a fundamental contradiction at the heart of the term
'intellectual property,' because information isn't transferred
between brains: it's copied." - Charles Stross
Ray Ingles
> That is nice. But to write *good* applications I think you should never
> look at the underlying code. Why? Because you can code "workarounds". #1
> rule : code to the API.
Why this doesn't always pan out in practice:
http://www.faqs.org/docs/artu/ch16s01.html
(Before you discount this story, note that the respected Joel Spolsky,
in an article I pointed to you, says this "will ring true to anyone who
has ever used a library in binary form.")
But you *can* get work done without the underlying source, if you pick
the right API. For one project that had to be portable, I stuck with the
basics - C file I/O, sockets, and pthreads. Then I stuck with the core
parts of those, abjuring the fancy stuff. And I wrote wrappers around
them, too.
That worked pretty well. It runs on a lot different platforms now -
Netware, at least seven flavors of Unix, OpenVMS, even Windows (because
I used wrappers, and stuck to common operations, I could replace the
pthreads stuff with Windows thread functions). There are a few kludges
in the wrappers, but overall it works quite well. Even on Netware, which
in older versions isn't even preemptively multitasking.
--
Sincerely,
Ray Ingles (313) 227-2317
The study concludes... that even though there is little data to prove
the effectiveness of zero-tolerance policies, such initiatives serve
to reassure the public that something is being done to ensure safety.
- http://www.nasponline.org/publications/cq298zero.html