The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
I was moving a bit of code just yesterday and I had a class with two properties to return a result from a function.
That was the only place where the class was used and other than that it didn't add anything of value.
Of course, back in the day you could use an out parameter if you had more than one return value, but that is now frowned upon.
So then I remembered C# has introduced named tuple values and I rejoiced.
Never again will I use these multiple-return-values-from-function-classes anymore
Had you posted this the day before yesterday I wouldn't have known either
I don't use Linq because of perf issues with enumerators and esp. iterator functions**, but then I'm not writing business code.
I'm writing things like parsers and code generators and compiler toolkit stuff.
** they aren't bad in moderation, but they cause a lot of object creation that isn't strictly "necessary" if you use other methods to enumerate. Linq relies on this stuff super heavily and so there's a performance penalty for that - the worst maybe being the added memory pressure.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
LINQ has a small performance hit, if only because you do multiple method calls and it creates some extra objects.
The iterations aren't so bad if you do it right though.
For example, collection.Where(...).Select(...).ToList() only does one iteration, and not the three you'd expect.
The ToList() causes the iteration, which iterates through the SelectIterator, which uses the WhereIterator, so each item just goes through a chain of iterators just once
that still doesn't make it appropriate to use in parsing code
Yeah, I never said nor believed that
In terms of business applications the performance hit is small (unless you're doing LINQ to SQL/Entities/other data sources, in which case the performance hit can be huge if the query isn't build properly).
I'm just saying the amount of iterations probably isn't the problem.
I've met people who believed every LINQ method was a separate iteration, but that certainly isn't the case
type Work = unit -> unit
type ThreadExceptionHandler = Exception -> unit
type ThreadGate = Semaphore
type ThreadQueue = ConcurrentQueue<Work>
type AThread = ThreadGate * ThreadQueue * ThreadExceptionHandler
type ThreadPool = ConcurrentBag<AThread>
I'm reading a lighter book right now and it is fantastic. It hits on a lot of things I'm interested in.
The Setup 40-something psychologist / university prof with no musical skills but a lot of desire plays Guitar Hero and becomes mediocre at it. He then wonders, "hey, could I learn to play the guitar? Could I learn to play it well?" The journey ensues.
If you're interested in how we learn in general, music, music theory and practice and/or guitars you will like this book.
all of my friends who actually play the guitar and have tried the game say they are horrible at Guitar Hero.
I know. Same thing here. Been playing Guitar for a long time but terrible at Guitar Hero.
The author's experience is a bit different because he started with Guitar Hero and went to the Guitar. Basically leveraging only the rhythm / syncopation of press buttons on Guitar Hero.
I play bass, upright and electric, and tried GH at a friend's house. Bass instruments are usually slower to speak, so you have to start the note a little early if you want the sound to start on time. The program complained about every note until I tried deliberately playing each note late.
I do think we all have musical ability, to greater and lesser degrees, and anyone can learn an instrument.
I agree. That's why I'm finding the author's study of the subject so fascinating since he started so late in life (and many people believe that is a problem, while brain plasticity suggests otherwise.)