It's expensive to keep binary groups online (bandwidth) and the text groups are all SPAM these days.
Edit: Forgot to say that the tech is fine; a member of my family operates a usenet server over in Switzerland for our family. Works well for that sort of thing and avoids facebook etc.
Not a great fan of LINQ if I'm honest. Sure it's terse and powerful but with it comes great responsibility and a relatively large pile of tasty landmines. Three regular problems I see:
FirstOrDefault being passed 2 rows = non-determinism. This one is always fun when your SQL server doesn't guarantee the order of rows returned so every time you hit .FirstOrDefault you get a different item. Never happens in dev due to the tiny datasets fitting in a single page.
There's also Single being passed 2 rows = crash. SingleOrDefault being passed >1 rows = crash.
And when it does crash it's entirely not helpful because the lambda block reports no state information in the stack. Inevitably this leads to adding precondition checks to avoid "Hey everyone, one of the 20 LINQ expressions in this method blew with more than one element in the sequence".
Then there's the fact that you don't know the size of the set of data nor really think about it. So if someone passes in a collection of 10 rows in dev and it works out that it's O(N^2) and has a random .ToList() in it then you're up shit creek in the memory and time departments when that 10000 items collection appears in production.
None of this unique to LINQ but it hides a lot of problems behind a wall of pain.
With all respect, it doesn't sound like you've taken the time to understand LINQ:
- Single and SingleOrDefault crashing with >1 row is a feature, not a bug. It means that your expectation that your filter is unique was incorrect. In that scenario, a crash is what you want. It's like when we use asserts. Similarly ..
- First and FirstOrDefault are only really appropriate after an OrderBy, i.e. to get the top item of a particular ranking. Using them anywhere else is almost always incorrect, and in the very few cases where it isn't, needs a comment to explain why, or I'll bounce your code back to you in review :).
LINQ is very expressive (you can do a lot with a little bit of code), especially with the embedded (non-fluent) syntax. That means that, yes, you can write some non-optimal code without realizing it, because it's only a few lines. On the flip side, you can also refactor that code quickly into more optimal patterns. By comparison, old-school iterating through collections is often much more difficult to refactor.
I understand LINQ very well (right down to code generation and expression trees) but unfortunately I work with a lot of other people's code.
Perhaps that is the problem? :-)
More seriously, the thing has really leaky abstraction boundaries which is a main pain point. I have to write and manage a lot of boring enterprise code and creativity and expressiveness go a long way to introducing a lot of additional work.
LINQ is not where the leaky abstraction is, IEnumerable is. IEnumerable makes virtually no guarantees about anything, including order, finiteness, side effects and speed/efficiency.
This is actually one of the main reasons that the BCL team introduced the IReadOnlyXXX<> interfaces - over the years, many .NET developers trying to do the right thing and express intent in their code had taken to using IEnumerable<> in method signatures to signify that the method would not modify the list/collection... but an IEnumerable doesn't have to be a list/collection, it can be infinite! In trying to do the right thing and be expressive with intent, lots and lots of people were unwittingly losing the expression of another (very important) assumption.
Any time you are wrangling any kind of enumerable in code, you have to think about its guarantees and assumptions. LINQ's expressiveness might make it easier to forget this but it's still the rule - if I hand you a "malicious IEnumerable", it doesn't matter if you use LINQ or a couple of foreach loops, it's going to launch the missiles on every call to MoveNext() regardless.
If you are trying to express intent in your code, IEnumerable is almost never what you want to use.
How should First work? How is this different than manually doing "SELECT TOP 1" or using LIMIT, but not specifying an ORDER BY? What a strange complaint.
And Single is supposed to crash if there's more than one row. Again, it's directly like selecting "TOP 2" then doing a check to make sure there isn't a second row. Your complaint seems like complaining that using a "while" conditional instead of an "if" can lead to trouble.
Seriously I'd love to know what code you are writing where you weren't sure if you wanted First or Single, decided Single (thus enforcing that data integrity rule), then decided it's the library's fault for doing exactly what you asked.
> FirstOrDefault being passed 2 rows = non-determinism... There's also Single being passed 2 rows = crash. SingleOrDefault being passed >1 rows = crash.
Which is the point of the different API's, you get to pick the behavior you want. Don't want it to crash? pick `FirstOrDefault`. A formal API is better than manually codifying the elected behavior each time, making it tedious to infer the intent each time whilst being susceptible to human errors manually copy+pasting imperative code.
The problem is that it's a complex trade off whichever way you turn. Knowing which trade off to make is difficult for many people as it requires knowing all of the assumptions and conditions that are before and after the call as well as how the expression will react under all conditions. Add complex predicates to that,which the language encourages and it's pain.
Except your example isn't a complex trade off -- it's just how it works. FirstOrDefault() returns the first or a default. It's right in the name? Which is first? Well you better provide an order if you care. If you don't care, don't provide an order. There is nothing complex about that at all.
It almost seems like your looking to blame Linq for what is clearly poor database and project design. If you have poor design you're going to have problems no matter what.
Objects.Where(el => el.Id == myRequestedId).FirstOrDefault().Name; //Crashes when there is no result, but this has been handled by the null operator in c# 5.0 => Objects.Where(el => el.Id == myRequestedId).FirstOrDefault()?.Name; The issues was not Linq, it is/was c#
Single() is when there is absolute only 1 result. > 1 result is not expected ( i'll admit that i never use Single or SingleOrDefault() )
And using paging is the same thing in linq as it is in SQL. If you don't know how Linq works, you should learn it. What you should know is that .ToList() hits the database, so when you query all the objects, you get all the objects. Limit your query before the database query :)
Here are the results of page 4 with 10 items : Objects.Skip(10 x 3).Take(10).ToList(); //fetches 10 items = paging in the query
Here is how someone could write it without knowing Linq: Objects.ToList().Skip(10 x 3).Take(10);//fetches all the items and does the paging on the list.
As long as your DataType is an IQueryable<T>, it doesn't hits the database. When it's a List<T> (eg. when calling .ToList()) it's too late
But both you and I know that is bad design. The operator is a shortcut for simple scenarios, but in this case if a decision has to be made then you should be handling the null checks yourself and making those decisions explicitly.
A line like that is just lazy. I'm more keen to blame the developer and not the language. Striking nails with your fists as they say.
>There's also Single being passed 2 rows = crash. SingleOrDefault being passed >1 rows = crash.
It's not a crash, it's an exception. You can catch an exception. But, as others have said, you could instead call the function that doesn't throw an exception if having more than one result isn't an error.
> None of this unique to LINQ but it hides a lot of problems behind a wall of pain.
There is your problem and it isn't LINQ. You'd have the same problem with C# without it. LINQ is a good declarative tool when declarative programming makes sense : data pipelines. And LINQ is 'lazy'...
You should be glad that an imperative language succeeded in getting declarative features. And that makes C# better than the competition in the same space, even though I never use MS techs.
Man I wish Android had LINQ, and the Java language support it relies on in C#. This is at or very near the top of the list of Things That Would Have Made Android Better especially since non-game Android coding is so database-centric.
True, but it means taking the rest of Xamarin, too. While Xamarin is brilliant, and by far the best cross-platform SDK I've seen for any set of targets, it's still riskier than native platform development for most developers. I'd use it for a client who has a C#-oriented in-house team and the ability and resources to commit to overcoming the vicissitudes of cross-platform development, but I wouldn't just to get LINQ.
Hah. I actually am very happy with my music solution (for now). I buy CDs and rip them with iTunes to MP3 on my media PC to a network drive, and then manually sync my phone. I can play it on anything by opening a folder.
The UI is essentially put in CD, wait, have music, and sync phones occasionally.
What is your current setup that you're happy with?
My entire outlay is now a single laptop running CentOS 7, a desktop as a backup machine if I kill the laptop, some earphones, a dumbphone and a USB stick and USB mp3 player in the car. I rsync the USB stick for the car periodically and that is it.
As for everything else, browser is Firefox still (ick) and the only services I use are an IMAP box and domain.
I gave up music on my phone, contact sync, email on my phone, navigation, everything. A simpler life seems to be better for me.
Also the advice about marketing yourself is crap. Recruiters are the #1 way of landing contracts. They're finders and you're paying a finders fee for that service. They have the big guys with oodles of cash to get hold of.
If you can't get a gig through a recruiter then you either don't have skills that are in demand or don't come across as someone who they'd want to sell.
If you don't go through the recruiters, you end up being left with the cheap arse companies that won't pay up anyway. If you're sneaky about it, you and the recruiter can get the client to pay the finder's fee.
Once you're in the system, build up a network of contacts and then move through that rather than using the recruiters. I'm doing that at the moment and ended up taking a perm position that was better paid than the contract rates were (without all the hassle of IR35, rolling a Ltd etc)
> If you don't go through the recruiters, you end up being left with the cheap arse companies that won't pay up anyway.
I've never used a recruiter, the companies I work for paid pretty good and I had one unpaid bill in a couple of decades.
Building your own network and getting rid of recruiters as your main source of income is very important to new contract programmers.
For one they take a cut and for another they will sell those parties where they can take the largest cut first.
I'm not saying they don't have a function but recruiters goals and the recruited goals are not 100% aligned and you should be very much aware of that when using one.
One way to side-step recruiters is to build up (large) number of contacts with people in the industry who may get to know someone that needs your particular skillset.
The more peculiar your skills the harder it will be for recruiters to place you and so more of the acquisition part will have to be done by yourself.
Think of using recruiters as 'outsourcing acquisition', it has all the upsides and the downsides associated with all other forms of outsourcing.
Another danger with outsourcing your acquisition to recruiters is that you are handing the keys to one of the most important parts of your business to another party, who can then either cut you off at will, replace you and retain their contact with the company you were placed in and so on.
The sales department (which you've essentially outsourced) is a very important (if not the most important) element in any company, even a small one.
You may be able to make your life a little easier by not doing that work, especially if you're an introvert but in the longer term you're setting yourself up in a very dangerous position.
So, use recruiters if you have to but be wary and make sure you have alternative channels to being hired under your own control. Never let a single recruiter get you all of your jobs or even a majority of your jobs.
I did find that you can play recruiters off against each other quite easily to negotiate a higher rate. Also when you sign, you sign with the company not the recruiter and have a solid contract in place. Never work for sharecropper recruiters like some of the bigger ones.
If they want to get rid of you after 2 weeks, make sure there's an exit fee. That is usually 100% for me if under 6 months of contract left. I did 2 weeks at a company on a 3 monther at £550 a day and completed the work but was paid for the 3 months.
The particular sector I worked in was finance and that is still heavily recruiter driven unfortunately.
This echoes my thoughts and experience, all the while I was contracting I could easily find new work through word of mouth. The few recruiters I talked to seemed happy to waste my time (and their own).
In practice, it's they who find you. Just change the address on your linked in profile to "London" and see the emails coming in. If they don't come, your CV is probably not a good fit to the current needs of available contracts (due not enough experience in technologies that are currently hot).
Look for smaller companies and individual recruiters first. If they get you an interview in under 48 hours for a non shonky outfit and are willing to discuss your terms rather than enforcing theirs then you're probably ok. The big ones are shit. Requires phoning around for a couple of days.
Actually in the UK it is covered by the Data Protection Act. Interesting times ahead. If you knowingly or unknowningly give personal information away without my consent this is illegal.
I would challenge you to show something conclusive that states that I am forbidden by law from stating "I know this person. His name is batou." while pointing at you.
So if someone were to ask your computer "Do you know any trade unionists?" and it were to reply "I know this person. His name is batou.", and you weren't covered by the Schedule 3 exceptions, that would be an offence. This is an attempt at preventing employment blacklists.
And yet your original post was in response to this:
"If you tell me your name, I'm free to repeat that to whoever I want. If you aren't ok with public information being re-broadcasted, don't go outside."
to which you said:
"Actually in the UK it is covered by the Data Protection Act. Interesting times ahead. If you knowingly or unknowningly give personal information away without my consent this is illegal."
What you're saying now and what you said then are two different contexts.
He wasn't broadcasting his name in the first place; only you had the information (in the limited knowledge of the context). In case you are using this for anything damaging to him or for profit, that is what the Data Protection Act covers. That suddenly his name becomes public knowledge has little to do with this law.
Edit: Forgot to say that the tech is fine; a member of my family operates a usenet server over in Switzerland for our family. Works well for that sort of thing and avoids facebook etc.