Hacker News Reader

Comment by eropple | Hacker News Reader

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

View on HN

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

Reply on news.ycombinator.com