New Yorp New Yorp posted:

Does "modifying your program to display a political message every time it's run" constitute a coding horror? There's even a GitHub issue about it that's just waiting to turn into a shitfest.

Asymmetrikon posted:

vim asks me to donate to Uganda on startup and has done so for like, decades, so that seems fine.

Hammerite posted:

~~~HYPERLAMBDA~~~

There's no way it can possibly be serious, the author is a masterful troll.

uncurable mlady posted:

not really seeing the problem here

New Yorp New Yorp posted:

Does "modifying your program to display a political message every time it's run" constitute a coding horror? There's even a GitHub issue about it that's just waiting to turn into a shitfest.

Master_Odin posted:

I expect he'll lock the issue like he did the PR that added in this message.

Ghost of Reagan Past posted:

I once, on a lark, wrote an application that'd create a REST API with Flask from a JSON spec.

I quit when I realized that anything more than simple SQL insert/select and schema updates were going to be nearly impossible to do without building out a DSL that embeds within the JSON.

This guy saw that and said "good idea."

antpocas posted:

this is it

this is the worst code i've ever seen

Bognar posted:

The result of hearing "Lists are slow for lookups, use a Dictionary".

New Yorp New Yorp posted:

I feel like mixing politics/religion and software is bad form in general, but especially right now, since the political atmosphere in the US is so strongly polarized.

I don't want this to turn into a political discussion. If no one else is bugged by that kind of thing, then it's just me.

antpocas posted:

code:

    public class GenericFactory<T> : IFactory<T>
    {
        private readonly Dictionary<string, Type> storedTypes = new Dictionary<string, Type>();

        public GenericFactory()
        {
            TypeHelper.LoadInterfaceTypesFromAssembly<T>().ToList().ForEach(
                type => storedTypes.Add(type.GetType().Name, type.GetType()));
        }

        public T CreateInstance(string typeName)
        {
            Type t = GetTypeToCreate(typeName);

            Guard.Against<ArgumentNullException>(t.IsNull(), "Couldn't find any implementation to type: " + t.FullName);

            return (T)Activator.CreateInstance(t);
        }

        private Type GetTypeToCreate(string typeName)
        {
            foreach (var type in this.storedTypes)
            {
                if (type.Key.Equals(typeName))
                {
                    return this.storedTypes[type.Key];
                }
            }

            return null;
        }
    }

this is it

this is the worst code i've ever seen

Athas posted:

That's not the big problem.

antpocas posted:

NihilCredo posted:

That and, you know, the fact that Activator.CreateInstance has a (String assemblyName, String typeName) overload which makes the class's very existence completely pointless in addition to revolting.

EssOEss posted:

At this 100 person company I work for, there are 2 people who understand DI containers and maybe 10 who use them. Plenty of people think DI is hipster weirdness overhead and a bizarre way to define method parameters.

Edison was a dick posted:

Isn't it enterprise weirdness overhead?

TooMuchAbstraction posted:

Dependency injection is what we're talking about, right? It's loving amazing. You use it to make your code testable. Instead of having a hardcoded reference to the database, your query code takes the DB connection as a parameter, and then your unit test code can create a mock or fake DB and send that in instead. Ditto with network calls, references to the filesystem, etc. Your unit tests can do everything in memory, which means they run faster and more reliably, which means you run them more often, which means they're more useful.

Of course there are good and bad ways to do dependency injection, but one of the things IMO almost every developer should be learning is how to recognize where a dependency should be injected vs. implicit.

Mr Shiny Pants posted:

Meh, I am coming around to the fact that DI just makes stuff more complicated and diffuse. Going on all the question on Stack Overflow from people who can't grasp it, it seems needlessly complex.

New Yorp New Yorp posted:

I like DI, I dislike DI containers.

New Yorp New Yorp posted:

I wasn't talking about DI, I was talking about using DI containers to manage constructing and injecting the dependencies. I like DI, I dislike DI containers.

Mr Shiny Pants posted:

Meh, I am coming around to the fact that DI just makes stuff more complicated and diffuse. Going on all the question on Stack Overflow from people who can't grasp it, it seems needlessly complex.

Hammerite posted:

I find dependency injection difficult to wrap my head around but I recognise that it's a bit of a personal blindspot. The same way some people find it difficult to understand pointers, or what have you, dependency injection is something I find difficult to grasp.

I've felt at times that I had a good grasp of it, when I've seen an explanation that's particularly compatible with my way of understanding things I guess, but I don't use it enough to keep a handle on it for the next time I need to understand it...

New Yorp New Yorp posted:

What's hard to understand about this?
Given this:

code:

public interface IDependency {
   void Butts();
}

public class Dependency : IDependency {
   public void Butts() {
   }
}

Using DI:

code:

public class Foo {
   IDependency bar;
   public Foo(IDependency bar) {
     this.bar=bar;
   }
}

public class Main {
   public Main() {
      var dependency = new Dependency();
      var foo = new Foo(dependency);
   }
}

Using not-DI:

code:

public class Foo {
   IDependency bar;
   public Foo() {
     this.bar = new Dependency();
   }
}

public class Main {
   public Main() {
      var foo = new Foo();
   }
}

The idea is that your classes don't depend on concrete implementations of dependencies defined within the class itself, they depend on being given implementations adhering to an interface.

New Yorp New Yorp posted:

What's hard to understand about this?
Given this:

code:

public interface IDependency {
   void Butts();
}

public class Dependency : IDependency {
   public void Butts() {
   }
}

Using DI:

code:

public class Foo {
   IDependency bar;
   public Foo(IDependency bar) {
     this.bar=bar;
   }
}

public class Main {
   public Main() {
      var dependency = new Dependency();
      var foo = new Foo(dependency);
   }
}

Using not-DI:

code:

public class Foo {
   IDependency bar;
   public Foo() {
     this.bar = new Dependency();
   }
}

public class Main {
   public Main() {
      var foo = new Foo();
   }
}

The idea is that your classes don't depend on concrete implementations of dependencies defined within the class itself, they depend on being given implementations adhering to an interface.

Hammerite posted:

Well, that's not hard to understand at all, in fact it's extremely simple. But generally when I see an explanation of dependency injection it's explained in abstract terms and crucially, the discussion is bundled up with a whole lot of other terms, like "inversion of control" and "SOLID" that I might be able to understand if they were introduced individually but which are too much to take in when all introduced at once and defined abstractly. I'm best equipped to understand concepts when they're expressed in terms of a prototype - a motivating example - rather than an abstract definition. It doesn't help that I tend to remember dependency injection as meaning the kind of big, complex frameworks that other posters are talking about (as being distinct from dependency injection), because that's what I've seen talked about in discussions at work.

New Yorp New Yorp posted:

DI is a method of implementing IoC. It's just a way of solving the problem "I want to test a thing that gets data from a web service/database/other complex component without actually involving the web service/database/other complex component" or, "I want this thing that gets data from something else to be able to get data from any number of something elses based on some set of criteria, without altering the logic of the thing".

Hammerite posted:

It doesn't help that I tend to remember dependency injection as meaning the kind of big, complex frameworks that other posters are talking about (as being distinct from dependency injection), because that's what I've seen talked about in discussions at work.