No one is supposed to know what I'm actually talking about!

Soooo true... I am blown away when I see "programmers" that don't know the bare essentials concerning debugging.

"Set a break point? What's that?" -Senior "Engineer"

It's all about the load curve. Static typing is heavily front loaded, dynamic rear loaded.

Also, a complete retard would have a problem destroying a staticly typed system, whereas they could easily introduce chaos in a dynamic code base with one check in.

Anyone seriously deving in dynamic languages is probably using a strict pre-processor anyways. At least I'd hope so.

Dynamic typers: Let's let the end users find the problems.

Static typers: I'd rather have the compiler take a look first.

So war it is! ;) @GeneralDouche get my Shotgun.

We use a self-hosted gitlab server now. I'm very happy with gitlab but I've been using gitlab since the beginning of time.

It just depends on what you are doing, you can use a self hosted gitlab if you are serious or gitlab.com for a free (I think) service.

Nothing really wrong with github in my opinion (other than their retard pull vs merge nomenclature) and its benefit is it's used by so many that you're bound to get more contributions and activity in that ecosystem.

Moving repos is easy, so can't really go wrong. Don't like github, go to gitlab in 10 minutes. It's literally copy and paste easy.

Send me a PM when you decide so I can check it out (unless it's a Voat clone, then it's war. Not really but I have an image to maintain ;) ).

You can make this truly robust but you'd need to make it more organic - cycling through a series of websites, and especially just the root page is not ideal.

What might be best is to start a search and have links returned then navigated and thus having a flow. This concept has a lot of potential but needs more logic involved.

The solution above is bad for two reasons: The searches they do are very questionable (incest, stds, murder) and secondly, this is only google search.

I've created some fantastic messes. Wrote an ORM framework back in the day that uses the .NET CodeDom to write all logic then outputs source code files, thousands of them, which are then compiled as libraries.

Extending this is a nightmare but I have a few apps that use it exclusively for all database interaction so it lives on unfortunately.

If I need to modify an if statement in the output, finding the code that expresses this if statement is nearly impossible.

I'd only argue that DRY is a never compromising principle. If you have 3000 unit tests that are all copypasta and you refactor something they all touch it makes updating them all painful.

Sending help package now...

Yeah, I looked at the script and noticed you were concatenating titles. I think originally I thought this was a bug. Makes linking a bit interesting.

Anyways, it's interesting and I'll be eyeing this.

Very interesting and random. I really like seeing things like this.

As others have mentioned a link would be great.

Translate a problem into a solution - The critical element a lot of devs don't have.

Once you can solve problems logically, language/stack isn't a significant barrier.

Good luck, can't be done with average devs.

F# - parallel data analysis and related libraries.

I'll ask the automation team at work what tools they use to test UIs. Will comment later.

But shipping is the most important thing with software. That's when you find all the bugs and the fun really starts.

It's not a fault, it's bad code.

Bad code is bad, just like your bad code examples that aren't braced properly.

I think Microsoft should force you to brace every for, foreach, if, if/else, etc statement because unbraced blocks can present bugs if the developer doesn't have the education to indent properly. Now argue that we don't need that safety in C# using your same logic.

It's really not a gotcha or something that should be fixed IMO. It's how lambdas work, they are executed in the scope/context of their creation, they have to be. So a lambda's scope variables can always change.

To me this is not a bug, it's an education/testing thing. Devs should understand how lambda scoping works (what block is in scope when lambda is created) and then this isn't an issue. Lambda scoping is still block scoping at the root though, just which block is the confusing part I suppose.

JavaScript closures and C# lambda scoping are identical (nearly).

If you had this bug in JavaScript you'd be laughed and mocked out of a job but in C# it's a big issue?

It only took them 10+ years. I remember being excited that the C# language/CLR was standardized but that went nowhere except Mono if you were paying attention. Once all those Java devs, and other platform devs realize .NET is the cleanest platform available I think MS will benefit with more MSDN licenses and VStudio copies sold.