Introducing STFU: Command line C# projects | Hacker News Reader

Introducing STFU: Command line C# projects

github.com

24 pointsdarkxanthos29 comments

.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.)

> 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

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.

I agree, with both you and your sibling. I meant to include "this one is no exception."

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.*"?

I meant making assembly references. I tried it with System.Drawing and csc complained about not being able to find it.

System.dll isn't enough to really stand up anything that isn't very trivial.

Exactly. We're on the same page. :)

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.

And it'll actually work.

In VS: Debug -> Windows -> Immediate

voila, C# REPL! great for testing out code snippets

No Linq (at least in the VS Express editions).

Nor lambdas (in all editions). (Here's why: http://blogs.msdn.com/b/jaredpar/archive/2009/08/26/why-no-l...)

"test some part of C#" - Snippet Compiler already works well for this, if you don't want to start Visual Studio.

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

Is Snippet Compiler stuck at .net 3.5 though? I'm looking here:

http://www.sliver.com/dotnet/SnippetCompiler/

I tried it with default parameters and it looks like no go.

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.

You said the conventions aren't quite to your tastes.. what specifically? I'd love to correct it.

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.

http://www.linqpad.net/ is fairly useful to test c# snippets, if a bit bloated.

There is also the F# interactive window if you're poking into the BCL while in Visual Studio.

If you've got Mono around, there's the interactive C# shell there too. (I think it actually works in .NET as well but I haven't tested it lately.)

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?

Here's a different take at this, that even comes with a screencast (linked in the README):

https://github.com/remi/clide

It's distributed with NuGet.

Awesome! Thanks! It's all about trying new things.

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.

I don't get it.

Could someone clarify WTF is STFU?

it's just a simple exe that will compile a cs file without much fanfare.

Reply on news.ycombinator.com