Slashdot Mirror
Microsoft's Top Devs Don't Seem To Like Own Tools
ericatcw writes "Through tools such as Visual Basic and Visual Studio, Microsoft may have done more than any other vendor to make drag and drop-style programming mainstream. But its superstar developers seem to prefer old-school modes of crafting code. During the panel at the Professional Developers Conference earlier this month, the devs also revealed why they think writing tight, bare-metal code will come back into fashion, and why parallel programming hasn't caught up with the processors yet." These guys are senior enough that they don't seem to need to watch what they say and how it aligns with Microsoft's product roadmap. They are also dead funny. Here's Jeffrey Snover on managed code (being pushed by Microsoft through its Common Language Runtime tech): "Managed code is like antilock brakes. You used to have to be a good driver on ice or you would die. Now you don't have to pump your brakes anymore." Snover also joked that programming is getting so abstract, developers will soon have to use Natal to "write programs through interpretative dance."
MSDN is another way of saying you don't know what you are doing.
Advanced developers who learned how to code on what would be considered bare bones IDEs don't feel the need to use tools that are meant to let low level developers produce functional GUI applications without having to dedicate tons of hours.
News at 11!
I hate Microsoft more than anyone, but... I really don't see an issue or any hypocrisy here.
"Most people, I think, don't even know what a rootkit is, so why should they care about it?"
The only pro: anyone can probably learn to write some sort of simple application through Microsoft's tools via managed code.
The cons: managed code doesn't give nearly as much control because it tries to spoonfeed you. This is basically a catch-all for every con anyone can think of for managed code.
Viable Slashdot alternatives: https://pipedot.org/ and http://soylentnews.org/
Yes, in some respects, programming is becoming easier and more unqualified people are able to do it.
But I think that these guys are really missing the boat. The closer the programming environment can come to providing domain-relevant expression tools to the user, the better they will be able to create programs that fit their domain.
In addition, content these days is a form of programming. Whether it is HTML/CSS or word processing or spreadsheets, the distinct line between what is a program and what is pure data is blurred beyond recognition. So a programming language for interpretive dance would probably find the Natal very useful.
You don't have to be a crack programmer or have a team of them to publish great software on a deadline.
Yes, it helps. A lot. And in a serious large scale development effort you want as many as you can get...
But it's good to be able to be useful without having to be elite.
Platform advocacy is like choosing a favorite severely developmentally disabled child.
I use Visual Studio because I couldn't program my way out of a wet paper bag. I'd be a bit concerned if the people writing the application were similarly impaired.
VB.NET and Microsoft's other tools make programing possible. People on slashdot will argue that this leads to bad applications, but the choice is between bad applications and no applications, not bad applications and good applications. Granted, sometimes bad applications are dangerous, but that's not a sufficient rationale to withhold these types of tools.
so MS has elitist morons in their ranks as well, how is this news?
If you mod me down, I will become more powerful than you can imagine....
It does not affect my decisions at all.
Businesses aren't in business to push programming ideology. They are in business to make money. If I need an application I'm going to get the application that does the job for the least amount of money (all the caveats about it not being poorly written and being moderately open to possible future expansion, etc.. apply). If I need bare-metal code then I'll get a guy to do that. If VB will do the job then I'm going to get a guy to do that and probably a bit cheaper. I don't care what the language is. I care that the problem is solved adequately for the least amount of overhead possible.
When I researched the Visual BASIC.Net 2002 development tools in beta I noticed those problems and my employer thought I was crazy. They moved on to Dotnet without me, having fired me for getting sick on the job and I eventually ended up so sick from the stress that I ended up disabled. I went on short-term disability for a while, tried a few more jobs, but ended up on disability.
Wow! I never thought I'd see a "crappy Microsoft software made me disabled!" post on Slashdot. Though I guess it shouldn't come as a surprise to me.
"Managed code is like antilock brakes. You used to have to be a good driver on ice or you would die. Now you don't have to pump your brakes anymore."
Might have been more appropriate to compare it in that people in the high performance arena (nascar) don't like antilock brakes because of their limits and the separation you get from your task at hand. (you lose your "feel for the road")
Tho I'm a little strangely biased, I miss the days of assembly, when 10k was a LOT of code to write to solve a problem, thing ran at blindingly fast speed with almost no disk or memory footprint. Nowadays, Hello World is a huge production in itself. 97% of today's coders don't have any idea what they've missed out on and just accept what they've got. Even someone that understands the nerf tools like VB at a lower level can get sooo much more out of them. I recall taking someone's crypto code in VB and producing a several thousand-fold speed boost because of my understanding of how VB was translating things. They didn't know what to say, they'd just accepted that what they were doing was going to be dog slow. (and unfortunately the users are also falling under the same hypnosis)
I work for the Department of Redundancy Department.
because the modern Microsoft development tools need that infernal Dotnet library to be loaded and then when it gets messes up any software that depends on it does not work.
Indeed. One of my PCs has a broken '.Net framework' which can't be fixed without a complete reinstall of the operating system: even Microsoft's own 'completely obliterate every last trace the bloody thing' uninstaller isn't enough to remove all the traces which prevent it from reinstalling properly. As a result, a lot of new software simply will not run.
Fortunately I do most of my useful work on Linux or Solaris these days so not being able to run random Windows software is no big deal, but '.Net' is such a monstrosity that it makes 'DLL Hell' look good in comparison; if even Microsoft can't fix it when it breaks, what chance do users have?
Well you are very close to the mark here.
The integrated IDEs arose to allow the hobbyist and corporate IT newbie turn out something, which has a good chance of being functional if not maintainable or efficient. These tools also allow specialists from other fields (accountants, meteorologists, scientists) actually turn out products.
Efficiency, maintainability and extensibility don't matter for that type of programmer. They just need to put up a few screens to count the widgets or produce the daily report. It doesn't have to be portable,or efficient, and chances are it will be tossed as soon as that programmer moves on to another job.
Those programmers do manage to turn out a reasonable amount of customized applications, some of which are actually marketable. The vast majority are for in-house use. But some actually work quite well for specialized industry applications like Medical Billing, where the knowledge of the subject matter is more important than the efficiency of the code.
OS level code has to be much more efficient, and there is no substitution for knowing the programming language, the processor capabilities, and the compiler peculiarities. You can not leave to some IDE the task of putting code behind a button that will drag in half a ton of MS Foundation Classes or use some particular C/C++ construct that is horribly inefficient. You are basically always dealing with some data stream or message and doing X Y and Z with it and handing it off to the next task.
As such these guys virtually never see a piece of data all the way thru the computer. Their customers are other pieces of software. Their wholesaler are yet more pieces of software. Its data-in, whack it, pound it, and pass it on sort of code, and a lot of it, and a lot of self plagiarism. The IDEs just get in the way.
Sig Battery depleted. Reverting to safe mode.
Actually BASIC and Visual BASIC are beginner languages. The B in BASIC stands for beginners. Not a "baby" language. You can still get things done in Visual BASIC but you don't have the control or memory management of C++ or C#.
I never used the Visual C++.Net languages, so I didn't know that. I usually use Turbo C++ for MS-DOS, or Borland C++, or even GNU C++ or MINGW C++ or C++ with Cygwin instead. I don't really see a need for a MS-C++ anymore when there are FOSS alternatives or cheap alternatives as in Turbo C++ and Borland C++ etc.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
This seems a good place to point out one of the chronic errors of people talking about software development...
Abstract does not mean slow, bloated, inefficient, or incomprehensible.
Having the wrong abstraction for the task at hand, however, often does. And blindly questing after "managed" "portable" and "high-level" is a good way to get abstractions which work poorly for *any* task. At best, you get Java/.Net/Javascript... tolerable for many tasks, and completely useless for others.
I could write a lengthy essay about how old programmers don't like to use new tools that offer them little because they already know all the tricks and gadgets for their old, "inferior" and more complicated tools, while new tools are perfect for new programmers because they don't have to learn so much to achive the same results because those tools are easier to use and the learning curve isn't so steep until you have a result, but I think I can sum it up in a single word:
Emacs.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Actually the stress was from management and coworkers, which the stress from Dotnet language was nothing compared towards. Everything was fine at my job, until I got mentally and physically sick, and then I was discriminated against until I kept getting sicker and sicker and eventually fired for being too sick.
I remember these words:
"Programmers are a dime a dozen. We get 500+ resumes a week for your position alone. We can easily hire a programmer who won't get sick on the job for a fraction of what we pay you." after that I was fired and escorted out by a security guard and my programming books and other property got mailed to my old address and I had to hunt it down to get it back. You'd think they'd use my new address instead of the old one, as my paychecks were mailed to my new address not the old one.
But it wasn't VB.net alone that made me sick, I want to clarify.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
WTF?
VisualStudio supports plain old C++. In fact, the new MSVS it's THE BEST editor for plain old C++, with the best autocomplete and refactoring support for C++ which exists in this Universe. I routinely write kernel-mode code in it, for example.
Some features like online C++ error checking are simply unique.
Many companies aren't big enough (or use Windows extensively enough) to get a volume license. And besides that, the significant cost is not the license, but replacing the hardware, and all the man-hours of work getting all the old apps up and working again.
Windows 9x will remain for many years to come, on business PCs with modest needs. And yes, there periodically need to be new programs written, as well as several old programs maintained.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
When BASIC was bundled with almost every 8-Bit computer sold in the 1970's and 1980's? It was the default language on most of the systems sold and other languages like FORTRAN, C/C++, Pascal, COBOL, etc had to be bought separately. So the el cheapo way to program was via BASIC. Many computer magazines issued BASIC programs in them and cross platform modifications for Apple //, Commodore 64, IBM PC MS-DOS, Atari 800/400, TRS-80 and TRS-80 COCO, TI 99/4a, etc that had BASIC default.
Borland turned Turbo Pascal into Borland Delphi, but Microsoft turned GWBASIC and Quick BASIC into Visual BASIC. Then when Windows dominated the Visual BASIC took over C++ and Delphi, as it was easier to program in for managers to understand. I didn't program in Visual BASIC because I liked it, I programmed in it because the job required me to do so. My managers didn't understand Java, C/C++, Python, Perl, PHP, etc, only BASIC and Visual BASIC, so they didn't trust programmers to write with anything else. Most of the Microsoft Windows IT/IS departments are run almost the same way and most of them use Visual BASIC (or in some cases Visual C# as it is easier than C++) because it is easier for management to understand what their programmers are doing and review code.
You don't earn money programming with your choice of a programming language, you earn money with a programming language that your employers choose for the jobs that are available in your area. Unless you want to migrate to a Linux or Macintosh IT/IS department, but sometimes you have to settle for a Visual BASIC development job and have no choice in the matter.
Just that now Microsoft Programmers are catching on that Dotnet is rotten, and if corrupt any program written to use it won't work.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
I'm a great programmer and I use emacs, you insensitive clod!
The
Huh? If you don't want .NET, don't use a Managed C++ project, use a native C++ project. You can control exactly what libraries are included, and no, it doesn't include .NET libraries by default. I'm not sure how you can claim to know anything about Visual Studio, if you don't know this.
Get off it That is all
do they use vim or emacs now?
Intellisense is pretty slick, but overall if I'm doing development on Windows I'd rather use an emacs as my text editor.
Of course, Visual C++ makes a fantastic debugger. It's almost good enough to forgive Windows for its lack of valgrind. Almost.
The point its easy to spot, which language is used to code kernel libraries? core operating system parts? drivers? big name applications? .net? i dont think so.
if you dont mind, ill stick to my c/c++ coding practices for the time being, and btw me thinks vc9 is the new vc6, just saying
I remember reading that it was "Beginners' All-purpose symbolic instruction code" (this is in one of my dad's old programming books when I was a wee lad. I'm surprised I even remember it)
The biggest posers I worked with used Visual Studio. The best group of programmers I worked with used text editor. That group could code rings around VS. The best of the best of them used vi.
This is absurd. Visual Studio, Eclipse, Vim, these are fucking *tools*. People use tools, not because the people are better, but because they find the tools useful.
Me, if I'm writing code for Unix or my DS, yeah, I prefer a maximized xterm, GNU Screen, and Vim. But if I'm writing a .NET application, I'm gonna use Visual Studio, as it's a very powerful development environment (doubly so when coupled with ViEmu).
OTOH, people who judge others based on their choice of IDE? Those people *are* tools...
The original article and the summary both come of as rather smug to me. The truth of the matter is that you need both low-level nitty-gritty programming and high-level programming. It depends on what you're using it for.
Think of it this way. You have people who make pipes. You know, the kind used in plumbing. Fittings, too. And they're very good at it. If you take your average house builder and try to get him to make a pipe, he'll be hopelessly bad at it. But you know what those guys who build houses are good at? Putting the pipes together in meaningful ways to get what they need (i.e. building a house) done. Take a guy who's brilliant at making pipes and fittings and try to get him to build a house. Yeah, not such a superstar now.
It's the same with programmers. Tell someone who is very good at writing low-level code, "I need a killer efficient compiler." Give them enough time, and they can churn it out and make it wicked optimized. Tell them, "I need a new type of control that works in this specific way and with crucial efficiency," and they're your guys. Tell them, "I need an new application entirely from scratch that can process my specific business logic, it needs to look and feel like a standard Windows application, it needs to be easy for end users to figure out and work with, and we need a working version in a couple of weeks," and they'll probably laugh at you. Yet that's what those people they're looking down on, the people developing with higher-level abstracted languages, are doing every day.
In my experience, competence != usefulness. They're not opposites, mind you, but it takes both types. It takes the people who work with the low-level nitty-gritty stuff, and it takes the people who use what they churn out to actually accomplish real-world productive things. One isn't smarter, one isn't better, neither should be looked down upon. Both are necessary.
Yeah, because IDEs don't have lists of errors, and double clicking on the error doesn't take you right to the line where the error is. It's so much easier to hunt through random code than to look at the little red squiggle on the line the IDE pointed out to you.
I'd call you an idiot but that would be insulting to idiots.
let me know when they start writing "writing tight, bare-metal code" (i.e. assembler). C isn't that.
Linux is 99% C and 1% assembler. Today it would be foolish to write the entire OS in assembler - at least because the compiler often optimizes the machine code better than you do, unless you really spend time on it. I wrote assembly code years ago, and it is minimally maintainable or reviewable. Imagine how far Linux 1.00 would go if it was all in assembly... and you'd immediately lose portability.
Our programmers are getting a bad rep because of our coding-for-weenies tradition. Can you please run an article that makes Microsoft programmers look like total badasses?
XOXOXO
-Steve B.
Uh, with all due respect: To say that "the distinct line between what is a program and what is pure data is blurred beyond recognition" merely proves that you've never understood the difference.
Warning: This signature may offend some viewers.
I'm a great programmer and I use emacs, you insensitive clod!
I don't know that I would say I'm a 'great' programmer, but I do OK. I use VI, but have great respect for emacs users.
Most (all) of my co-workers use a nice IDE editor. I think it's a good code browser but I'm much faster editing with two or three gVim windows than I am with the IDE.
A cow-orker of mine is pretty good using Visual Studio to create apps, but he has no clue about making things thread safe. Causes very hard to find problems.
As I said I don't use Visual C++, only Visual BASIC. I use a different C++ compiler than Visual C++ so there is no need to buy Visual C++.
I never said I knew everything about Visual Studio, quit putting words in my mouth.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
Supposedly through either Vimplugin or Eclim you could get the advantages of both, but I couldn't get them to work :(
Dilbert RSS feed
So, you're implying that Microsoft wrote Linux? Meh.
The point you are missing is that "bare-metal code" is assembler, regardless of how much effort is involved. Go ahead and write a real time driver in C, let me know how it works for you.
"National Security is the chief cause of national insecurity." - Celine's First Law
Do they use MFC, with its cruftology of C++ classes, templates, macros and You-Can't-Touch-This "wizard" generated code?
Or do they use MFC with out the "wizard" code from an IDE?
Or do they have their own C++ object library for Win32/COM/ActiveX that is not "out in the wild?"
Or are they writing the Big-Fine-Case-Statement of Win32 programming under C?
I'd be frustrated too trying to write code with tools that generate memory leaks for days and sucks at returning free'd memory to the system. I remember one version of Word you could start it up and just let it sit, within and hour or so Windows would crash. Then the version of Excel that shipped with debug code because the stripped version would never pass QA. Aw fine tools.
When I have to write a Windows GUI app, C# rocks! I can design the UI whip off the code and be done with it. It's better than MFC and after writing countless message loops in win32 and OS/2 for that matter, I don't think writing more GUI boiler plate code, using the APIs to match resource IDs, and all that mindless coding will do any good - especially when I need the time to figure out an algorithm or other problems. And I can still do low level stuff (really low level) with P/Invokes, so the only thing I'm really missing out is busy work. And if there's a time when I DO need the control and abilities of unmanaged code, well there's the C++ stuff.
It's NOT me! It's the meds! I'm on 1000mg of Fukitol.
IT program Im in focuses on xp environments, we are told often (Only been in school for about a year, and Ive heard it at least 20 times.) that we should expect to see older operating systems and computers. Most of the businesses in my area have switched to XP at least, so my school teaches based upon the needs of local businesses.
You are entitled to your own opinions, not your own facts.
There are times I am forced to, like if I'm doing gaming video, I have to do it using the Direct-X toolkit.
I mean, there is no other way around, since some users are using ATI cards and CUDA is useless on ATI GPUs.
But on other projects, I do bare metals, and when I have the chance, I go assembly.
Muchas Gracias, Señor Edward Snowden !
My biggest complaint about Visual Studio is the horrible API designs that it fosters. Since the APIs is so difficult to use, and so poorly documented (I'm thinking ATL, and to a lesser extent MFC) the only effective way to use them is to take advantage of the hand-holding that VS provides.
Yes I agree it wasn't written that well. I had forgotten about Visual C++ can write code without Dotnet when I wrote it. I did later write that I didn't even use Visual C++.Net because I use other C++ compilers. I wrote a correction later, which was ignored by the poster.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
You mean this intellisense IDE I use almost everyday makes me a weenie? I rarely read something on slashdot that makes me irritated but this does. I started with C then moved to C++ then I learned BASIC then Visual Basic then Perl then more C++ then PHP then C#. I'm sure theres a bzillion C like languages I've learned in between learning the languages that make me money. Sometimes I find myself writing bare bones stuff, usually on *nix platforms. It takes me twice as long to write the same routines in that type of minimal environment then without a full featured IDE. I write win32 C++ using the latest VS and even mix mode libraries where I've bridged unmanaged code to work with managed code - no com required. When I want high performance I will switch back to the bare bones approach but when I need to get a job done quickly I am very thankful for modem advancements in programming sciences. These Microsoft programmers might very well be the elite of the elite but for the rest of us not writing operating systems - we don't really care.
Don't know about interpretive dance, but I'm guessing that the MFC was written in abstract pottery.
Red to red, black to black. Switch it on, but stand well back.
The point you are missing is that "bare-metal code" is assembler, regardless of how much effort is involved.
I again have to point you to Linux or *BSD, these OSes have real time drivers in C. I don't recall seeing *any* peripheral driver in Linux that is not C. Practically all assembly code is under arch/ which means bootstrap, memory initialization and main timers. The rest is C.
Go ahead and write a real time driver in C, let me know how it works for you.
I'm doing this right now, and it is a very usual thing for me to do because I work on firmware for slower microcontrollers that run at clock speeds from 1.8 to 16 MHz. I have tons of peripherals in the MCU, and they must be serviced on time. A typical MCU project is a real time design. Sometimes I profile the code by connecting an oscilloscope to some spare pins and check that I have enough time in critical parts of the code. And *all* the code is C, compiled by avr-gcc 4.3.2. I have maybe 0.1% of the code that is in assembler, and that is stock macros that come with avr-gcc.
To illustrate, here you can see the lowest level of avr32 support, and you can observe how many LOCs are in .S and how many are in .c files. If still not convinced, visit mm/ and see what language the do_page_fault() is implemented in; that is one of most performance-critical pieces of code. C today is the "bare-metal" language of choice, and it works well in that role.
The article didn't actually have much in it, it was Computer World after all, but it makes sense if you read it as visual programming tools instead of Visual Studio. The article seemed, as CW articles tend to, that it was a good article that was cut to 1/4 it's original size just because.
With today's libraries, a half-decent IDE can make a huge difference in productivity. But the comment about zooming in and out makes perfect sense if you think of the "I'll drag an IF block here, then wire it to the blah field..." kind of visual programming. The kind that people are always trying to make so that programming will be available to the "everyman". The kind that never works.
Hypercard is the closest I've ever seen this come to working well. It's so sad Apple never knew what to do with it. It was approachable, and for simple record keeping was rather easy. HyperScript worked very well and was extremely approachable, especially with it's ability to do things like "take word 5 of line 2 of textbox".
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
Indeed. One of my PCs has a broken '.Net framework' which can't be fixed without a complete reinstall of the operating system: even Microsoft's own 'completely obliterate every last trace the bloody thing' uninstaller isn't enough to remove all the traces which prevent it from reinstalling properly.
Did you try Aaron Stebner's .NET cleanup tool? It's not an official MS product but it's written by an MS dev. I had a system with the same problem, and the cleanup tool fixed it.
Researchers have found Italians that don't like Spaghetti!
For every problem, there is at least one solution that is simple, neat, and wrong.
I use vim. But you know, I have respect for emacs users too. How could anyone crazy enough to use emacs ever be productive at any other endeavor? I mean, emacs usage and mouth breathing are really the extent of their capabilities.
"Programmers are a dime a dozen. We get 500+ resumes a week for your position alone. We can easily hire a programmer who won't get sick on the job for a fraction of what we pay you."
For future reference, those are walking papers.
I was given an equivalent song and dance once also (back in 2003). I had my resignation turned in in less than 30 minutes. Hated to do that, but at least I wasn't abandoning an important project at the time, plus I didn't want to be walked out by security. Later that month, four other devs followed suit.
You are where you are at the time you are there.
Or do they have their own C++ object library for Win32/COM/ActiveX that is not "out in the wild?"
WTL originated in Microsoft, which may well be the answer to your question.
A cow-orker of mine is pretty good using Visual Studio to create apps, but he has no clue about making things thread safe. Causes very hard to find problems.
Is that a problem with him, or is it a problem with the thread model in general, as opposed to an actor model or software transactional memory or multi-process architecture or some other non-thread concurrency model that I can't think of at 10:49 PM?
thats funny, because people using vi are usually doing it just to prove how l33t their skills are, and hence are the biggest posers of them all.
If you mod me down, I will become more powerful than you can imagine....
Not what the discrimination lawsuit that I won said.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
Most drivers consider themselves good drivers. But most drivers are bad drivers. Anti-lock breaks save lives. Managed code saves billions in lost revenue every year. How many of you have seen a situation in which an in-house developer brewed their own solution, with disastrous results? Most I'll bet. Anti-lock breaks could have prevented that.
One of my PCs has a broken '.Net framework' which can't be fixed without a complete reinstall of the operating system [...] Fortunately I do most of my useful work on Linux or Solaris these days so not being able to run random Windows software is no big deal
Have you tried these apps under Mono?
I don't really see a need for a MS-C++ anymore when there are FOSS alternatives
I tried MinGW. Hello World with <cstdio> was efficient as expected, but Hello World with <iostream> of GNU libstdc++ was roughly a quarter megabyte. When I mentioned this on Slashdot before, other users seemed to be of the opinion that the compiler and C++ library in Microsoft Visual C++ Express did a better job stripping dead code, resulting in a binary roughly one-third the size.
Were you thinking of a different FOSS alternative for compiling C++ programs for Windows?
You don't earn money programming with your choice of a programming language, you earn money with a programming language that your employers choose for the jobs that are available in your area.
By "area" do you mean a geographic area or a field of endeavor?
I don't really see the point in using assembly anymore. Yeah, its fast. But, its also a total pain to port and sometimes to maintain. With predictions saying that ARM will eventually catch up to x86 within the next 5 years, the fact that an ARM version of netbooks could be coming, etc. I don't know why anyone would still program in assembly for anything other than, say, emulators which need to be built for speed.
Taxation is legalized theft, no more, no less.
No real programmer really likes their tools. That is the punchline.
And dead funny? I mean, they seem like fun loving people, but I'd stop at "funny."
MS has probably / arguably more good designers and developers for software than any other company - IBM, Google, HP, Sun, etc and not counting the Japanese and Chines companies - Hitachi, Sony, Fujitsu - don't know the name of Chines companies but I know the people! The difference is - at BG time the (good/clever) people had at least some saying what, how, where, when - now, sorry, this is a corporate - you follow the rules and don't think! Let's see how long that lasts - if no changes I will give at most ten years (based on 35+ experience) - a side note, I loved Univac, Burroughs, Honeywell, some Wang ideas, DEC was superb, Prime before Cray, real object oriented at end of 60's way before it came a fad with technology not really supporting OO (always hilarious!),
Actually - this has been the way forever(?) or at least since 70's - talk to the company and talk to the developers, you will often get a totally different picture! Guess which one I have always trusted and which one has always later one proven to be the correct one? I wonder why companies still go with the all bs. - and I always wonder why some / most customer management buys to that? Maybe some of Dilbert makes sense - well, maybe more than some.
Back to topic - MS tools are not bad, actually (very) nice but geared to public, not real, hardcore developers. When you are "under the gun" - get something, working right, out - you either know what you are doing or you don't, there are no shortcuts! All and any (at least in last 35+ years) help tools, defaults, wizards, best practices, corporate standards, industry standards (of course commercial!), etc will not help - maybe that's why the MS developers don't like their own tools.
for the most part I don't use development environments if I do not have to as I can work a lot faster without them. (then build with unit test, good to go).
I don't know why anyone would still program in assembly for anything other than, say, emulators which need to be built for speed.
How about programs designed to run in the same class of systems that such emulators emulate? There are dirt-cheap mass-produced computer-on-a-chip designs that connect an 8-bit CPU core clocked at under 5 MHz to a TMS9918-like video generator. You're dealing with something comparable to a Sega Master System or NES on a chip. C on a Z80 or 6502 isn't pretty.
Lucky day for you, Visual C++ express is free, if you wanted to take it for a spin.
Yeah, you can buy it, but buying Visual Studio from Microsoft is for chumps. You either use the express if you're new, or you requisition it at work. :) ... Come to think of it, that applies to a lot more Microsoft stuff than just Visual Studio.
Visual Studio, specifically VC++6, rocked in the days of writing Windows apps. I'm not talking about any specific library or technology (the C++ compiler had incomplete template support, for example), but the editor itself was just awesome. It was solid, never crashed (though I could get the compiler to crash if I just looked at it funny), and was fast fast fast. I may be a weenie, but I actually like the suggestion popups, tool-tips over the code, etc., as I can barely remember my kids names on a good day, let alone the parameters to BitBlt(). The only thing though is that it has to be fast...any delay over 1/2 a second and I'm stopping to look it up on msdn. With VC6, that almost never happened.
Later versions, though, got seriously sluggish, and yes, ultimately it's just a glorified text editor, so why are all these windows sliding in and out at odd times, they rearranged all the project settings (why put the most important line for compiling (include header files) at the top, and then stick the same thing for linking somewhere near the bottom (not even *at* the bottom!)? Plus everything up to VS2008 has just been slow for me...from constant annoyingly-slow to wait-did-it-freeze-up-on-me-oh-no-it-just-came-back slow. Plus I've been able to crash pretty easily all of them to the point where, yes, I really do write a good amount of code in vim, then switch over to VS2008 when I want to compile or check something. It's just that painful.
I have the beta of VS2010 and I actually like it...it feels more solid than all the previous versions, and I dare say it's kind of close to VC6 reliability. I'll be following that development cycle more closely...it'd be nice to have a decent windows dev tool again (well, one that speaks MFC and ATL natively....if I were doing straight or platform-neutral C++, I'd go with Eclipse, which I find rock solid).
http://blogs.msdn.com/jasonz/archive/2009/02/20/a-new-look-for-visual-studio-2010.aspx If I'm not mistaken, Visual Studio 2010 will have a WPF UI including the editor.
Very insightful reply, and you're 100% correct. That was my other line of thought. This is the company (and probably some of these "superstar" programmers are the very people) who have given us a litany of buffer overruns, security holes, and other low-level programming "features" over the years.
I'm not saying that no one should ever program at a low level, but I am saying that people shouldn't be afraid to take advantage of features of managed code and other conveniences. Don't program at a low level if you don't have to. You're only making your life harder for no reason, and needlessly exposing yourself to risks of fundamental errors that are much worse. Take advantage of all of the hard work that others have already done.
The real reason why they don't use Visual Studio is far more prosaic -- the build environment of most of Microsoft products does not support the Visual Studio project files. Their products are built using a system called CoreXT -- basically a set of binary tools and scripts cobbled together by build engineers and developers over the past decade or so. CoreXT uses a lot of different crap, make, perl, compilers, etc, etc., and all tools and SDKs are checked in and versioned. The upside is that you can roll back your Source Depot (Microsoft's own flavor of Perforce) enlistment to an earlier date and be sure things will build exactly the same way, and once you enlist, you get repeatable, isolated build environment where you can guarantee the correctness of versions for all tools, compilers and libraries (Java developer's wet dream, even though they don't know it). The downside is that you have to maintain the makefiles by hand, and you can't use Visual Studio, because there are no project files checked in, and even if there are, most people don't use them and they are not updated, so you can count on them being broken.
I did a lot of my coding in either Notepad2, or in a separate project in Visual Studio against a test harness emulating the rest of the project (what Enterprise Java types call a "mock"). Some folks used Ultra Edit or vi, or EMACS. For some just a bare Notepad did the trick. Some stuck with Visual Studio, which in their case was just a glorified Notepad with autoindent since it doesn't support build or Intellisense if you don't have a project file.
Yes, it's an enormous waste of time, and yes, it was painful. But CoreXT is so integrated into the rest of the dev pipeline that replacing it with something else in a large product is a major, destabilizing endeavor that is bound to undo at least some of the work around gated check-in infrastructure, test infrastructure, automated deployment infrastructure and god knows what else, so few teams ever attempt it. Now naturally, DevDiv eats their own dogfood, so they were one of the first teams to switch completely to MSBuild. It took something like a year in their case, they did it gradually, from the leaves down the tree. I'm sure if they had a choice, they would be using CoreXT to this day though, and fighting with incremental build issues. :-)
Recently, a few more teams have adopted MSBuild. They can actually open their entire projects in Visual Studio and rebuild them. If they have test infrastructure deployed on the side, some of them can even test the product without waiting for it to deploy. So I predict that as more and more teams adopt MSBuild (this in itself could take another decade easily), these "senior" folks will come around to appreciate its benefits. It's awfully handy when you can set a conditional breakpoint on your local box and step through things.
I've worked with .NET from the beginning. I can't recall ever seeing a "broken '.Net framework'" install. I can't recall ever having to reload Windows to fix a .NET problem.
Perhaps not reloading Windows, but pretty close: Try installing SQL Server 2005 one of these days. The .NET framework 2.0 conflicts with .NET 3.51, .NET 2.01 and refuses to install. You need to uninstall ALL your current versions of .NET, install SQL Server 2005, reinstall them and pray that everything goes fine.
Actually, you're both right. Or I should say, you are right and the OP may be right. You're right because it is obviously true that there exists at least some non-poser programmers who use Visual Studio and at least some "poser" programmers who use a text editor. But the OP may be right if it is statistically true (I don't know that it is) that there exists high correlations between "good" programmers preferring a text editor and/or "posers" preferring Visual Studio.
While it is obviously true that such correlation coefficients do not equal 1.0 (since supposedly at least some of us subjectively know of some good programmers who prefer Visual Studio or some poser programmers who prefer a text editor, it is my opinion that there probably does exist a pretty strong correlation on the basis (and assumptions) that programmers who are familiar with a text editor are older and therefore more experienced than those whose only real experience is with an IDE. If this is true, then the OP is generally correct (and it is obvious that he was generalizing).
This author takes full ownership and responsibility for the unpopular opinions outlined above.
I think you're overgeneralizing. Not all IDEs separate the code in menus and popdown lists. Unfortunately, some of Microsoft's tools don't give you access to the full source code and it's a royal pain in the ass to refactor code.
This is the problem that perhaps the article is talking about: When the source code is tied to the IDE, everything becomes impossible to maintain.
That tool helped fix two WinXPs for me that would not complete Windows Update. So I'd say it's a common problem, because I don't administer that many PCs. Fuller instructions here.. Even with the tool, you're looking at a minimum 30 minutes of uninstalling, typically, 4 versions of DotNet, and reinstalling them, requiring several reboots. If you don't reinstall them all, who knows what installed software will no longer run.
It's called Razzle, not Rascal. It basically means "top of tree" and it changes on a daily basis. Razzle has nothing to do with Visual Studio.
"I work on firmware for slower microcontrollers that run at clock speeds from 1.8 to 16 MHz"
No wonder you can afford to use C! ;)
I can buy a $1.20 microcontroller that's more than an order of magnitude faster than the machine I learned to code on. Still, there are still times when a nice bit of assembly makes a big difference. Not much, just as much as you need.
As for the rest of the thread, assembly IS the bare metal. C is the next best thing to bare metal. Not to say that you should code everything in assembly, that would be silly. But being aware that it exists can't hurt.
I've installed SQL Server 2005 multiple times in the last few weeks (setting up different OS's in VMs), and each time I've installed it on machines with .Net 3.5 installed. There is no conflict, and the installer does not even try to install .Net 2.0, because it's already there. You're doing something wrong.
When confronted with one problem, some think "I'll use recursion". Now they are confronted with one problem.
And yet, the people doing graphics and gaming programming for Linux seem to do just fine without it. This isn't intended to knock Windows, please don't misunderstand me. It's just a statement of fact, and a question. Why is Direct-X so vital for such things on Windows and so irrelevant on Linux that it doesn't exist? The answer may be obvious to you, but I'm not a graphics or gaming programmer and I don't normally need to know these things. If you have a good explanation, I'd be interested in learning something new.
Good, inexpensive web hosting
If you'd go back and reread the statement, you'll see you argued against a point not made. Here's an example of what the GP means: I'm working on a team developing some computer vision software that will ultimately run under Linux. I develop under Linux, but my teammates do not. OpenCV operates under Windows, but when I get things running on my VS installation and send them the code, nothing. An error located somewhere in the configuration means they cannot use the (correct) code without first identifying and changing library and linker options.
I'd call you an idiot but that would be insulting to idiots.
And who's the one who is incompetent?
Part of me agrees with this offhand statement. As someone who used to write C++ COM objects for banking risk management, I can honestly say COM is short for COMplex and COMplicated rather than Component Object Model. Table of vectors for function calls? Simple idea, terrible implementation. I spent more time doing the stupid COM plumbing then actually writing code that benefited the customer. And Don Box waxing lyrical about how wonderful and cool COM was in his book(s) just made me want to smack him in the face with a half-rotten tomato. At least one of the good things about .NET is that is works very well with legacy MS code, COM objects included.
OpenGL doesn't encapsulate anything other than graphics. DirectX encapsulates input, 3D acceleration, sound, etc.
From a developer standpoint, DirectX is a no-brainer when it's available.
You can't legislate goodness. Let each to his own destiny, by will of his freely made choices.
But the OP may be right if it is statistically true (I don't know that it is) that there exists high correlations between "good" programmers preferring a text editor and/or "posers" preferring Visual Studio.
I'll buy the former, but absolutely *not* the latter.
Coding with a simple text editor, make/gcc/etc, and gdb implies a fundamental set of skills: familiarity and comfort on the command-line, ability to (presumably) write and invoke Makefiles, ability to use gdb (which, let's face it, ain't pretty for a newcomer), and so forth. So it stands to reason that there's a greater chance such an individual has the skills necessary to write decent code (also known as "trial by fire"), as a poorer developer would likely be scared away.
But I find it very difficult to believe that, given a population of VS users, there's a disproportionate number of crappy developers (ie, that the ratio of skilled to unskilled developers exceeds the ratio in the software developer population at large). A weak developer will obviously use any tools that make the job of writing code less daunting, and a good IDE definitely fits in that category. And a strong developer will use whatever tool makes their job easier, and guess what? VS is a *damn* good tool, particularly if you're targeting the .NET stack.
So I'd would say this: A developer that's happy using a simple text editor/compiler/debugger combo has a greater than average chance of being a good developer. But you can assume nothing about a developer who chooses an integrated IDE over the aforementioned environment if given the choice.
In fact, I would go so far as to say that any developer who actively *shuns* IDEs without good reason (and, BTW, simple familiarity is a good reason... mindless elitism, however, is not) deserves as much skepticism as one who isn't capable of using the editor/compiler/debugger environment, as they're expressing dogmatic tendencies that can be deeply counterproductive in the work environment.
Thank you, but that's not what I was asking,although the comparison is both interesting and informative. (to me, at least) What I wanted to know is why Linux devs don't feel the need for a Linux version of Direct-X. However, it occurs to me that you have answered my question, indirectly: OpenGL may not do everything Direct-X does, but it does enough so that Linux devs don't feel the need for a more comprehensive solution. Thank you again.
Good, inexpensive web hosting
I can't stand it when Microsoft developers talk about multi-threaded programming when the entire corporation has done that absolute bare minimum to make developer's lives easier. No wonder that they don't like using their own tools, because their tools are terrible.
Many years ago, a brilliant third-party multi-threaded library was released for Java, by a professor at Oswego university. I used it in several large production apps, and it absolutely rocked. You could build up safe, reliable, scalable multi-threaded applications by simply snapping together flexible pieces like Lego. It was so good that it became a part of the SUN Java standard library, and it's now called "util.concurrent". Compared to having to "hand craft" multi-threaded code in C++, it was wonderful. It's as if the lights had just turned on, and everything had become clear to me.
Now that I'm a C# dev, it's been a huge step backwards, doubly so because .NET was developed after the Oswego library was already popular, so Microsoft must have seen it and just flat out ignored it. For years afterwards, the whole entirety of multi-threading in both .NET and C++ were "threads" and "locks". The one nicety they included was an anemic thread pool in .NET which was just usable enough for the most basic tasks, but couldn't handle any real load. Even the locks were heavyweight inter-process kernel locks that are unusably slow for many tasks.
It's only now in .NET 4 (which won't be final until 2010) that they are adding a small set of very basic lock-free containers, light-weight locks, and actual interfaces that one can implement in order to customize behavior. It's all still very basic, and nowhere near as flexible, powerful, or comprehensive as the Java APIs that are years old now.
Microsoft's general attitude to API design is so bad that it can only be described as wilful ignorance. Reading articles evangelizing "modern multithreaded programming to better utilize new multi core processors" somehow feels like a religious zealot harping on about their appreciation of pure rational logic and science.
The only prerequisite to use C code for "bare-metal" code is a working stack. That means setting the stack pointer to a sane value right after a RESET. I've coded lowlevel embedded stuff for the Gameboy Advance and GP2X with C only. Down to the interrupt handler.
Linux video in general is a mess...
But open source developers have put a ton of effort into cloning DirectX in Wine, which is arguably a better solution given Linux's current marketshare.
because the modern Microsoft development tools need that infernal Dotnet library to be loaded and then when it gets messes up any software that depends on it does not work.
Indeed. One of my PCs has a broken '.Net framework' which can't be fixed without a complete reinstall of the operating system: even Microsoft's own 'completely obliterate every last trace the bloody thing' uninstaller isn't enough to remove all the traces which prevent it from reinstalling properly. As a result, a lot of new software simply will not run.
Fortunately I do most of my useful work on Linux or Solaris these days so not being able to run random Windows software is no big deal, but '.Net' is such a monstrosity that it makes 'DLL Hell' look good in comparison; if even Microsoft can't fix it when it breaks, what chance do users have?
A lot of that comes from badly written fragile apps doing stupid things like writing entries into the "machine.config" file, or depending on things that aren't guaranteed. Oracle and any apps that depend on their client come to mind, it does horrible things to the .NET framework config files. I see the same all the time with Java apps as well, it's not unusual to see even a "point release" of the JRE break apps.
On the other hand I have written (and seen third party) apps for .NET that have worked consistently well across 3 operating system releases (2003/XP, 2008/Vista, 2008 R2/Windows 7), and 3 major .NET revisions (2, 3.x, 4), AND a change from 32-bit to 64-bit without any significant changes. That's not bad. Meanwhile, there are traditional C++ apps that will fall over if you look at them the wrong way.
Then again, Windows 7 actually contains a "stealth" release of .NET: 3.5.1. It's not the same as 3.5 on Vista or earlier. Developer tools target "3.5" as if it was a single platform, but it's not, there are two slightly different point releases. It broke VMware's vCenter client, among other things.
"I work on firmware for slower microcontrollers that run at clock speeds from 1.8 to 16 MHz"
No wonder you can afford to use C! ;)
I can buy a $1.20 microcontroller that's more than an order of magnitude faster than the machine I learned to code on. Still, there are still times when a nice bit of assembly makes a big difference. Not much, just as much as you need.
As for the rest of the thread, assembly IS the bare metal. C is the next best thing to bare metal. Not to say that you should code everything in assembly, that would be silly. But being aware that it exists can't hurt.
I hear that Windows 7 / Server 2008 R2 has a pure-software implementation of DirectX 11 that's got some huge percentage implemented in assembler. It's still a useful and current skill that turns up in large scale deployments of production code! 8)
I've used SDL, which provides for audio, 2d graphics, controller input, network communication (I think), among other things. Basically, it's a multi-platform toolkit similar in use to DirectX....of course, I'm not claiming that it's a full feature-matched equivalent, but it's pretty useful.
It is pitch black. You are likely to be eaten by a grue.
So your saying the only reason you don't code in asm is that another archetecture might be popular in 5 years? That's a joke you program in what ever the guy who signs your checks says is good like everyone else. If you call your own shots and assembly is still no good you haven't been at it long enough to make any good libraries. Either way don't start telling us it's no good cause something better might show up in 5 years. Your going to have to recode it by then any ways cause it's gonna be worth it when you do.
A loop, by its nature, continues. If that didn't make sense, start reading this sentence again.
If you call your own shots and assembly is still no good you haven't been at it long enough to make any good libraries.
I've made some very good libraries that help me code assembly. I like to call them higher-level programming languages.
I'm a Java developer. Please explain to me the wet dream I'm missing out on.
Are agnostics skeptical of unicorns too?
maximized xterm
Please don't do that. I will hunt you down and deliver a round-house open-handed slap to your ear; rupturing your eardrum asunder. Consider that next year I might have to maintain your 512 column code. There is nothing more nauseating than opening someone's code in a standard xterm and seeing single lines fucking wrap around the fuck around the fucking terminal.
Just as a function should ideally be as small as possible (not always possible, I know) without too much scrolling, you really should try and use 80 columns only. As with most poetry which employs constraints such as stanzas, etc, you can also achieve beauty (and better code) in 80 cols. And you won't piss off other devs who have to look at your code.
Damn. I don't even use Java(I'm an embedded C guy), but if DL did it, then it's probably really good. As a C developer I feel the old pthreads style is a throwback to old multi-process hacks on SysV of 25 years ago.
What dragged you to the dark side anyways? (C#/.NET)
“Common sense is not so common.” — Voltaire
Well, both of you are correct imo. Yes I prefer having to double click on the error in the IDE and have the cursor positioned on the correct line on the correct source code... except sometimes the indicated error has nothing to do with the actual problem. In practice, on non trivial projects involving many developers, libraries, inherited property sheets and complicated solution files, it is quite common that the error is due to something included before something else, or somebody changing an inherited parameter somewhere else in the code base. So yes in the end you have an error somewhere, but the cause of the error is not necessarily located there and may be very difficult to find.
Obviously someone who uses Visual Studio isn't necessarily an idiot. But maybe the parent has noticed a correlation (not causation) that extends beyond the anecdote. Someone who uses vim or (and I'll be charitable - it is a powerful editor) emacs almost by definition has to be intelligent enough to see that putting up with the learning curve in the short term is an investment that pays for itself many times over in time saved. And when you use an editor that can edit at the pace of your thinking, you find that you can concentrate better - your train of thought doesn't derail - which will give additional speed and ability. And maybe, a vim/emacs user also needs the intelligence to learn at a fast enough rate that the learning curve does not seem onerous.
You're also going to need some intelligence to even think that a decision on a text editor is something you should research. Someone smart could do a "site:slashdot.org text editor" search on google, find a poll and probably choose vim or emacs or something similar on that basis. If they are that smart, they are probably going to do that for other aspects of coding and it is going to show up in their coding ability. Someone stupid is going to stick with the default, or prioritize immediate ease of use over long term time saved.
In short: dumb users get filtered by the learning curve, smart users have incentive to learn the editor. Because of that the average vim/emacs user is going to be smarter than average, and also a better programmer. However, if someone uses another editor I am not going to make an assumption about their intelligence.
If I have seen further it is by stealing the Intellectual Property of giants.
Off the top of my head, your applications will run on OS X without having to add Aqua specific extensions, people won't ignore your application just because it's "java" and you won't get a plethora of users moaning that it's "slow".
Change is certain; progress is not obligatory.
Microsoft's Top Devs Don't Seem To Like Own Tools
No, really? I'm shocked.
It does make me think that these tools were not written by these people though but by some team headed by a PHB.
You could try writing code so awesome the managers would have no alternative than let you choose your tools. I did this recently, there was a customer management system that needed some data from engineering. I wrote a "stop gap" thingy in Python in two months, with the understanding that this would be replaced by a "proper" system in .NET as soon as possible.
When budget time came in, the bill for converting my small Python script to VB.NET was $200k. Now it's official: Python has been accepted by the upper management as a valid cost-cutting tool to replace .NET wherever possible.
I can't stand the .NET invasion. I keep being told by .NET people it's really not that heavy and it much more productive etc etc. Most admit it would be a problem if every app was written in .NET, but it ok for their app. BUT the very same people blame .NET when their applications are fat and slow! It gets worse when you have multiple of these apps running, each written basically on the assumption it's the only thing to run. Apps should be written to be a good citizen, i.e. take as little as they can, and give as much as they can. Don't get me wrong, it's not just .NET, this seamed to happen before with JAVA, which didn't take over either. Now I don't know if it's an environment thing, or programmer skill level thing, but JAVA applications don't seam to be as bad as .NET.
Then worse of all, things written badly as web apps. I was in the doctors and they had been computerize. The register for your appointment system was really slow, but what blew me away was the slide show of information. It couldn't even scroll large text across the screen properly. I could see this was a web thing because some of it was broken and the page was a IE page not found page. Here we are in 2009 with crazy powerful computers from the future, and we have such bad choices of technology, so much abstraction in the way, and bad "professionals", that it's worse then I did as a kid in BASIC on a computer with 2MHz. It makes me soo angry. It feels like we are going backwards. The fact these crap systems always seam to be running on Windows doesn't help. I'm sure it would be as easy and faster+ cheaper on a stripped down Linux with just X, the required libs and python!
that's a funny image, but after I've seen programming languages like brainfuck, whitespace, shakespeare or piet, I'm pretty sure that some day there really will be a programming language like that...
The MAFIAA is a bunch of mindless jerks who will be the first up against the wall when the revolution comes
If only Microsoft's architecture and best practices groups actually worked to leverage the efficiency of the tools, rather than just drain it. The thing about Microsoft is that the tools are good, yes, but then they sell them with these practices and recommendations that just drain innovation and drags all developers down to a lowest common denominator.
It's really, Taylor all over again but applied to computer programming. The problem is, Taylor is what GM and Ford and Chrysler do, and the unions are locked in with. Just like we have pipefitters and machinist titles of varying kind on the shop floor at an old style manufacturing plant, we have guys that are being pushed into the database, u/i design, or middle tier roles, and really, 90% of all projects could be done with one guy putting together a half way decent screen in a craftsmen like fashion.
At this point, Microsoft is headed out just like GM - recruiting a lot of the best engineers, then just killing them in red tape, and delivering products that increasingly fail to captivate their market.
This is my sig.
Off the top of my head, your applications will run on OS X without having to add Aqua specific extensions, people won't ignore your application just because it's "java" and you won't get a plethora of users moaning that it's "slow".
The main issue for OSX GUI apps vs. GUI apps on other platforms is that apps tend to be laid out differently on OSX. So while you can reuse your layouts from other platforms, they look out of place. (By contrast, Windows and Linux tend to use much more similar GUI layout strategies; their GUI heritages diverged much more recently.)
"Little does he know, but there is no 'I' in 'Idiot'!"
WTF?
VisualStudio supports plain old C++
Visual Studio 2008, the current shipping version, is not nearly as effective with intellisense as Eclipse is. In particular, Eclipse actually feels faster when it comes to editing, does a good job with sifting through templates, and has the nice added bonus that integrating assembly is easy.
I mean, come on, integrating MASM for 64 bit assembly does NOT WORK OUT OF THE BOX with Visual Studio 2008. How can you call VisualStudio a serious tool for low level work when they didn't even test it with assembly. That's just crazy.
This is my sig.
If you know how to build a program from the command line, it means you understand how the build process works. Ultimately, Visual studio works just like any other IDE. It manages some sort of a build engine visually and provides support designed to shorten the build and test cycle. If it helps you, use it. If it doesn't, don't.
This is my sig.
Please don't do that. I will hunt you down and deliver a round-house open-handed slap to your ear; rupturing your eardrum asunder. Consider that next year I might have to maintain your 512 column code. There is nothing more nauseating than opening someone's code in a standard xterm and seeing single lines fucking wrap around the fuck around the fucking terminal
Wouldn't it be easier to turn off line wrap in your editor?
This is my sig.
When I get an error, the compiler also points exactly to the line where the error is. So your insults are completely unwarranted.
The main issue I found, was that the display stuff is broken. Just check out my slashdot link, http://scorch.quickfox.org/ - On older versions of OS X, it flickers to hell (hence the epilepsy warning), on newer versions of OS X the scroll bars are missing, on some versions of OS X server it will cause the system to kernel panic (all 100% reproducible). The only solution I am aware of, to get around it, is to add platform specific code, which I have absolutely no interest in doing.
The application in question even works on kaffe, msjava and plenty of other java runtimes.
Change is certain; progress is not obligatory.
Then long lines disappear at the end of the term. I'm not sure what's worse.
Disappearing text (forcing you to scroll right), or long lines wrapping, breaking the flow of the code.
Actually the stress was from management and coworkers, which the stress from Dotnet language was nothing compared towards. Everything was fine at my job, until I got mentally and physically sick, and then I was discriminated against until I kept getting sicker and sicker and eventually fired for being too sick.
I remember these words: "Programmers are a dime a dozen. We get 500+ resumes a week for your position alone. We can easily hire a programmer who won't get sick on the job for a fraction of what we pay you." after that I was fired and escorted out by a security guard and my programming books and other property got mailed to my old address and I had to hunt it down to get it back. You'd think they'd use my new address instead of the old one, as my paychecks were mailed to my new address not the old one.
But it wasn't VB.net alone that made me sick, I want to clarify.
So what the hell did you include that for, in a post regarding DotNet?
you really should try and use 80 columns only
Hi. The Time travel tourist board called, they said your "work in the future" visa was about to expire and could you make your way back to 1978 please. :)
You don't need to port assembler. Consider. You write some application which is a bit close to the limit in terms of real time performance - e.g. a video codec. Everything is in C or C++ initially and you concentrate on getting the high level algorithms right. It works fine on a Core2 laptop.
Then you test it on a netbook. It stutters a bit or maxes out the CPU. So you profile it and write assembler versions of the critical parts. I.e. your code looks like this
Now on low end netbooks (i.e. x86) the code runs smoothly. On high end laptops (x64) the processor is fast enough for the C code to work anyway. Later processors probably won't be that much faster, but they are unlikely to get slower. Actually netbooks are the one case where slower processors have suddenly become more common.
Now if at some later date ARM netbooks become common (I seriously doubt this) you'd be best off profiling once again and doing an ARM version of the hot spots in the code. The point is that you make sure your code will run without the inline assembler and bet on future processors being faster. Actually x86 changes quite drastically to the point where at some point the C compiler may well do a better job on compiling the C code than you did on the assembler anyway. From what I've read optimizing for Atom is pretty different from optimizing for Core2. And C compilers get smarter every year.
Of course for most non real time applications you're better off making sure you have an efficient C/C++ application. I've never written any PC code that needed this sort of treatment. Embedded systems sometimes do, but you can do the same there - write the whole lot in C and if you can't make it fast enough profile and hand optimize the bits that need it.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
Except that, as far as I know, DirectX doesn't do anything to unify all of these. There's a DirectX 3D graphics API, an input API, a sound API, etc - but they're all independent of each other. There's nothing to stop you using DirectX for input in an OpenGL app - or, indeed, using the DirectX sound API in a media player that doesn't make use of any of the other bits of DirectX.
Thats utter bollocks - the first thing I do when I install a Windows server is update .Net to the latest version, being 3.5 SP1 these days, and I've installed enough SQL Servers in the past 6 months to know that what you claim is a total fabrication, as SQL Server goes on after the .Net updates.
.Net 3.5 SP1 already installed on it. You are talking utter shite.
SQL Server 2000, 2005 or 2008 have no problems installing onto a Windows Server 2003 R2, 2008 or 2008 R2 system with
I think without realizing it, you've made a fundamental assumption that is not true: # of good developers == # of bad developers. If that assumption were true, then by your logic we should expect that about a 50-50% breakdown of good/bad developers who use VS.
But, if instead, the # bad developers is much, much larger than the # of good developers we should expect that for an IDE that has a low barrier of entry that bad developers would naturally gravitate to that particular IDE, wheras good developers don't necessarily have a bias (as for example, you don't have a bias). In which case the IDE usage heavily favors the bad developers (they were the vast majority of the population already, and now they are even even more concentratrated since there are proportionally fewer good developers who use only that IDE.
As you pointed out, the IDEs that have "higher" barrier to entry (aka, vi, emacs, etc.) are naturally not going to present a problem to the good developers, but the bad developers will shy away from them. So, of course we should expect then that the percentage of good developers who use vi vs. bad developers who use vi will be (much) higher than the percentage of good developers vs. bad developers in the general population.
In other words, if Pr(Code Monkey is bad) = p, Pr(Code Monkey is good) = q (with p much larger than q), then Pr(Code Monkey is bad | Code Monkey uses VS) > p and Pr(Code Monkey is good | Code Monkey uses vi) >> q.
Intuitively, this explains why people are more likely to be impressed by someone who uses vi, emacs, etc. than someone who uses VS. It's not that VS stinks or that continual use of it melts your brains, it's just that as an indicator of your skillset, someone who uses vi,emacs, etc. is *probably* at the least competent and most likely *good*. Whereas, usage of VS indicates very little about your skillset other than the majority of VS users are "bad" which would suggest such a person *probably* is also a bad coder.
To get rid of the stench of incompetence associated with use of VS I would suggest that Microsoft come out with another IDE that is "dumbed down" from VS, sort of a "VS, junior" for those who remember the IBM PC, junior. Something that has an even lower barrier to entry than VS, so the bad Code Monkeys can gravitate to "VS, junior" and thus boosting the probabilities for the competent VS developers. Maybe they could throw in a Clippy on VS, junior or a dog with mental bubbles of suggestions.
You can assume one thing about a developer who's using a simple text editor/compiler/debugger combo targetting .NET; (s)he's using MONO/Linux.
GET THE FUCK OFF MY LAWN!
Please don't do that. I will hunt you down and deliver a round-house open-handed slap to your ear; rupturing your eardrum asunder. Consider that next year I might have to maintain your 512 column code.
You've never heard of vertical window splits, I take it...
Not really. Compilers these days do a better job at optimizing most code than most assembly programmers (for well-supported CPUs anyway), mostly because instruction timing and dependency issues in modern complex CPUs are quite complicated, and compilers are able to take a lot more into account (just because the code 'looks' tighter doesn't mean it'll run faster). The only place where it really makes sense to use asm is for tight inner algorithm loops, especially when you can use SIMD instructions.
Assembly was a luxury in the old days. I seriously remember writing in hex to memory, referring to the assembly code in a reference book.
I keep being told by .NET people it's really not that heavy and it much more productive etc etc.
I feel the same way about Python. CPython is a naive interpreter, one of the few used for serious programming. Even Javascript has JIT compilers now. Not only that, on a multicore CPU, each CPython process runs slower, due to badly designed fighting over the global interpreter lock.
If CPython didn't suck so bad at performance, Google wouldn't have had to write "Go". Sad.
A lot of this depends on the environment you work in. In some companies you'd get fired if you took the time to do a real design, even if it saves time and money in the long run.
Of course in start-ups you sometimes don't have a long run if you can't get the product out before the money runs out.
Another factor is how fast and furious new technologies appear. For example, who has enough experience in Android to mentor less experienced developers?
Ah, the good old days. In undergrad we built simple programmable computers out of gates and programmed them by flipping DIP switches and pressing buttons.
Assembly is usually one-to-one translated to machine code though, so they're technically both equivalent as far as bare metal goes.
I was at the talk, and yes Don Box said "I will fight you if you try to take away my text editor" but it was after having being asked a leading question by Eric Meijer. Something along the lines of "will we ever write software entirely without writting text?"
However, what was Don doing for the rest of the PDC? He was hawking Entity Framework and M, both of which allow users to model data access using rich graphical tools!
The talk is here: http://microsoftpdc.com/Sessions/FT52.
using System.Awesome;
Eclipse? That's for poseurs.
But seriously, you're going to make up crazy stereotypes to support your own irrational beliefs about VS? Personally I have no use for VS, but I'm not going to create a fantasy around Microsoft tools to justify my own Vi-using habits.
“Common sense is not so common.” — Voltaire
Same here. I had the work done in a matter of minutes in Emacs, but I couldn't figure out how to exit Emacs to run the program. :(
“Common sense is not so common.” — Voltaire
Ask yourself why we have "builds", where everything gets rebuilt. Do I have to have my ICs re-fabbed when I change the PC board design? No. We're still not doing components right.
Historically, the big problem came from C include files. Everything but the kitchen sink is in there. There's no language-enforced separation between interface (the parts clients of the module see and may have to recompile if changed) and implementation (the part the implementations see). Also, you can include files inside include files, even conditionally. So developing the dependency graph of the program is hard.
C++ made things worse, not better. The private methods of a C++ class have to appear in the header file, which exposes more of the internals than is really necessary. Every time you add a new private method, the clients, who can never see or use that private method, have to be recompiled. This not only produces cascading builds, it discourages programmers from adding new private methods rather than bloating existing ones. That's bad for code readability and reliability.
Ada explicitly dealt with this. Ada has a hard separation between interface and implementation. This was considered a headache when Ada came out, but now that everyone has bigger monitors, it's less of an issue.
Java, despite having interfaces, seems to have build and packaging systems of grossly excessive complexity. I'm not really sure why.
The next problem is the "make" mindset, which is built on timestamps. "make" doesn't check what changed; it checks was was "touched". If "make" decided what had changed based on hashes, rather than timestamps, many unnecessary recompiles would be avoided. Something could run "autoconf", produce exactly the same result as last time, and not trigger vast numbers of recompiles.
There's also the tendency to treat "make" as a macro language rather than a dependency graph. This results in makefiles that always recompile, rather than only recompile what's needed.
It would be useful if compilers output, in the object file, a list of every file they read during the compile, with a crypto grade hash (MD5, etc.) of each. A hash of the compile options and the compiler version would also be included. Then you could tell, reliably, if you really needed to rebuild something.
I have no idea what you're talking about or how it relates to my question. I was asking a question of a guy who works on Microsoft products, so I'm having difficulty figuring out why you're talking about OSX. Yes, I realize that Microsoft makes Mac software as well but that's not what the discussion is about. Once again, I ask what wet dream I'm missing out on as a Java developer that all these developers at Microsoft seem to have?
Are agnostics skeptical of unicorns too?
So these are the guys responsible for Windows (all versions), Internet Explorer, Excel right? So why should we take any notice of these guys? Unless of course we wanted to learn how to develop slow, buggy, insecure applications that suffer from chronic feature bloat.
Bad analogies are like waxing a monkey with a rainbow.
For vim, yes. However, vsplit is not available for some versions (ie, whatever comes with your distro). ...and no, installing the latest from src is not an option.
Ah but you see why I prefer Python over .Net/Java is it doesn't try and be fast (bar a few crazy projects). You write/use a collection of fast part written in C, joining it together into a application with python. Reminds me of a little the way so many RiscOS apps where a blend of BBC BASIC and ARM code. You write the parts that need to be fast in a fast language, and the rest in a expressive language.
People are reading a lot into this that isn't there. These people use Visual Studio, and I don't think they'd claim that using a GUI to design a...GUI is a bad thing. They're referring largely to the new modeling tools MS is pushing with VS2010, and they're saying sometimes it's quicker to just write the code than design the model. And indeed it is.
It's a tradeoff. For example, they already have some modeling tools (web service factory) for developing a web service. You layout interfaces, data contracts, message contracts, etc... and associate them visually. I think this sucks, personally, and I still just do it the old school (and much quicker, more powerful) method by creating an interface and data contracts. But for some scenarios designing the model might pay off in terms of self-documentation and allowing some standards to be followed by multiple developers working on a web service.
You're missing out on guaranteed versions of binaries in your build, side by side deployment of different versions if your dependencies need them.
I was shocked when I found out that in Java world if library A requires version x of library B, and library C, which in turn requires version y of library B, a Java developer will pick some version of library B at random and pray it works with both A and C.
For most folks, compiler and tools are not checked in and versioned (even though they can be, in most cases), so there's no guarantee that your crap will even build two years down the road when you roll back to an earlier revision to fix an issue your customer is having with an older version.
Furthermore, folks who use Maven rely on unsigned components pulled from random places on the web, and components can be silently updated, compromised or removed.
I could go on and on. Java devs are sloppy with their dependencies and tooling, and it's no fault of their own -- it's just that their platform is brain dead and outdated. .NET had side-by-side deployments and signed assemblies in _2001_.
Also, looking down the thread, you seem to imply that I work on Microsoft products. I don't. I left Microsoft quite a while ago. These days it's mostly C++ and Python. Couldn't bring myself to code Java, sorry.
You can (and should) check in the C++ compiler separately from Visual Studio. It's a free download from Microsoft -- no reason not to check it in. You should also check in any other compilers and interpreters you use. If you use MSBuild or make on Windows platform to build your code, you should check it in as well. The beauty of MSBuild is that it can take VS project files and build stuff without needing Visual Studio.
I'm afraid you know very little about Java development. Perhaps you just worked with incompetent developers but I haven't worked on a Java project in many years that works even remotely as you describe it.
Any company using Maven that's got any sense at all uses local repos so what you're talking about just can't happen short of your repo getting corrupted.
For companies using ant, we check in all our jar dependencies. This is by far the most common thing I see as a consultant. I've never had any difficulty building old versions of code.
Your dislike of Java appears to taint your understanding of how it's actually developed. There are certainly retarded ways to manage your code and dependencies but they aren't a Java or tooling issue since there are plenty of tools to deal with these issues.
In any event, you cannot claim the high ground by stating you code C++, which is a disaster of a language. In any just world, Stroustrup would be shot for creating it. Python is actually pretty sweet.
Finally, feel free to rip on Java. It's not my preferred language but it is what I make my living on.
Are agnostics skeptical of unicorns too?
If you google the subject, you'll find several projects that implement type safety, termination, and correctness proofs at the assembly language level. The proofs are more complex and sometimes limit the allowed instructions to a subset of the original machine language, but in theory it is possible to prove just about any property about any arbitrary machine code program, given a suitable model of the hardware and OS and a trusted proof verifier.
oO! Wow, I've *never* come across a modern build of Vim, for any distro, that didn't have vsplit compiled in. You have my pity. :)
It's pretty well spelled out how it relates. Developing the application in Microsoft's tools does not have the issues Java does and that includes not having some of the issues you get with java on OS X. My entire response did not refer to OS X.
I already gave three points to that without really giving much thought, read the response I gave again.
Change is certain; progress is not obligatory.
Those local Maven repos are not versioned within the source control system, and therefore are unreliable. And checking in only jars is insufficient - in order for things to be 100% repeatable and isolated, you need to check in all your tooling, jdk and compilers as well, and make sure the developers launch a separate bash session which makes sure you're using only the tools in the enlistment, and not the ones installed locally on the box. No one does this.
I like how you avoided the jar hell issue and the issue where people grab cryptographically unverified jars off the web and stuff them into production code with very little testing (you aren't going to tell me you thoroughly tested each of the jars that your latest dependency pulled in through Maven). That's zealotry at its best. Perhaps if the java community (or should I call it a committee?) was willing to admit that Java has severe deficiencies, it would improve faster? I know it's far easier to just rip on Microsoft while writing yet another web or IoC framework that no one will ever use.
These days, many compilers offer mechanisms to access SIMD instructions from the high level language, so that you don't have to yourself. These vary from special vector types, to "intrinsic functions" that model the target instructions, to directives to specify pointer alignment and loop iteration count properties. The compiler for the architecture family I work on is rather sophisticated in this regards, and it does some really impressive transformations. Even without annotations, it can figure quite a lot out if enough of the program is visible to it.
That said, I sometimes still pop down to hand-coded assembly when it really, really matters, but these days it's usually to do things that can't be expressed in C/C++, such as manipulating interrupt vector tables or aspects of the run time environment. Most people I know that try to "optimize" something by writing assembly code delude themselves that they can outperform the compiler. I remember seeing this one several-page assembly function that had been optimized over several months by one of our teams at work get replaced by ~30-40 lines of properly written C code that compiled to 30% faster code. Assembly code isn't magic.
Program Intellivision!
I can version a repo if I want to. Again, what special magic does Microsoft have? As for repeatable, isolated, etc...it's called a build script which you can execute outside of an IDE, on the command line. As for checking in the JDK, I can but I don't need to because I can retrieve any version I want at will.
As for Jar hell issue...most sources of open source jars also provide hashes to verify you've got the right jar. It's not rocket science. Granted, not everyone verifies these hashes, but that's not a Java issue.
Java does have deficiencies but you have failed to name any of them. Congrats! I have no problem discussing Java's deficiencies because I also have no problem being one of its harshest critics. Like I said before, it's not my language of choice -- it's the language I put food on the table with.
Finally, where did I rip on Microsoft? I certainly can, but I challenge you to find it anywhere in this thread. The only zealot here is you.
Are agnostics skeptical of unicorns too?
I don't think so. Go is very different than Python. Python's designed to be a really simple procedural + OOP language. Go is procedural only, but the big idea is to facilitate concurrent programming by forbidding shared mutable state, and have all thread synchronization be done by communications channels. Even if Python suddenly became a lot faster, it would still be haunted by shared memory issues when it comes to concurrent programming, and Go would still have the advantage for writing concurrent code.
Are you adequate?
And you need to build and deploy crap by hand, and then attach the debugger, tell it where the sources are, etc.
Sure, WinDbg is a viable option, but far from a convenient one. Some folks at MSFT use Rascal as well - an xcopy-able custom build of VS2005 debugger.
Apparently you don't understand what "jar hell" means. Let me really break it down for you.
Let's say you use foo.jar, which relies on a concrete version of log4j.jar. Let's also say foo.jar requires bar.jar, which in turn requires a different version of log4j.jar.
In .NET you deploy two different assemblies side by side and they coexist peacefully.
In Java you're fucked. Now, there are OSGI bundles now, but their use is far from widespread. This means that Java developers have no fucking clue whether jars in their their extensive dependency hierarchies are even fully compatible. :-)
Well originally you were arguing that it was impossible to rebuild your code to be exactly the way it was in a previous release. Now you're talking about dependency resolution.
In any event OSGI and Java Modules (JSR 277) address the dependency management issue. I do agree it has sucked up till recently and I would also agree it has taken too long to get implemented. However, in practice this has had little impact for most since most Java jars are designed for backward compatibility so grabbing the latest one is safe but one exception is with the xerces libraries which are pretty notorious for causing issues if you don't have your shit straight. I've been doing Java since 1.1 and the only time this has been an issue is with xerces.
I still don't see any wet dreams on the horizon though.
Are agnostics skeptical of unicorns too?
Are there any IDEs for Kernel Programming?
I'd like to buy homeland for our 10 million people. http://twitter.com/mahadiga
... The discussion is wobbling around Microsoft's coders and tools and why machine code isn't necessary anymore ...
And here we were just discussing yet-another-chip-bug in an Intel chip which affects, as they say, 'three guesses and two don't count', yes, a Microsoft product. (Remember? Something about timer interrupts which can get stepped on by other timers, hanging the system. It's a known bug. In fact, there's 69 pages of known bugs in the i7 chip "errata" sheet.)
I would (gently) ask this: Which programmer is more likely to make the mistake of relying on this timer:
Programmer A, who learned C++ in college and is wizard at high level abstraction, or,
Programmer B, who has gone down to the bare metal and programmed chips?
Who is more likely to actually read the errata sheet that says, 'Don't use this frickin' timer'?
My answer is that people who have read chip datasheets (and errata sheets!) before are far more likely to read them again before trying to use that (broken) timer on the i7 chip.
Something else which really troubles me is how hard this bug may have been to find. Windows crashed? And the processor hung, not "leaving any tracks" in memory? I will just mention that this has happened to me a time or two (*cough, cough*). Just realizing it was a seperate and new bug was probably awful.
Now imagine you're the poor slob at Redmond who has to fix this! You're told: "Windows Server crashes. Fix it." What are you gonna do? If you don't have an in-circuit emulator that can "watch" the crash, you are in for some real debugging hell. I've been there.
Someone had to fix this problem and make a "hot patch". What language do you think they used, APL?
Someone still has to read the datasheets that chip manufacturers put out, in particular the North/Southbridge chipsets. The Linux people are getting really good at it.
People overclock RAM. They have to understand enough about SDRAM to do that. That's machine level clock-cycle stuff. They also overclock CPU's and use amazing cooling systems (anyone for liquid nitrogen?).
Back When Dinosaurs Ruled The Earth and I was in college, I was told that assembly was on its way out and a High Level Language, PASCAL, was going to be the standard. This was 1976-1980.
It's been awhile since I've even seen a PASCAL compiler, but the Visual C debugger shows me RAM, disassembly of opcodes, and all the Intel registers step-by-step ... and man, does it ever help to know what the hell each assembly instruction does.
There's a time and place for high level abstraction. And there's a time and place for talking to the chips. I suspect that people's opinions about this are something like the C "brace wars" (the "proper" placement of "{}".)
Enjoy --
Dave Small
There are earlier version which don't have vsplit. Depends what your definition of "modern" is. Remember there are many server installations which are difficult to upgrade for many reasons.
Besides all that, how exactly is splitting the screen vertically going to help with lines which are so long they're either truncated or wrapped? Vertical splitting is for editing two files in parallel - as with horizontal split. I don't follow how splitting is relevant here.
Well, for all practical purposes in most (99%) of Java dev teams, it is impossible to rebuild a version from 2 years ago an be sure it's exactly the same (modulo the fixes). No one uses versioning for tools, jre and and jars. Everyone uses Maven and pulls the deps either directly from maven repos on the web, or set up Nexus, which is not versioned either. In addition, folks see nothing wrong in deploying their code on a newer (or just plain different) version of a JRE. They just cross their fingers and hope it will work somehow. I know it for a fact that OpenJDK, for instance, doesn't even run Netbeans properly.
You may be doing things differently, but you're the exception rather than the rule.
>> Java jars are designed for backward compatibility
>> so grabbing the latest one is safe
Heard that tune MANY times. The simple fact is, YOU DON'T KNOW THIS. That's precisely my point. Some Joe Sixpack changes calling semantics of a function on a whim and you end up with hairy issues in production, because a function, for instance, throws the kind of exception you don't catch further up the stack.
It will be another three or four years until OSGI becomes mainstream. By then .NET will have had cryptographically verified side-by-side deployment of code for well over a decade.
I agree with you. The big, fat, ugly problem with the actual MS Studio is the STUPID .NET framework. Bloated, installs files on all the system, the installer is a FUCKING MESS unable to deal with any single error. And if the damn thing looses some obscure file or registry entry, you are doomed... Because the dammed thing do not uninstall, cannot "repair" and reinstall never works because the ridiculous installer. Is a hell.
Religion: The greatest weapon of mass destruction of all time
Guess what Wine uses to have hardware acceleration in their DirectX emulation: OpenGL...
Besides all that, how exactly is splitting the screen vertically going to help with lines which are so long they're either truncated or wrapped? Vertical splitting is for editing two files in parallel - as with horizontal split. I don't follow how splitting is relevant here.
Umm... exactly. You *are* aware that programmers typically edit multiple files in parallel, right? Therefore having a maximized xterm, where that viewport is split, both horizontally and vertically, each window displaying a different file (or in the case of vim, a QuickFix list), is a very common and useful work pattern.
Your problem is you made the silly assumption that, because I use a maximized xterm, I must therefore be writing code with 152 column lines, as opposed to utilizing that extra real-estate for another, more useful purpose. You're wrong, of course. But, please, don't let me stop you from enjoying your precarious perch upon your ever-so-high horse.
"By then .NET will have had cryptographically verified side-by-side deployment of code for well over a decade."
And nobody in the Java community cares. Somehow we manage to survive without it. In fact, I've never ever heard from any Java developer bemoaning the fact that Java doesn't have "cryptographically verified side-by-side deployment of code". Nor have I ever had an issue that made me even think I need that I might need it. So obviously it's only important in your mind.
Are agnostics skeptical of unicorns too?
OK, I made the wrong assumption. Does that make you feel better? ;)
I edit various files in parallel all the time. However, I prefer using multiple screens each with multiple xterms - much more productive.
I prefer using multiple screens each with multiple xterms - much more productive.
For you. People *are* different you know. :)
Personally, I find multiple xterms get lost, while splitting a single xterm makes it trivial to use the keyboard to switch between buffers, add and remove splits, etc, while GNU Screen makes it trivial to add and remove additional sessions and switch between those via the keyboard. This setup also reduces RSI, as there's less movement between keyboard and mouse.
And clearly I'm not the only one who prefers this type of setup given the existence of ratpoison, wmii, and a whole host of other tiling window managers.
You mean Microsoft *didn't* write Vista using interpretive dance? I figured it was that or the "James Joyce" emulator program written in GWBasic in 1983.
Please do not read this sig. Thank you.