It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 13 years ago.
Please can anyone one point me to a good tutorial that helps me to make my code fast and light.
I'm interested to know which Method is faster and when to use a method instead of other...
And how to evaluate if a code is good or bad?
My programming language is C#.
Hi all,
Thanks for your replies, they are very helpful.
I'm editing my question to be more specific specially that optimization is unlimited.
I want to know what is the best method in each condition.
For example using StringBuilder is better than string if i am appending lines to a string...
I only need this simple things.
Be aware of sub optimization.
Even though one specific function is faster than another replacing this isn't necessarily gonna make any difference in the runtime of your application. You need to understand which parts of your code that actually is a potential problem, and focus on optimizing these parts. Be aware of the O notation of your functions, and how often they are called. To identify parts that needs optimization a profiler can be of good help.
This question has some interesting points on why you shouldn't optimize until there is actually a need to do so.
Sure. Here's what we do:
Begin the journey by deciding when the journey is over. Set meaningful, customer-focussed, realistic performance goals. (For both speed and resource consumption.)
Carefully test your code frequently to see if you are meeting your performance targets.
If you are meeting your performance targets, don't worry about performance. Things are fine. Worry about bugs, or robustness, or features.
If you are not meeting your performance targets, run a profiler. Use it to identify what is the worst offending code. It only makes sense to fix the worst code; making something that is already incredibly fast and light slightly faster and lighter does not solve your performance problem.
Rewrite the slow code so that it's more performant. (This is the hard bit.) Make sure you test it to make sure it really is better.
If despite your best efforts you cannot make it good enough, either re-evaluate what your goals are, or cancel the project and spend your time on something that you can be successful at.
Keep iterating on that until you ship something.
Basically implement first, then test where to optimize.
If you are using Visual Studio Profissional you can use Analyze -> Launch Performance Wizard to analyze method performance. I am not sure about whether the other versions support this feature, however, there are also some commercial/free applications around ... look for profiler (see here for a list).
Type REALLY fast.
You should look at hidden features of c#, this post covers the most best practises in c# development
You can get a ton on advice of on this. But be aware of :
Premature optimization is root of all evil.
Aim first for correctness, next for clarity and only then performance.
As the old saying goes,
"No one cares how quickly you can calculate the wrong answer"
(on a practical level though, use a profiler)
If one method was always faster than another, they wouldn't bother including the slower one.
The only invariant when it comes to performance is that you need to profile. Everything follows from that.
If you get yourself a profiler, it will help you along, some will even give you great tips.
Example: ANTS Profiler
Usually you will find that reducing the number of times you create Strings to be the main performance boost you can get.
That and not messing with the Garbage Collector manually (unless you really really know what you're doing)
This link for Java design patterns is way too involved, don't get too put off by the word Java there, you can use what they teach for development in any language.
The thing is, if you want to know when to do what and what methods to use and so on, design patterns is what you are talking about.
I wish someone had pointed this to me earlier in my career.
In terms of general advice:
Try to use the fewest loops necessary
Move code out of loops where possible
Avoid copying things (like strings) in loops
Avoid creating objects in loops
Cache where warranted (generally small objects that take a lot of time to make), but make sure your cache has a good disposal policy or it turns into a memory leak
You can compile your program in native mode to improve the runtime performance.
One of the ways of figuring this out yourself is having a console app where you try running discrete pieces of code against each other and timing them. Like here.
Related
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I have been advised to refrain usage of Reflection. I really wanted to know, is it because Reflection is expensive? If not what is the reason to avoid using it?
My current and future projects might as well need to access any given class - members information. As I some times need to list fields & Properties - values or declaration name.
So What I would like to know, is:
How does Reflection work? How does it get to the information? (a short explanation will do)
And why it's not so recommended to use the reflection in application? If you do need to get required information being a field or properties values OR names, could you do it not by using System.Reflection?
Some background.
The usage in my current project(for example), is to list out a specific sql server table-columns names, or SQL - tables names .
I could think of other ways to have it returned as a List<strings>.
If I really knew why or how "bad" it is, to use reflection,
..I could then make a decision, if I really want to avoid it, as I might find an alternative approach (in this specific scenario).
Either by accessing database (not preferable) any time I need (say) list of tables names or I could do it once (access the data ), then store it in a text file or xml, if I really must avoid reflection.
I know of some even more elegant one, too. That's not the issue though. (again this is only an example as there could be many other use cases, you probably know that. )
update
this Question was closed please help reopen it , and vote 'reopen' below
thanks .
A CLR assembly (executable or dynamic link library) typically contains metadata about its structure, which means information about the types, the structures, the methods, the fields, their names and a bunch of other information that, in "traditional" languages, were usually lost and replaced by offsets and size information only.
Reflection is a powerful tool and some (usually advanced) things can only be achieved using reflection. However, it also raises concerns about security and encapsulation, because you start relying on the implementations of the parts of your program (or other programs), while you should generally avoid those and just trust the interface those parts give. Another concern is performance, because to access all this kind of (ultimately textual) information, the program is slowed down, in contrast to using the non-reflective approaches (which usually still use offset and size information). For instance, you could re-implement polymorphism using reflection and bypass the virtual method table. But the latter is many times faster than the former.
Use reflection if you have to, but don't use it if you don't have to. It's one of those tools that are very powerful and people advise against using them, but you may use them if you really know what you're doing. That being said, please keep in mind that using reflection techniques in a wrong manner does not only raise the above issues, but tends to make your code significantly harder to maintain as well.
If it were as simple as "never use reflection", we wouldn't have reflection at all.
Reflection is slow, and as such, you have to be judicious in its use. Often times there are better solutions (both in terms of design and performance) that use interfaces, delegates, etc to accomplish your goals (dependency injection and dynamic types come to mind).
Try to figure out how to solve your problem using object oriented design without reflection. If you truly need to use reflection, consider how its performance will impact your application, and design accordingly.
Reflection works by parsing class type information. Use it sparingly as its computationally expensive.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I'm writing trading software and I need every single microsecond in speed.
What can I do? I was thinking to use ngen but wikipedia tells that JIT might be even better. What can I tune? May I force it to use Xeon E5 instructions somehow? Will changing priority in Windows to highest help and if so how to run program always with highest priority? May I add this program to "trusted" so .NET will not check security etc.
I.e. I want complete list of configurations in hardware/software/.net and actions (like running ngen) which can affect and help run program faster.
The time comes stop guessing and find where the problem(s) actually are.
Use EQATEC free preformance analyzer to figure out your bottlenecks and fix them.
NGEN is usefull to boost the startup time of the application , but it's definitely not a golden key for that problem. It's most probabble that you will fix it profiling your app.
What about runtime optimization:
checkout DB accesses (if any), optimize your queries and minimize the data retrived to the amount you really need
look on disk access operations
look on CPU consuption. After profiling yoi can use Process Explorer to check CPU and Memory consuption from your application behavioural point of view
after profiling identify unnecessary or heavy iteration you made (if any), and make use of dictionary (just example) for O(1) access
... and more...
Like a literature for reading on performance can suggest definitely the monster blog of one of the greatest performance specialists in IT industry: Rico Mariani's Performance Tidbits
Hope this helps.
Not windows, pick a more real-time focused OS, as speed has several components, consistent speed or best possible?
Tuning code is nice and all, but don't always go for that. Try code reviews, correcting large logical errors or extra work is much more beneficial than low level tuning.
Understand that every microsecond counts, but your CPU and logic are the fastest part, network, disk, paging, etc are more than likely the real enemies. So make sure you are focusing on the right thing. You must stop all I/O which is not needed.
Certain drivers, network cards, etc are faster than others.
Review your use of libraries and make sure you understand their performance aspects, so much run time is within libraries etc.
Sure there are more .NET centric answers and specific ones, but I tried answering the question behind the question.
Eliminate GC!
Another "trick" that people use is in trading systems is to write C# code that does not garbage collect. Obviously it is impossible to remove garbage collection entirely, but what you can do is minimize or eliminate GC once your program is running. You do all the work to setup your app, initialize your components, etc in an initialization phase and allow any GC here. But once you are setup and ready to run, you make sure that the code does not generate garbage and does not perform boxing/unboxing. (Have a search on SO for like "avoid GC" and you will find some useful information).
The term "trading system" can encompass a myriad of different things. Are you talking about writing an algo in .NET? Or is your algo written in something else and there is .NET framework that is hosting it? Are you just talking about the UI? Is your trading system distrubuted? Do you know how fast you program needs to be? If you are not trading a High Frequency model then what is "fast enough"? Don't just push for something that has to operate in the 1-2ms scale when your trading strategy does not need it.
And importantly, don't throw out the tried and trusted OO principles; SOLID still applies to trading systems although you may bend the rules in certain cases. Just make sure that you identify what needs to be performant and optimize that - don't think that you have to optimize everything and make sure you benchmark and measure everything so that you know what needs to be faster and by how much.
And Keep It Simple! A trading system does not have to be complex.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
I have a first job interview for a software engineer position but in the email they state that I will have to write out a program at the interview stage. Does everyone do this?
What kind of program might it be for a graduate?
The job is for a .NET developer, but I can use any language, so I will stick with C#. I'm actually S**Ting it; I have no clue what they are going to ask me to do.
Many companies will spend much of the interview time asking candidates to write actual code (usually on a whiteboard or piece of paper though sometimes on a real computer) as this is a great way to see if they will be successful in the job. Some things to keep in mind:
Talk out loud. Often interviewers care about your thought process and approach to the problem as much or more than they care about the actual code you write.
Ask questions. Interviewers will often intentionally make a problem ambiguous just to see if you'll notice and seek clarification. Ask things like: "Who is the audience?" "Should I include exception handling?" "Shall I optimize for performance or just make sure it works?"
Don't get flustered if you're struggling. Tell the interview what you're thinking and they'll often point you in the right direction. Partial credit counts.
Get a good night's sleep before your interview. Lots of whiteboard coding and related discussion can be surprisingly grueling.
Good interviewers will be able to extract what you've learned over the course of your lifetime, so don't worry too much about last minute study sessions. It's too late. That said, it's not a bad idea to brush up on basic language syntax and core data structures and algorithms.
Here are some sample problems you may want to practice writing out on paper:
Write a function to calculate the nth number in the Fibonacci sequence.
Write a function to sort 2 arrays of numbers (without using existing libraries).
Design a Deck class and a Card class and write a function to shuffle a deck of cards.
Design a Circle class and write a function to determine if 2 circles intersect.
Design a LinkedList class and write a function to reverse the elements in the list.
At least be able to do this FizzBuzz
By the time the interview is scheduled, there's probably not too much you can do in the order of preparation.
Just remember, they want to know about your problem solving process. Just try to think out loud as much as possible and if you truly don't know something just say so.
No matter what type of question they ask, just go with the flow and do your best on it. The last thing any interviewer wants to see is someone who gets flustered or upset due to a particular question. I'll be the first to admit that some of the questions asked in an interview may be lame and unnecessary, but you are trying to get a job from these people and you will just have to humor them.
When you have more time to study, you should probably start looking at Questions every good .NET developer should be able to answer.
We issue programming tests all the time. There are many reasons for doing this, over and above the obvious one of testing coding ability. We look for
a) Coding style
b) Ability to develop and implement algorithms
c) Ability to follow instructions
d) Ability to communicate what has been done
But by far and away the most valuable thing about a programming test is discussing with the candidate why they did what they did. In this discussion it becomes obvious rather quickly how much the candidate really understood the test and their own design and implementation. It also roots out plagiarism very quickly.
Usually software development jobs give simple tests. I've never once interviewed for a job that required any more than a simple implementation of a function.
Her'es a few simple tests I know of:
FizzBuzz: http://www.geekschool.org/programming/fizzbuzz/
For a job at MS, I was asked to write a function to reverse the words in a string.
At a different job, I was asked to write an implementation of the Join function in c++.
A friend of mine got this one for game development: Write a function to test simple rectangle collision
More than likely it's something simple like FizzBuzz, just meant to weed out the totally unqualified people.
If the company don't ask for you to write code in the interview, that's really, really bad. Go for another company.
The type of test depends. I've done test that i had to write small C code, with pointers or recursive functions.
But generally, they ask for a basic asp.net application (I'm also C# developer), like just one form, inserting and reading from the DB.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I've been programming for a few years in C# and XML. I used only the basics of those languages and have survived on the web for info like arrays and text manipulations. But when I am get interview, the interviewers ask only advanced questions - I found the answers later in the Advanced sections in the books on the subject.
Why do the interviewers ask such advanced questions? The job looks almost the same as what I was previously doing, so there's need for advanced knowledge, like what class delegate is or XPath commands.
Questions are:
What version of XSL does .NET 3.5 uses?
What XPath command to use to get value in element X?
What are class delegates in C#
Does C# allows multiple interface inheritance?
How do you access GAC in C#?
There are two reasons that I ask them.
To see a person actually say "I do not know the answer to that", as opposed to trying to BS through the question.
To see what kind of logical problem solving skills a person has.
Usually a question will be of one or the other, but not both. Both are extremely valuable in screening a perspective employee, however.
Also, the question might not actually be "advanced" for the position. It is reasonable to assume that Senior-level and/or Architects can answer questions that a Junior to Mid-level might not.
Perhaps because they are trying to find programmers who know more than the basic stuff. If they are trying to distinguish between a field of candidates, it isn't helpful to ask questions that everyone knows the answer to - how do you select among those candidates? If you're going to hire only 1 or 2 out of a pool of candidates, you need to find some harder questions that only 1 or 2 out the pool can answer.
Getting the answer wrong is what I want from an applicant in some cases.
One of the reasons I like to ask a question that I think the applicant will get wrong is to see how they adjust to the situation. How they handle getting something wrong and handle someone telling them how they should have answered etc. If they are very defensive or rude when you tell them they are incorrect then it is a good indication of how they will work on a team when many times your ideas will be challenged.
If they take the solution or recommendation and realize they can learn from it or even add to it that is usually a sign of someone what is easy to work with and willing to work 'outside of their box'. If they just make excuses and dance around trying to say why they could be right or should be right (in cases where they are clearly not) then this tell me when the same issue arises in the future this applicant is going to cause headaches.
Not so worried about the answer, more interested in how they react to the question / solution.
Another reason would be to gauge their level when hiring as well. You might be hiring for a bunch of positions but not sure where this applicant fits. Hard questions that show problem solving and attention to detail can sometimes make it easier to categorize their skill set.
I ask advanced questions for a few reasons:
Some of my questions are advanced usage of things everyone should know (not a trivia question) -- I want to see you reason through the answer using knowledge you have, but in a way that isn't common.
I want to see what happens when you don't know something -- do you give up?
I want to hire people that are serious about what they do. People that really care about the technologies they use tend to want to know the advanced stuff.
I want to see if there are gaps where you just don't know that an entire area of knowledge even exists. For example, in your XPath example -- I might be ok with: "I believe that XPath could be used to help solve this, but I don't know it well enough to write it out here" -- then I would show them a little XPath and see if they could apply it. If you don't even know that XPath exists, google isn't going to help you.
Likely they're just getting a gauge of where you are. They probably got stuck on this problem themselves and perhaps wanted to see if you could think of an answer on your feet.
I've experienced the same types of questions, and considering when I program I use excessive resources, this type of thing usually throws me off. Their loss.
Because competency as a programmer involves both depth and breadth of knowledge.
The interviewer is trying to devine your level of knowledge, and he is copping out by "borrowing" a question from the last chapter of that book.
Really, this is sloppy work on his part, relying on one question to guage your expertise level. You may have low programming skills, but recently come across the buzz-word, and are able to ace the interview.
I did get burned once in interviewing a candidate who professed high levels of C expertise. It turned out that he was reading "C for Dummies" and managed to BS through the interview process. I admit that I wasn't concentrating on his programming skills, but was looking for other aspects, which he also managed to BS through. Turns out his whole resume was a pack of lies.
Nowadays, I make sure the candidate has working knowlege of variable scope, persistance, pointer arithmetic, basic algorithms, structured programming, object-oriented programming, polymorphism, multitasking and inter-process communication. I will quiz him on his debugging skills, and zero in on details such as race-conditions, heisenbugs and security vulnerabilities.
Depending on the job, I will ask about experience in the target language - such as key=>value maps (arrays) in PHP, Swing programming in Java, event handling in C#, tables vs CSS in html -- you get the picture.
If the candidate passes the first part of the interview (I usually know within about 5 minutes), I will then give him a binder and send him into the coffee room (nice couch and table there) to prepare for 20 minutes for a code review on a selected module.
That's when I send in the troops - employees are instructed to use the coffee room normally, introduce themselves and make conversation for about a minute.
What I'm looking for is the ability to concentrate on a task (blatant ADHD), the ability to work under pressure, and interpersonal dynamics.
When the candidate returns, I have him act as main presenter and start our normal code review process. The first thing I look for is if he read the page titled "Code Review Process". I'm not looking for him to complete the review - about 10 minutes is enough. As a matter of fact, the fewer main lines processed, the better - within reason.
I haven't been burned by a new hire for a long time now.
Your username suggests you like coding (duh), but your question suggests you don't. If you really liked coding, then you should love to learn about it. Those questions that you listed are not that advanced.
Even if those questions were advanced, the interviewer is trying to gauge how much knowledge you have in the area that you say you have knowledge in. They are also trying to gauge how well you would fit into their group.
P.S. Not to be mean, but if you program using XML and don't know what XPath is, then you are a little far behind.
They probably want to see if you really know what you're talking about or if you're a novice programmer who gets along on the web using only what he has picked up through trial and error...
1.What version of XSL does .NET 3.5 uses?
Because they can't tell important things from non-important ones. Bad sign.
2.What XPath command to use to get value in element X?
Because they want to see if you know XPath. This can be either because they use it extensively and you need it to get they job done or because they think XPath knowledge == skill.
3.What are class delegates in C#
(I've never heard the term "class delegate" and a google search shows no definition, so I assume you mean just "delegate").
Delegates can hardly be considered an advanced topic.
4.Does C# allows multiple interface inheritance?
If they really asked about "interface implementation", it's part of the most basic concept so it's a valid question (although too simple to really mean anything). If they really asked about "interface inheritance", it's more of trivia, but I would still say acceptable. Bonus point for them if they asked what "interface inheritance" really means.
5.How do you access GAC in C#?
This is the kind of thing every team MUST have one person who knows. I'd say it's also a indication of seniority (which BTW, I don't care much about) since nobody reads about these things, the only way to find out is to be forced to solve a real-world problem.
I ask advanced questions to try see how people work through the problem. I like to ask questions that I don't know off the top of my head for that reason.
I want someone who is a critical thinker rather than just an academic who can recite text books to me.
They want to find someone with practical experience that extends beyond what is taught in beginner courses. When my company interviews candidates, we often find that most of the applicants cannot solve what we would consider to be very basic programming problems simply because they don't know the API or don't understand when to use various basic data structures.
If you want to impress an interviewer, work on your own programming projects outside of class. Learn a good chunk of the language API, and start learning about third-party libraries that can greatly simplify your work.
Another reason is to gauge your response to a question they really don't expect you to know the answer to. Problem solving skills are essential, so asking you questions you already know the answer to is not going to address that, is it?
There are even instances of companies asking odd, non-programming related questions just to see how you think your way through a problem. There is the classic "Why are manhole covers round" question, reportedly asked at Microsoft interviews.
More Microsoft interview questions
I'm not meaning to offend you but maybe your understanding of the job is not deep enough and it in fact requires knowledge of advanced techniques.
Also, you can do a lot of things with basic methods but advanced methods might the better way to implement regarding complexity, time to implement or maintainability.
There are many possible reasons. They may:
actually use those techniques (delegates and XPath aren't particularly rare or obscure)
have a large pool of candidates and want to try to find the more knowlegable ones
want to see where the limits of your knowlege are, so they ask question up to the point where you start to be unable to answer well
want to see how you might approach areas that are unfamiliar to you - to see how you might adapt to new stuff
want to show off their own knowlege (probably not a legitimate reason, but it certainly happens)
I've heard these really aren't in use anymore, or at least not nearly as much as they used to be, but you might be interested in this. I picked up a pretty cool short book a few days ago that has to deal with the "Microsoft style" logic interview questions that are sometimes asked. I'm a few chapters in and it gives a neat little history of the tech field's interview style and has a ton of logic problems, complete with answers in the back.
It's called "How Would You Move Mount Fuji" and it's on amazon for pretty cheap.
http://www.amazon.com/gp/offer-listing/0316919160/ref=dp_olp_used?ie=UTF8&condition=used
I've just completed a round of interviews, where I use a three or four stock 'simple' C# code fragments that the interviewee will look through and attempt to explain what the expected result will be. In each case the code sample is no more than ten lines of clearly-formatted code that utilises basic C# skills (inheritance, generics, anonymous delegates); also in each case there will be a 'gotcha' - but like others have stated, I don't put these in to be spiteful, they're there because I want to see how the candidate reacts when confronted with something that doesn't work as expected.
We had a candidate recently that had sailed through the first part of his interview; impressive CV, was apparently the Lead Developer of a team of 10 and had been developing code in C# since 1.0; yet apparently had no idea what "Console.WriteLine()" did (nor could he even hazard a guess), nor could he even begin to cope with the tiny anonymous delegate example.
Another candidate was self-effacing, and didn't know how to grade herself as a developer - she'd had less experience than the former candidate yet she sailed through the code samples, fell for a couple of the 'gotchas' but asked the right questions to get the correct conclusions and genuinely learnt from the experience. Needless to say, she was hired.
If you're claiming domain-specific knowledge (like XML) you should expect to be asked specific (and sometimes hard) questions about that domain; if I'm interviewing a senior ASP.NET developer and they've got no idea about HttpModules or HttpHandlers (like some recent interviewees) then alarm bells start to ring.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I use LINQ in my code all the time. I've gotten to the point where it just seems so natural to Group, Order, an organize a bunch of objects using the LINQ syntax that I struggle to think how I would do the same things without it.
I had never delved into the SQL-esque world before this, but I imagine many people who learned even the normal SQL syntax suddenly felt constricted by most normal programming languages abilities to wrangle complex object hierarchies?
Am I painting myself into a corner becoming reliant on LINQ to do my more complex tasks? It just feels so much more expressive than if I wrote plain C# code.
Is becoming dependent on the LINQ syntax in my day-to-day programming going to hurt me in the long run if I end up switching languages or frameworks where something like it isn't available?
Fortunately, no. The "LINQ" way of thinking is more properly understood as a "functional" way of thinking, and this is a highly transferable mindset.
Obviously when you move from language to language and framework to framework the syntax and framework methods will be different but the mindset is the same. The important skill that you have aquired is the ability to think in terms of sequences and functional pipelines that process those sequences.
Instead of looking at your prospective future outside of C#, I would concentrate on what helps you get your work done today.
If that means using and becoming fluent with LINQ, so be it. As long as you're willing to learn and adapt in the future (just like today) it won't be that big of an issue.
Yes, your concern is valid.
That is, when you get good at using any tool, you start to forget how to function well without the tool. You also get frustrated when that tool is not available.
For millions of years humans were able to feed themselves without the use of metal tools. They weren't miserable. Today very few know how to do that, and most are scared of what that would be like.
For tens of years humans wrote software without real-time interaction with a computer, e.g. punch cards. They weren't miserable. Today very few know how to do that. The idea of doing that sounds miserable to me.
If you become adept with Linq, you will miss it when it's not around. It's a great tool. As your skill with Linq grows, your skill of programming without Linq (which you aren't practicing) will become rusty.
In all the above cases, we have replaced a human skill with a tool + a new human skill. Each time, the idea of giving up the tool sounds scary. I believe there's always some value in exploring the older, lower-tech way of doing things, as it helps me become more well-rounded, but usually I'll pick the higher-tech way.
So, don't shy away from Linq, but do explore other ways of doing things, as part of your self-education as a programmer.
Does it matter? Every language has its unique nice features. It's like saying "Will using braces in C# make it hard to transfer it to another non curly brace language?"
Its not going to hurt you. I truly believe all modern languages are going to move to this syntax very shortly. Java is already moving in that direction, and other languages will follow with something similar. MS, for all of the bashing they take, were way ahead of the curve on this one. The wiped out a whole class of bugs related to temporary variables/arrays in terms of querying array objects. The benefits to this are enormous.
LINQ is a great thing. It will spread. In fact, the spread has already begun.
If it could be equated to learning OO, I know people who have gone from C to an OO language and back to C and although they didn't have objects available, they tended to be able to use many techniques in a language without objects.
Could the same thing happen with LINQ?
Yes, it will hurt you if LINQ to SQL is the only sql you know.
I find that understanding the logic behind it helps me feel better about using LINQ extension methods. If you can write your own Where or Group ..etc extension methods then there is no shame in using them.
I think it's important to understand what's going on behind the scenes of high-level abstractions like LINQ - otherwise you can have problems such as performance. Funnily enough our host's latest blog post is on this subject.
So if "thinking in LINQ" means forgetting this, which I suspect it does for some developers (present company excepted), it could be considered "bad".