I actually really believe that half of the reason Java for desktop apps has such a bad name (in particular when the apps are 'slow' and 'unresponsive') is just because they are poorly coded.

The other half is probably because Sun royally screwed the pooch with Java GUI frameworks (EJB as well, but that's another story...)

First there was AWT, then they realised it wasn't up to snuff so then Swing comes along. Meanwhile IBM develops SWT to improve on the deficiencies of both AWT and Swing, so now you've got 3 GUI toolkits over time leading to fractures in the developer community.

even in the case where threads have been implemented in the intended "windows way", you still get the same kind of lagged UI
ie the mouse still works and you can navigate the menus etc, but clicking a button does nothing until the previous I/O intensive child has finished

^
That sounds like a specific implementation rather than a Windows thing that affects everything. If you have a technical article / white paper that describes what you are talking about I'm definitely keen to be proved wrong - being wrong is more important than being right in a field you are trying to be awesome in!

Dazhel: and yet MS currently supports Win Forms, WPF, Silverlight, MFC and the win32 API?

I'm not a fan of static linking. Disk space may be cheap but apps are commonly distributed via the web the days, and bandwidth is certainly not cheap. A trim installer & update mechanism is well-received, a massive bloated package is not.

Except by Match Fixer's mum. She loves it.

last edited by Hogfather at 21:30:36 07/Feb/10

and yet MS currently supports Win Forms, WPF, Silverlight, MFC and the win32 API?

WinForms and MFC are just layers on top of the Win32 API for C#/VB.Net and C++ programmers respectively. WPF and Silverlight are almost the same thing, and the latter is a web technology not desktop GUI technology.

Not quite sure what you're saying mate - my point was that this 'fracturing' hasn't hurt MS devs at all.

They are very different technologies to work with despite where they sit in terms of layering - all those Java UI APIs just sit on top of Java, right? :)

take your pick of:

- unresponsive apps
- buggy apps
- really expensive, responsive apps

Multithreading an app needs to be kept simple, otherwise you will spend a fairly large amount of time managing the threads and managing the data they access.

Most windows app I write, if they have a multi-threaded component it normally involves keeping that part extremely simple, ie not sharing any information with the main thread to avoid concurrency issues. The only data that's shared with the second thread is the call parameters and whatever is returned.

In more complicated applications where I need a lot of threads doing a similar task I will use a thread pool and just write each individual task to be autonomous, again to avoid concurrency issues.

Doing this properly will result in a fully responsive UI.

But even with those precautions I can sometimes become unstuck :(

.NET 4.0 will be introducing a new library for managing parallel work called the Task Parallel Library. It's introducing a bunch of great stuff for helping with multithreaded apps.

last edited by Thundercracker at 11:00:53 08/Feb/10

Not quite sure what you're saying mate - my point was that this 'fracturing' hasn't hurt MS devs at all.

My point was that when you pick your language on Windows the GUI API that come with that choice has been supported and built upon since release.
C - Win32 API
C++ - MFC
C#/VB.Net - WinForms for raster graphics; or WPF if you prefer vector graphics (is there an equivalent to WPF for Java yet?)
HTML/JS - Silverlight

If you pick the Java language, you've had to deal with Sun's flip flopping over GUI toolkits over the years. AWT was horribly underpowered for serious use, Swing was good but lacking in some areas which prompted IBM to develop a competing toolkit from scratch.

I wasn't disagreeing with you when I mentioned MFC et al.

The reason that I brought it up was to illustrate that its possible for a platform to run multiple well-supported development environments. The problem with Java isn't that Sun and co had a few concurrent implementations of a UI framework; they just cocked it up and they weren't well-supported.

Also:

C#/VB.Net - WinForms for raster graphics; or WPF if you prefer vector graphics (is there an equivalent to WPF for Java yet?)

I prefer WPF over Win Forms more for the markup-driven design surface and excellent data binding than the vector graphics, we still user raster icons etc.

last edited by Hogfather at 12:39:23 08/Feb/10

Personally I think the WPF renderer is awful. The controls look horrid, the fonts render awfully. It's all well and good to try and change to a resolution independent GUI, but frankly I don't believe the average monitor DPI is good enough to replace finely tuned, more "artistic" bitmaps.

last edited by 3dee at 13:05:56 08/Feb/10

You can easily force bitmaps to be pixel perfect in WPF

I much prefer the appearance of WPF apps.

But we don't use the stock controls, and about an hour into the first test app worked out how to make bitmaps pixel-perfect.

I think JavaFX is the closest thing to WPF. It's not the full answer but you can get the same results with JavaFX, Swing and Java2D. It's not as unified and packaged approach to the same problem obviously.

haha faceman

(Y)

IBM have done great things with SWT, but it's still not native, and it's utterly horrible to work with.

Layout managers in Jzva have always been horrible, as has the flattening if controls and lack
of ability for them to look native in windows.

Also, 'DLL-Hell' is bulls***. It's just that developers are too lazy to make their software support previous versions - not really a hard task, it just takes effort. And nobody likes effort.

lol @ this arm-chair-programming comment.

Because it's SO feasible and elegant to have 500 switch/if statements to handle all the API changes and discrepancies for every DLL you use and all the previous versions of each DLL ever created.

Personally I think the WPF renderer is awful. The controls look horrid, the fonts render awfully.

If you think it's bad in WPF, Silverlight is worse. Adobe has no problems with font rendering in Flash, but Microsoft is still trying to figure it out.

Font rendering problems were reported in the first release of Silverlight and Microsoft promise it'll be better in the Silverlight v4.

No, really.

Seriously, this time for sure.

<wild-assumption>I like how Microsoft had alreayd had Silverlight twenty billion out before most of the world had even heard of the word, letalone realised what it actually was. I'm sure 98% of web developer have probably not even bothered touching it. Silverlight = Another Flash. </wild-assumption>

last edited by 3dee at 20:27:38 08/Feb/10

in todays day and age

um.. yeah, todays games are much simpler than frogger.

lols, all you silly windows programmers

oh s***, im one of you now :(

lucky windows can run perl

teehee

#!C:\Perl\bin\perl.exe

i thought i'd hate working full time in vb.net, and rarely if ever going outside the .net framework

like it would make me soft or something

but like driving an automatic car you get over that pretty quick :D

haha Insom. I sort of miss VB.NET but we needed cross-platform. I looked at Mono but it was too half-baked and not good for graphics (moved from DirectX 9.0c to OpenGL using JOGL). Things might have changed but now I'm tossing up going to C/C++ with a Qt interface.

Don't give a rats about which language in the end as in most cases the choice is taken out of your hands and made by someone else before you or outside of you. I've learned over the years that regardless of which language you use you will write the best you can in that language, unless of course you're a dips*** and write s*** no matter which language and I've seen many a developer like that.

Another of my bugbears is people whom write overly complex code unnecessearily as they think this somehow is a good indicator of a good developer. I see this a lot in younger chaps. They think that if I make it as complex as hell and use all the most fanciest stuff/techniques I can find I'm showing the world I'm a hot programmer when in reality they're s***. KISS is always triumphant when combined with concise, succinct code that is structured well and is efficient and effective.

Same goes for software architectures, frameworks, system designs etc.

Another of my bugbears is people whom write overly complex code unnecessearily as they think this somehow is a good indicator of a good developer.

Agreed. I tend to prototype methods and code and then when I need that code in another place, take it out, generalise it via some parameters and ultimately I end up having gotten the code "working" quicker, and knew the variables I could mess with.

They think that if I make it as complex as hell and use all the most fanciest stuff/techniques I can find I'm showing the world I'm a hot programmer when in reality they're s***. KISS is always triumphant when combined with concise, succinct code that is structured well and is efficient and effective.

I find fancy techniques are good, but only when they serve to make the code more reusable, or actually make the design simpler or more easily extendible.

Generally I'm not biased about the language. But I am very biased about the platform that is used for development, and that is generally pretty tightly bound to the language (or a few languages). Some software is just so much easier to write and maintain under particular platforms.

Another of my bugbears is people whom write overly complex code unnecessearily as they think this somehow is a good indicator of a good developer.

Haha, that reminds me of last week, a few of the guys here at work threw out the Fizz Buzz interview question because programming quizzes to developers are like waving a red flag to a bull.

The responses were "interesting":

a) Most just did a 'for' loop which is the way you'd expect it to be solved in the interview setting (~12-15 lines of code).
b) There was a Linq example with lambda expressions that solved it (~5 lines of code).
c) One of the guys developed a monster that was 130 lines of code, using strategy pattern, composite pattern and all classes adhering to the Single Responsibility Principle and other object oriented techniques.
It took way more time than necessary to comprehend what he'd done. Even though it solved the problem, if you need a flipping road map to get from one end of your backyard to the other something's wrong.

c) One of the guys developed a monster that was 130 lines of code, using strategy pattern, composite pattern and all classes adhering to the Single Responsibility Principle and other object oriented techniques.
It took way more time than necessary to comprehend what he'd done. Even though it solved the problem, if you need a flipping road map to get from one end of your backyard to the other something's wrong.

Heh that's pretty interesting but I spose it depends how you asked the question - if you'd been talking previously about all the software dev practices the respondent knew, and then asked him to solve a problem, he might think it was a test of his knowledge.

b) There was a Linq example with lambda expressions that solved it (~5 lines of code).

This is win. <3 linq

I spose it depends how you asked the question

The question is:
Write a program that prints the numbers from 1 to 100. But for multiples of three print "Fizz" instead of the number and for the multiples of five print "Buzz". For numbers which are multiples of both three and five print "FizzBuzz".
It's usually asked up front in an interview and intentionally low balled as a basic way to weed out those that can't write code at all vs those that can.
There was nothing wrong with the 130 lines of code really, just so much more of it than necessary and therefore difficult to grok.

SFB's bugbear is mine as well: there exists many developers out there that like to stroke their ego by intentionally writing large amounts of complicated code that everybody else has a hard time reading and understanding.

Thunder - f*** yeah! We use LINQ lambda expressions f***ing everywhere now, its a seriously expressive syntax for solving common problems.

Dzahel & SFB: this can be an artefact of the 'lines of code per day' programmer productivity measure still used by some people. I'd definitely rather have a savant who stared at the wall and drooled for 7 hours a day thinking about the problem and then wrote 100 lines of beautiful code than a furiously busy, line-slinging psycho!


last edited by Hogfather at 11:28:35 09/Feb/10

Billy Hollis has a solution:
Codeheads Anonymous

i'd take a dim view of using linq to perform such a trivial task, but that's just me

behind those five lines are thousands more

not hating on linq btw

If someone at work did something as simple as FizzBuzz with linq I would cry at them for creating an overcomplicated solution that made maintenance more complicated, when they could have written ten neat lines of really easily readable code using for, if, and mod

You just use linq where it makes sense though. I would consider the following example pretty readable:

static void Main(string[] args)
{
Enumerable.Range(1, 100)
.Select(p => getFizzBuzz(p))
.ToList()
.ForEach(x => Console.WriteLine(x));
}

private static string getFizzBuzz(int number)
{
string returnMe = "";
if (number % 3 == 0)
returnMe += "Fizz";
if (number % 5 == 0)
returnMe += "Buzz";
if (returnMe == "")
return number.ToString();
else
return returnMe;
}

Or something of that sort. (edit: excuse indenting)

last edited by Thundercracker at 23:12:28 09/Feb/10

foreach(range(1, 100) as $i) echo $i%3 == 0 ? ($i%5 == 0 ? "FizzBuzz\n" : "Fizz\n") : ($i%5 == 0 ? "Buzz\n" : $i."\n")

If someone at work did something as simple as FizzBuzz with linq I would cry at them for creating an overcomplicated solution that made maintenance more complicated

A LINQ expression is only complicated or difficult if you are unfamiliar with the syntax.

^ I am unfamiliar, does that make me thick? Probably, lol. I have a tendency to not worry so much though as I do consultancy at higher levels for business process re-engineering, workflow/taskflow management and project management not programming. But I still love programming, more so for the linguistics and mental gymnastics, I just don't do it as the main focus of a living anymore. In saying that I think I could still run rings around a few. I'm just not up to date with all the syntax, frameworks, patterns etc. Give me a book, let me watch you and I'm sure I'd cope just fine.

I also feel the best Project Managers/Consultants are those that come from a programming, systems analysis or systems architecture background. Seems though nowadays all you need is Prince or PMBOK Certification and Bob's ya uncle.


Enumerable.Range(1,100).ToList().ForEach(n =>
{ string s = "";
s += n % 3 == 0 ? "Fizz" : "";
s += n % 5 == 0 ? "Buzz" : "";
Console.WriteLine(s.Length > 0 ? s : n.ToString());
});


Unreadable and complicated?


last edited by Dazhel at 00:53:56 10/Feb/10

            string[] n = { "1", "2", "Fizz", "4", "Buzz", "Fizz", "7", "8", "Fizz", "Buzz",

                         "11", "Fizz", "13", "14", "FizzBuzz", "16", "17", "Fizz", "19", "Buzz",

                         "Fizz", "22", "23", "Fizz", "Buzz", "26", "Fizz", "28", "29", "FizzBuzz",

                         "31", "32", "Fizz", "34", "Buzz", "Fizz", "37", "38", "Fizz", "Buzz",

                         "41", "Fizz", "43", "44", "FizzBuzz", "46", "47", "Fizz", "49", "Buzz",

                         "Fizz", "52", "53", "Fizz", "Buzz", "56", "Fizz", "58", "59", "FizzBuzz",

                         "61", "62", "Fizz", "64", "Buzz", "Fizz", "67", "68", "Fizz", "Buzz",

                         "71", "Fizz", "73", "74", "FizzBuzz", "76", "77", "Fizz", "79", "Buzz",

                         "Fizz", "82", "83", "Fizz", "Buzz", "86", "Fizz", "88", "89", "FizzBuzz",

                         "91", "92", "Fizz", "94", "Buzz", "Fizz", "97", "98", "Fizz", "Buzz"};

            for (int i = 0; i < 100; i++) Console.WriteLine(n[i]);

run-time performance bitches

ahah Insom

Insom your runtime optimisations are lacking

Console.WriteLn("1\n2\nFizz\n4\nBuzz\nFizz\n7\n8\nFizz\nBuzz\n...

although i think it could be faster using a byte array instead of a string


string [] l = { null, "Fizz", "Buzz", "FizzBuzz" };

byte [] n = { null, null, 1, null, 2, 1, null, null, 1, 2,
null, 1, null, null, 3, null, null, 1, null, 2,
1, null, null, 1, 2, null, 1, null, null, 3,
null, null, 1, null, 2, 1, null, null, 1, 2,
null, 1, null, null, 3, null, null, 1, null, 2,
1, null, null, 1, 2, null, 1, null, null, 3,
null, null, 1, null, 2, 1, null, null, 1, 2,
null, 1, null, null, 3, null, null, 1, null, 2,
1, null, null, 1, 2, null, 1, null, null, 3,
null, null, 1, null, 2, 1, null, null, 1, 2};

for (int i = 0; i < 100; i++) Console.WriteLine(n[i] == null ? Integer.toString(i) : l[n[i]+1]);

last edited by Raven at 07:50:37 10/Feb/10

strange rash heh yeah that one occurred to me after writing it

but it's kind of cheating :)

whereas mine totally isn't

If someone at work did something as simple as FizzBuzz with linq I would cry at them for creating an overcomplicated solution that made maintenance more complicated

A LINQ expression is only complicated or difficult if you are unfamiliar with the syntax.

well, I don't subscribe to that school of thought. even being familiar with the code and syntax of regular PHP I often find particular implementations hard to read and hard to maintain if they're not done in a way that was intended to be easy to maintain (like excessive use of ternary operators to try and be tricky, when writing out a proper if/else chain would be instantly recognisable and require zero deciphering)

For me the dread is someone learning something like linq, then coming in and starting to spray code everywhere thinking its a really great approach - but without the rest of the team members being up to speed on it, it kills maintainability dead.

The trick with linq is to start using it (well, "linq to objects") in simple scenarios in your code. It really does cut down on a lot of basic grunt iteration code you have to write.

Mind you, I don't use linq to sql and only a little bit of linq to xml, but that's because I write all my own SQL as stored procedures.

The trick with linq is to start using it (well, "linq to objects") in simple scenarios in your code. It really does cut down on a lot of basic grunt iteration code you have to write.

Mind you, I don't use linq to sql and only a little bit of linq to xml, but that's because I write all my own SQL as stored procedures.

yeh was just googling it, it looks pretty neat, although wikipedia tells me there's a performance impact?

lol excessive ternary to be tricky. "if this, then this, otherwise this" is tricky?
slow down, egghead

I'm not sure how much overhead linq adds to basic iteration due to it just being linq. Under the covers it's not doing anything particularly complicated, so I can't see exactly what would add the overhead. In my own personal use of it, I have found it to perform well, but I'm not exactly writing bare bones performance apps.

Of course, it's still iterating over data in memory, so its definitely possible to write a poor performing linq query just like its easy to write a poorly performing set of nested loops.

lol excessive ternary to be tricky. "if this, then this, otherwise this" is tricky?
slow down, egghead

long nested ternary equations split out over multiple lines are hard to read, is what I'm saying

If they're one line, relatively simple and short, then they're not a hassle in most circumstances

There can be a performance impact, so it may not be appropriate in performance critical applications. The trade off between programmer time spent and CPU time spent is age old.

I think Linq has it's place, but declaring everything a nail so I can use my Linq hammer is silly. In a lot of desktop applications the computer spends 99% of it's time waiting for the monkey in the chair to press a button on the keyboard anyway.

well, I don't subscribe to that school of thought

Well, I guess that the end of that line of conversation. Care to demonstrate why you think LINQ is less maintainable than regular C#?

Note that we use lambda expressions which I find a lot more natural and 'codey' to read than the LINQ you'll see in most This is LINQ introductions.

well, I don't subscribe to that school of thought

Well, I guess that the end of that line of conversation. Care to demonstrate why you think LINQ is less maintainable than regular C#?

That's not what I said

OK so what you said was:

If someone at work did something as simple as FizzBuzz with linq I would cry at them for creating an overcomplicated solution that made maintenance more complicated, when they could have written ten neat lines of really easily readable code using for, if, and mod

We routinely do very simple tasks with LINQ because we find it a very elegant solution to a lot of small problems. Working with WPF and web services you have a lot of IEnumerable collections and LINQ to Objects makes working with them a breeze.

Care to demonstrate why a LINQ solution is less easily maintainable or readable than for, if, and mod statements?

last edited by Hogfather at 11:57:19 10/Feb/10

In response to Insom, yeah I'd probably not use Linq for a trivial thing like FizzBuzz in the real world, but here's what Microsoft has to say:

LINQ queries offer three main advantages over traditional foreach loops:

1. They are more concise and readable, especially when filtering multiple conditions.
2. They provide powerful filtering, ordering, and grouping capabilities with a minimum of application code.
3. They can be ported to other data sources with little or no modification.

In general, the more complex the operation you want to perform on the data, the more benefit you will realize by using LINQ instead of traditional iteration techniques.

http://msdn.microsoft.com/en-us/library/bb397919.aspx

Care to demonstrate why a LINQ solution is less easily maintainable or readable than for, if, and mod statements?

I didn't reaaaaaally mean that it's not readable - as above, I meant if someone came in and busted out LINQ in the middle of a project when noone else had used it, then it would be totally gay for everyone else working on that project (this has actually happened on projects here; not with LINQ but with other new technologies that were included without everyone being made aware of what they were, what they did, how they worked, how to maintain them, etc).

I assume Dazhel's code above is fizzbuzz in LINQ? It would personally drive me mad reading stuff like that every day, as opposed to something broken down simply in if/then loops

At the end of the day tho I have no data to back it up, but as someone that gets to maintain a lot of other people's code, I like it to be crystal clear and easy to understand, rather than super-elegant and concise.

What I was really saying above was, you can have seemingly simple things like LINQ (or if/then/else loops) that seem like a good idea, and then implement them in ways that make sense to one person, but are utterly incomprehensble to another

Enumerable.Range(1,100)

Really only this bit is Linq. The Enumerable class generates a range of 100 integers starting at 1.

.ToList().ForEach(

The IEnumerable<int> gets converts it to a List so that we can use the ForEach method on List<T>. The IEnumerable<T> might have been backed by a List<T> to begin with (I don't find out) so the conversion might be straight forward.

n =>
{ string s = "";
s += n % 3 == 0 ? "Fizz" : "";
s += n % 5 == 0 ? "Buzz" : "";
Console.WriteLine(s.Length > 0 ? s : n.ToString());
});

This bit is a lambda expression.
You think of 'n => { ... }' as a function without a name, but takes single argument where the type is inferred from the context.

That's an implementation and shop-standards issue rather than a language problem.

Dazhel's example is a wee bit more esoteric than I would use in practice as I'm all about readability over cleverness - I'd rather make a few statements than chuck a bunch of operations together to save a few lines. Now, that said...

Working with System.Collections a lot, we just tend to do things like this:

// Let "WidgetList" be a System.Collections.List
// Get blue widgets that are in default:
return WidgetList
         .Where(r => r.Type == "Blue")
         .Where(r => r.Default == true)
         .ToList();

Rather than:

List results = new List();
foreach(Widget item in WidgetList)
{
   if(item.Type == "Blue" && item.Default == true)
   {
      results.Add(item);
   }
}
return results;

With a bit of practice and "getting used to" LINQ lambda, the former is as readable as the latter.

last edited by Hogfather at 12:39:23 10/Feb/10

I'd add to that, there's lots of different LINQ extension methods to do sorting, filtering, etc. The equivalent for loop code is much more difficult to read.

e.g. Top 10 default blue widgets by lowest price:

return WidgetList
.Where(r => r.Type == "Blue")
.Where(r => r.Default == true)
.OrderBy(r => r.Price)
.Take(10)
.ToList();


If it was LINQ to SQL the code above would be directly converted into an SQL query, though LINQ to SQL is deprecated in favour of LINQ to Entities and the Entity Framework in the latest framework versions.

^ Hey all that LinQ stuff is pretty neat. I know I would probably have a tendency to use it in favour of the standard coding approach HogFather showed in his example of LinQ vs Standard.

though LINQ to SQL is deprecated in favour of LINQ to Entities and the Entity Framework in the latest framework versions

Yeh I very nearly became a Linux guy when I read that, needed a f***ing Bex and a lie down. For a small shop like us L2S is f***ing awesome.

Unless they backflip or the EF ships with a lightweight version that mirrors L2S we'll probably switch to NHibernate instead. MS are so f***ing stupid sometimes.

last edited by Hogfather at 14:58:18 10/Feb/10

Do we all agree that java is the most hilarious joke ever played on IT?

that's like a perfect example of why I don't like using fancypants new things like that :P

Eh, it'll work for a few years yet if its while deprecated, and L2S is different to LINQ itself.

Reading more today, the latest rumar is that they are now scared to actually deprecate it cos of the e-rage they got over the announcement, and they may just stick it in the attic and hope we all give up on it. That didn't work so well with MFC.

I'm happy enough with that to be honest, even with its quirks it does lots and lots of stuff I want.

last edited by Hogfather at 16:00:17 10/Feb/10

Yeah now that LINQ to SQL is released and being used they'll find it tough to get rid of so it's not all doom and gloom if you've picked it up.
I'd be hesitant invest time to learn it and use it in new projects though.

Edit: Should clarify that like Hogfather said, LINQ to Objects, LINQ to SQL, LINQ to XML and LINQ to Entities is still fully supported, it's just that most of the effort MS makes in the future will likely be directed into entity framework and LINQ to Entities instead of LINQ to SQL


last edited by Dazhel at 16:33:27 10/Feb/10

Without really knowing too much about LINQ, LINQ to SQL sounds instantly useful and awesome (so I guess I'm unsurprised out of those, it's the one they'd pick to axe)

^
I know its amazing, and seemingly full of politics. The C# team built L2S as a bit of a showcase for LINQ. L2S is easy to use and has been massively useful, especially for ISVs delivering smaller-scale solutions from day 1.

Anyway, after .Net 3.5, as data isn't really their thing, the C# boys handed it over to ADO.Net (the data team). These are the guys who are still struggling to get their big shiny f***en entity framework into production, and in .Net 4.0 will likely release a product with limited support for seemingly baseline functions like stored procedures that L2S has always had.

So while their flagship data bells-and-whistles product struggles to make it into production the little L2S upstart must be a massive embarrassment. Any lightweight implementation of the EF intended to replace L2S will probably lack features that exist in L2S...

No wonder they don't want to develop it ;)

last edited by Hogfather at 17:15:11 10/Feb/10

I'm not even a programmer (but know languages like C#, PHP, ASP, VB, C) and I knew that FizzBizzBang thing would need to use MOD.

Anyway the correct answer is to off-shore it to an Indian development centre, pay them $5 and get back a 100,000+ line program with no documentation with for loops and counts all over the place that would give you the correct result only 75% of the time.

^ You don't work for Accenture do you? :)

One of the big downsides of LINQ to SQL is that it only works with SQL Server, whereas the Entity Framework plugs into any ADO.NET provider that wants to support it.

next time a program hangs i'm gonna pay my lawyer 3k/day to get me a refund of said program

Dazhel: I guess that's a problem if you want to connect to non-MSSQL databases in L2SQL! Fortunately that's not on our radar, I prefer to keep the MS stuff separate from the non-MS stuff, something is always gonna f*** up somewhere.

^ You don't work for Accenture do you? :)

truth lols

gotta learn me this linq thing

I've got a pain in the arse performance problem that could be fixed by making a class IQueryable, and analysing the query to check whether i need to retrieve more s*** from the database to fulfil the query

but I looked at the microsoft walkthrough and my head a sploded so it's not a one day deal :D

I heard back in 2008 Tech Ed MS weren't continuing development of Linq2Sql, in favour of an apparently more robust EF. We've delivered a number of solutions with L2S working in the DAL. I found it confusing and not as compelling as NHibernate. writting decent unit tests when using Linq2Sql entities is more painful than it needs to be too.

I haven't heard a whole lot of positive from my friends working on EF projects. Their chatter mainly was about ramp-up time though.
I think MS have tried to put their fingers in too many pies. OSS is doing a great job of filling the MS gaps.