What are you currently into?
-
The last year I have been programming WinForms most of the time. I recently started doing some WCF too. I tried doing some WPF (but got distracted by F#). So I was doing F#, but got distracted by some cool WinForms designer stuff I didn't know yet... And back at WinForms I was. And that's basically how I've been going around in circles. There is a lot to learn when programming WinForms, but it is a somewhat outdated technology. I feel I should be doing WPF, but F# looks really nice too. I also wanted to do some C++ (which I did for about two evenings) because I want to know a bit more about why some stuff is how it is (and a lower level language seems like a good way to learn). Knowing more about pointers and memory management has my special interest. But that won't help me in WPF or WCF or F# or... And now we're going to use Microsoft Enterprise Library at work too, so I am supposed to do some of that too! There is just so much to learn (old and new) and there is more coming still! I was just curious, are people here currently learning some new language, technique, framework etc.? And why? For all the people who are going to shout "No programming questions in the lounge!", this is NOT a programming question. It's a question about programming :)
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
}Like you, I keep coming back to WinForm development after occasionally dabbling in WPF, and similarly, goofing around in F# but not doing anything serious in it - I think it'll be much more effective in VS2011/.NET 4.5 (???) with the type descriptor feature. But for the moment, I'm mainly into looking at the idea of making relationships more first class citizens, if you will, rather than the current approach of foreign keys, the idea being that relationships can themselves have attributes, temporal components, etc. Something called Anchor Modeling[^] looks intriguing as well. Basically, regardless of the programming language, the framework, the UI implementation, the backing database, etc., what I'm into is a deeper understanding of what it is we're doing with these things we call "objects" and the relationships that exist both between objects abstractly and the data, concretely, that exists between them. I guess you could say, I'm into putting objects on the couch and psychoanalyzing their sex life. ;) Marc
-
The last year I have been programming WinForms most of the time. I recently started doing some WCF too. I tried doing some WPF (but got distracted by F#). So I was doing F#, but got distracted by some cool WinForms designer stuff I didn't know yet... And back at WinForms I was. And that's basically how I've been going around in circles. There is a lot to learn when programming WinForms, but it is a somewhat outdated technology. I feel I should be doing WPF, but F# looks really nice too. I also wanted to do some C++ (which I did for about two evenings) because I want to know a bit more about why some stuff is how it is (and a lower level language seems like a good way to learn). Knowing more about pointers and memory management has my special interest. But that won't help me in WPF or WCF or F# or... And now we're going to use Microsoft Enterprise Library at work too, so I am supposed to do some of that too! There is just so much to learn (old and new) and there is more coming still! I was just curious, are people here currently learning some new language, technique, framework etc.? And why? For all the people who are going to shout "No programming questions in the lounge!", this is NOT a programming question. It's a question about programming :)
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
}I've been learning WebGL and javascript. It's just so easy to bring an idea to life with this stuff.
Curvature of the Mind now with 3D
-
The last year I have been programming WinForms most of the time. I recently started doing some WCF too. I tried doing some WPF (but got distracted by F#). So I was doing F#, but got distracted by some cool WinForms designer stuff I didn't know yet... And back at WinForms I was. And that's basically how I've been going around in circles. There is a lot to learn when programming WinForms, but it is a somewhat outdated technology. I feel I should be doing WPF, but F# looks really nice too. I also wanted to do some C++ (which I did for about two evenings) because I want to know a bit more about why some stuff is how it is (and a lower level language seems like a good way to learn). Knowing more about pointers and memory management has my special interest. But that won't help me in WPF or WCF or F# or... And now we're going to use Microsoft Enterprise Library at work too, so I am supposed to do some of that too! There is just so much to learn (old and new) and there is more coming still! I was just curious, are people here currently learning some new language, technique, framework etc.? And why? For all the people who are going to shout "No programming questions in the lounge!", this is NOT a programming question. It's a question about programming :)
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
}sticking with C#/c++/Java with mobile/asp.net/other in mind. Still toying with 3dsMax (I've created a pug ugly Delek). xna development is just practice.. Tinkering with Asian cooking styles as I'm needing a change of pace from euro style (and something else to do with the stash of homemade stock I have). may toy with indi next. ((joke)over all not much done. on a cellular level, I'm rather quite busy(end joke)).
///////////////// -Negative, I am a meat popsicle.
-
Last 6 years have been c++ on linux day in, and day out, before that was a c/c++ embedded system and c++/MFC before that. I would argue that learning about memory management in a language like c would be useful even if you dont intend to use that knowledge directly. In the last year I've been looking for excuses to use Python as it makes a nice change from c++
That's a lot of C :wtf: Reason I want to learn about memory management is because I recently read some stuff on IDisposable in .NET. While I know how it works I do not quite know when and why to Implement it (in less obvious cases). Doing a language such as C++ would greatly help in understanding such stuff I think :)
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
} -
Technology is an interesting thing, in one part because of how facinating all of the new "stuff" can be, and another part because of how fast it changes. Having solid well-rounded knowledge in this industry never hurts, as long as your skills can be carried over and applied else where. When you start to specialize is where you can get into trouble. With all of the that being said, I choose to do stuff that I find enjoyable on my own time, and I keep my work technologies at work. This helps me stay sharp with multiple technologies, not get burnt out on any one things (especially work) and I am sure that part of my time is purely for fun. What am I learning? Lately I have found an interest in GPU processing. I am learning Direct3D and Direct2D. Direct3d 11 has some very nice features that makes GPU computing much more accessible and embraces this paradigm with DirectCompute, all in C++.
Paul Watt wrote:
Having solid well-rounded knowledge in this industry never hurts, as long as your skills can be carried over and applied else where. When you start to specialize is where you can get into trouble.
True, I am currently aiming for some more common knowledge, such as OOP principles or the functional paradigm of F#. Learn F# (or any other functional language) and you'll be a better programmer in every language I think :)
Paul Watt wrote:
I choose to do stuff that I find enjoyable on my own time
Yeah, that's fun if you're good enough to function at work. I started from as good as nothing last year. So the first few months I spent learning .NET, VB syntax, OOP principles, using company libraries... Luckily I caught up pretty fast, so I can now justify doing my own thing in my spare time :) And occasionaly doing some overtime at home and learning about new stuff such as TPL and WCF. It's great when you get to learn new stuff and get paid for it :) I still don't really get that graphic stuff though. Never was good with Paint either ;)
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
} -
That's a lot of C :wtf: Reason I want to learn about memory management is because I recently read some stuff on IDisposable in .NET. While I know how it works I do not quite know when and why to Implement it (in less obvious cases). Doing a language such as C++ would greatly help in understanding such stuff I think :)
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
} -
In the last 2 years its been a rollacoaster of technologies. When I joined my current employer they started on phasing out an out dated Access ADP project. The IT Manager has requested VB.NET due to his Access background. So why mainly developing in VB I have explored WPF, Winforms, WCF, JQuery, Javascript, Ajax, Silverlight, SQL Server, Web services, ASP.NET and even Adobe FLEX and have also done project in C# just because I can do any other none high priority jobs in what ever language that is needed. on a personal note I have mainly been doing things in C# at home purely as I am currently playing around with C# Generic lists / collections and Lambda to find out what it has above VB.NET
Lobster Thermidor aux crevettes with a Mornay sauce, served in a Provençale manner with shallots and aubergines, garnished with truffle pate, brandy and a fried egg on top and Spam - Monty Python Spam Sketch
Sounds interesting. I also had the luck that my company started doing all kinds of new stuff soon after I joined. I am now doing VB, Entity Framework 4.0, WCF, using some libraries such as Microsoft Enterprise Library and programming more OO oriented than my company has ever done (I kind of lay on the ground and started screaming until they agreed we should be more OOP oriented) ;p
Simon_Whale wrote:
to find out what it has above VB.NET
If I should believe some books I've read both C# and VB can do the exact same stuff. They just do it differently sometimes :) I still prefer lambda's in C# though, VB looks kind of awkward.
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
} -
Like you, I keep coming back to WinForm development after occasionally dabbling in WPF, and similarly, goofing around in F# but not doing anything serious in it - I think it'll be much more effective in VS2011/.NET 4.5 (???) with the type descriptor feature. But for the moment, I'm mainly into looking at the idea of making relationships more first class citizens, if you will, rather than the current approach of foreign keys, the idea being that relationships can themselves have attributes, temporal components, etc. Something called Anchor Modeling[^] looks intriguing as well. Basically, regardless of the programming language, the framework, the UI implementation, the backing database, etc., what I'm into is a deeper understanding of what it is we're doing with these things we call "objects" and the relationships that exist both between objects abstractly and the data, concretely, that exists between them. I guess you could say, I'm into putting objects on the couch and psychoanalyzing their sex life. ;) Marc
Marc Clifton wrote:
a deeper understanding of what it is we're doing
I think that's key to becoming a good programmer! I work at a company that went from a custom DB tool someone wrote once to a quick flirt with "typed datasets" to Entity Framework. As a result none of my colleagues knows how to use DbConnection, DbCommand and DbAdapter Objects... It's the first thing I started to explore when we switched to typed data sets. I also found out they were not as "typed" as we believed. I didn't want to work with those typed data sets, so I started using DbCommand Objects out of protest (yes, I am that kind of guy. It was only a prototype project anyway). It was not in vain since we now use Entity Framework 4.0. Although it took an MVP to convince my employers what I had been saying for weeks... :~ Knowing what's going on keeps you from making wrong decisions or choosing tools you don't need.
Marc Clifton wrote:
I'm mainly into looking at the idea of making relationships more first class citizens
Interesting idea. Can we expect an article on that anytime soon? :)
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
} -
In my experience IDisposable is probably the worst part of the dot net design. It has all of c's memory issues and more.
Biggest issue is that any Object could Implement it. So you never know when to call Dispose. The safest way is probably to TryCast ANY Object to IDisposable and Dispose it if it succeeds. But then your problem is that you don't know what other Objects are currently referencing it... Some cases are obvious, such as
using { ... }. Unfortunately many cases are not that obvious. It makes it practically impossible to Dispose of ALL your Disposable Objects... :~ I recently read IDisposable: What Your Mother Never Told You About Resource Deallocation[^]. A real eye-opener, but unfortunately focused on calls to unmanaged code.It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
} -
In my experience IDisposable is probably the worst part of the dot net design. It has all of c's memory issues and more.
Isn't that simple? You need a 'destructor' as soon as your class holds any additional resources like open file handles or everything that has to be created with 'new' (= memory). In a managed language like C# you can simply make a habit of using Dispose() to 'close' (where possible) and then dispose (also where possible) all objects held in the member variables of your classes. And in 'normal' methods you should always think a second about letting a local object simply go out of scope or properly disposing it. Cleaning up an opened file stream, for example, avoids problems when the file has to be accessed again before the garbage collector has taken care of the last object used to access the file. In C# this is a covenience to properly free those resources long before the garbage collection does so. In C++ this is a must, unless you like memory leaks or inaccessible files.
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse. -
Biggest issue is that any Object could Implement it. So you never know when to call Dispose. The safest way is probably to TryCast ANY Object to IDisposable and Dispose it if it succeeds. But then your problem is that you don't know what other Objects are currently referencing it... Some cases are obvious, such as
using { ... }. Unfortunately many cases are not that obvious. It makes it practically impossible to Dispose of ALL your Disposable Objects... :~ I recently read IDisposable: What Your Mother Never Told You About Resource Deallocation[^]. A real eye-opener, but unfortunately focused on calls to unmanaged code.It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
}The rule of thumb is fairly simple: explicitly dispose anything which uses restricted or unmanaged resources. If it's just memory then the garbage collector will grab it when appropriate, but if it's something that might run out or cause a problem before the garbage collector arrives (file handles and graphics resources are the usual ones, though I think graphics objects are cached or reused because I've written lots of things which don't Dispose local pens/brushes and never had an issue). The garbage collector will call Dispose as part of finalisation, so all your IDisposables will, eventually, get disposed – but quite possibly not in a time frame that you are happy with.
-
Isn't that simple? You need a 'destructor' as soon as your class holds any additional resources like open file handles or everything that has to be created with 'new' (= memory). In a managed language like C# you can simply make a habit of using Dispose() to 'close' (where possible) and then dispose (also where possible) all objects held in the member variables of your classes. And in 'normal' methods you should always think a second about letting a local object simply go out of scope or properly disposing it. Cleaning up an opened file stream, for example, avoids problems when the file has to be accessed again before the garbage collector has taken care of the last object used to access the file. In C# this is a covenience to properly free those resources long before the garbage collection does so. In C++ this is a must, unless you like memory leaks or inaccessible files.
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse.It's not quite that simple. What happens, for example, when a Disposable Object holds a reference to another IDisposable that might still be referenced by other Objects? Calling Dispose should Dispose of managed and unmanaged resources, while the GC can only free managed resources (something like that). So to properly clean all your Objects you should wrap unmanaged resources in managed Objects that Implements IDisposable and have those Dispose in the Disposer of the Object that uses it and always call Dispose, which might dispose Objects that are still referenced... *Head explodes* ... ... Just believe me, it's not that simple ;p Just think of this. IEnumerator does not Inherit from IDisposable, IEnumerator<T> does. This basically means that IEnumerators are (probably) NOT properly disposed even though they Implement IDisposable. IEnumerator<T> is ALWAYS disposed even though you won't need it 99 out of 100 times (perhaps even more). In this case IEnumerator and IEnumerator<T> kind of break Liskov's substition principle because a derived Class should be handled differently than a base class. And this might be the case for any derived class Implementing IDisposable... So every Object that uses a Class and makes it go out of scope should always check if the Object is an IDisposable and call Dispose if it is (for example when using Factory Classes, instantiating a possible IDisposable Object, using that and then Disposing it). As my vague explanation proves I am no expert on IDisposable and memory management. But I hope you can understand some troubles concerning IDisposable :)
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
} -
The rule of thumb is fairly simple: explicitly dispose anything which uses restricted or unmanaged resources. If it's just memory then the garbage collector will grab it when appropriate, but if it's something that might run out or cause a problem before the garbage collector arrives (file handles and graphics resources are the usual ones, though I think graphics objects are cached or reused because I've written lots of things which don't Dispose local pens/brushes and never had an issue). The garbage collector will call Dispose as part of finalisation, so all your IDisposables will, eventually, get disposed – but quite possibly not in a time frame that you are happy with.
See my post below[^] for a reaction. I'm no expert, so I hope what I'm saying is true and at least somewhat clear ;p
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
} -
It's not quite that simple. What happens, for example, when a Disposable Object holds a reference to another IDisposable that might still be referenced by other Objects? Calling Dispose should Dispose of managed and unmanaged resources, while the GC can only free managed resources (something like that). So to properly clean all your Objects you should wrap unmanaged resources in managed Objects that Implements IDisposable and have those Dispose in the Disposer of the Object that uses it and always call Dispose, which might dispose Objects that are still referenced... *Head explodes* ... ... Just believe me, it's not that simple ;p Just think of this. IEnumerator does not Inherit from IDisposable, IEnumerator<T> does. This basically means that IEnumerators are (probably) NOT properly disposed even though they Implement IDisposable. IEnumerator<T> is ALWAYS disposed even though you won't need it 99 out of 100 times (perhaps even more). In this case IEnumerator and IEnumerator<T> kind of break Liskov's substition principle because a derived Class should be handled differently than a base class. And this might be the case for any derived class Implementing IDisposable... So every Object that uses a Class and makes it go out of scope should always check if the Object is an IDisposable and call Dispose if it is (for example when using Factory Classes, instantiating a possible IDisposable Object, using that and then Disposing it). As my vague explanation proves I am no expert on IDisposable and memory management. But I hope you can understand some troubles concerning IDisposable :)
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
}Naerling wrote:
Just believe me, it's not that simple ;-P
I know that. That's why it is a good practice to give some object control over the lifecycle of other objects, from instantiation to destruction. It's the idea behind more or less abstract class factories. When disposing, a class should simply clean up whatever is under its own control and leave all objects under another control of another class alone. Such problems only arise when objects are instantiated on the fly and passed around without some other object feeling responsible for it. As to your other example: Is IEnumerator really derived from IEnumerator? Or are they just two different interfaces which share some similarities? Anyway, don't confuse Dispose() with Finalize(). Every object has a finalizer, Dispose() only adds the capability to do the finalization at a time of your choice long before the garbage collector does finalize an object before removing it. Not disposing an object does little harm as long as you can afford to wait for some resources until the garbage collector has freed them.
-
Marc Clifton wrote:
a deeper understanding of what it is we're doing
I think that's key to becoming a good programmer! I work at a company that went from a custom DB tool someone wrote once to a quick flirt with "typed datasets" to Entity Framework. As a result none of my colleagues knows how to use DbConnection, DbCommand and DbAdapter Objects... It's the first thing I started to explore when we switched to typed data sets. I also found out they were not as "typed" as we believed. I didn't want to work with those typed data sets, so I started using DbCommand Objects out of protest (yes, I am that kind of guy. It was only a prototype project anyway). It was not in vain since we now use Entity Framework 4.0. Although it took an MVP to convince my employers what I had been saying for weeks... :~ Knowing what's going on keeps you from making wrong decisions or choosing tools you don't need.
Marc Clifton wrote:
I'm mainly into looking at the idea of making relationships more first class citizens
Interesting idea. Can we expect an article on that anytime soon? :)
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
} -
Naerling wrote:
Just believe me, it's not that simple ;-P
I know that. That's why it is a good practice to give some object control over the lifecycle of other objects, from instantiation to destruction. It's the idea behind more or less abstract class factories. When disposing, a class should simply clean up whatever is under its own control and leave all objects under another control of another class alone. Such problems only arise when objects are instantiated on the fly and passed around without some other object feeling responsible for it. As to your other example: Is IEnumerator really derived from IEnumerator? Or are they just two different interfaces which share some similarities? Anyway, don't confuse Dispose() with Finalize(). Every object has a finalizer, Dispose() only adds the capability to do the finalization at a time of your choice long before the garbage collector does finalize an object before removing it. Not disposing an object does little harm as long as you can afford to wait for some resources until the garbage collector has freed them.
CDP1802 wrote:
Is IEnumerator<T> really derived from IEnumerator?
Yes, I wrote an article[^] about it (didn't go into the IDisposable 'detail' though). Check the picture in the "Enumerator" sub-section. :) As of the rest of your post, neither Finalizer nor Dispose clean up unmanaged resources unless you call Dispose from code. "The .NET garbage collector manages the memory of managed objects (native .NET objects) but it does not manage, nor is it directly able to clean up unmanaged resources."[^], which is also in the article I linked a few posts up. The article I just linked gives the example of a DB connection. Should an Object keep an (unmanaged) DB connection open until Dispose is called this will not be closed when you simply wait for the GC. That's why managed wrappers around unmanaged code are absolutely necessary! You can see however, that if IEnumerator would open up a connection and close it in a Dispose method Dispose is probably not called when iterated over the Enumerator (unless Microsoft checks for any Enumerator if it is also IDisposable). Where would you call Dispose now? Now keeping a connection open like that may not be the best practice, but this sort of thing is exactly why IEnumerator<T> DOES Implement IDisposable. So did I understand some stuff wrong and is it not, in some cases, absolutely necessary to call Dispose explicitly (where this is not always easily possible)?
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
} -
Naerling wrote:
Can we expect an article
Indeed!
Naerling wrote:
anytime soon?
Aye, there's the rub! Marc
Good news! And I'm not in a hurry. Lots of other stuff to keep me busy :)
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
} -
Isn't that simple? You need a 'destructor' as soon as your class holds any additional resources like open file handles or everything that has to be created with 'new' (= memory). In a managed language like C# you can simply make a habit of using Dispose() to 'close' (where possible) and then dispose (also where possible) all objects held in the member variables of your classes. And in 'normal' methods you should always think a second about letting a local object simply go out of scope or properly disposing it. Cleaning up an opened file stream, for example, avoids problems when the file has to be accessed again before the garbage collector has taken care of the last object used to access the file. In C# this is a covenience to properly free those resources long before the garbage collection does so. In C++ this is a must, unless you like memory leaks or inaccessible files.
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse.CDP1802 wrote:
Isn't that simple? You need a 'destructor' as soon as your class holds any additional resources like open file handles or everything that has to be created with 'new' (= memory). In a managed language like C# you can simply make a habit of using Dispose() to 'close' (where possible) and then dispose (also where possible) all objects held in the member variables of your classes. And in 'normal' methods you should always think a second about letting a local object simply go out of scope or properly disposing it. Cleaning up an opened file stream, for example, avoids problems when the file has to be accessed again before the garbage collector has taken care of the last object used to access the file.
Doesn't sound simple to me and I'm pretty sure there's more to the story but I might be wrong as its a long time since I've had to look into the subject.
-
The last year I have been programming WinForms most of the time. I recently started doing some WCF too. I tried doing some WPF (but got distracted by F#). So I was doing F#, but got distracted by some cool WinForms designer stuff I didn't know yet... And back at WinForms I was. And that's basically how I've been going around in circles. There is a lot to learn when programming WinForms, but it is a somewhat outdated technology. I feel I should be doing WPF, but F# looks really nice too. I also wanted to do some C++ (which I did for about two evenings) because I want to know a bit more about why some stuff is how it is (and a lower level language seems like a good way to learn). Knowing more about pointers and memory management has my special interest. But that won't help me in WPF or WCF or F# or... And now we're going to use Microsoft Enterprise Library at work too, so I am supposed to do some of that too! There is just so much to learn (old and new) and there is more coming still! I was just curious, are people here currently learning some new language, technique, framework etc.? And why? For all the people who are going to shout "No programming questions in the lounge!", this is NOT a programming question. It's a question about programming :)
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
}Android all the way, baby! After almost 20 years of Turbo Pascal, C#, then a little Java, I'm "all about" Android now, and expect to be for years to come.
-
The last year I have been programming WinForms most of the time. I recently started doing some WCF too. I tried doing some WPF (but got distracted by F#). So I was doing F#, but got distracted by some cool WinForms designer stuff I didn't know yet... And back at WinForms I was. And that's basically how I've been going around in circles. There is a lot to learn when programming WinForms, but it is a somewhat outdated technology. I feel I should be doing WPF, but F# looks really nice too. I also wanted to do some C++ (which I did for about two evenings) because I want to know a bit more about why some stuff is how it is (and a lower level language seems like a good way to learn). Knowing more about pointers and memory management has my special interest. But that won't help me in WPF or WCF or F# or... And now we're going to use Microsoft Enterprise Library at work too, so I am supposed to do some of that too! There is just so much to learn (old and new) and there is more coming still! I was just curious, are people here currently learning some new language, technique, framework etc.? And why? For all the people who are going to shout "No programming questions in the lounge!", this is NOT a programming question. It's a question about programming :)
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
}Currently I'm sticking with C#, brought onboard from C++ in order to do do XNA with a detour for WinForms. And, of course, C preceeded the C++. I'd love to be able to do it all but there's no time to handle it all. And not being in a programming shop I have no cohorts off of whom I can feed. So I stay with the do-it-all for me.
I'm not a programmer but I play one at the office
