Speaking for myself, I just can't get used to the Xmonad (or other tiling WMs) way of use. For example, imagine I'm using a web browser and want to open an xterm to quickly type in a couple commands I'm grabbing from a website. A tiling WM only has two choices: Split horizontal, or split vertical, with one window getting X% of the space, and the other getting (100-X)%. But such an arrangement is quite awkward... you either get two skinny, tall windows, or two short, extremely wide ones. Either way, the arrangement is highly suboptimal.
And then there's all the apps that just don't fit well in a tiled environment. Gimp, Pidgin, and Gnome Do are the first that come to mind, but I'm sure there are *many* others. And in the case of Xmonad, the only way to work around that is to explicitly configure those apps to work in a floating mode, which itself isn't all that pretty...
Now, maybe Bluetile (which has been integrated into Xmonad) will solve some of these issues, as it seems to do a great job of marrying tiled and floating layouts so that you can easily switch between the two paradigms. Unfortunately, it's rather immature, not to mention lacking in documentation (for example, there must be a way to turn off their toolbar thinger, but I'll be damned if I can figure out how).
Wow, way to miss the entire point of the damn article. The poster askes for multi-head power tools, and you post a comment about a WM whose author stated (link):
Ion does not support runtime changes in display configuration, and _won't_ get it "right" even over restarts if the displays are shuffled around a lot. I have no plans of writing that support. Xinerama sucks anyway, being incompatible with every other extension, and multihead in general is a fucking waste (of energy etc.) most of the time too.
As an aside, the guy sounds like the Theo de Raadt of the window manager world.
The fact that Sony has "other, substantial businesses" helped when the console slogged through its first few years, but the only console producer that has consistently profited from hardware is Nintendo.
Exactly. So what the hell is wrong with the rest of them?
Oh, right. They're subsidizing their product and selling it at a loss in order to gain a competitive advantage. That's dumping, and there's laws against it.
And regardless, I'm not sure why we should care. Nintendo has shown over and over that selling consoles at a loss is *not* a requirement for competing in the industry. So the idea that the industry will somehow evaporate because the manufacturers can no longer make money from licensing is demonstrably false, given that the current market leader has never had to do so.
According to an article on IGN, the PlayStation 3's production cost at launch was as much as $840.35. They had a hard enough time pushing the console at $600, and an additional $240.35 wasn't going to make that any easier, which would have been the bare minimum without the current business model.
You say that like it's a bad thing.
If Sony can't make an affordable product without basically dumping it on the market (selling *way* below cost and subsidizing income from their other, substantial businesses), then tough shit.
This is a rather dangerous precedent. A completely open system would eliminate any need for licensing which is the console manufacturers bread and butter. Most consoles at least in the first couple years sell at a significantly subsidized loss.
Well, then they should stop doing that, shouldn't they? Nintendo seems to have figured that out. If Sony can't, tough shit.
For example, suppose that someone produced an M-rated game with adult content for the Nintendo Wii console and marketed the game as "Wii Wanker". Wouldn't that harm the family-friendly image that Nintendo has so carefully cultivated and protected? If it does, shouldn't Nintendo at the very least be compensated for you harming their brand?
Only in-so-far as the term "Wii" is trademarked, and thus Nintendo could simply sue.
But as long as the term "Wii" isn't included in the title, frankly, I don't see what the issue is. After all, you don't think less of Dell just because their laptops can be used to browse for porn, do you?
Why is that a problem? It doesn't violate any known laws, as far as I'm aware (the DMCA is concerned with cracking crypto on existing, encrypted content, *not* on creating a compatible implementation of an existing authentication system).
You made an emotionally charged comment that was designed to illicit a response. That's a classic troll.
No. A classic troll begins with a reasonable statement, then progresses to the ludicrous, all with the intent of eliciting a response.
The OP was airing his personal opinion, one held by many. Definitely not a troll, though rating it +5 is probably a little silly, as I wouldn't call it insightful or informative.
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.
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.
600 vertical pixels aren't enough to properly code with. Even really stretching it and using 8 pixels for characters and 2 for line spaces, that's only 60 lines of text full-screen. And your eyes would go crossed trying to read it.
Good lord, that's ridiculous. 60 lines of text is *plenty*, and half that would be perfectly fine. You know, some people actually used to code with just 25! I know, shocking!
Hint: If your subroutines are so long that you need >60 lines visible to be able to comprehend them, you're doing something wrong.
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...
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.
In order to dispense with hardware memory protection (and get the associated speed benefits), the runtime system needs to verify that your code does not diddle its pointers and look at parts of memory that it shouldn't.
Once again, that's a function of the language and the facilities it provides. If your language doesn't give you pointers, you can't "diddle... pointers", can you?
Again, this has *nothing* to do with the underlying runtime system, and everything to do with how the language is designed.
This means using a bytecode that can be checked for type-safety.
Huh? I can only assume you don't really mean "type safety" here, given that "pointer diddlying" and type safety are entirely orthogonal concepts.
So what do you *really* mean?
Sounds to me like what you're *actually* talking about is sandboxing, and in that case, it is generally true that targeting an arbitrary virtual machine, whose bytecode is then executed by a monitoring VM, makes it a lot easier to sandbox code. 'course, then you have to trust the VM (and be willing to pay the price in overhead)...
It's both. Writing traditional parallel code requires a certain level of expertise and experience. OTOH, STM, Actor models, or other modes of concurrency help to do away with some of that complexity... but it still requires expertise to make effective use of those multiprocessing models.
Or: I don't think you can make concurrency easy. But you can make it easier (and safer).
Managed code does (well, can) have one totally awesome feature: provable type safety.
That's ridiculous. There's absolutely nothing about "managed code", aka bytecode, that makes it type safe. Type safety is a function of the language... it just so happens that two of the most common "managed code" languages, C# and Java, are both strongly, statically typed.
OTOH, Haskell is probably the most strongly typed language out there, and it compiles down to machine code binaries.
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...
Slashdot Mirror
Speaking for myself, I just can't get used to the Xmonad (or other tiling WMs) way of use. For example, imagine I'm using a web browser and want to open an xterm to quickly type in a couple commands I'm grabbing from a website. A tiling WM only has two choices: Split horizontal, or split vertical, with one window getting X% of the space, and the other getting (100-X)%. But such an arrangement is quite awkward... you either get two skinny, tall windows, or two short, extremely wide ones. Either way, the arrangement is highly suboptimal.
And then there's all the apps that just don't fit well in a tiled environment. Gimp, Pidgin, and Gnome Do are the first that come to mind, but I'm sure there are *many* others. And in the case of Xmonad, the only way to work around that is to explicitly configure those apps to work in a floating mode, which itself isn't all that pretty...
Now, maybe Bluetile (which has been integrated into Xmonad) will solve some of these issues, as it seems to do a great job of marrying tiled and floating layouts so that you can easily switch between the two paradigms. Unfortunately, it's rather immature, not to mention lacking in documentation (for example, there must be a way to turn off their toolbar thinger, but I'll be damned if I can figure out how).
Wow, way to miss the entire point of the damn article. The poster askes for multi-head power tools, and you post a comment about a WM whose author stated (link):
As an aside, the guy sounds like the Theo de Raadt of the window manager world.
The fact that Sony has "other, substantial businesses" helped when the console slogged through its first few years, but the only console producer that has consistently profited from hardware is Nintendo.
Exactly. So what the hell is wrong with the rest of them?
Oh, right. They're subsidizing their product and selling it at a loss in order to gain a competitive advantage. That's dumping, and there's laws against it.
And regardless, I'm not sure why we should care. Nintendo has shown over and over that selling consoles at a loss is *not* a requirement for competing in the industry. So the idea that the industry will somehow evaporate because the manufacturers can no longer make money from licensing is demonstrably false, given that the current market leader has never had to do so.
with no need for licensing or control over their platforms there is no revenue stream
Well, other than, you know... selling consoles and in-house developed games and thus actually making money on their product like any normal business.
I know, *crazy*.
According to an article on IGN, the PlayStation 3's production cost at launch was as much as $840.35. They had a hard enough time pushing the console at $600, and an additional $240.35 wasn't going to make that any easier, which would have been the bare minimum without the current business model.
You say that like it's a bad thing.
If Sony can't make an affordable product without basically dumping it on the market (selling *way* below cost and subsidizing income from their other, substantial businesses), then tough shit.
This is a rather dangerous precedent. A completely open system would eliminate any need for licensing which is the console manufacturers bread and butter. Most consoles at least in the first couple years sell at a significantly subsidized loss.
Well, then they should stop doing that, shouldn't they? Nintendo seems to have figured that out. If Sony can't, tough shit.
For example, suppose that someone produced an M-rated game with adult content for the Nintendo Wii console and marketed the game as "Wii Wanker". Wouldn't that harm the family-friendly image that Nintendo has so carefully cultivated and protected? If it does, shouldn't Nintendo at the very least be compensated for you harming their brand?
Only in-so-far as the term "Wii" is trademarked, and thus Nintendo could simply sue.
But as long as the term "Wii" isn't included in the title, frankly, I don't see what the issue is. After all, you don't think less of Dell just because their laptops can be used to browse for porn, do you?
Why is that a problem? It doesn't violate any known laws, as far as I'm aware (the DMCA is concerned with cracking crypto on existing, encrypted content, *not* on creating a compatible implementation of an existing authentication system).
So I assume you have a similar problem with, say, razor manufacturers, among many *many* other industries?
You made an emotionally charged comment that was designed to illicit a response. That's a classic troll.
No. A classic troll begins with a reasonable statement, then progresses to the ludicrous, all with the intent of eliciting a response.
The OP was airing his personal opinion, one held by many. Definitely not a troll, though rating it +5 is probably a little silly, as I wouldn't call it insightful or informative.
Uh, that's how TiVo works (unless you have a CableCard model), and yet no one calls that a hack.
Incidentally, I have a dual-tuner setup capping from a pair of low-end DSTBs driven with blasters, and it works great.
Yes, because I'm sure no engineers worked on the LHC. The whole thing was built by a bunch of theoretical physicists. ::rollseyes::
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.
Yes, I'm sure people developing the Linux kernel, for example, aren't "doing something complicated".
Hint: Just because you're using a GUI builder, doesn't mean you're doing anything complicated.
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.
To break out an old saw... you *must* be new here. :/
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. :)
600 vertical pixels aren't enough to properly code with. Even really stretching it and using 8 pixels for characters and 2 for line spaces, that's only 60 lines of text full-screen. And your eyes would go crossed trying to read it.
Good lord, that's ridiculous. 60 lines of text is *plenty*, and half that would be perfectly fine. You know, some people actually used to code with just 25! I know, shocking!
Hint: If your subroutines are so long that you need >60 lines visible to be able to comprehend them, you're doing something wrong.
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...
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.
In order to dispense with hardware memory protection (and get the associated speed benefits), the runtime system needs to verify that your code does not diddle its pointers and look at parts of memory that it shouldn't.
Once again, that's a function of the language and the facilities it provides. If your language doesn't give you pointers, you can't "diddle ... pointers", can you?
Again, this has *nothing* to do with the underlying runtime system, and everything to do with how the language is designed.
This means using a bytecode that can be checked for type-safety.
Huh? I can only assume you don't really mean "type safety" here, given that "pointer diddlying" and type safety are entirely orthogonal concepts.
So what do you *really* mean?
Sounds to me like what you're *actually* talking about is sandboxing, and in that case, it is generally true that targeting an arbitrary virtual machine, whose bytecode is then executed by a monitoring VM, makes it a lot easier to sandbox code. 'course, then you have to trust the VM (and be willing to pay the price in overhead)...
To work properly, the verification needs to be done by the runtime system rather than just the compiler.
Uhuh. Why?
And what specific "verifications" are you referring to, exactly?
It's both. Writing traditional parallel code requires a certain level of expertise and experience. OTOH, STM, Actor models, or other modes of concurrency help to do away with some of that complexity... but it still requires expertise to make effective use of those multiprocessing models.
Or: I don't think you can make concurrency easy. But you can make it easier (and safer).
Managed code does (well, can) have one totally awesome feature: provable type safety.
That's ridiculous. There's absolutely nothing about "managed code", aka bytecode, that makes it type safe. Type safety is a function of the language... it just so happens that two of the most common "managed code" languages, C# and Java, are both strongly, statically typed.
OTOH, Haskell is probably the most strongly typed language out there, and it compiles down to machine code binaries.
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...