4 ms·

Isn't it a bit cynical then that a VT100 terminal emulator and the unix shell are still my biggest productivity boost as a programmer? The Windows development e

Isn't it a bit cynical then that a VT100 terminal emulator and the unix shell are still my biggest productivity boost as a programmer? The Windows development environment is a terrible mess. Its command window and batch script language are barely usable. The Windows guys didn't care to fix this problem in a long long time. While Unix/FOSS platforms have traditionally been very strong in developers tooling. If you look in Windows more generally, they seem to be more wary not to break compatibility than Linux. That's because they need to run ancient programs that cannot be recompiled. I would say that "too late to fix it" is actually a problem with proprietary software, not FOSS.

thfuran 8y ago
Developers deciding to develop good developer tooling on a FOSS platform is about the least surprising possible outcome and doesn't really seem to have much to do with whether FOSS or enterprise is better suited to fixing a big, uninteresting problem.
banachtarski 8y ago
This isn't a super fair characterization. Visual Studio is miles ahead of Xcode or anything available on Linux as far as debuggers are concerned. You also have Windows Subsystem for Linux if you need it. Just because it doesn't conform to your particular workflow doesn't mean the development environment is a "mess." Personally I'm more productive in Linux for certain kinds of work, and more productive in Windows for other things (graphics work mainly, as the driver situation for GPUs on Linux is a "mess" to use your words).
- jstimpfle 8y ago
  Yes, Visual Studio has a reputation for having the best in class debugger. While I don't know any graphical debugger for Linux that I would prefer to gdb. Other than that, Visual Studio has a reputation for being a morass slow POS. (Apparently that has gotten a little better with the latest releases). The game developers I follow all use Visual Studio exclusively for debugging. Otherwise they use a standalone editor and hand picked tooling, and batch scripts and the command window (or something like mintty which has its own problems) while cursing all the time.
  - banachtarski 8y ago
    > The game developers I follow all use Visual Studio exclusively for debugging. I work with all sorts of people in the industry across genres and I've seen plenty of workflows at many studios. I have no idea where you are getting this but you don't have any idea what you're talking about.
    - jstimpfle 8y ago
      I am talking about the game developers that I follow. I like to think that I have a good idea about the game developers that I follow. If you do it differently or know many people who do it differently, that's fine with me. I don't work in the game industry. The general statement I made was that VS is slow and that it has bugs. I also know from my own experience that this was more true in 2011 than it is now. I still don't like it.
      - banachtarski 8y ago
        Out of curiosity, who do you follow?
        jstimpfle 8y ago
        Mostly Casey Muratori and Jonathan Blow. I've also watched a few streams by Abner Coimbre who now works for Jonathan Blow. And generally I like the guys from the circle of RAD Game Tools, although I'm not sure about their workflows. I believe Sean Barrett still uses Visual Studio 6.0 which is from the year 1998 according to Wikipedia.
- msla 8y ago
  > Visual Studio is miles ahead of Xcode or anything available on Linux as far as debuggers are concerned. That's one aspect, sure. The rest of Windows is a mess as far as programming goes, especially once you leave the simple case of "Oh I'll write everything how Microsoft currently prefers and hope it doesn't pull another COM-to-.Net again, pulling the rug out from under my whole ecosystem."
  - pjmlp 8y ago
    Because writing software as if still sitting at Bell Labs is so much better.
    - msla 8y ago
      It certainly is if I'm not suddenly destroyed by a minor shakeup at Microsoft.
mehrdadn 8y ago
> Isn't it a bit cynical then that a VT100 terminal emulator and the unix shell are still my biggest productivity boost as a programmer? The Windows development environment is a terrible mess. Its command window and batch script language are barely usable. It doesn't sound like you do Windows development? Batch files are hardly at the center of it. Things just work differently over here, and if you're gonna insist on doing things the way you're used to then there's going to be corresponding friction, just like I would if I tried Linux's GUI dev tools. Though even the CLI friction on Windows is far less now that WSL has come around. (Though PowerShell's been around for a while, which you somehow omitted.)
- jstimpfle 8y ago
  >It doesn't sound like you do Windows development? I do, although I have only done it part time for about 16 months. And I don't do business software. I'm working on a compiler in my spare time, and on an industrial dashboard for work. Both are written in plain C (plus OpenGL and FreeType for the latter) and run under Linux as well. Command window and batch files are still way more productive for me than using a pile of junk that I don't understand, hidden behind an IDE that I cannot automate.
  - AnIdiotOnTheNet 8y ago
    "I don't want to bother learning to use the good tools, so I'll just base my opinion on all the shitty ones".
    - jstimpfle 8y ago
      Would you care to substantiate your accusations? What tools do you think are superior to approaches that let you control what happens, and do not require you to push all operations through a slow, RSI inducing, non-automatizable GUI?
      - zaphar 8y ago
        You absolutely can automate the GUI. People make very good money doing exactly that. The key difference is that the barrier to doing that automation is higher than automating a CLI.
gameswithgo 8y ago
I'm definitely not arguing that FOSS is always worse or anything. But there are certain hard, minor usability things that tend to never get dealt with in that space. Detecting key-up fits that category. It isn't a big deal, and hard to make it happen, so it won't happen (and in this case maybe it shouldn't)
- cryptonector 8y ago
  No it doesn't. FOSS had nothing to do with why ttys are the way they are.
p2t2p 8y ago
While I am much more productive in Unix command line than in GUI I still am not sure if it is real productivity boost or I just have a skill and simply used to Unix command line.
- jstimpfle 8y ago
  The command-line is a huge productivity boost: 1) The programmer does not need to synchronize with the results displayed on screen. That's because the command-line is technically not that interactive. Input is coming from a serial line. As long as the programmer knows by heart the state transitions that his previous inputs will effect, he can simply continue typing without caring if the effected state is already displayed on screen. This is serious because typical systems can often not keep up with user input since processing is jerky and many operations simply take a certain amount of time. But GUIs with their focus based input model absolutely require that the state is updated on screen before the programmer can continue with inputs. The interpretation of inputs in GUIs is a function of the on-screen state (besides the user devices' inputs). So the serialized nature of command-lines not only saves time, but significantly reduces the stress induced upon the programmer. 2) All operations that the programmer knows how to do "interactively" can easily be combined in a script for automation. Both points are arguably missing from IDEs. The only ad

thfuran 8y ago

Developers deciding to develop good developer tooling on a FOSS platform is about the least surprising possible outcome and doesn't really seem to have much to do with whether FOSS or enterprise is better suited to fixing a big, uninteresting problem.

banachtarski 8y ago

This isn't a super fair characterization. Visual Studio is miles ahead of Xcode or anything available on Linux as far as debuggers are concerned. You also have Windows Subsystem for Linux if you need it. Just because it doesn't conform to your particular workflow doesn't mean the development environment is a "mess." Personally I'm more productive in Linux for certain kinds of work, and more productive in Windows for other things (graphics work mainly, as the driver situation for GPUs on Linux is a "mess" to use your words).

jstimpfle 8y ago
Yes, Visual Studio has a reputation for having the best in class debugger. While I don't know any graphical debugger for Linux that I would prefer to gdb. Other than that, Visual Studio has a reputation for being a morass slow POS. (Apparently that has gotten a little better with the latest releases). The game developers I follow all use Visual Studio exclusively for debugging. Otherwise they use a standalone editor and hand picked tooling, and batch scripts and the command window (or something like mintty which has its own problems) while cursing all the time.
- banachtarski 8y ago
  > The game developers I follow all use Visual Studio exclusively for debugging. I work with all sorts of people in the industry across genres and I've seen plenty of workflows at many studios. I have no idea where you are getting this but you don't have any idea what you're talking about.
  - jstimpfle 8y ago
    I am talking about the game developers that I follow. I like to think that I have a good idea about the game developers that I follow. If you do it differently or know many people who do it differently, that's fine with me. I don't work in the game industry. The general statement I made was that VS is slow and that it has bugs. I also know from my own experience that this was more true in 2011 than it is now. I still don't like it.
    - banachtarski 8y ago
      Out of curiosity, who do you follow?
      - jstimpfle 8y ago
        Mostly Casey Muratori and Jonathan Blow. I've also watched a few streams by Abner Coimbre who now works for Jonathan Blow. And generally I like the guys from the circle of RAD Game Tools, although I'm not sure about their workflows. I believe Sean Barrett still uses Visual Studio 6.0 which is from the year 1998 according to Wikipedia.
msla 8y ago
> Visual Studio is miles ahead of Xcode or anything available on Linux as far as debuggers are concerned. That's one aspect, sure. The rest of Windows is a mess as far as programming goes, especially once you leave the simple case of "Oh I'll write everything how Microsoft currently prefers and hope it doesn't pull another COM-to-.Net again, pulling the rug out from under my whole ecosystem."
- pjmlp 8y ago
  Because writing software as if still sitting at Bell Labs is so much better.
  - msla 8y ago
    It certainly is if I'm not suddenly destroyed by a minor shakeup at Microsoft.

mehrdadn 8y ago

> Isn't it a bit cynical then that a VT100 terminal emulator and the unix shell are still my biggest productivity boost as a programmer? The Windows development environment is a terrible mess. Its command window and batch script language are barely usable. It doesn't sound like you do Windows development? Batch files are hardly at the center of it. Things just work differently over here, and if you're gonna insist on doing things the way you're used to then there's going to be corresponding friction, just like I would if I tried Linux's GUI dev tools. Though even the CLI friction on Windows is far less now that WSL has come around. (Though PowerShell's been around for a while, which you somehow omitted.)

jstimpfle 8y ago
>It doesn't sound like you do Windows development? I do, although I have only done it part time for about 16 months. And I don't do business software. I'm working on a compiler in my spare time, and on an industrial dashboard for work. Both are written in plain C (plus OpenGL and FreeType for the latter) and run under Linux as well. Command window and batch files are still way more productive for me than using a pile of junk that I don't understand, hidden behind an IDE that I cannot automate.
- AnIdiotOnTheNet 8y ago
  "I don't want to bother learning to use the good tools, so I'll just base my opinion on all the shitty ones".
  - jstimpfle 8y ago
    Would you care to substantiate your accusations? What tools do you think are superior to approaches that let you control what happens, and do not require you to push all operations through a slow, RSI inducing, non-automatizable GUI?
    - zaphar 8y ago
      You absolutely can automate the GUI. People make very good money doing exactly that. The key difference is that the barrier to doing that automation is higher than automating a CLI.

gameswithgo 8y ago

I'm definitely not arguing that FOSS is always worse or anything. But there are certain hard, minor usability things that tend to never get dealt with in that space. Detecting key-up fits that category. It isn't a big deal, and hard to make it happen, so it won't happen (and in this case maybe it shouldn't)

cryptonector 8y ago
No it doesn't. FOSS had nothing to do with why ttys are the way they are.

p2t2p 8y ago

While I am much more productive in Unix command line than in GUI I still am not sure if it is real productivity boost or I just have a skill and simply used to Unix command line.

jstimpfle 8y ago
The command-line is a huge productivity boost: 1) The programmer does not need to synchronize with the results displayed on screen. That's because the command-line is technically not that interactive. Input is coming from a serial line. As long as the programmer knows by heart the state transitions that his previous inputs will effect, he can simply continue typing without caring if the effected state is already displayed on screen. This is serious because typical systems can often not keep up with user input since processing is jerky and many operations simply take a certain amount of time. But GUIs with their focus based input model absolutely require that the state is updated on screen before the programmer can continue with inputs. The interpretation of inputs in GUIs is a function of the on-screen state (besides the user devices' inputs). So the serialized nature of command-lines not only saves time, but significantly reduces the stress induced upon the programmer. 2) All operations that the programmer knows how to do "interactively" can easily be combined in a script for automation. Both points are arguably missing from IDEs. The only ad