Hacker News new | past | comments | ask | show | jobs | submit login

Sometimes it feels like we're entering a new age of coding. C# is so full of "features" that code refactoring tools like ReSharper, CodeRush and JustCode became simply indispensable. It is quite hard to be sure, every time, what is the most elegant/compact way of doing things.

In the .Net/VisualStudio world, the language tooling (Intelisense, visual drawing XAML & WinForms, etc) became as important as the language semantics or the availability of frameworks and documentation.

A long ago there was a fad, known as CASE (Computer Aided Software Engineering) that advocated doing on programming what CAD did to other engineering. It seems that were finally getting there.




The most productive I've been as a developer was 20 years ago when I was creating VB6 apps and components...


So true. Between 1998 and 2000 VB6 was perfect, you could develop Windows GUI applications in a rapid manner. The VB6 IDE, the Windows UI guideline, the VB6 API, everything was great. And PlanetSourceCode.com was what was later SourceForge and nowadays GitHub. When I read about Microsoft's vision for .Net in 1999 about applications running as a service over the internet (that was their original idea), I thought that will end the great Windows platform and started looking for alternatives. Microsoft dumbed VB6, but it took them until 2003 to come up with DotNet with a different implementation, it (C# 1) was basically a Java clone with small syntax improvements. The biggest fail was to announce VB.Net and their lackluster Channel9 video that showed the third party developed the converter wizard (VB6 to VB.Net) that barely worked and was free only in the lite version. In the meantime I switched to C, C++, PHP, etc. The web replaced desktop applications in many cases anyway. And nowadays Android and iOS are important targets too. Sadly, the rapid development never got that easy to use as it was with VB6 IDE, with HTML4+PHP with Dreamweaver being almost as fast. But nowadays, the GUI builder aren't as polished and well integrated and don't support all features of the supported languages - so many skip the GUI builder and write the GUI code by hand.


Edit-and-Continue is the greatest productivity feature ever added to a development stack for the real conditions one would encounter in large projects, and it astonishes me even now how misunderstood it's purpose is.

Consulting has me moving jobs a lot and I encounter a veritable kaleidoscope of crappy work. Being able to correct minor issues in scope without restarting, while ten form posts deep in an archaic webforms app with dodgy "we-didnt-know-so-we-rolled-our-own" state management has been a lifesaver. Thank you nineties VB team, it's because of you that I'm not rocking back-and-forth in a padded cell making animal noises today.


If you've ever tried jrebel or even the default hot swap feature on the JVM the edit-and-continue feature feels like a bad joke though. Any non-trivial change requires a restart, and you are forced through a series of distracting button presses and dialogs any time you want to use it.

In Eclipse (for example) you just start typing code, (none of this silly locking the IDE while debugging stuff), and the debugger will update the running program instantly. With jRebel you can even change things structurally without restarting.

Oh how I would love an actually working hot swap feature for .Net.


Does Edit-and-Continue ever work? I'm curious, because I'm almost always forced to build x64-only, because of some libraries we have to use that are 64-bit only, and I've never been able to change code while the debugger is running. Supposedly it is supposed to work in VS 2015, but I'm not seeing it - it's always the nasty messagebox saying "Changes to 64-bit applications are not allowed"


Build 64-bit only or release 64-bit only?

I only ask as I can usually manage 32-bit builds on dev while working, then just test there's no spooky differences when I target 64-bit.

There are issues with some projects that aren't well documented. E+C on web apps on local or remote IIS are a no-go (at least to the best of my knowledge), whereas if you can target IIS express during development it works beautifully.

I've always found that the juice has been worth the squeeze, for values of squeeze that only require me to tweak configuration for my dev box.


I was a huge fan of E&C when I was doing VC++ in the 00s.

I'm not sure about other languages, but with Erlang's hot loading (plus the sync[1] project) I find that aspect to be nearly as good as E&C in Visual Studio.

While it's not quite at the level of 'stop the code from executing, changing something, continue', it's close enough for practical usage - save a file, the underlying module is more-or-less instantly recompiled and loaded.

[1] https://github.com/rustyio/sync


> Between 1998 and 2000 VB6 was perfect, you could develop Windows GUI applications in a rapid manner

Delphi was much better.


I miss Borland.


Since 1984 (SideKick)


I had to do some maintenance on old and messy VB6 code one year ago. I studied best practices to improve the code while fixing bugs.

In the end, I found it hard to do maintenable code for complex applications. And it was not specifically because of the IDE but more because of the way you have to organize the code.

But I did not spend more than some months on it so maybe I'm wrong.


VB.net development is not that different from VB6. It is a way more sophisticated language and therefore can do more complex things. But the basic things take pretty much the same syntax than they were in VB6.


It is and it isn't. VB.Net is basically everything from C# with an syntax heavily inspired by VB6. But the similarity ends there. The RAD IDE of VB6 or Delphi are unmatched, and the compatibility is gone. As WinForms is legacy as well, the whole experience is different anyway. People would like to run their Win32 apps on their smartphone, nowadays you have more luck with Android than what Redmond comes up.


> People would like to run their Win32 apps on their smartphone

And they did actually. Windows Mobile - the original Windows Mobile, 2000-2012 - had 42% smartphone market share in 2007, a native Win32 API (and .Net Compact Framework for C# and VB.Net too), had WinCE kernel and worked on x86, MIPS, ARM and SuperH CPUs.


I loved WinCE/WinMobile back then, except for RAM as document storage - only WinMobile 2005 or so and later supported Flash-storage as well. Though, it supported yet another Win32API implementation with less functions and you had to recompile your code for the target (another reason was: mobile had ARM based CPUs).

All what people like me want is NT kernel, Win classic UI, WinAPI with transparent JIT of x86 exe applications on a mobile device (like WinNT on Mips or DECAlpha or OSX Rosetta). And no nonsense like the metro crap from Win8/10.


Add to it resistive screen with stylus - because it provides much more information density instead of gigantic interface elements catered to fingers-driven UI, with no luck however - fingers are closing half of the screen, unlike a thin stylus - hardware qwerty keyboard and a small optical trackpad, which moves a cursor on the screen or works like two-dimensional Tab button cycling focus between UI elements, depending on mode. Removable battery, and multi-color programmable RGB LED would be nice to have too.

I loved it until the 'trendy' movement toward fingers-driven UI started, around version 6.0.


You mean back when you could type a whole ten characters without twenty new languages and frameworks coming out showing you how obsolete you were? How lame!


Did you ever maintain vb6 apps? Because I still want to cry thinking about the times I've had to.


I have. If they were designed well then they are normally OK to maintain. If they were developed badly then they can take extra effort. Much like any other project in any other language.

If you had an large old Vb6 project build using MVP pattern you would be laughing.


    Much like any other project in any other language.
Yes, you can write good or bad code in any language. But some languages have an endemic culture of not caring about good code. IME, VB is one of them, as is PHP.

All the VB6 code I've seen has been a random mashup of databinding directly to the and click handling. The tools encouraged this approach.


I see your point to a degree. The tools made it easy for folks to get apps up and running quickly, RAD being a popular buzzword at the time. I don't think it's fair to say the culture was that of people who didn't care about the code.

I've certianly seen lot's of terrible VB6 code, but also lots of Vb6 apps that were better designed than some WinForms C# apps I've seen. I know this is all subjective.


My experience tells me that any company whose business isn't selling software, doesn't care about the code.

I have learned the hard way that they don't care one single second about quality, only that it works the way required to support business, anything else is secondary.


In some sense it's true, but what's your point? Still in those companies, a better language/framework can go a long way in conducing better code quality, even if the boss gives zero shit about it.


The boss giving zero shit about it means not getting the approval IT requires to support anything you might want to do.

In such environments even root access is time limited to a few hours and requires a ticket asking for it with a reason that should be validated by the boss.


That type of programming never went away.

That is what I was doing on Windows 3.x and have done while coding in Mac OS X and Windows.

Also the reason I never quite adapted to UNIX mentally of VI/Emacs.

Even though I have spent enough years coding for UNIX that me and Emacs are quite old acquainted with each other.


There's a Vi plugin for almost everything. Highly recommend VsVim for visual studio.


Except I don't like VI at all.

I know the essential for when Emacs isn't available which is quite common on commercial UNIX installations, learned back when Xenix was still being sold and don't intend to learn more than that.

Thanks anyway, I know you had good intentions.


"WinForms" is "language tooling"? "XAML" is "language tooling"? By what definition?

I can write server-side C# in vim (without omnisharp) just fine, actually.

Maybe the tools became "indispensable" because they add value? I refactor my code in vim but it would probably be faster in VSCode. That doesn't make C# a bad language.


C# has (had? I'm still a couple of versions behind) so much syntactical overhead that writing code without a visual studio seems painful at the very least.

The var keyword was the first time it was even possible to write C# without tooling. It has definitely made it possible for me to use Vim for editing C# code. Newer features, such as lambda expressions, and some of the much nicer property syntax makes me feel that it may actually be fun to write C# from scratch without Visuak Studio looking over it.


Compared to what languages ?

I always thought of C# as the improved, less verbous Java. I wouldn't compare it with Python or other dynamic languages, but I prefer it to most compiled languages (especially at the times it was created)


When I read their comment I thought of how much annotation of static types you have to do that compilers in other languages are smart enough to figure out on their own. Consider the following snippet in C#:

    public static IList<Ephraimite> FindEphraimitesToKill(IList<Ephraimite> ephraimites)
    {
        IList<Ephraimite> ephraimitesToKill = new List<Ephraimite>();

        foreach (Ephraimite ephraimite in ephraimites) 
        {
            if (ephraimite.Speak("shibboleth") == "sibboleth")
            {
                ephraimitesToKill.Add(ephraimite);
            }
        }

        return ephraimitesToKill;
    }
Now, the same in (imperative-style) OCaml:

    let findEphraimitesToKill ephraimites =
      let ephraimitesToKill = ref [] in
      List.iter (fun (ephraimite) -> begin
        if speak(ephraimite, "shibboleth") = "sibboleth" then
          ephraimitesToKill := !ephraimitesToKill @ [ephraimite] 
      end) ephraimites ;
      ephraimitesToKill;;
See how much less we had to specify the type of what we're handling here? And things would have gotten easier if we used functional-style OCaml, but that's not entirely a fair comparison.

So hypothetically it should be possible to write a C# compiler that would, if type annotations were omitted in some places, be confident enough to assign a sensible default, which is why we call the current version verbose. Although I suppose it's slightly more complicated than that. (Interfaces, if we want to have them, need to be explicitly declared as there are potentially many interfaces that could be used for a given object, and the rigidity imposed by redundant type declarations could help with the health of large and long-lived codebases.)


I'm probably missing your point, but

  public static IList<Ephraimite> FindEphraimitesToKill(IList<Ephraimite> ephraimites)
  {
      var ephraimitesToKill = new List<Ephraimite>();
      foreach (var ephraimite in ephraimites)         
          if (ephraimite.Speak("shibboleth") == "sibboleth")            
              ephraimitesToKill.Add(ephraimite);                    
      return ephraimitesToKill;
  }
or:

  public static IList<Ephraimite> FindEphraimitesToKill(IList<Ephraimite> ephraimites)
  {
      return ephraimites.Where(e => e.Speak("shibboleth") == "sibboleth").ToList()
  }
is not that verbose.


The thing is, though, would those be allowed by style guides at the enterprise companies where C# is most common?

The C# style guide of a former employer of mine (an enterprise C# user) forbids both of these snippets because of the unbraced statements in the former and the LINQ and lambdas in the latter. But admittedly I don't know what's common among C# users, so maybe they were in the minority.


5-6 years ago enterprise guidelines preventing LINQ/lambda's were more common. Current C# practices for enterprise companies(familiar with 6+ fortune 500's, have not seen or heard of them being banned in the last 4 years) definitely allow lambdas and LINQ.

The "required brackets" is more common but I think it's a good rule :). Readability is only slightly hindered by the extra brackets, but I've seen quite a few errors from

if(shibboleth)

    DoSomething();

    DoSomethingElse();


The brackets, maybe. Preferences for brackets for single lines vary. I personally don't like them, but many code style guides (including MS's) recommend them.

The LINQ version should be allowed almost everywhere that has a good development group. Sometimes LINQ queries can get hairier than the equivalent foreach, but I've never worked anywhere that would frown upon the shorter/cleaner LINQ.


I think its strange comparing languages and then saying that the point doesn't stand because code guidelines of companies don't support the more compact version.

I don't like the version without brackets, but I don't think it would make the code less compact if you'd add brackets.


Second time I'm going to mention VsVim here. You still have to wait a month for VS to start, but you get enough of Vim to be pretty productive.


For the last decade or so the c# world has been moving away from those ill conceived tools. Winforms/Webforms were drag'n'drop based and have since been replaced with xaml and html. SSDT has given way to migration based approaches.

Intellisense has become it's own lightweight thing and consumable from more tools, you can code just fine without it. ReSharper I've never used, I find it gets in my face more than it helps.

If you want to see a tooling based approach, go look at the state of android development these days. That's why we see stuff like react native becoming popular.


SSDT style database upgrades are still the most popular. Since it's what most of the red gate tools do, unless you use ready roll.


With the migrations tools listed above there is no need for any of the red gate tools.


What tools listed above? I haven't seen any DLM tools mentioned.


Sorry, it was in another post:

> My go to migrator is fluent migrator (https://github.com/schambers/fluentmigrator) or flywaydb if anyone objects to the c# (https://flywaydb.org/).


They've been around for a long time.

I don't think they will become as popular as red gate. Since you have to write the migrations yourself. That's a lot of additional work.


They run deterministicaly though, making them much safer. I've done migrations with these tools that would be impossible with redgate, clients could be several months out of date since an upgrade and the migrations would just work. I've seen redgate/ssdt need manual coaching after just a few weeks.

I also think your over estimating the popularity of red gate. A minority of places use it, whereas a lot use EF migrations.


Literally every place I've worked uses red gate.

I've never had an issue with it, If you make sure your database is constantly up to date. So changes are small.


> Literally every place I've worked uses red gate.

I've had the opposite experience, I've only been at one place that used it and a couple that considered it.

> I've never had an issue with it, If you make sure your database is constantly up to date. So changes are small.

This is not an option in many places, if you have 3 month release cycles for instance (although I favor continuous deployment). Another is when you have apps installed on site, some clients can be multiple versions behind.


I don't know about that. I'm working on a codebase that heavily uses C# 6.0 features, and for the most part, the "most elegant/compact way of doing things" is disseminated via code reviews, and quite fast at that. Convenient things stick around and become idiomatic precisely because they're convenient.

Then again, you don't have to always go for the most elegant/compact thing, either.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: