Exciting news for Linux developers: now you can use Visual Studio?! Seriously?
RayLopez99
I am so excited by this news I just might switch to a Linux OS to
develop programs for it.
But, I have a sneaky suspicion this is not a "real" version of Visual
Studio and perhaps not all the libraries are supported by it. Anybody
can confirm my suspicion? Is this the complete library as found in VS
for Windows or are their holes?
Quick check: if anybody has this running in Linux, check to see if
the GeometryHitTestParameters class is present. It's a Windows based
class, but there should be an analog for Linux.
If it's too good to be true, it probably is (not true), as the saying
goes.
Still, it would be incredible if they Linux fools finally got a world
class API like Visual Studio. And btw thanks to Microsoft.
RL
Novell Delivers First Commercial Solution to Build .NET Applications
for Linux with Microsoft Visual Studio
Nov 10, 2009 08:30:00 (ET)
WALTHAM, Mass., Nov 10, 2009 /PRNewswire-FirstCall via COMTEX/ --
Novell today announced the availability of the first commercial
solution to facilitate the development of .NET applications for
Linux*, UNIX* and Mac* OS X within Microsoft* Visual Studio*. A
revolutionary new add-in module for Microsoft's Visual Studio
integrated development environment (IDE), Mono(R) Tools for Visual
Studio allows Microsoft .NET developers to utilize their familiar
Visual Studio environment to design, code and maintain multi-platform
applications. By significantly reducing the time and costs of multi-
platform development, Mono Tools enables corporate developers,
independent software vendors (ISVs) and development services providers
to quickly and easily expand their market opportunities and deployment
options.
"Microsoft Visual Studio is an integrated environment that helps
simplify the entire development process from design to deployment,"
said Cyrill Glockner, director of Business Development, Platform and
Tools, Microsoft Corp. "With the Microsoft Visual Studio Industry
Partner program (VSIP), we support the development of tools that
seamlessly integrate with Microsoft Visual Studio and help our
customers achieve success. Mono Tools for Visual Studio enriches the
Visual Studio ecosystem, making it possible for the over six million
engineers targeting .NET to gain additional value from their Microsoft
tools and skills."
Mono Tools for Visual Studio is a commercial solution that enables C#
and .NET developers trained in Microsoft Visual Studio to stay within
their preferred IDE, and use their existing skills and extensive .NET
ecosystem of code, libraries and tools to develop or port applications
to Linux, UNIX or Mac OS X. Prior to Mono Tools, .NET application
porting required developers to invest heavily in learning new
programming tools and rewriting/re-architecting applications. With
Mono Tools, developers trained in the popular Visual Studio IDE can
utilize their existing skills and expertise to build multi-platform
applications and identify related issues, isolating and fixing them
directly within Visual Studio.
"While Linux presents software vendors with a host of new
opportunities, developers familiar with .NET tools can find Linux
application development tools challengingly different and unsuitable
for their needs," said Al Hilwa, program director, Application
Development Software at IDC. "Products like Mono Tools that
enable .NET developers to better leverage the Linux platform increase
their market opportunities and ultimately strengthen the reach of
the .NET environment itself."
Pablo Santos, CEO at Codice Software, said, "Our customers want
options for Linux, as well as UNIX, Mac OS X and Windows, so multi-
platform support is a critical feature for us to offer in our product.
Plastic SCM, our flagship software configuration management product,
is largely implemented in C# because we find it to be the most
productive language. By using Mono Tools for Visual Studio, we can now
develop and debug on Linux quickly and easily using our preferred
programming language and development environment."
Unique multi-platform development from within Visual Studio
Mono Tools is an add-in module to Microsoft Visual Studio. It is built
by many of the engineers who develop and support Mono, an open source
project sponsored by Novell. Through a pull-down menu and other
integration points in Visual Studio, Mono Tools enables developers to
leverage the multi-platform coding, testing and debugging
functionality of the Mono platform, all while staying within Visual
Studio.
Key features of Mono Tools for Visual Studio include:
-- Development and porting of .NET applications to Linux, UNIX
and Mac OS X
with analysis, testing, debugging and deployment all from
within Visual
Studio. Using Mono Tools for Visual Studio, ISVs, corporate
developers
and development services providers can dramatically cut the
costs of
multi-platform application development and save time in
porting existing
.NET applications to non-Windows platforms.
-- Creation of turnkey virtual appliances and software appliances
for .NET
applications using integrated appliance building
functionality. Mono
Tools for Visual Studio delivers out-of-the-box integration
with SUSE(R)
Studio Online, an innovative, easy-to-use hosted tool that
enables users
to rapidly build and test appliances based on SUSE Linux
Enterprise
Server or openSUSE(R). ISVs and development services providers
can
immediately fulfill demand for appliance versions of their
existing
applications, thus increasing revenue opportunities while
simplifying
application support and accelerating sales cycles.
-- Integrated porting analysis tools that provide .NET developers
a
road-map to Linux, Mac OS X and UNIX. Many .NET developers
today lack an
approach or even an idea of where to begin an application port
to
non-Windows platforms, a challenge quickly solved with Mono
Tools.
-- Ability to run and debug applications in Mono within Visual
Studio to
isolate incompatibilities between Mono and .NET and between
Linux and
Windows* - issues which may affect cross-platform application
development.
-- Automated packaging for SUSE Linux Enterprise Server and
openSUSE to
prepare applications for immediate deployment on Linux.
"With Mono Tools for Visual Studio, we are bridging the gap between
Visual Studio, one of the world's leading development platforms, and
Linux, one of the world's leading deployment platforms," said Miguel
de Icaza, Mono project founder and vice president of Developer
Platforms at Novell. "Customers have been asking us for an easier,
more simple and streamlined process to port their .NET applications to
Linux, UNIX and Mac. By integrating our tools right into Visual
Studio, we are enabling developers familiar with Windows and .NET to
quickly bring their applications to the Linux market, and ISVs to
offer their software as ready-to-run appliances."
Mono Tools Pricing and Availability
Mono Tools for Visual Studio is available now. Three product editions
are available: Professional Edition (individual) for $99, Enterprise
Edition (one developer in an organization) for $249, and Ultimate
Edition for $2,499 which provides a limited commercial license to
redistribute Mono on Windows, Linux and Mac OS X and includes five
enterprise developer licenses. All product versions include a one-year
subscription for product updates.
To learn more about Mono Tools for Visual Studio and download a free
30-day trial visit www.novell.com/monotools . To learn more about the
Mono Project visit www.mono-project.com .
About Novell
Novell, Inc. (NOVL, Trade ) delivers the best engineered, most
interoperable Linux platform and a portfolio of integrated IT
management software that helps customers around the world reduce cost,
complexity and risk. With our infrastructure software and ecosystem of
partnerships, Novell harmoniously integrates mixed IT environments,
allowing people and technology to work as one. For more information,
visit www.novell.com .
Novell, Mono, openSUSE and SUSE are registered trademarks of Novell,
Inc. in the United States and other countries. *All third-party
trademarks are the property of their respective owners.
SOURCE Novell, Inc.
RayLopez99
>
> Novell Delivers First Commercial Solution to Build .NET Applications
> for Linux with Microsoft Visual Studio
>
> Nov 10, 2009 08:30:00 (ET)
>
> WALTHAM, Mass., Nov 10, 2009 /PRNewswire-FirstCall via COMTEX/ --
> Novell today announced the availability of the first commercial
> solution to facilitate the development of .NET applications for
> Linux*, UNIX* and Mac* OS X within Microsoft* Visual Studio*. A
> revolutionary new add-in module for Microsoft's Visual Studio
> integrated development environment (IDE), Mono(R) Tools for Visual
> Studio allows Microsoft .NET developers to utilize their familiar
> Visual Studio environment to design, code and maintain multi-platform
> applications.
Wait--rereading this it seems that this is a tool to allow you to port
to Linux, from within Windows? If so, even better for me, as I don't
want to go through the hassle of installing Linux.
RL
Hadron
> Visual Studio for Linux? Are they serious?
>
> I am so excited by this news I just might switch to a Linux OS to
> develop programs for it.
>
> But, I have a sneaky suspicion this is not a "real" version of Visual
> Studio and perhaps not all the libraries are supported by it. Anybody
> can confirm my suspicion? Is this the complete library as found in VS
> for Windows or are their holes?
>
> Quick check: if anybody has this running in Linux, check to see if
> the GeometryHitTestParameters class is present. It's a Windows based
> class, but there should be an analog for Linux.
>
> If it's too good to be true, it probably is (not true), as the saying
> goes.
>
> Still, it would be incredible if they Linux fools finally got a world
> class API like Visual Studio. And btw thanks to Microsoft.
VS is an IDE. Not an API. Ask Liarmutt : he uses it apparently.
Jan Panteltje
<raylo...@gmail.com> wrote in
<bd339471-5f61-4a7c...@p28g2000vbi.googlegroups.com>:
Yea, it would be typical for an MS programmer not to bother to test their products on the intended platforms.
.NET is dead, MS is dead, Novel is in bed with MS, and basically betrayed open source.
Visual Studio is an idiot application, the last thing I would want is it polluting
my Linux system, programming would become frustrating with such a GUI monster.
So, I dunno why you post here, but let's see your first Linux application made with Visual Stupido^H^H^H^Hdio,
that actually does something new, and runs without problems.
Rainer Weikusat
> On Nov 10, 10:25�am, RayLopez99 <raylope...@gmail.com> wrote:
>> Novell Delivers First Commercial Solution to Build .NET Applications
>> for Linux with Microsoft Visual Studio
In other news, it was reported that a sack of rice has fallen off a
lorry in southern China. Stay tuned ...
RonB
Really?! A *whole* sack of rice?... in southern China? Whoa!
--
RonB
"There's a story there...somewhere"
Ryan McCoskrie
gcc /g++/perl/python/$SHELL, Vim, make, sed and svn are a much more
flexible and powerful combination. I don't know how you put up IDE's.
Chris Ahlstrom
> RayLopez99 wrote:
>
> gcc /g++/perl/python/$SHELL, Vim, make, sed and svn are a much more
> flexible and powerful combination. I don't know how you put up IDE's.
Amen.
--
You get along very well with everyone except animals and people.
Rainer Weikusat
In addition to this, which could be called a matter of taste (I
wouldn't agree with such a statement), IDEs have the very important
shortcoming that the 'main development computer' must be identical
to the 'personal workstation' of the the developer, because code is
supposed to be edited, compiled, run and debugged using the same
program (which happens to run there). This is typically true for all
one type of development visual studio circus rider are familiar with
(develop simple, GUI-based end-user applications) and thus, tend to
confuse with 'development' as such, but this is a lack of knowledge/
experience and does not beget facts -- for me, the computer I am
running a text editor and web browser on is rarely, if ever, the
computer were the source code resides on or which is supposed to run the
application and often, there is a considerable distance between the
two, such as the distance between Germany and the US east cost.
BTW, in my opinion, the typical mark of 'a fool' is the blind
assumption that one's personal and always necessarily limited
experience would encompass all that could be experienced in this
universe and to call everyone whose experience are actually different
'a fool' (another would be the conviction to never make serious
mistakes, IOW, to never understand the mistakes which have been and
are being made).
cc
> Ryan McCoskrie pulled this Usenet boner:
>
> > RayLopez99 wrote:
>
> > gcc /g++/perl/python/$SHELL, Vim, make, sed and svn are a much more
> > flexible and powerful combination. I don't know how you put up IDE's.
>
> Amen.
>
I've used my share of vi and make, but I've always prefered an IDE.
Just for pure convenience, especially when working with legacy code.
Hadron
Ahlstrom is showing off once more. A good "IDE" simply brings the tools
together. It "integrates" the development environment.
RayLopez99
> Ryan McCoskrie <ryan.mccosk...@invalid.invalid> writes:
> > RayLopez99 wrote:
>
> > gcc /g++/perl/python/$SHELL, Vim, make, sed and svn are a much more
> > flexible and powerful combination. I don't know how you put up IDE's.
>
> In addition to this, which could be called a matter of taste (I
> wouldn't agree with such a statement), IDEs have the very important
> shortcoming that the 'main development computer' must be identical
> to the 'personal workstation' of the the developer, because code is
> supposed to be edited, compiled, run and debugged using the same
> program (which happens to run there). This is typically true for all
> one type of development visual studio circus rider are familiar with
> (develop simple, GUI-based end-user applications) and thus, tend to
> confuse with 'development' as such, but this is a lack of knowledge/
> experience and does not beget facts -- for me, the computer I am
> running a text editor and web browser on is rarely, if ever, the
> computer were the source code resides on or which is supposed to run the
> application and often, there is a considerable distance between the
> two, such as the distance between Germany and the US east cost.
Well you can always switch to a server-based application, such as ASP,
no? Besides, why should software be written on one machine to work on
another, entirely different machine (unless it's a server side
solution)? That makes no sense (nonsense), as any computer scientist
worth their salt will tell you software is written, at the machine
level, for the machine it resides on.
>
> BTW, in my opinion, the typical mark of 'a fool' is the blind
> assumption that one's personal and always necessarily limited
> experience would encompass all that could be experienced in this
> universe and to call everyone whose experience are actually different
> 'a fool' (another would be the conviction to never make serious
> mistakes, IOW, to never understand the mistakes which have been and
> are being made).
Conservative = fool? My liberal friends / fiends would agree. But if
Iceland and Greenland are very conservative, as written about by Jared
Diamond in his book "Collapse", then that makes them all fools, no?
And witness this: "If you've been at the poker table for 30 minutes
and you don't know who the fool is, you're the fool".
So who's the fool in this thread?
RL
RayLopez99
>
> Ahlstrom is showing off once more. A good "IDE" simply brings the tools
> together. It "integrates" the development environment.
So Hadron, what do you think of the new 'functional' language GO (not
the game, the language, see here: http://golang.org/doc/go_tutorial.html
)
You're a big fan of functional language, no?, where you cram 10 lines
of code into one, usually with obscure syntax. Think Regex, LINQ
(which I've gotten the hang of), etc.
I prefer C#, which is less terse but makes more sense to me, though it
can get verbose, as C/C++ can.
RL
Tom Shelton
MS is introducing a new functional programing language with VS2010 -
F#. It's based on OCaml. I've found it very interesting to play with
it...
--
Tom Shelton
Chris Ahlstrom
> cc <scat...@hotmail.com> writes:
>
>> On Nov 10, 8:16??pm, Chris Ahlstrom <ahlstr...@launchmodem.com> wrote:
>>> Ryan McCoskrie pulled this Usenet boner:
>>>
>>> > RayLopez99 wrote:
>>>
>>> > gcc /g++/perl/python/$SHELL, Vim, make, sed and svn are a much more
>>> > flexible and powerful combination. I don't know how you put up IDE's.
>>>
>>> Amen.
>>
>> I've used my share of vi and make, but I've always prefered an IDE.
>> Just for pure convenience, especially when working with legacy code.
>
> Ahlstrom is showing off once more.
How so? Is it really *that* remarkable? Or is "Hadron" a pubeless newb who is
easily impressed?
I've been coding for a decade and a half, using all sorts of tools, and I
most prefer to use separate tools.
> A good "IDE" simply brings the tools
> together. It "integrates" the development environment.
Spoken like a guy who is stuck with a single editor, a single compiler, and
a single debugger.
--
Although he does have a point about vi. vi is garbage. And the only
people who stick with it do it for "kewl" points. It comes with a free
pony tail and bad breath. I dare you to Google up how often Ahlstrom
mentions vim to fellow advocates for hardcore points. You will be
amazed.
-- "Hadron"
chrisv
>Hadron quacked:
>>
>> A good "IDE" simply brings the tools
>> together. It "integrates" the development environment.
>
>Spoken like a guy who is stuck with a single editor, a single compiler, and
>a single debugger.
Poor Quack. Spanked again.
--
"I develop software for a living" - Larry "message ID" Qualig
cc
> Chris Ahlstrom wrote:
> >Hadron quacked:
>
> >> A good "IDE" simply brings the tools
> >> together. It "integrates" the development environment.
>
> >Spoken like a guy who is stuck with a single editor, a single compiler, and
> >a single debugger.
>
> Poor Quack. Spanked again.
>
How so? Both are right. It's kind of a personal preference thing. IDEs
aren't useless, and they aren't necessary either. This is turning into
the debugger argument that those jackasses in clc argue about all the
time.
Hadron
> On Nov 11, 1:09 pm, chrisv <chr...@nospam.invalid> wrote:
>> Chris Ahlstrom wrote:
>> >Hadron quacked:
>>
>> >> A good "IDE" simply brings the tools
>> >> together. It "integrates" the development environment.
>>
>> >Spoken like a guy who is stuck with a single editor, a single compiler, and
>> >a single debugger.
Huh?
I use Emacs as my "IDE". I use it to bring together all the tools I
need. As does Vim of course.
You really are a clueless twat.
>>
>> Poor Quack. Spanked again.
>>
>
> How so? Both are right. It's kind of a personal preference thing. IDEs
> aren't useless, and they aren't necessary either. This is turning into
> the debugger argument that those jackasses in clc argue about all the
> time.
IDE and "external" tools are not mutually exclusive. Any good IDE allows
you to configure which external tools are used for your tool chain.
Terry Porter
> Hadron pulled this Usenet boner:
<snip>
>>
>> Ahlstrom is showing off once more.
>
> How so? Is it really *that* remarkable? Or is "Hadron" a pubeless newb
> who is easily impressed?
>
> I've been coding for a decade and a half, using all sorts of tools, and
> I most prefer to use separate tools.
>
>> A good "IDE" simply brings the tools
>> together. It "integrates" the development environment.
>
> Spoken like a guy who is stuck with a single editor, a single compiler,
> and a single debugger.
Yes, sounds like someone who has never had to actually create software,
and just copied some advert for a IDE.
It also sounds like someone who has *no idea* how versatile separate
tools can be.
It sounds like a clueless troll to me.
--
This machine running Gnu/Linux Ubuntu 9.10 and posting via Pan.
Get your Free copy NOW! http://www.ubuntu.com/
Chris Ahlstrom
> On Nov 11, 1:09?pm, chrisv <chr...@nospam.invalid> wrote:
>> Chris Ahlstrom wrote:
>> >Hadron quacked:
>>
>> >> A good "IDE" simply brings the tools
>> >> together. It "integrates" the development environment.
>>
>> >Spoken like a guy who is stuck with a single editor, a single compiler, and
>> >a single debugger.
>>
>> Poor Quack. ?Spanked again.
>
> How so? Both are right. It's kind of a personal preference thing. IDEs
> aren't useless, and they aren't necessary either. This is turning into
> the debugger argument that those jackasses in clc argue about all the
> time.
It is mostly preference... do you like having all your tools slowed down by
integration into a GUI? Besides, you can usually plug other editors
compilers debuggers into IDEs.
Finally, if "Hadron" really is the Emacs guy he claims, then he's got his
editor compiler debugger embedded in along with his Gnus.
--
Using emacs doesn't mean you can't be an asshole, too.
Hadron
> cc pulled this Usenet boner:
>
>> On Nov 11, 1:09?pm, chrisv <chr...@nospam.invalid> wrote:
>>> Chris Ahlstrom wrote:
>>> >Hadron quacked:
>>>
>>> >> A good "IDE" simply brings the tools
>>> >> together. It "integrates" the development environment.
>>>
>>> >Spoken like a guy who is stuck with a single editor, a single compiler, and
>>> >a single debugger.
>>>
>>> Poor Quack. ?Spanked again.
>>
>> How so? Both are right. It's kind of a personal preference thing. IDEs
>> aren't useless, and they aren't necessary either. This is turning into
>> the debugger argument that those jackasses in clc argue about all the
>> time.
>
> It is mostly preference... do you like having all your tools slowed down by
> integration into a GUI? Besides, you can usually plug other editors
> compilers debuggers into IDEs.
How are they slowed down? What total and utter nonsense. The only "slow
down" is the piping into the relevant error/status buffers where any
half decent IDE (vim/emacs etc included) then lets you hot key between
the pertinent points.
Its not a sacrilege for you to acknowledge that often a well configured
IDE can and does a wonderful job : it does NOT mean you use sub standard
tools in the tool chain - invariably they are the SAME just pulled in
together into a INTEGRATED DEVELOPMENT ENVIRONMENT.
>
> Finally, if "Hadron" really is the Emacs guy he claims, then he's got his
> editor compiler debugger embedded in along with his Gnus.
Do TRY and read the bloody thread. That is EXACTLY what I said. Emacs
and the tools I use IS the "IDE".
Rainer Weikusat
[...]
> Its not a sacrilege for you to acknowledge that often a well configured
> IDE can and does a wonderful job
Well, it doesn't. At best, it is redundant, at worst, harmful. I am
willing to concede that the idea of using multiple programs in
parallell instead of interacting with a single program which contains
'everything' is probably simply too complicated for many people,
presumably closely overlapping the set of people who cannot really
deal with multi-threading and abhor the idea of stateful objects
changing over time because this, too, is something beyond them[*]. It
is neverthless both convenient and powerful because, as I already
wrote, different computers can be used for different tasks, say,
compile on the machine with the fastest disk and run the editor were
the GUI happens to be installed. Perhaps this is somewhat more
accessible to people to whom my distributed development because of
technical necessities, and then even programs without any end-user
interface whatsoever, sounded more like a fable. It was nevertheless
true.
[*] Coming to think of this, a coffee-maker must be a
nightmare machine well beyond the limits of human control to a
pure-breed functional programming advocate. This could also
explain why 'men' apparently cannot operate flushing toilets
:->.
Chris Ahlstrom
> Chris Ahlstrom <ahls...@launchmodem.com> writes:
>>
>> It is mostly preference... do you like having all your tools slowed down by
>> integration into a GUI? Besides, you can usually plug other editors
>> compilers debuggers into IDEs.
>
> How are they slowed down? What total and utter nonsense. The only "slow
> down" is the piping into the relevant error/status buffers where any
> half decent IDE (vim/emacs etc included) then lets you hot key between
> the pertinent points.
Either the IDE is single-threaded, in which case running the debugger while
other code is compiling is not possible, and you have to serialize all of
your actions, or it is multithreaded, which means contention (hourglasses)
and probably more bugs.
Apparently you never compared build times in a Visual Studio with build
times using make (especially on Linux). There's a reason Microsoft added
incremental building and precompiled headers (which I've never found to work
correctly in VS or Borland), and why builds go faster (once autoconf has
done its job) on Linux than on Windows.
> Its not a sacrilege for you to acknowledge that often a well configured
> IDE can and does a wonderful job : it does NOT mean you use sub standard
> tools in the tool chain - invariably they are the SAME just pulled in
> together into a INTEGRATED DEVELOPMENT ENVIRONMENT.
Depends on the IDE, and how much work you want to put into reconfiguring it.
My main point is that they are bulky and slow. Also Ryan (IIRC) and his
point about running different processes on different machines.
Is there anything like distcc for Visual Studio?
>> Finally, if "Hadron" really is the Emacs guy he claims, then he's got his
>> editor compiler debugger embedded in along with his Gnus.
>
> Do TRY and read the bloody thread. That is EXACTLY what I said. Emacs
> and the tools I use IS the "IDE".
Whatever. Your misstatements and miscomprehension are becoming legendary.
I would agree that I'd rather use an emacs "IDE" than, say, Visual Studio.
--
Your love life will be... interesting.
Chris Ahlstrom
> Hadron <hadro...@gmail.com> writes:
>
>> Its not a sacrilege for you to acknowledge that often a well configured
>> IDE can and does a wonderful job
Always with the exaggeration! "Hyperbolic Hadron", they called him.
> <snip>
>
> Perhaps this is somewhat more
> accessible to people to whom my distributed development because of
> technical necessities, and then even programs without any end-user
> interface whatsoever, sounded more like a fable. It was nevertheless
> true.
I remember talking with a hard-core .NET guy about my preference for the
separate tools, and he basically said he admired me for it, that such a
paradigm was, in some sense, too tough for him. Strange. It was what
I grew up with. I figure any coder who has dug into complex projects and
got them debugged ought to be able to handle "non-integrated" tools, so I am
puzzled when such a person cavils about complexity.
Now, I remember preferring IDEs in my DOS/Win3/WinNT3/4 days, but that was
because the console and standalone editors for those platforms were bad.
(My favorite DOS IDE was Borland's TurboVision; and with overlays, you could
write some huge DOS programs.)
--
"...The name of the song is called 'Haddocks' Eyes'!"
"Oh, that's the name of the song, is it?" Alice said, trying to
feel interested.
"No, you don't understand," the Knight said, looking a little
vexed. "That's what the name is called. The name really is, 'The Aged
Aged Man.'"
"Then I ought to have said "That's what the song is called'?"
Alice corrected herself.
"No, you oughtn't: that's quite another thing! The song is
called 'Ways and Means': but that's only what it is called you know!"
"Well, what is the song then?" said Alice, who was by this
time completely bewildered.
"I was coming to that," the Knight said. "The song really is
"A-sitting on a Gate": and the tune's my own invention."
-- Lewis Carroll, "Through the Looking Glass"
Ezekiel
"Chris Ahlstrom" <ahls...@launchmodem.com> wrote in message
news:hdgu7b$88f$1...@news.eternal-september.org...
> Hadron pulled this Usenet boner:
>
>> Chris Ahlstrom <ahls...@launchmodem.com> writes:
>>>
>>> It is mostly preference... do you like having all your tools slowed
>>> down by
>>> integration into a GUI? Besides, you can usually plug other editors
>>> compilers debuggers into IDEs.
>>
>> How are they slowed down? What total and utter nonsense. The only "slow
>> down" is the piping into the relevant error/status buffers where any
>> half decent IDE (vim/emacs etc included) then lets you hot key between
>> the pertinent points.
>
Wow.... you really are clueless about how these things actually work.
> Either the IDE is single-threaded, in which case running the debugger
> while
> other code is compiling is not possible, and you have to serialize all of
> your actions, or it is multithreaded, which means contention
> (hourglasses)
> and probably more bugs.
So the "leap" here is that if it's multithreaded (which it is - you don't
seem to know) it's going to have more bugs or automatic contention. For
starters an "hourglass" is only displayed when there's long wait times for
something. Apps have micro-second contentions all the time and don't put up
an hourglass each time it happens.
> Apparently you never compared build times in a
> Visual Studio with build times using make (especially on Linux).
Apparently you've never compared the price of tea in China to the cost of a
subway pass in Detroit. And *exactly* what do "build times" tell you about
the overhead of an IDE??? Perhaps I have a brain that actually works or
something but to me the differences in the underlying file-system and
things like the differences in the gcc compiler vs. the Microsoft compiler
would be the predominant factors. But when you see some difference here you
completely disregard these MAJOR items and figure it's just IDE vs.
non-IDE.
> There's a reason Microsoft added
> incremental building and precompiled headers
And the reason has *nothing* to do with an IDE. It's because computers and
HDD's used to be slow and limited in memory. These were introduced when
Windows released because files like "windows.h" were very large and never
changed so it didn't make sense to for the preprocessor to keep reading and
parsing the file each time. But in your "knowledge" you think this had
something to do with runnin in a IDE do you?????
> (which I've never found to work correctly in VS or Borland),
And it's always worked fine for me and millions of other people. Gee....
everyone but you somehow managed to figure out how to use it correctly.
> and why builds go faster (once autoconf has
> done its job) on Linux than on Windows.
Builds go faster because of differences in the *filesystem* and differences
in the *compiler* - it's completely ridiculous to account for the time
difference because one runs in an IDE and the other doesn't. (You can also
use devenv to compile outside of the IDE.) There's advantages and
disadvantages to using different tools and it's a matter of personal
preference. But to claim that there's some sort of huge performance
advantage to compile-times because of the IDE is utterly ridiculous.
chrisv
>> Hadron <hadro...@gmail.com> writes:
>>>
>>> Its not a sacrilege for you to acknowledge that often a well configured
>>> IDE can and does a wonderful job
>
>Always with the exaggeration! "Hyperbolic Hadron", they called him.
Indeed. Transparently, shamelessly dishonest.
--
"What a joke you and your "William Poaster" alias are. If you had any
credibility you would not hide behind some phoney alias." - Larry
"message ID" Quack, claiming that William Poaster was a chrisv sock.
cc
> cc pulled this Usenet boner:
>
>
>
>
>
> > On Nov 11, 1:09?pm, chrisv <chr...@nospam.invalid> wrote:
> >> Chris Ahlstrom wrote:
> >> >Hadron quacked:
>
> >> >> A good "IDE" simply brings the tools
> >> >> together. It "integrates" the development environment.
>
> >> >Spoken like a guy who is stuck with a single editor, a single compiler, and
> >> >a single debugger.
>
> >> Poor Quack. ?Spanked again.
>
> > How so? Both are right. It's kind of a personal preference thing. IDEs
> > aren't useless, and they aren't necessary either. This is turning into
> > the debugger argument that those jackasses in clc argue about all the
> > time.
>
> It is mostly preference... do you like having all your tools slowed down by
> integration into a GUI? Besides, you can usually plug other editors
> compilers debuggers into IDEs.
I don't feel like my tools are slowed down by integration into a GUI.
Even if it were true, it would have be a slow down on a miniscule
level. I think the benefits *I* get from using an IDE outway any small
performance hit. But like you said, it's preference.
Hadron
There is no slowdown of any measurable amount.
Running a process like gcc as a process and piping the output to an
emacs based output processor is hardly any overhead at all : and the
advantages are many.
Liarmutt is talking through his backside again and trying to promote
this "lean and mean old school" techy image.
Hadron
> Hadron pulled this Usenet boner:
>
>> Chris Ahlstrom <ahls...@launchmodem.com> writes:
>>>
>>> It is mostly preference... do you like having all your tools slowed down by
>>> integration into a GUI? Besides, you can usually plug other editors
>>> compilers debuggers into IDEs.
>>
>> How are they slowed down? What total and utter nonsense. The only "slow
>> down" is the piping into the relevant error/status buffers where any
>> half decent IDE (vim/emacs etc included) then lets you hot key between
>> the pertinent points.
>
> Either the IDE is single-threaded, in which case running the debugger while
> other code is compiling is not possible, and you have to serialize all of
> your actions, or it is multithreaded, which means contention (hourglasses)
> and probably more bugs.
What are you talking about? Nonsense.
>
> Apparently you never compared build times in a Visual Studio with build
> times using make (especially on Linux). There's a reason Microsoft
> added
Err, I have.
> incremental building and precompiled headers (which I've never found to work
> correctly in VS or Borland), and why builds go faster (once autoconf has
> done its job) on Linux than on Windows.
What the fuck has incremental header or anything like it go to do with
it? Features of GCC (staying on the one platform ...) are avilable in an
IDE or not. Depends how you set it up.
>
>> Its not a sacrilege for you to acknowledge that often a well configured
>> IDE can and does a wonderful job : it does NOT mean you use sub standard
>> tools in the tool chain - invariably they are the SAME just pulled in
>> together into a INTEGRATED DEVELOPMENT ENVIRONMENT.
>
> Depends on the IDE, and how much work you want to put into
> reconfiguring it.
Duh.
>
> My main point is that they are bulky and slow. Also Ryan (IIRC) and his
> point about running different processes on different machines.
Bullshit.
I use emacs to edit code. firing up gdb inside it and then being able to
navigate etc is a HUGE performance increase. In this case Emacs is the
IDE. Why are you SO single minded.
I know you're a Windows programmer but VS is NOT the only IDE you know.
>
> Is there anything like distcc for Visual Studio?
You tell me. You're the VS user.
>
>>> Finally, if "Hadron" really is the Emacs guy he claims, then he's got his
>>> editor compiler debugger embedded in along with his Gnus.
>>
>> Do TRY and read the bloody thread. That is EXACTLY what I said. Emacs
>> and the tools I use IS the "IDE".
>
> Whatever. Your misstatements and miscomprehension are becoming legendary.
> I would agree that I'd rather use an emacs "IDE" than, say, Visual
> Studio.
Why "IDE"? It IS an IDE.
--
Ezekiel
"Hadron" <hadro...@gmail.com> wrote in message
news:hdh6b1$4tl$2...@news.eternal-september.org...
The *fact* is that whether you're running the compiler through an IDE or a
console window the compiler will *always* write it's output to stdout and
stderr. That's just how it works. In once case the IDE reads from
stdout/stderr and displays the compilers output in it's console-like
terminal window and in the case of a running a compiler in a console window,
it does the exact same thing.
Ezekiel
>"cc" <scat...@hotmail.com> wrote in message
>news:5c09aefc-c2c6-405f...@o10g2000yqa.googlegroups.com...
Look at it this way - whether you use an IDE or a "console" application, in
both cases the compiler/linker writes its output to stdout and stderr. In
both cases the IDE and console read from stdout/stderr and display the
output. What exactly is the difference between a console application
displaying this output and the IDE displaying this output? There is no
difference.
Hadron
> Hadron <hadro...@gmail.com> writes:
>
> [...]
>
>> Its not a sacrilege for you to acknowledge that often a well configured
>> IDE can and does a wonderful job
>
> Well, it doesn't. At best, it is redundant, at worst, harmful. I am
> willing to concede that the idea of using multiple programs in
Because you are too stuck in the mud to actually learn what one is not
really the issue.
> parallell instead of interacting with a single program which contains
> 'everything' is probably simply too complicated for many people,
> presumably closely overlapping the set of people who cannot really
And clearly the whole concept of an IDE is unknown to you.
once more:
A good IDE is NOT "one program". It is a framework holding the different
tools together.
Emacs is my IDE.
Whoever said all these tools are "working in parallel"? What ARE you
talking about???
gcc, gdb and split are all used inside emacs. As are ediff and git for
revision management. I use flymake. All inside the one frame. It is an
IDE. Similar for Eclipse for example or code::blocks.
Is it SO complicated for you and Ahlstrom to see how hitting one key to
compile a quick change and seeing the errors hilited correctly in a new
pane and being able to jump directly to the error can be useful? What is
wrong with you?
An IDE is not necessarily a large lumbering behemoth which create crap
programmers.
> deal with multi-threading and abhor the idea of stateful objects
> changing over time because this, too, is something beyond them[*]. It
Oh god. Another guy blowing hot air and accusing others of being too
dense.
> is neverthless both convenient and powerful because, as I already
> wrote, different computers can be used for different tasks, say,
Thats nice. Thanks for that gem.
> compile on the machine with the fastest disk and run the editor were
> the GUI happens to be installed. Perhaps this is somewhat more
> accessible to people to whom my distributed development because of
> technical necessities, and then even programs without any end-user
> interface whatsoever, sounded more like a fable. It was nevertheless
> true.
>
> [*] Coming to think of this, a coffee-maker must be a
> nightmare machine well beyond the limits of human control to a
> pure-breed functional programming advocate. This could also
> explain why 'men' apparently cannot operate flushing toilets
> :->.
>
That's some nice philosophising. Quite what you're trying to prove is
anyones guess :-)
RayLopez99
>
> MS is introducing a new functional programing language with VS2010 -
> F#. It's based on OCaml. I've found it very interesting to play with
> it...
Fashion is fashion, and with lambda, functional programs, anonymous
delegates, extension methods and LINQ this is to be expected. I might
tip my toe in it, like I have with LINQ, and lazy loading, etc, does
help on occasion, at a cost of having to learn yet another programming
language.
RL
F# is a strongly typed language that uses type inference. As a result,
data types need not be explicitly declared by the programmer; they
will be deduced by the compiler during compilation. However, F# also
allows explicit data type declaration. Being a .NET language, F#
supports .NET types and objects. But it extends the type system and
categorizes types as immutable types or mutable types. .NET objects
classify as mutable types (which can be edited in-place), and are used
to provide an object-oriented programming model. Immutable types
(editing which creates a new instance without overwriting the older
one) are primarily used for functional programming.
RayLopez99
>
> Either the IDE is single-threaded, in which case running the debugger while
> other code is compiling is not possible, and you have to serialize all of
> your actions, or it is multithreaded, which means contention (hourglasses)
> and probably more bugs.
>
Stupido. You claim to write all your code multi-threaded? It's full
of bugs then. Only a handful of programmers do error-free mult-
threading, and from the frequent number of posts here, you're not one
of them, else you'd not have enough time to post your garbage.
Until they work out a way to parallelize instructions at the
instruction set, via the compiler, 99% of serious programmers stick,
when at all possible, to single thread, unless for trivial stuff like
waiting for the database to respond for select methods, etc.
Troll!
RL
Hadron
The only difference is that in an IDE its almost certainly then filtered
and routed off to wherever. The overhead is almost non existent
however. Chris is spouting his usual mantras to pretend to be a hard
core code jockey who disdains modern conveniences. The fact he doesn't
even appear to know what an IDE is (he thinks VS is the only IDE it
seems) is not the issue.
We wont even go into Liarmutt's nonsense about compile times since
99.99% of compiles are done properly based on modified files (Makefiles
anyone?) and usually are one or two modules : i'd like to see him make a
decent argument that the overhead of some error filtering adversely
affects that. I'd bet a penny to the pound that redirecting errors to an
erro file, opening it in an editor and then manually navigating it
greatly out numbers that of using the IDE to make it one sweet tool
chain experience.
Hadron
Of course. How Chris seems to unaware of this is astonishing. The only
"overhead" is the processing the IDE does to format/hotlink/pretty print
etc the output. Which might will be done anyway in the "hard core"
tty/term method Chris is espousing anyway with sed/awk/redirct to error
file etc etc etc.
I'm beginning to wonder if he is a programmer at all.
Tom Shelton
> Hadron pulled this Usenet boner:
>
>
<snip>
> My main point is that they are bulky and slow. Also Ryan (IIRC) and his
> point about running different processes on different machines.
>
Ummm... I do that all the time. Oh, I build and debug on my local
machine for debugging, but my distribution builds are built on a build
server using CC.NET and msbuild from the command line.
I'm not sure what all the fuss is about. An IDE simply pulls together
tools into a central location. There is almost no part of VS that
can't be replaced with a different tool if you don't like the one that
comes with it.
Using VS does not limit you to the local machine. You can debug
attach to and debug process on other machines - assuming you have
remote debugging configured. So, the process your debugging doesn't
even have to reside on your machine. You can configure your build
process to do just about anything - at my last job I had a build
profile that would compile a release mode build, zip it up, and ftp it
to a release server. It would then send a http request to a in house
release server telling it to refresh it's database of current
builds....
Is an IDE appropriate for all occasions? No. But, for many kinds of
development they can make a big difference in developer productivity -
and in the world I live in, time is money baby!
> Is there anything like distcc for Visual Studio?
>
There are several commercial offerings that offer distributed
compilation in VS.
--
Tom Shelton
Hadron
> On Nov 12, 5:21 am, Chris Ahlstrom <ahlstr...@launchmodem.com> wrote:
>> Hadron pulled this Usenet boner:
>>
>> > Chris Ahlstrom <ahlstr...@launchmodem.com> writes:
>>
>
> <snip>
>
>> My main point is that they are bulky and slow. Also Ryan (IIRC) and his
>> point about running different processes on different machines.
>>
>
> Ummm... I do that all the time. Oh, I build and debug on my local
> machine for debugging, but my distribution builds are built on a build
> server using CC.NET and msbuild from the command line.
>
> I'm not sure what all the fuss is about. An IDE simply pulls together
> tools into a central location. There is almost no part of VS that
> can't be replaced with a different tool if you don't like the one that
> comes with it.
Bingo. We have a winner ....
>
> Using VS does not limit you to the local machine. You can debug
> attach to and debug process on other machines - assuming you have
> remote debugging configured. So, the process your debugging doesn't
> even have to reside on your machine. You can configure your build
> process to do just about anything - at my last job I had a build
> profile that would compile a release mode build, zip it up, and ftp it
> to a release server. It would then send a http request to a in house
> release server telling it to refresh it's database of current
> builds....
>
> Is an IDE appropriate for all occasions? No. But, for many kinds of
> development they can make a big difference in developer productivity -
> and in the world I live in, time is money baby!
Of course. If you can run one its rare its not less productive to ignore
it. They are there for a reason.
>
>> Is there anything like distcc for Visual Studio?
>>
>
> There are several commercial offerings that offer distributed
> compilation in VS.
distcc is wonderful. Useful for a few ok.
>
> --
> Tom Shelton
--
Ezekiel
>"Tom Shelton" <tom_s...@comcast.net> wrote in message
>news:53448bf9-4455-4baf...@z41g2000yqz.googlegroups.com...
>On Nov 12, 5:21 am, Chris Ahlstrom <ahlstr...@launchmodem.com> wrote:
>> Hadron pulled this Usenet boner:
>>
>> > Chris Ahlstrom <ahlstr...@launchmodem.com> writes:
>>
>
><snip>
>
>
>>
>
>There are several commercial offerings that offer distributed
>compilation in VS.
Several people here at work use IncrediBuild with Visual Studio.
Chris Ahlstrom
> On Nov 12, 5:21?am, Chris Ahlstrom <ahlstr...@launchmodem.com> wrote:
>> Hadron pulled this Usenet boner:
>>
> <snip>
>
>> My main point is that they are bulky and slow. ?Also Ryan (IIRC) and his
>> point about running different processes on different machines.
>
> Ummm... I do that all the time. Oh, I build and debug on my local
> machine for debugging, but my distribution builds are built on a build
> server using CC.NET and msbuild from the command line.
Cool. I did not know about cc.net.
> I'm not sure what all the fuss is about.
It's about people stamping their feet and whining that they're preferred way
is best, unfortunately.
> An IDE simply pulls together
> tools into a central location. There is almost no part of VS that
> can't be replaced with a different tool if you don't like the one that
> comes with it.
Maybe you can help me get vim to work properly with it, then. :->
> Using VS does not limit you to the local machine. You can debug
> attach to and debug process on other machines - assuming you have
> remote debugging configured.
Yeah, I've used that quite a bit, and it works out pretty well.
> So, the process your debugging doesn't
> even have to reside on your machine. You can configure your build
> process to do just about anything - at my last job I had a build
> profile that would compile a release mode build, zip it up, and ftp it
> to a release server. It would then send a http request to a in house
> release server telling it to refresh it's database of current
> builds....
>
> Is an IDE appropriate for all occasions? No. But, for many kinds of
> development they can make a big difference in developer productivity -
> and in the world I live in, time is money baby!
Partly true. I've not seen any time savings with an IDE, myself.
Thanks for the nice survey. It's nice to get more light than heat.
And to know that developers are brothers under the skin.
--
It is often the case that the man who can't tell a lie thinks he is the best
judge of one.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"
cc
>
> Until they work out a way to parallelize instructions at the
> instruction set, via the compiler, 99% of serious programmers stick,
> when at all possible, to single thread, unless for trivial stuff like
> waiting for the database to respond for select methods, etc.
I can't tell whether that is serious or sarcasm. If you're serious,
you're a moron.
Rainer Weikusat
> On Nov 12, 5:21�am, Chris Ahlstrom <ahlstr...@launchmodem.com> wrote:
>> Hadron pulled this Usenet boner:
>>
>> > Chris Ahlstrom <ahlstr...@launchmodem.com> writes:
>
> <snip>
>
>> My main point is that they are bulky and slow. �Also Ryan (IIRC) and his
>> point about running different processes on different machines.
>>
>
> Ummm... I do that all the time. Oh, I build and debug on my local
> machine for debugging, but my distribution builds are built on a build
> server using CC.NET and msbuild from the command line.
Consequently, you not only "don't do this all the time" as you claimed
but you are actually doing it *never*, as in "Oh, I build and debug on
my local machine for debugging". This isn't necessarily even possible,
let alone desirable, eg if a couple of other distributed computers are
involved, 'build and debug on the local machine' might involve
mirroring the deployment setup in a local lab, ie all hardware
required twice. Of course, it also possible to do a realistic lab
simulation of 'internet conditions' the software is supposed to deal
with.
[...]
> Using VS does not limit you to the local machine. You can debug
> attach to and debug process on other machines - assuming you have
> remote debugging configured.
... and assuming that using 'a debugger' is at all possible. It isn't
necessarily.
[...]
> Is an IDE appropriate for all occasions? No. But, for many kinds of
> development they can make a big difference in developer productivity -
> and in the world I live in, time is money baby!
In the world I live, downtime is money, 'baby' ...
Rainer Weikusat
> On Nov 12, 5:21�am, Chris Ahlstrom <ahlstr...@launchmodem.com> wrote:
>> Hadron pulled this Usenet boner:
>>
>> > Chris Ahlstrom <ahlstr...@launchmodem.com> writes:
>
> <snip>
>
>> My main point is that they are bulky and slow. �Also Ryan (IIRC) and his
>> point about running different processes on different machines.
>>
>
> Ummm... I do that all the time. Oh, I build and debug on my local
> machine for debugging, but my distribution builds are built on a build
> server using CC.NET and msbuild from the command line.
Consequently, you not only "don't do this all the time" as you claimed
but you are actually doing it *never*, as in "Oh, I build and debug on
my local machine for debugging". This isn't necessarily even possible,
let alone desirable, eg if a couple of other distributed computers are
involved, 'build and debug on the local machine' might involve
mirroring the deployment setup in a local lab, ie all hardware
required twice. Of course, it also impossible to do a realistic lab
simulation of 'internet conditions' the software is supposed to deal
with.
[...]
> Using VS does not limit you to the local machine. You can debug
> attach to and debug process on other machines - assuming you have
> remote debugging configured.
... and assuming that using 'a debugger' is at all possible. It isn't
necessarily.
[...]
> Is an IDE appropriate for all occasions? No. But, for many kinds of
> development they can make a big difference in developer productivity -
> and in the world I live in, time is money baby!
In the world I live, downtime is money, 'baby' ...
Tom Shelton
> Tom Shelton pulled this Usenet boner:
>
> > On Nov 12, 5:21?am, Chris Ahlstrom <ahlstr...@launchmodem.com> wrote:
> >> Hadron pulled this Usenet boner:
>
> > <snip>
>
> >> My main point is that they are bulky and slow. ?Also Ryan (IIRC) and his
> >> point about running different processes on different machines.
>
> > Ummm... I do that all the time. Oh, I build and debug on my local
> > machine for debugging, but my distribution builds are built on a build
> > server using CC.NET and msbuild from the command line.
>
> Cool. I did not know about cc.net.
>
So far I have had really good luck with it for our .NET builds... I'm
just about to start integrating our C++ builds in - so, I'll let you
know how that goes :)
> > I'm not sure what all the fuss is about.
>
> It's about people stamping their feet and whining that they're preferred way
> is best, unfortunately.
>
Yeah... I see that.
> > An IDE simply pulls together
> > tools into a central location. There is almost no part of VS that
> > can't be replaced with a different tool if you don't like the one that
> > comes with it.
>
> Maybe you can help me get vim to work properly with it, then. :->
>
LOL... We've had that discussion before :) It's my dream to have that
work properly. I admittedly have never tried the plug in that comes
with gvim, since the one time I tried to set it up I wasn't able to
get it to work...
I did find a nice add-in once that worked really well, but it was like
$70 dollars - and it just wasn't worth the money to me to keep it
after the eval period.
--
Tom Shelton
Hadron
> Tom Shelton <tom_s...@comcast.net> writes:
>> On Nov 12, 5:21 am, Chris Ahlstrom <ahlstr...@launchmodem.com> wrote:
>>> Hadron pulled this Usenet boner:
>>>
>>> > Chris Ahlstrom <ahlstr...@launchmodem.com> writes:
>>
>> <snip>
>>
>>> My main point is that they are bulky and slow. Also Ryan (IIRC) and his
>>> point about running different processes on different machines.
>>>
>>
>> Ummm... I do that all the time. Oh, I build and debug on my local
>> machine for debugging, but my distribution builds are built on a build
>> server using CC.NET and msbuild from the command line.
>
> Consequently, you not only "don't do this all the time" as you claimed
> but you are actually doing it *never*, as in "Oh, I build and debug on
> my local machine for debugging". This isn't necessarily even possible,
> let alone desirable, eg if a couple of other distributed computers are
> involved, 'build and debug on the local machine' might involve
> mirroring the deployment setup in a local lab, ie all hardware
> required twice. Of course, it also impossible to do a realistic lab
> simulation of 'internet conditions' the software is supposed to deal
> with.
All very impressive. But clearly the subject is about the "general
case". While I am sure we are all very impressed with your depth of
knowledge about your case studies these do not apply to the great
majority.
>
> [...]
>
>> Using VS does not limit you to the local machine. You can debug
>> attach to and debug process on other machines - assuming you have
>> remote debugging configured.
>
> ... and assuming that using 'a debugger' is at all possible. It isn't
> necessarily.
No. Nothing is "necessary". Please stop using remote island rareties to
derail.
>
> [...]
>
>> Is an IDE appropriate for all occasions? No. But, for many kinds of
>> development they can make a big difference in developer productivity -
>> and in the world I live in, time is money baby!
>
> In the world I live, downtime is money, 'baby' ...
What are you talking about?
How is using a well configured IDE "downtime"? You got so wrapped up in
impressing people with your cutting edge minority system configs that
you forgot what were were talking about.
John Fuhrer
Seems to be a common ailment around COLA these days.
Terry Porter can't keep his distribution review lies straight either.
Rainer Weikusat
> Rainer Weikusat <rwei...@mssgmbh.com> writes:
>> Tom Shelton <tom_s...@comcast.net> writes:
[...]
>>> Ummm... I do that all the time. Oh, I build and debug on my local
>>> machine for debugging, but my distribution builds are built on a build
>>> server using CC.NET and msbuild from the command line.
>>
>> Consequently, you not only "don't do this all the time" as you claimed
>> but you are actually doing it *never*, as in "Oh, I build and debug on
>> my local machine for debugging". This isn't necessarily even possible,
>> let alone desirable, eg if a couple of other distributed computers are
>> involved, 'build and debug on the local machine' might involve
>> mirroring the deployment setup in a local lab, ie all hardware
>> required twice. Of course, it also impossible to do a realistic lab
>> simulation of 'internet conditions' the software is supposed to deal
>> with.
>
> All very impressive. But clearly the subject is about the "general
> case". While I am sure we are all very impressed with your depth of
> knowledge about your case studies these do not apply to the great
> majority.
I really don't give a rats as for your opinion about me and you are
free to feel as 'impressed' or 'unimpressed' as you desire. I am
trying to explain to you or $someone (although for what reason I don't
really understand -- maybe make the world a better place -- but how
so, if flat-out refusal to learn anything new is the only reaction?)
that 'using an IDE' *is* *not* *possible* *in* *certain* *situations*
and that your assumptions regarding 'matter of taste' &c are wrong.
>> [...]
>>
>>> Using VS does not limit you to the local machine. You can debug
>>> attach to and debug process on other machines - assuming you have
>>> remote debugging configured.
>>
>> ... and assuming that using 'a debugger' is at all possible. It isn't
>> necessarily.
>
> No. Nothing is "necessary". Please stop using remote island rareties to
> derail.
Please stop babbling nonsense. The statement above bascially amounts
to the confession that you cannot even imagine that software may need
to run unattended or that some error conditions are not reproducible
under 'lab conditions'. And the remote island rarety were this happens
is called 'Internet'. I assume you might have heard of that already,
although you apparently haven't yet figured out that it consists of
stored-program computers which also need to be programmed. What do you
believe a Cisco router happens to be (example chosen because you have
likely already heard of it). A funny brick? Or an alien lifeform?
[...]
>>> Is an IDE appropriate for all occasions? No. But, for many kinds of
>>> development they can make a big difference in developer productivity -
>>> and in the world I live in, time is money baby!
>>
>> In the world I live, downtime is money, 'baby' ...
>
> What are you talking about?
>
> How is using a well configured IDE "downtime"?
I didn't write this statement, you did. This means the question you
should be asking yourself is: Why doesn't $random_nonsense I came up
with because I didn't understand something make sense?
NB: This is useless discussion I will stop to particpate in after this
posting.
Ezekiel
"Rainer Weikusat" <rwei...@mssgmbh.com> wrote in message
news:87vdhfp...@fever.mssgmbh.com...
You're not the first linux "advocate" to run away after looking like a fool.
Hadron
I'll take that as a "high five". It's rare to see someone talk so much
bull as Rainer while thinking he is educating people.
I mean.
Really.
Step back and read his first reply.
It makes me cringe.
RayLopez99
cite please? You're a moron, if you think the sh iite you multithread
is really multithreaded.
RL