True, but we shouldn't understate how beneficial elegant solutions can be in the appropriate setting. Sometimes you read code that gives you a new and memorable way to think about a certain kind of problem.

▲ pessimizer 10 days ago | parent [-]

I agree we like it. I don't want to have to review it. I'd rather review code where the bugs stick out like blinking yellow lights, even if it runs 10% slower (or 1000% slower, if I'm only running it once.)

	▲	n4r9 8 days ago \| parent [-]
		I guess it depends what mean by "elegant". For me, an elegant solution makes it obvious that certain classes of bugs will not be present. For example, suppose you have an application that connects to 17 queues and processes a different type of request from each. You could do this in lots of lines as follows: `var processors = new Processor[18]; processors[0] = client.CreateProcessor("FooQueue") { Handler = GetHandler("FooRequest") }; log.Write("Connected to Foo Queue"); ... processors[17] = client.CreateProcessor("BarQueue") { Handler = GetHandler("BarRequest") }; log.Write("Connected to Bar Queue");` Or you could do this: `var queues = new List<string> { "Foo", ... , "Bar" }; var processors = queues.Select(q => client.CreateProcessor(q + "Queue") { Handler = GetHandler(q + "Request") };` The former - despite being "warts and all" - is more prone to bugs getting missed in development and review.