Hacker News Reader

Comment by tkubacki | Hacker News Reader

I'm using C# mainly because of debugger integration in Visual Studio.

Make decent visual debugger and devs will come.

In general make good tooling and others will come. Look at Java/Eclipse

Can confirm. At work we're moving from Clojure 8 to Java 8 partially because IntelliJ is amazing and partially because Java 8 plus the right libraries is close enough to Clojure anyway, except much faster.

I think as developers we are so used to pain that we forget how "easy" development can be if we allow people the right tools.

If any language had the tooling and development Java did it would hold the market share. It's my opinion that if Rust makes a similar IDE experience (even just using Eclipse's platform) with every feature like code completion, formatting, debugging, the hole 9 yards and integrate Cargo into it they'll win. But, here's the caveat: It needs to be FLAWLESS integration.

I've been a java developer for my entire programming career. Java was my first language when I was 12 and I'm 19 now. I still can't use javac without looking at a compiler guide since I never use it. Eclipse does the business and I don't ever even need to think about what's going on outside my code. Not once.

Java like tooling already existed before Java was born.

We had it in the form of Common Lisp, Smalltalk, Delphi and Visual Basic, IBuilder (for those rich enough), CA Objects, C++ Builder.

To add to this: in school I found Java a complete waste of time.

Started working and someone showed me how to productively use eclipse and suddenly it was acceptable.

That you need an IDE to make a language bearable speaks volumes to the design of the language.

Go is doing well because it realizes we can strip so much away, stay with the standard lib, and get real work done quickly.

That's not to say that Java, in particular the JVM, isn't an impressive piece of engineering, but more that we should be careful when we choose our tools so as to not overly complicate things.

While Java may be somewhat verbose, good tooling is not just about "making the language bearable".

Things like being able to jump to a definition, rename it throughout the project correctly and jump back without even thinking about it are hugely valuable in any language.

And maybe you have ways of doing that in your workflow too, in which case great, you too appreciate the value of good tooling.

Thanks for your comment. It inspires me to write a blog post on why Java is my new favorite language, especially in comparison to Go.

Rather than looking at it as a language that needs an IDE to be bearable, it might be more helpful to look at it as a language that is most pleasant to use in concert with well build tools.

I look at it similarly to the way I look at Smalltalk. It's possible to use it as just a series of text files (with GNU Smalltalk), but using it with tools that understand the language (such as Visualworks or Squeak/Pharo) turns it into a very different experience.

I know that a Smalltalk dev environment feels alive in a way that Java doesn't, but using Java with a tool like IntelliJ is a nice experience. Using something like JRebel or HotSwapAgent to swap code changes into a running application also improves the dev experience significantly.

I'm not a Java developer, so I'm interested to know what the amazing parts of IntelliJ are. When I look at it it just looks like they ripped off the skin from Sublime Text and it has some debugging features that are readily available in other editors. I get pretty much everything on https://www.jetbrains.com/idea/whatsnew/ in my vim setup.

All the refactorings and context-aware code completion, for starters. And as for ripping off, IntelliJ came out 7 years before Sublime Text.

whoa!! this is huge - can you talk a bit more about your stack please. This is the first time I have heard something like this - what libraries, code style, etc would get you the same "feel" as clojure ?

I'm assuming Lombok and using the new Lambdas. Maybe even a fibers library.

Yep, mostly Lombok (especially @Data for immutable typed objects with automatic constructors without boilerplate), streams, and lambdas.

Personally I think Lombok should be mainlined at some point. It's just so perfect in everything I've tried.

are there any opensource github projects that illustrate the use of this infrastructure (java 8 + lombok + streams + lambda) in a very clojure-ish way ?

its hard to find good examples of this style of coding. For example, it is hard to figure out which app server (Spring Boot, undertow, dropwizard, wildfly). I'm sure you can use any... but it would be nice to learn from your experiences.

Could you provide an example project that you'd like to see implemented and I'll give it a go? I'm not the person who's doing this but I think I'd like to mess around with functional programming and I love Java.

Nice! Drip campaigns - https://www.sendwithus.com/resources/guide#ch2-drip

This is an example of a project that is not UI centric, has quite a bit of database integrations (postgres), mailer integrations (mailgun), scheduler (https://dzone.com/articles/distributed-tasks-execution-and-s...). It has also has a bit of math to compute stuff.

Even without a UI - it is something that could be very useful!

Sounds pretty good. I've sent you an email for more details. I'm interested in doing this. It's a cool project idea.

Programming in C# feels almost like scripting. Blazing-fast compilation with the added benefit of static type system. If only MS took a different path of cross-platform support in the beginning.

That was already our experience in Turbo Pascal, Delphi, Oberon, .... :)

My only complaint is that they took the CLR path instead of the Ext-VOS one, with is now reborn as UWP (aka WinRT).

Visual Studio code has pretty decent debugger for Go.

Is that delve? If so, it doesn't work debugging tests, which makes it, depending on your style either totally useless or just quite annoying to use.

Yes, it is a visual interface over delve.

Delve supports debugging tests.

What are you developing with C#? I see Go more for server-side stuff, and C# for Unity/Desktop development...

some legacy Windows server stuff - part of this could be rewritten to Linux/Go/whatever_server_lang just team mates are not willing to leave their comfortable VS env. if not provided with decent IDE/debugger

Interesting. I've used C# heavily at my last couple of jobs and it has all been server side web work - mostly back ends of web apps, but also services and microservices of various kinds.

From talks with coworkers, the impression I've gotten is that most C# in the wild is running server side, though there's obviously a lot of it in desktop apps, and on mobile with Xamarin.

On our case desktop applications for interacting with healthcare and manufacturing devices, web sites and distributed computing.

Make decent unit test coverage and you'll hardly ever see a debugger again. Neither will you need a fancy code editor.

Nope. It is absolutely false. You will always need a debugger and there are some problems that are not unit testable at all. How do you unit test a random WPF bug? And you'll always need a fancy code editor unless you're masochist.

Go doesn't have yet anything capable of matching WPF and Blend.

If WPF was designed from the get-go using TDD, there would be less of a problem here in this case.

I myself have hardly ever needed a debugger in any code i've worked on that has been TDD from the ground up. And it is almost ALWAYS related to OTHER code that was clearly not written with TDD in mind.

Tell me something: What exactly is a "bug"? It is literally just a state the programmer did not expect, correct? So how do you keep all states expected? By constraining them (types, guards, etc.), by testing them in the small (unit testing, TDD), and by making them (ideally) immutable values (preventing unexpected changes to values within one stack frame). If you can control all possible states in the small, you can largely eliminate bugs in the large.

At least, I've found this to be the case after 20 years of working on procedural and OO code...

I am yet to see TDD work with native GUIs.

http://stackoverflow.com/questions/382946/how-to-apply-test-...

It's possible, and it works. Read the topvoted comment there and follow its links.

"This approach removes the GUI layer from TDD and unit testing. It does not mean the GUI is never tested but just acknowledges that it is not cost effective to pursue automated GUI testing, particularly as part of TDD. Integration and user testing should cover the GUI."

Hence, not tested at all via TDD.

I'm not going to say categorically that you never need a debugger...

But, I've been working with Go for years and have never used a debugger. I don't feel like I'm missing out on anything.

That is true, I used to work in legacy Java code base and the debugger was my Lord and Saviour. I am now working in fresh, well tested (both unit and integration) Go codebase and I yet to have to use debugger. Usually adding few debug logs (which usually just stay there for future) and writing test case for new discovered edge case is enough.

Finally, someone who's had the same experience i have had and which i got downvoted for!

Reply on news.ycombinator.com