221–230 of 252 posts
JetBrains is deadly. IntelliJ IDEA is simply the best tool I've ever used for HTML, CSS, JavaScript, PHP, and PostgreSQL. Incredibly intuitive and it does it all. It's what Photoshop is for designers. This immediately gets me stoked for doing my Unity C# development with this. * Edit. Initially thought this was an entirely new IDE, and not just a plugin. Less excited, but certainly worth a look.
This will have to be very good to be better than Visual Studio on Windows. I've used Visual Studio 2013 a fair bit in the last 12 months and it's a fantastic IDE. Microsoft are also developing their cross-platform offering Visual Studio Code, which is a nice text editor and I imagine it's just going to get better. I am using another JetBrains product, PHPStorm, on the Mac at the moment for some Front End Dev, which i…
> This will have to be very good to be better than Visual Studio on Windows. Having worked with VS for many years, things not so glorious in my opinion. The main criticism is an increasing lack of stability and error prone refactoring. I've basically given up on automatic renaming with VS2015. The IDE crashes more often as it should, especially during debugging. Furthermore the solution/project-file concept (instead…
This will have to be very good to be better than Visual Studio on Windows. I've used Visual Studio 2013 a fair bit in the last 12 months and it's a fantastic IDE. Microsoft are also developing their cross-platform offering Visual Studio Code, which is a nice text editor and I imagine it's just going to get better. I am using another JetBrains product, PHPStorm, on the Mac at the moment for some Front End Dev, which i…
> This will have to be very good to be better than Visual Studio on Windows. Having worked with VS for many years, things not so glorious in my opinion. The main criticism is an increasing lack of stability and error prone refactoring. I've basically given up on automatic renaming with VS2015. The IDE crashes more often as it should, especially during debugging. Furthermore the solution/project-file concept (instead…
This will have to be very good to be better than Visual Studio on Windows. I've used Visual Studio 2013 a fair bit in the last 12 months and it's a fantastic IDE. Microsoft are also developing their cross-platform offering Visual Studio Code, which is a nice text editor and I imagine it's just going to get better. I am using another JetBrains product, PHPStorm, on the Mac at the moment for some Front End Dev, which i…
Completely agree. Also, the fact that Visual Studio Community edition is free, whereas Jetbrains is now on a SaaS model for their products means this is pretty much dead on Windows.
And I say that as a longtime VS fan and advocate!
(Of course, I guess JetBrains products would suffer exactly the same problem now with the new SaaS model - I just needed a rant about this particular issue.)
A full Go ide would have been better in my experience.
You should also consider vim (w. the vim-go plugin) if you're on Unix. It's well-written, and along with several other vim plugins and a decent configuration, it's miles ahead of any IDE (except emacs, not starting an editor war here). Read here, http://farazdagi.com/blog/2015/vim-as-golang-ide/
Colleagues tell me that neovim alleviates some of this, but during the time before that was stable I switched to emacs (specifically Spacemacs) with evil mode instead.
A full Go ide would have been better in my experience.
You should also consider vim (w. the vim-go plugin) if you're on Unix. It's well-written, and along with several other vim plugins and a decent configuration, it's miles ahead of any IDE (except emacs, not starting an editor war here). Read here, http://farazdagi.com/blog/2015/vim-as-golang-ide/
Colleagues tell me that neovim alleviates some of this, but during the time before that was stable I switched to emacs (specifically Spacemacs) with evil mode instead.
Earlier quoted context omitted.
> I feel MS has really dropped the ball with VS. This has been the case for C++ for a while now. Every version of VS has gotten worse since, IDK, 2006 or something (and that's ignoring how long it takes them to finish new versions of the language). I had a suspicion that they had moved their A team over to work on C#, but hearing this... maybe they're just getting worse.
For C# at least every version is at least better than the previous. 2015 was the big Roslyn makeover so I suppose I can accept a few more regressions than usual. But feature-wise, each version has had at least one killer feature that made the previous seem dated on day 1. Examples: edit-and-continue, or lambdas in watches.
Sarcasm notwithstanding, that was a terrible decision that still annoys me almost daily when I want to automate a repetitive task in the text-editor.
Earlier quoted context omitted.
> I hate to say this, but a lot of your issues might also be coming from the TFS integration. I suspect some of the problems are, for sure - our big internal project is a multi-million line app, maybe 70-80 csprojs. VS2013 dealt with it OK, but had its occasional problems (the TFS issues weren't occasional though), VS2015 is much worse in general. It's very unstable. My open-source project LanguageExt [1] uses git an…
Yeah - not surprised the DNX stuff is wonky. It seems like every time there's a new project format the first version is just really awful. I think they really only test it on small almost toy-level projects thoroughly but fully conjecture. That's a very cool project though - what got you going on that? If I could convince my coworkers to not kill me for doing so, I would try to introduce using that at work :-) I've d…
Thank you :)
> what got you going on that?
Heh, long story...
I'm a CTO of a healthcare software house in London, we've been developing a very large web-app in C# over the past 10 years. Over the years it has evolved as any project does, but I started noticing more and more that OO was really not the right tool for the job of managing large inter-dependant systems (well, the Java/C# brand of OO anyway). The promise of re-use, decoupling, composition, ... all seemed to be lies. On top of that I started to get a sense of the common bugs that were coming through: null-reference errors being by far the biggest. The in-your-face bugs like null-ref errors are relatively easy to spot though, what becomes more problematic over time is shared mutable state logic errors. They can remain buried for some time.
I'd already had an interest in functional programming piqued by LINQ and Erik Meijer's talks on Haskell. I spent some time learning Haskell and F#, and came to the understanding that the stability and reliability of a system could be massively improved if null didn't exist, if objects were immutable by default, and if functions were pure/referentially transparent. Expression oriented programming became my order-of-the-day, but C# kept getting in the way. Unfortunately I couldn't just drop it and move to F# because our code-base is huge and written in C#.
So that's when I started writing csharp-monad [1], it was my first attempt at bringing functional concepts into C#. It had a couple of problems though, and they were:
* The types were classes, and therefore if a function returned Option then it could still be null
* It followed the '.NET BCL way' of having functions like GetValueOrDefault() - again breaking the safety net that an Option type (for example) is supposed to give.
It had benefits though, primarily that I could make composable computations with the various monads (using LINQ). The problem with that approach was that it quickly bumped up against the rest of the BCL. And, in my case, the rest of our multi-million line C# OO app.
So I mothballed that project to an extent. I'd use it now and again where I had control over a process end-to-end. But it got me thinking, that the main issues I had were:
1. Non-expression based C# constructs (if/else, switch, etc.)
2. OO-heavy core types, like List, Dictionary, etc.
3. Whenever I brought in 3rd party libraries that 'did functional', they wouldn't work with my Option type in csharp-monad, or any of my functional types - and they never could because there's no baseline for functional (other than LINQ) in C#.
4. The lack of more expressive LINQ grammar makes it less useful and sometimes more cumbersome than Haskell's 'do' notation or F#'s computation expressions.
1-3 cries out for an equivalent of a BCL for functional constructs. I was under no illusion how big a job that would be, but I could see real value in it: a unified set of types for Option, Either, Try as well as collections Lst, Map, etc.
"A functional prelude for C#"
Item 4 was more problematic. I couldn't create more LINQ grammar. So I started thinking about it in a different way. Mostly I wanted to create expression oriented code. It was just safer. But with C# OO you always hit that expression boundary. So I thought about how I could control the boundary. Some of that was to build 'matching' constructs into the core types, but that wouldn't deal with all boundary issues. That's where the actor system comes in (LanguageExt.Process [3] ). I'd looked at Akka.net and its very Java-like API horrified me - it looked like C# 1.0. So I took the idea that a LanguageExt Process (an actor) is a fold over a stream. That suddenly created a very powerful idea that I could create packets of pure computation and wrap them with their state, and each message would evolve that state. In one fell swoop it created a better and more controlled OO that can interact with pure functions - and all fully integrated with the functional BCL I'd developed. It also allowed us to start breaking up our monolithic app in a much more controlled way.
So yeah, that's the back story! Sorry if it turned into War & Peace.
Btw, I am in the market for two developers at the moment. So if none of what you just read horrified you, please drop me an email with your CV to plouth AT gmail :)
[1] https://github.com/louthy/csharp-monad
[2] https://github.com/louthy/language-ext
[3] https://github.com/louthy/language-ext/blob/master/LanguageE...
Earlier quoted context omitted.
Altho I don't share your issues with all the 'bloating' stuff ( as others mentioned most of them can be avoided ) , I have a growing concern for the performance of VS while working with a bigger codebase (120+ projects) . It gets really really slow and full of loading screens which literally block you from doing anything. In fact you can sit there and wait 5+ minutes sometimes just to have the IDE let you do anything…
I would have to ask why you have 120+ projects. That's likely your problem; you're doing far too much within one solution.
Earlier quoted context omitted.
+1 vscode is just using Electron Shell, not entire Atom. vscode is a well executed project. During initial testing vscode seemed much more responsive than Atom to me.
Yeah, VSCode definitely seems more responsive. I tried giving Atom a try 2-3 times now, but it always seemed "laggy" for lack of a better word.