|
parse tables are especially lovely.
How often do you get to declare nasty things like this?
IDictionary<int, IDictionary<int, KeyValuePair<int, int>>>
or
Tuple<TAccept, Tuple<KeyValuePair<char, char>[], int>[]>[]
I have a headache in my eye.
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.
|
|
|
|
|
It's containers, all the way down!! 
|
|
|
|
|
The issue is dependencies. These are opaque structures used to hold parse tables and FA state tables. They're static initialized and not mutable, and basically opaque to the end developer.
I thought about creating types to better encapsulate this data in a more friendly manner, but that just means extra type declarations in the end developer's code for something they will never use directly.
So meh. It's whatever. But creating them is a PITA
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.
|
|
|
|
|
codewitch honey crisis wrote: but that just means extra type declarations in the end developer's code for something they will never use directly
That makes sense. It's always an issue of trade-offs with this kind of stuff.
|
|
|
|
|
codewitch honey crisis wrote: but that just means extra type declarations
If the "extra" types make the code more readable, they go from being "extra" to "recommended". 
/ravi
|
|
|
|
|
since the code is never touched by humans, and only generated by tools, it doesn't need to be readable. it doesn't even step through in the debugger (DebuggerHidden)
adding, putting in a bunch of extra code they have to include and understand into their projects makes adoption *more* not less difficult
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.
|
|
|
|
|
|
haha looks like fun
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.
|
|
|
|
|
Don't use a tuple like that!
(TAccept meaningfulNameInsteadOfItem1, (KeyValuePair<char, char>[] keys, int something)[])[] So much more readable... Ok, I guess just don't do this 
In such scenario's I usually create a class, which may inherit from Dictionary<...>, for readability.
Or I do something like:
var lookup = originalCollection.ToLookup(i => i.Key, v => v.ToLookup(...)); So that I never have to specify the type 
|
|
|
|
|
I haven't used that syntax before. I know it's available but i just haven't touched it.
I'm relatively new to the more modern iterations of C#.
Luckily this type is used to store machine generated tables and isn't touched by the end-developer at all. That profoundly limits the impact of using non-descriptive names
That being said I updated my code according to your suggestion. Thanks!
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.
modified 3-May-19 5:34am.
|
|
|
|
|
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've been using LINQ for years though (and even rewrote it in JavaScript[^]).
It's been making life so much easier
|
|
|
|
|
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 
|
|
|
|
|
small perf hit *per subquery*. not a small perf hit. not for complex queries.
I've perfed LINQ.
No.
Just, no.
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.
|
|
|
|
|
adding, I'm glad there are some optimizations. that still doesn't make it appropriate to use in parsing code
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.
|
|
|
|
|
codewitch honey crisis wrote: 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
|
|
|
|
|
I don't care about performance in business applications.
If I'm talking about performance I'm not talking about business applications.
For business applications, performance is a last priority. Including for business.
LINQ is about developer productivity. It's a business dev tool, primarily.
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.
|
|
|
|
|
codewitch honey crisis wrote: How often do you get to declare nasty things like this?
Often enough. It can be quite fun. You can use the using statement to declare a name for a more complex type, example:
using ThreadPool =
System.Collections.Concurrent.ConcurrentBag<System.Tuple<System.Threading.Semaphore,
System.Collections.Concurrent.ConcurrentQueue<System.Action>, System.Action<System.Exception>>>;
but it's cumbersome, and this is where F# really shines[^]
Example from my article I linked above:
type Work = unit -> unit
type ThreadExceptionHandler = Exception -> unit
type ThreadGate = Semaphore
type ThreadQueue = ConcurrentQueue<Work>
type AThread = ThreadGate * ThreadQueue * ThreadExceptionHandler
type ThreadPool = ConcurrentBag<AThread>
Latest Article - A 4-Stack rPI Cluster with WiFi-Ethernet Bridging
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
yeah i really wish there were something in C# as flexible as typedef in C++. Using has too many limitations when it comes to declaring templates (for example no templated usings)
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.
|
|
|
|
|
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.
Guitar Zero: The Science of Becoming Musical at Any Age - Kindle edition by Gary Marcus. (amazon)[^]
|
|
|
|
|
What I find funny is all of my friends who actually play the guitar and have tried the game say they are horrible at Guitar Hero. I don't bother with the game - I prefer the real thing.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
Rick York wrote: 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.
|
|
|
|
|
Rhythm is an issue for many musicians people who play music.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
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.
|
|
|
|
|
Playing the guitar like playing Guitar Hero is simply a motor skill. Anyone can do it with practice. It takes more practice to play Through the fire and flames than it does to play Slow ride.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
)
