.NET is not Java, and things that are a good idea in Java are not always a good idea in .NET. Then again, I don't think it would make for a very good JVM tool, either. Hard-coded compiler paths. Assumption of Windows as a platform--come on, that's easy to avoid, and close to inexcusable with the existence of Mono. How does this even consume basic GAC resources without a defined reference somewhere?
The code smells, too. If you don't pass in a command-line argument it's going to barf with an exception. WTF?
Meh--I guess I just don't see the point. If you want to "STFU and code" (what a miserable attempt at a catchphrase), shouldn't you have something that actually works? If I want to "STFU and code" isn't it likely that I might dare to want System.Drawing?
Does the dude not know about msbuild/xbuild or something?
> Does the dude not know about msbuild/xbuild or something?
I am guessing not. Or hates it, one or the other.
> The code smells, too. If you don't pass in a command-line argument it's going to barf with an exception. WTF?
(I don't know the author) but in his defense: He started this yesterday and has written about 70 lines of code in 13 commits. Most projects don't really do anything in 70 lines of codes (although there are some notable and AWESOME exceptions.)
This project doesn't really do anything in 70 lines of code, either. That's the thing. It invokes csc on a single hard-coded filename, and doesn't support even the bare minimum of stuff to actually write a nontrivial piece of code.
msbuild ain't perfect, but at least it can reference the GAC.
Actually, this is great even with all the rough edges. You know why? It makes it really simple to test some part of C# in a tiny program if you don't know what you're doing very well. Where I am we all use VS to develop websites and it's a hassle to fire up C# express, create a project and build it for a quick test program. I am familiar with msbuild (have it working great with msdeploy on a continuous integration server) but for small things this would be great with of course a bit more cleanup.
I see the name STFU more like instead of having a long (or short) email exchange about how to do something just whip out STFU and do a quick bit of coding to test out your idea.
"Actually", it doesn't make it really simple to do that at all. This is considerably more complex than copying a 'build all in directory' build file in and running msbuild on it. (Such a build file is the moral equivalent of the generic makefile that most C/C++ programmers have in their back pocket.)
And even tiny bits of code often need to be able to things that are rather basic within the framework. Importing System.* assemblies, for example.
Still smells like a solution looking for a problem.
I just tried it and it was simple enough to use. After using it though I agree -- I'd prefer my own rolled batch file as it has conventions built in that aren't to my taste.
By importing System.* assemblies do you mean automatically adding some boiler plate "using System.*"?
The page of "not doing anything notable or material, but talking up a storm"? I mean, what else can be drawn from submitting 70 lines of broken code to HN?
To be honest, you'd be better off writing that msbuild file mentioned upthread instead of trying to jump on some silly "STFU and code" bandwagon. Unlike this, you can do useful stuff even with a very trivial msbuild file. And you only have to write it once.
i have a test console app ready for that reason.. combined with slick run, i can open it with a few key strokes and be coding in seconds.
also why would you want to miss out on all the helpful vs tools like intellisense, refactoring, code snippets ?
What about the awesome feature in vs that will auto add the namespace for any classes you declare (ctrl+.)?
this thing seems like a poor solution to a problem that barely exists.
It's really minor things like the src and bin directories. I could come to like it that way but if it really is a small chunk of code I'd probably keep the .cs and .exe in the same directory. But that is really minor. The other thing (which people might really not like) that I'd use is copying in a main.cs when doing "stfu new" that has some boiler plate code in there. I'd also display the command options when no input is specified.
I do like the idea in practice -- it's simple but useful. It is also short enough that tweaking it to meet my own needs couldn't be simpler. I'll play with it some more.
Is this a joke project or something? You need to tell visual studio to STFU so you can get some work done? Has this person ever used VS? It's one of the best editors I've ever used. What is he going to use to be more productive, vi?
Thanks for the feedback, exactly the point of releasing early and often no? :) STFU is in its experimental infancy so I look forward to how it affects the workflows of those who use it.
The next step is to get it to test itself so I can start resolving quality issues within it and then beyond that to get it to build tiny WPF apps.
Being able to quickly add references and usings is something I miss when using this tool and I am looking for collaborators to help me brain storm on how to address this. Fork it and let me know what you come up with! :)
I think it is a neat idea, but why do you choose a name (and the tone) to irritate people? I would like to use STFU sometime but I love Visual Studio most of the time. Why put me in an irritable/angry/frustrated state? I hope you come up with a better name.
That's a very interesting perspective. I hadn't thought of it that way but it makes sense in hindsight. Is telling Visual Studio to STFU being taken personally?
When tools get in the way, they should be told to STFU.
29 comments
[ 2.0 ms ] story [ 33.9 ms ] threadThe code smells, too. If you don't pass in a command-line argument it's going to barf with an exception. WTF?
Meh--I guess I just don't see the point. If you want to "STFU and code" (what a miserable attempt at a catchphrase), shouldn't you have something that actually works? If I want to "STFU and code" isn't it likely that I might dare to want System.Drawing?
Does the dude not know about msbuild/xbuild or something?
I am guessing not. Or hates it, one or the other.
> The code smells, too. If you don't pass in a command-line argument it's going to barf with an exception. WTF?
(I don't know the author) but in his defense: He started this yesterday and has written about 70 lines of code in 13 commits. Most projects don't really do anything in 70 lines of codes (although there are some notable and AWESOME exceptions.)
This project does not do anything in 70 lines of code. If we wanted we could create this "functionality" with some lines inside a .bat file
msbuild ain't perfect, but at least it can reference the GAC.
I see the name STFU more like instead of having a long (or short) email exchange about how to do something just whip out STFU and do a quick bit of coding to test out your idea.
And even tiny bits of code often need to be able to things that are rather basic within the framework. Importing System.* assemblies, for example.
Still smells like a solution looking for a problem.
By importing System.* assemblies do you mean automatically adding some boiler plate "using System.*"?
System.dll isn't enough to really stand up anything that isn't very trivial.
To be honest, you'd be better off writing that msbuild file mentioned upthread instead of trying to jump on some silly "STFU and code" bandwagon. Unlike this, you can do useful stuff even with a very trivial msbuild file. And you only have to write it once.
And it'll actually work.
voila, C# REPL! great for testing out code snippets
Snippet Compiler isn't broken, though, like STFU is. For instance, I have the .NET framework in C:\WINNT.
Besides, for command line use, how hard is it to:
1. Start menu, Visual Studio Command Prompt 2. vim temp.cs 3. csc temp.exe 4. temp.exe
http://www.sliver.com/dotnet/SnippetCompiler/
I tried it with default parameters and it looks like no go.
this thing seems like a poor solution to a problem that barely exists.
I do like the idea in practice -- it's simple but useful. It is also short enough that tweaking it to meet my own needs couldn't be simpler. I'll play with it some more.
There is also the F# interactive window if you're poking into the BCL while in Visual Studio.
The next step is to get it to test itself so I can start resolving quality issues within it and then beyond that to get it to build tiny WPF apps.
Being able to quickly add references and usings is something I miss when using this tool and I am looking for collaborators to help me brain storm on how to address this. Fork it and let me know what you come up with! :)
When tools get in the way, they should be told to STFU.
Could someone clarify WTF is STFU?
https://github.com/remi/clide
It's distributed with NuGet.