Perhaps a OOP programmer can explain to me why, in todays day and age, its so fuking hard to make programs that are always responsive? I mean should you have your main thread render the gui and your other child threads go ping a fuking server or wahtever and therefore the main thread is updating whenever new data is availiable from the child threads, why the hell do so many programs come back as not responding for 5-10seconds (example. steam somtimes does it when it tries to render the 'special discounts' popup on load - on rare occasion)

as i say to the business analysts at work:

too hard... and you're just moving the problem somewhere else

next!

having said that though, our apps at work need responsive UI even if back end isn't - so we usually handle your problem better.

The answer is clearly napalm.

Its normally about cost-benefit and return on effort.

Dumbed-down a bit:

A Windows application has a thread-safe architecture that mandates that only the 'main thread' can interact with the GUI. This is just not going to change anytime soon, and dealing with it is part of working in Windows application development.

Anyway, this is the thread that you get when you respond to an event like a user clicking on a button, so you are able to very easily hook up events to changes in the GUI, create new Windows etc.

The problem arises when the task involves a time-intensive operation. As there is a single thread that can draw the UI, it is now doing some work (waiting for a data store, doing some number crunching). While it is working on this task, everything else is held up and the application 'hangs'.

The way to resolve this is to create a worker thread to do the task, and then notify the application GUI thread when its done so that the result can be displayed to the user.

This is a LOT more work and problematic as you need to then consider thread-safety in your application - what happens if the user asks again while the task is running in the background? Is the task using common data that needs to be thread-safe, can the code result in deadlocks?

Basically although its ugly, the simplest course is to hang the application while the work is done. This is inappropriate for a commercial application though as users increasingly expect a more responsive experience.

last edited by Hogfather at 13:24:32 07/Feb/10

or that..

http://i244.photobucket.com/albums/gg35/ggb777/jokerjackheath.jpg

it kinda reminds me of those worker thread controls i had in vb 2005... but then when sp1-2 for vb2005 came out they changed a f***tonne of stuff with it and alot of my apps i had wrote to use them no longer were allowed to do stuff and alot of them broke.

that sucked, but it made it easy for me to make quick responsive apps myself. so many people talk about multi threading like its the devil. i had a few things here and there that happened like two threads changing the same data but i worked it all out. I think for small apps it was pretty easy, i can get how the bigger apps would become a mind boggle but seriously, i think having a responsive gui all the time is something that should really be a minimum spec in todays world and MS needs to make sure devs can build that spec easily.

Give me back by worker class control ms :( i dont want to have to create an object and do all that professional programmer crap in my program, i just want to drag it onto my design layer and go wp1.go ;)

faceman wtf is that about?

I think for small apps it was pretty easy

Its more work, though - especially if you are doing it correctly and using mutexes etc to prevent deadlocks. Probably at least an extra 100% overhead, and if you're writing a lot of code it adds up.

I sure as s*** don't bother to thread every single event..

Hog what is 'dll hell' - i used it hear it a fuktonne before .net came out. Why dont i hear it now that .net is out?

Most of my crashes are caused by windows :/

Doesn't matter what I'm running windows will find a way.

Even msn which is made by windows.

Like Hog said, software traditionally is much easier to program when everything is happening one thing at a time in a predetermined order. This isn't particularly good for the user though because as you know, it hangs the GUI while long processes are taking place (such as encoding).

For example,

• User clicks button
• Button click event calls a time intensive function
• Function exits, returning the code to the event function
• Event function exits and event monitoring/GUI resumes

While it's not difficult to implement a separate worker thread and have the GUI respond to user input during the process, it's a lot of work to make it work right, and keep the rest of the application from getting messed up because your process "hasn't actually finished yet".

Most of the time, the easiest solution is to basically lock down the GUI while keeping it responsive, in other words, disable all controls and throw up a progress bar. This lets the user know that the program is still doing things instead of creating confusion as to whether something has gone wrong or its just working away by itself.

The biggest technical problem with multiple threads is the accessing of shared objects. If the worker thread wants to modify something but the main GUI thread accesses this as well, you need to start "locking" resources, so that one thread waits until the other thread is finished with it. This can add generous amounts of error checking code and locking mechanisms (like critical-sections).

All in all, it's just more work.

Instead of letting the program hang couldn't you simply implement a small popup that appears with a message indicating the user's request is being processed?

this is why I stick to server:client applications where possible
also, cloud computing is the future

zig heil www

Hog what is 'dll hell' - i used it hear it a fuktonne before .net came out. Why dont i hear it now that .net is out?

DLL Hell refers to DLL dependency mismatch or problems. Basically, your application might depend on a particular feature in particular library installed to the computer, and likely exposed via COM.

Before .Net Assemblies libraries were accessed and maintained in a very ad-hoc fashion from computer to computer. Working out what was causing your application (or portion of an application) to fail could be a complete bastard, as you might be accidentally referencing a particular version of a DLL, or worse via a DLL reference chain further up the line. Untangling it to work out what is wrong on a particular computer is a bastard.

When .Net was released, they did away with COM (kind of) and you instead register a .Net assembly to the Global Assembly Cache, or it is automatically available in the module's directory (same path as the exe). That's kind of a simplification, but instead of DLLs you get a neater index of installed modules.

In addition, a f*** TONNE of stuff you used to do via a referenced DLL call has been moved into the .Net Framework itself - a consolidation that was one of the core drivers of the implementation of .Net. There is much less need to reference libraries via COM, MFC, ATL or win32 calls, as more of what you want to do in an application is readily available under the Framework itself.

This reduction in DLL dependency has made 'dll hell' almost a thing of the past for a modern app unless your vendor is doing stuff via COM (like accessing a runtime library out of VBA or ASP Classic). It is still useful (and necessary) but a basic winforms or WPF app just doesn't have the same exposure to DLL mismatches and chain calls.

Instead of letting the program hang couldn't you simply implement a small popup that appears with a message indicating the user's request is being processed?

But that window is displayed on the screen using the GUI thread that is working on other stuff! Unless you implement a worker thread it will hang as well.

teq: client-server architecture doesn't alleviate this problem at all - one of the big reasons it manifests is when waiting for a response from a server in a c:s setup.

Websites don't inherently evade the problem either. You just redraw the entire interface after each call to the server (and wait for the response - you can't do anything else while you wait for this!), or implement a seperate UI thread via ajax to re-render a portion of the page.

last edited by Hogfather at 15:05:39 07/Feb/10

I thought everyone used ajax these days anyway?

Do you nav the same web I do?

Most of my interaction is full-page request-response, same way its been done for years. For example, ausgamers doesn't do partial-page rendering in these forums at all!

Same, while not a big website, the only dynamic loading I have in www.ludavico.com is the Shows page (accesses our public Google Apps calendar). I could do it via PHP but I'd rather the page itself load quickly and not wait for Google.

Modern day software devs "just don't get it". iTunes is a perfect example of what you've illustrated here. How can a supposedly top-tier company release such a widely-used application with such glaring problems?

Developers just don't seem to get the whole "don't do processing when handling events". It's like putting large chunks of code in a constructor, NOOOOOOO!

Ideally from the message handler they should be pushing a message on to a queue, with data if necessary, with another worker thread (one or more) that picks off messages and processes them. But no, they're not smart enough to do that.

And in fairness, 97% of programmers aren't smart or talented enough to manage multi-threaded software without rogering it up.

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.

I'm starting to understand why 99% of the people at my company refer to programmers as 'code monkeys' or 'code cutters'. They are considered below the support people ... none are really respected... only the 1% that do the ruby on rails / java stuff... but they are hard to talk to because everything is 'encapsulate this' 'export/portable that'... no one likes them.

It's like programmers are split into 99% that just got their peice of paper and make the software work however they can to get their 'paycheck' and are most likely all on contracts like the lazy superiority complex heiving shemales they are and the other 1% that are actually really smart and always manage to pop out oop code and re-use it without really trying.

guess i got a little ranty there...

Do you nav the same web I do?

Most of my interaction is full-page request-response, same way its been done for years. For example, ausgamers doesn't do partial-page rendering in these forums at all!

Imagine how awesome it would be if a thread auto updated itself while you were reading it? No more posting stuff that was already posted while you were busy reading the thread only to have to edit your post & say beaten or leave it & look like you didn't read the thread.

trog: get to work!

people who refer to their programmer colleagues as code monkeys etc are doing so because they are up themselves

Ugh, I realized that I stupidly said 'Queue', and I meant 'Channel'. Way to make myself look stupid :(

hog; I tend to use ajax in everything I write (for at least the past 12 months)
I have also noticed the lack of wide spread ajax on existing sites, but I think you'll find if you look at a new/popular/techy sites that keep up with this stuff - they will usually employ ajax somewhere

google for example in the predictive search
eventually everyone will have to fall into place, just like everyone will have to start using css finally

wrong thread gamer, www.google.com/search?q=toyota+prado

Ajax isn't the greatest for SEO which is probably why "baked" pages (i.e. PHP, ASP etc) are still very much prevalent. Besides that, sometimes it's not cool when you wait for a page to load only to find it's still gotta... load the page/

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.

static linking ftw

if your page requires ajax calls to get it to its initial state then it is dumb

ajax isnt incompatible with seo so long as there is some way to get to your searchable content thru hyperlinks

it's called xajax, do yourself a favor and use it
I wrote my own class to do axaj forms and then found xajax, wasted a fair bit of time

static linking ftw

If you're lazy and like 60MB binaries where 600KB would suffice.
Use a Mac for a few years, then you'll understand.

Ideally from the message handler they should be pushing a message on to a queue, with data if necessary, with another worker thread (one or more) that picks off messages and processes them. But no, they're not smart enough to do that.

And in fairness, 97% of programmers aren't smart or talented enough to manage multi-threaded software without rogering it up.

Hey I wanted to learn the fundamentals of multi-threaded software at uni, but they cut the course since half the enrolment numbers were buggering off to the new gaming schools and the like. This all makes sense though, so thanks it's given me something to start thinking about. :D

static linking ftw

On top of that, rolling your own ftl :P

If you're lazy and like 60MB binaries where 600KB would suffice.

I do if it means I don't have to install 6GB of support framework for one application.

Google HIT3197/HIT8197.

Like everything static linking has it's place. It's not the answer to everything.

people who refer to their programmer colleagues as code monkeys etc are doing so because they are up themselves

Disagree with this. It's like calling someone a 'wog' - doesn't necessarily mean that you think any less of them.

Agree with Raven's comment that writing good multi-threaded apps takes some expertise. 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. That's the price you pay for languages that are easy to enter into for beginners.

Writing a good stable multi-threaded app is not for the faint hearted. It will f*** with your head and can make debugging a real bitch. But once you've got it done right it's awesome and can really speed up large process if your CPU is also multi-core/multi-thread enabled.

On this subject apparently a new version of Excel 2010 will have multi-threaded recalculation enabled to take advantage of the multi core processors that people seems to have these days.

Like everything static linking has it's place. It's not the answer to everything.

The only thing it's not the answer for is saving disk space, which is something I stopped worrying about in around 1995 !@#!$$^%!

If you're lazy and like 60MB binaries where 600KB would suffice.
Use a Mac for a few years, then you'll understand.

Aren't Mac binaries just retardedly huge because they're built for both x86 and PowerPC archicture? I think that's a reasonable price to pay for that sort of compatibility... I'd happily take massive binaries if i meant I could move my Apps directory between computers and/or operating systems and still be able to run everything!

Perhaps a OOP programmer can explain to me why, in todays day and age, its so fuking hard to make programs that are always responsive?

Often it's a trade-off. If something CPU-intensive is being done, keeping the UI updated can waste a lot of CPU cycles. It can get to the point where you prefer it to take .5 sec with an unresponsive UI, than take 2 sec and have the paint/mousemove/click etc. messages pumped through. If something goes wrong though and screws up your estimates (network issues, HDD soft reset after I/O problem, unusually large amounts of data to process) then you can end up with the "This program has stopped responding ..." situation.

While it is working on this task, everything else is held up and the application 'hangs'.

The way to resolve this is to create a worker thread to do the task, and then notify the application GUI thread when its done so that the result can be displayed to the user.

This is a LOT more work and problematic...

You don't actually need to go to all this trouble, if all you want is for simple things like redraws to be processed while doing the time-consuming task. Using the windows messaging API you can peek into the message queue, and then translate and dispatch the ones queued up.

By controlling how frequently you pump through the pending messages, you get to control the UI/performance trade-off (if there is one to worry about). And you get to keep things simple by running the show from one thread still. Of course, you still aren't excused from then having to worry about people closing the window while it's halfway through processing, etc.

The only thing it's not the answer for is saving disk space, which is something I stopped worrying about in around 1995 !@#!$$^%!

Well, sometimes static linking can be annoying. Like when a whole bunch of programs share a component and you'd like to be able to update that component without recompiling every program. Or, thinking about it from the other perspective, you'd like your program to always be using the latest version and you trust the vendor to make backwards-compatible updates.

For example, you may recall the GDI+ exploit a few years back. A specially-crafted JPEG could cause arbitrary code to run if that application was using GDI+ to display it. MS pushed out an update which updated the DLL in system32, but those programs which statically linked to the old buggy version (or provided their own copies of the DLL) were left vulnerable.

Basically it boils down to this:
Windows development guidelines have said from the very beginning that doing any kind of I/O or CPU intensive operations on your message processing thread is bad juju. It can and will cause your program to stop processing messages - the most obvious indicator of this is an unresponsive interface since screen painting and handling mouse clicks are done by sending messages back and forth between the OS and the application.

That said, if someone has a manager breathing down their neck to get an application out to the customer on time, the response "I can't release it yet because in 1% of all cases the UI can get sluggish!" is going to be laughed at.
Time is money and all that.

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.

In that case, I have never, ever, ever, ever honest to god ever seen something developed by a good java programmer. Even Eclipse has the ability to turn my 8 core xeon box into a celron 300.

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.