Hahaha, was your argument just that programming tools that make thing less difficult should be avoided? What is the name of that sect of monks who flagellate themselves...?

Perhaps to be a true programmer you should switch to punch cards.

Also, I looked up that quote... You'll notice he goes on to admit that he still uses one.

OrangeDragon wrote:Perhaps to be a true programmer you should switch to punch cards.

I would not touch Visual Studio, not even with a pole stick, for the same reasons as Google would never touch it. We don't want that crap, not even for free.

It's interesting that mainly hardcore Windows developers feel the need for eye candy like Visual Studio. UNIX beards have been doing well for decades without graphical debuggers and straces.

This sounds more like the classical debate about frameworks to me. Anyway, OD, can you please show somebody that has successfully written an operating system using Visual Studio? Somebody that ever implemented a network stack in Visual Studio? Has anyone written a debugger in it? Disassembler? How many kernels are witten in Visual Studio? How about kernel drivers? Did anyone ever write router or switch firmware in Visual Studio? No matter where I look in network infrastructure it's all POSIX, e.g. Cisco IOS being a shell on top of a Linux kernel. Can you write Assembly in Visual Studio?

This unproductivity that you speak of, where is it? In comparasion, where is the productivity in Visual Studio? If you are right, how come nobody besides Microsoft developers use it? How come the rest of the world has survived so long without it and how come we never see anything impressive coming out somebody's Visual Studio environment? Perhaps I've just missed all the productivity.

Here's James Gosling quoted on the matter, surely the creator of Java would be considered productive?

James Gosling: One of the things I've found kind of depressing about the craft of computer programming is that you see all these fancy development environments out there, and they tend to be targeted at solving certain specific kinds of problems, like building user interfaces. But if you go around and look at the high-end developers, the people who actually have to implement algorithms, if you're using one of these high-end IDEs the IDEs generally don't help you much at all, because they drop you into this simple text editor. The number one software development environment for high-end developers these days is still essentially EMACS. At their heart, these tools are 20 years old, and there hasn't been much in the way of dramatic change. People have made all kinds of stabs at graphical programming environments and that, and they've tended to be failures for one reason or another.

It's always felt to me like there have been some good ideas in these exotic development environment ideas. Why is it that they tended to not work? Why is it that people still use ASCII text for programs? It just feels like there's so much territory out there that's beyond the bounds of ASCII text that's just line after line, roughly 80 characters wide, mostly 7-bit ASCII, something that you could type in on a teletype. That's still where programming basically is these days, and it's proven to be a very hard thing to get anything beyond that.

Dennis Ritchie and Rob Pike both use (/used, R.I.P.) Acme, written by Pike. Are these two developers not productive? Acme doesn't even support syntax highlightning because, from the FAQ:

Q: Is there syntax highlighting?

A: No. The creator of main users of Acme find syntax highlighting unhelpful and distracting.

A good programmer can find and understand the description of the IJK305I error he just got in his JCL manual. A great programmer can write JCL without referring to the manual at all.

:-)

I am intrigued to know what kind of projects you (OD) engage in that causes a productivity boost when developed in Visual Studio. If I am not mistaken, you are are web developer. No offense intended, but if that's your scope then I totally see your point. If you were reverse engineering network stacks in Visual Studio then I'd be impressed, but Windows doesn't really give you that low level access does it? (Can you tcpdump in Visual Studio?) I can, on the other hand, see how Visual Studio can take the edge off common Windows problems like Microsoft's illogical Win16 and Win32 API separation. In POSIX systems we don't really have those problems, all we need is man.

This takes me back to a work project I was engaged in some years ago. It was (to me) a fairly simple cryptographic suite for a hardware dongle. After finding tremendous amounts of bugs in its driver our team in Singapore had to rewrite it from scratch after having wasted nearly 4 years on what turned out to be a broken design, after I pointed out that practically every security mechanism was broken. After breaking it a little more they ended up having to incorporate a webserver into it. As they used Visual Studio, this webserver needed to be IIS. I found it impractical to install IIS on every client installation and went ahead and rewrote the implementation from scratch over night. My implementation was 80 SLOC and worked, compare that to their 200 Mb mess which didn't work. After that, I resigned.

eriksank wrote:Creating a "large" package is not particularly encouraged in this context. The idea is rather to reuse existing packages and build on top of those. A "large" project pretty much sounds like someone spending ages trying to reinvent the wheel, because most of the functionality will inevitably already exist in existing packages. On Windows, that behaviour is normal, because there are no packages and there is no package system, the reason being that the licensing regime on Windows does not allow to reuse packages built by others.

The greatest productivity gain is made when you do not need to write the code, simply because someone else has written it already. In that respect, Visual Studio programmers work in a zero-productivity environment.

Yes. This approach is in conflict with the UNIX philosophy. This is important when speaking about productivity. By nature, the UNIX philosophy methodologies of development eases re-using software in other projects. This is why we don't need Visual Studio, coreutils covers us. In short, it appear to solve a problem that was solved by design in the shell.

The UNIX Philosophy (Mike Gancarz):

- Small is beautiful.
- Make each program do one thing well.]
- Build a prototype as soon as possible.
- Choose portability over efficiency.
- Store data in flat text files.
- Use software leverage to your advantage.
- Use shell scripts to increase leverage and portability.
- Avoid captive user interfaces.
- Make every program a filter.

The UNIX Programming Environment (Brian Kernighan and Rob Pike):

Even though the UNIX system introduces a number of innovative programs and techniques, no single program or idea makes it work well. Instead, what makes it effective is the approach to programming, a philosophy of using the computer. Although that philosophy can't be written down in a single sentence, at its heart is the idea that the power of a system comes more from the relationships among programs than from the programs themselves. Many UNIX programs do quite trivial things in isolation, but, combined with other programs, become general and useful tools.

Program Design in the UNIX Environment (Brian Kernighan and Rob Pike again):

Much of the power of the UNIX operating system comes from a style of program design that makes programs easy to use and, more important, easy to combine with other programs. This style has been called the use of software tools, and depends more on how the programs fit into the programming environment and how they can be used with other programs than on how they are designed internally. [...] This style was based on the use of tools: using programs separately or in combination to get a job done, rather than doing it by hand, by monolithic self-sufficient subsystems, or by special-purpose, one-time programs.

In short, dotadiw, "Do One Thing and Do It Well."

BOFH wrote:By nature, the UNIX philosophy methodologies of development eases re-using software in other projects.

In that respect, github has become yet another fantastic tool. I've also got to say that the npm repository for nodejs is incredible too.

BOFH wrote:This is why we don't need Visual Studio, coreutils covers us.

Yes, coreutils for native bricks. But then again, only the inner loop of things needs to be done in native code. Everything else can be scripted. For that, we have a good core in C: kernel, libC, and tools that run directly on top of that. For my work, I rarely need to add to the native core. Most of the times, that work has been done by someone already.

BOFH wrote: This sounds more like the classical debate about frameworks to me. Anyway, OD, can you please show somebody that has successfully written an operating system using Visual Studio? Somebody that ever implemented a network stack in Visual Studio? Has anyone written a debugger in it? Disassembler? How many kernels are witten in Visual Studio? How about kernel drivers? Did anyone ever write router or switch firmware in Visual Studio? No matter where I look in network infrastructure it's all POSIX, e.g. Cisco IOS being a shell on top of a Linux kernel. Can you write Assembly in Visual Studio?

Cosmos OS was built with VS actually. It included assembly, which yes you can write in VS, but was mostly done in C#. Up until this change there hasn't been much in the way of core languages supported by VS... this changes that. Though you can build compilers, and as COSMOS shows, an OS in C# if you want. Why you'd ever want to build your own compiler is beyond me... other than to pass your CS class because they stupidly assign it as a task frequently. I guess maybe to prove how power-nerd you are and make something like the MOO compiler.

Yes there's been a few disassemblers built.
Yes there has been firmware written in it (even has an "embedded" set of project templates included.)

And so on... but most of all, you can write ANYTHING in it... if the language you want to use isn't supported, add it via a plug-in. Quite simple to do.

BOFH wrote: This unproductivity that you speak of, where is it? In comparasion, where is the productivity in Visual Studio? If you are right, how come nobody besides Microsoft developers use it? How come the rest of the world has survived so long without it and how come we never see anything impressive coming out somebody's Visual Studio environment? Perhaps I've just missed all the productivity.

They don't use VS, but they ARE using robust IDEs... just none really compare with it for power and usability (though PHPStorm isn't too bad). To imagine to yourself that they don't is naive. IntelliJ, Eclipse, PHPStorm. Though for C,C++ I've certainly met more than a few who use VS for them. Even a few PHP developers who used VS with the PHP add-on.

BOFH wrote: Here's James Gosling quoted on the matter, surely the creator of Java would be considered productive?

James Gosling: One of the things I've found kind of depressing about the craft of computer programming is that you see all these fancy development environments out there, and they tend to be targeted at solving certain specific kinds of problems, like building user interfaces. But if you go around and look at the high-end developers, the people who actually have to implement algorithms, if you're using one of these high-end IDEs the IDEs generally don't help you much at all, because they drop you into this simple text editor. The number one software development environment for high-end developers these days is still essentially EMACS. At their heart, these tools are 20 years old, and there hasn't been much in the way of dramatic change. People have made all kinds of stabs at graphical programming environments and that, and they've tended to be failures for one reason or another.

It's always felt to me like there have been some good ideas in these exotic development environment ideas. Why is it that they tended to not work? Why is it that people still use ASCII text for programs? It just feels like there's so much territory out there that's beyond the bounds of ASCII text that's just line after line, roughly 80 characters wide, mostly 7-bit ASCII, something that you could type in on a teletype. That's still where programming basically is these days, and it's proven to be a very hard thing to get anything beyond that.

He's not saying don't use IDEs... he's complaining that they don't go a step further... which since then they really have. I have done proof of concept development using some of the built in systems in VS with C# that literally allowed me to point it to a completed database and it generated a full UI for a semi-rich CRUD interface. The kind of interface you could shove at an accountant or admin just to "get the job done" without too much bitching. Literally 30 seconds and it was done.

BOFH wrote: Dennis Ritchie and Rob Pike both use (/used, R.I.P.) Acme, written by Pike. Are these two developers not productive? Acme doesn't even support syntax highlightning because, from the FAQ:

Q: Is there syntax highlighting?

A: No. The creator of main users of Acme find syntax highlighting unhelpful and distracting.

A good programmer can find and understand the description of the IJK305I error he just got in his JCL manual. A great programmer can write JCL without referring to the manual at all.

See above about power nerding. Are they unproductive? No.. they got stuff done. Are they less productive than they could have been? Quite possibly. Amazing how much linux developers often sound like luddite hipsters, lol.

BOFH wrote: I am intrigued to know what kind of projects you (OD) engage in that causes a productivity boost when developed in Visual Studio. If I am not mistaken, you are are web developer. No offense intended, but if that's your scope then I totally see your point. If you were reverse engineering network stacks in Visual Studio then I'd be impressed, but Windows doesn't really give you that low level access does it? (Can you tcpdump in Visual Studio?) I can, on the other hand, see how Visual Studio can take the edge off common Windows problems like Microsoft's illogical Win16 and Win32 API separation. In POSIX systems we don't really have those problems, all we need is man.

Currently my principal project is web, however quite often I'm developing actual productivity software. Accounting, management, analytics type stuff. Even a nice semantic engine once that does some pretty amazing shit with detecting the "mood" of the internet in relation to a set of search terms in near realtime. None of it is drivers, though I've gotten into drivers on a project that involved a proprietary IR receiver... not a fan.

And you don't "tcpdump in Visual Studio"... its like asking if vi can tcpdump. No, but if you're writing code in vi you can have it do so... just like the code in VS can do. And yes, you can do it in C# (and presumably VB). The win 16/32 separation doesn't really exist for C#. The language and framework deals with it. In C++/C you still have to deal with it yourself.

BOFH wrote: This takes me back to a work project I was engaged in some years ago. It was (to me) a fairly simple cryptographic suite for a hardware dongle. After finding tremendous amounts of bugs in its driver our team in Singapore had to rewrite it from scratch after having wasted nearly 4 years on what turned out to be a broken design, after I pointed out that practically every security mechanism was broken. After breaking it a little more they ended up having to incorporate a webserver into it. As they used Visual Studio, this webserver needed to be IIS. I found it impractical to install IIS on every client installation and went ahead and rewrote the implementation from scratch over night. My implementation was 80 SLOC and worked, compare that to their 200 Mb mess which didn't work. After that, I resigned.

That sounds like just bad architecture... from day one it seems. Its no surprise that their rewrite was broken as well. The IIS thing is irritating, again which makes this good news to see .net coming over to run in linux.

Overall you guys seem to still be talking about "server app" type development while I'm talking about actual enterprise software development. For instance, a company wide accounting and CRM suite that integrates lead generation with a UI so simple a sales guy can actually use it. Connected in with inventory, website contact forms, actual sales and accounting, purchasing with predictive ordering, and so on... something like that, with your suggested "do one thing and do it well" would end up with 30 things doing one thing each, and then each trying to talk to the other to find out what they did. And if one of those one things gets out of synch with the rest... boom. Systematic collapse.

You can see this in something as simple as the wordpress plugin methodology, where core updates end up killing off plugins until the plugin developers scramble to update, and then the people using them scramble to update the plugin as well. The alternative, and much more common in a business setting where the final call is by a CEO instead of IS, is to not update the core at all to prevent the downtime... which leaves major security holes/etc as the core falls further and further behind.

OrangeDragon wrote:Why you'd ever want to build your own compiler is beyond me... other than to pass your CS class because they stupidly assign it as a task frequently.

If there is a program that you cannot write, but that others are capable of writing, you are by definition just a second-rank programmer. Furthermore, you always need a compiler or a scripting engine to do any programming at all. So, that makes you a second-rank programmer dependent on more capable programmers for his main tool. Furthermore, if your main tool is just a black box to you, you will never be really proficient at using it. So, that makes you a third-rank programmer.

So, yes, a good CS course will de-mystify how these things work and elaborate on how lexers, parsers, and context-free grammars work, and why they sometimes may not work; what their limitations are, and therefore why your compiler can parse certain things but could never parse other things. The guys who build and maintain these tools are not some kind of gods or creators of the universe. They are just programmers like other programmers. You can more often than not log an issue with them at github and have a chat with them. Read through their source code, just for the hell of it. These guys tend to be good programmers.

OrangeDragon wrote:Cosmos OS was built with VS actually. It included assembly, which yes you can write in VS, but was mostly done in C#. Up until this change there hasn't been much in the way of core languages supported by VS... this changes that. Though you can build compilers, and as COSMOS shows, an OS in C# if you want. Why you'd ever want to build your own compiler is beyond me... other than to pass your CS class because they stupidly assign it as a task frequently. I guess maybe to prove how power-nerd you are and make something like the MOO compiler.

Yes there's been a few disassemblers built.
Yes there has been firmware written in it (even has an "embedded" set of project templates included.)

And so on... but most of all, you can write ANYTHING in it... if the language you want to use isn't supported, add it via a plug-in. Quite simple to do.

Valid point. I'll leave out the discussion on language performance.

OrangeDragon wrote:They don't use VS, but they ARE using robust IDEs... just none really compare with it for power and usability (though PHPStorm isn't too bad). To imagine to yourself that they don't is naive. IntelliJ, Eclipse, PHPStorm. Though for C,C++ I've certainly met more than a few who use VS for them. Even a few PHP developers who used VS with the PHP add-on.

I don't use any "robust IDE". I'm quite happy with vim and general cli tools.

OrangeDragon wrote:I have done proof of concept development using some of the built in systems in VS with C# that literally allowed me to point it to a completed database and it generated a full UI for a semi-rich CRUD interface. The kind of interface you could shove at an accountant or admin just to "get the job done" without too much bitching. Literally 30 seconds and it was done.

Wonder what a 30 second fuzz test would say about that.

OrangeDragon wrote:Amazing how much linux developers often sound like luddite hipsters, lol.

This shouldn't surprise anyone. The two main products of Berkeley, CA, is UNIX and LSD. Portions of the hippie movement went to Cyberdelia[1]. Like Timothy Leary said: PC is the LSD of the 1990s. I personally find computerized freedom not only utopic but also wonderful and beautiful, but I can see how it scares some.

1: https://en.wikipedia.org/wiki/Cyberdelic

We are not luddite. We just like to use logic and reason for changing our views and behavior. We are probably more driven by the idea that don't fix what's not broken. What's even more beautiful is that we are decentralized not only in behavior but also in code.

OrangeDragon wrote:Currently my principal project is web, however quite often I'm developing actual productivity software. Accounting, management, analytics type stuff. Even a nice semantic engine once that does some pretty amazing shit with detecting the "mood" of the internet in relation to a set of search terms in near realtime. None of it is drivers, though I've gotten into drivers on a project that involved a proprietary IR receiver... not a fan.

Yes, we do different things. Therefore we will have different problems, views and solutions. :-) Besides natural language processing obviously, sentimental analysis is fun. I can't imagine how painful it must be to do with those invoked DLLs.

OrangeDragon wrote:And you don't "tcpdump in Visual Studio"... its like asking if vi can tcpdump. No, but if you're writing code in vi you can have it do so... just like the code in VS can do.

vim has shell access, you can tcpdump from it.

OrangeDragon wrote:And yes, you can do it in C# (and presumably VB). The win 16/32 separation doesn't really exist for C#. The language and framework deals with it. In C++/C you still have to deal with it yourself.

So it's safe to say that you don't touch internals with VS?

OrangeDragon wrote:That sounds like just bad architecture... from day one it seems. Its no surprise that their rewrite was broken as well. The IIS thing is irritating, again which makes this good news to see .net coming over to run in linux.

Agreed. That's why my solution was to resign. I see no benefits with running .NET in this case. Frankly, even less so in the case of my 80 SLOC fully functional dongle driver for handling cryptographic key exchanges with an RFC valid raw packet httpd implementation.

OrangeDragon wrote:Overall you guys seem to still be talking about "server app" type development while I'm talking about actual enterprise software development. For instance, a company wide accounting and CRM suite that integrates lead generation with a UI so simple a sales guy can actually use it. Connected in with inventory, website contact forms, actual sales and accounting, purchasing with predictive ordering, and so on... something like that, with your suggested "do one thing and do it well" would end up with 30 things doing one thing each, and then each trying to talk to the other to find out what they did. And if one of those one things gets out of synch with the rest... boom. Systematic collapse.

Exactly my point. You do GUIs, I don't. I see why drag and drop programming helps your case, it doesn't help mine. There is nothing VS has to offer which would make it easier for me to do what I do. I don't want to do grid based development that I can handle to somebody who doesn't do software development to finish it for me in 30 seconds. I don't do apps. I do infrastructure, protocols and algorithms. Even if VS does disassembly, it will never do what IDA, OllyDBG, Valgrind or Immunity does better. If VS helps you guys in the application and presentation layer, that's great. I'm much more comfortable a few notches down in the OSI and that does not make me unproductive.

OrangeDragon wrote:You can see this in something as simple as the wordpress plugin methodology, where core updates end up killing off plugins until the plugin developers scramble to update, and then the people using them scramble to update the plugin as well. The alternative, and much more common in a business setting where the final call is by a CEO instead of IS, is to not update the core at all to prevent the downtime... which leaves major security holes/etc as the core falls further and further behind.

Frankly, in the UNIX philosophy, we don't see this at all. You can't really point at WordPress development and use it as an example in this case. I don't think that anybody in this thread will disagree with you on the point that WordPress and its developers are crap.

The only benefit in VS and .NET coming to Linux lays in people like yourself finding an easier transition to develop on those platforms. It doesn't help Linux developers develop on Linux, it helps Windows developers develop on Linux. As a Linux developer for nearly two decades, I think this is a mistake and the wrong way of approaching the platform. The more you use VS and .NET on Linux the more time you waste, time which could have been spent on developing on the platform by actually interacting with it rather than staying on Microsoft's desperate bridge to market share. There's a reason why only Windows developers are excited. I repeat myself, VS and .NET for Linux solves problems we don't have :-)