The right tool for the job...
-
The "right" tool for the job depends a lot on the job and its requirements. For me at work, the ability for others to be able to maintain it is an overriding (unstated) requirement, so the answer is always C#.
Sander Rossel wrote:
Should I be made responsible for a project with a tight deadline I'd go with... C# and SQL Server, because, well, that's what I know
Which makes C# and SQL the right tool for such a job -- the time pressure requirement forces you to choose tools you already know how to use.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
I've always found that a bit of a stretch... Sure, code should be maintainable by others than yourself, but if everybody thought that way we'd still work in FORTRAN, because that's what everybody knows (at least 50 years ago), right? So yeah, go with what you know, but let's say I'd have to make a web app and I'm a WinForms developer, and in fact this happened at my previous job. Would I try and make it work in WinForms (good luck with that :) )? Would I turn down the job (and risk that the client takes ALL his business elsewhere)? Would I hire a third party and lose some control (what we chose to do, which turned out alright after it first turning out a little less alright :laugh: ). Or would I actually consider something else than WinForms! Or maybe you already did C# web, but you need a real-time web app. Would you consider node.js? Sometimes it's just not worth the hassle, but if you can get new clients or keep old ones I think looking at some other languages, databases or frameworks may certainly pay off. And if you're a bit of a developer a new language shouldn't be THAT much of a problem, right? ;)
patbob wrote:
the ability for others to be able to maintain it is an overriding (unstated) requirement
I worked at a C# company where I could write C# that no one could maintain anyway (and let's just assume because I used libraries or techniques no one knew, not because I wrote spaghetti) :) And that same goes for SQL. I'm writing SQL because it gets my data FAST and I'm not so much worried about what other people know. My job is to write good software for the customer and know how to write that. I assume my coworkers know this too. Although it has been a problem in the past that, apparently, they didn't... Would you build a straw house because some (or all) people in the team don't know how to use bricks?
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
} -
I take the opposite side of that argument. I once interviewed for a Clipper (Summer of 87) job, having had no Clipper experience, and little dbase experience. My argument was that that FIRST job of a developer should be to correctly identify the problem being solved, and then identify the right solution for the job. After that, the language the solution is written in, is about syntax. And Clipper had a suitably generic syntax. If I solve the problems perfectly, and implement them correctly, with testing and verification. Then over time, the stability should prove itself. I won the job, and over the course of my employment, coded myself out of a job. For the first time since the system went live, they did not need a programmer to fix things, and correct reports, etc. etc. It just worked. So, at ONE end, I could care less about the language (Currently I am working with Cobol, RPG, CL, PHP, Oracle PL/SQL, SQL, ASP, and Delphi) for clients. Meaning, I will hit each of these tools this week and every week for the next few months. Some more than others. On the other hand, I have a gazillion lines of Delphi code, and tools and components, and I will gladly shoe horn a project into that environment, if it is gui/db based because my tools there rock. I am in the minority here, in that I don't use Visual Studio unless it is required (it has been a couple of years, maybe 4)... I consider myself a bit of a craftsmen. Obviously I don't write parsers/compilers in Cobol. And delphi programs have a tough time running on an as400 or an AIX box. So at some point the language needs to be suitable to the problem. In fact, I needed a DB+parsing solution for the 400... I used Delphi + ODBC. It was a quick and dirty program to generate test data. I find NOTHING wrong with using one tool for a lot of stuff... The real question I like to ask is: Do you REALLY have 5 years of experience with the tool, or do you have 1 year of experience, 5 times in a row? Do you look for new ways to attack problems with your tools? Have you used/analyzed C# Excel code to realize you should be using ANYTHING but COM to control Excel? (We had a 4hr report down to 15 seconds when we stopped using COM, and used an Excel generator Object). I think knowing your ONE tool very well makes more sense than being a generalist. Do I create Cobol programs from scratch.. No. I maintain someone elses code, or I debug it and find the performance issues. (And nobody writes Cobol from scratch, they copy an existing fi
Kirk 10389821 wrote:
I think knowing your ONE tool very well makes more sense than being a generalist.
Kirk 10389821 wrote:
Currently I am working with Cobol, RPG, CL, PHP, Oracle PL/SQL, SQL, ASP, and Delphi
That's kind of contradicting... :rolleyes: I agree that there's at least one or two languages that you should know very well. Without knowing something very well you could never write good solutions. But being a generalist helps you in knowing what's out there and may actually help you get better at the thing you're very good at. I really started appreciating and understanding LINQ when I dabbled in functional programming. And because I dabbled in functional programming I can question solutions written in C# that I never would've questioned before. I started looking at SQL completely different after I had tried NoSQL and I could understand the strengths and weaknesses of SQL much better. I've worked with people who didn't want to know more than C# because that was what they did and that's what they wanted to be really very good at. One of them even refused to do any database work, because it wasn't C#. With such an attitude I can't even take those people seriously (and that person can't ever create an app all by himself because he doesn't know SQL) :)
Kirk 10389821 wrote:
that FIRST job of a developer should be to correctly identify the problem being solved, and then identify the right solution for the job
No language, database or framework could help you if you didn't have that particular skill! And boy do few programmers have it... :sigh:
Kirk 10389821 wrote:
coded myself out of a job
Always leave a bug in the software and occassionally introduce new ones! :laugh:
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
} -
Kirk 10389821 wrote:
I think knowing your ONE tool very well makes more sense than being a generalist.
Kirk 10389821 wrote:
Currently I am working with Cobol, RPG, CL, PHP, Oracle PL/SQL, SQL, ASP, and Delphi
That's kind of contradicting... :rolleyes: I agree that there's at least one or two languages that you should know very well. Without knowing something very well you could never write good solutions. But being a generalist helps you in knowing what's out there and may actually help you get better at the thing you're very good at. I really started appreciating and understanding LINQ when I dabbled in functional programming. And because I dabbled in functional programming I can question solutions written in C# that I never would've questioned before. I started looking at SQL completely different after I had tried NoSQL and I could understand the strengths and weaknesses of SQL much better. I've worked with people who didn't want to know more than C# because that was what they did and that's what they wanted to be really very good at. One of them even refused to do any database work, because it wasn't C#. With such an attitude I can't even take those people seriously (and that person can't ever create an app all by himself because he doesn't know SQL) :)
Kirk 10389821 wrote:
that FIRST job of a developer should be to correctly identify the problem being solved, and then identify the right solution for the job
No language, database or framework could help you if you didn't have that particular skill! And boy do few programmers have it... :sigh:
Kirk 10389821 wrote:
coded myself out of a job
Always leave a bug in the software and occassionally introduce new ones! :laugh:
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}If you think about it, your choice of tool (language) is totally dependent upon what you have available in the toolbox. When I started in the industry, there were only six languages, now there's over 2000. I follow the approach of examining the problem, developing a number of approaches to a solution and selecting the best approach. Part of that solution development and selection process is an examination of the tools in the toolbox. I don't profess to know every language, but I know enough to understand the structure/syntax of the languages to carry a meaningful conversation with the programmers while trying to explain the concepts and objectives of the client. Yes, I'm an old dog, but I still enjoy new tricks.
The difficult may take time, the impossible a little longer.
-
VB.net is too permissive.
Sinisa Hajnal wrote:
its keywords are case sensitive
Yes, that's a good thing.
Sinisa Hajnal wrote:
compiles into same ILM
That doesn't matter.
Sinisa Hajnal wrote:
it behaves as C#.
Except when it doesn't.
I would argue that case sensivity is worst language part. VB.NET is too permissive if you let it be. I always have option strict on turned on and it behaves as it should. Default is stupid nod to the past so that those who rewrite VB6 apps can go over without too much trouble. Compiling same ILM matters (ease of translation if nothing else), as you would know first time you have to work in mixed company (VB.NET and C#) with C# guys being harder of the two - they know what they know, they will not change or adapt. Luckily, you get DLL from them which you can use without problems. Same with services written in VB.NET that they invoke from C#. As for "it behaves as C# except when not" - it is easy to say, give me an example. 9 cases out of 10, you'll be talking simply about something that YOU don't know how to do in VB.NET. And I'm again trying to educate C# guys and starting a flame war. Sorry about that, last post on this.
-
MikeTheFid wrote:
a fire alarm manufacturer
MikeTheFid wrote:
the performance of the system as a whole sucked
So the alarm wouldn't go off until the whole place was burned to the ground? :laugh:
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}Quote:
So the alarm wouldn't go off until the whole place was burned to the ground?
No, not quite that bad. Occasionally one sees in a tele program or a movie someone pulling a red pull-station on the wall and the evacuation signals sound instantaneously. Well signals never sound instantaneously on any system, but on that particular system, it could take 5 to 10 seconds (an eternity, granted) for all signals correlated to the input to sound. In some jurisdictions that did not meet local codes. Don't get me wrong. The system was absolutely reliable and the performance issues were eventually fully resolved. :)
Cheers, Mike Fidler "I intend to live forever - so far, so good." Steven Wright "I almost had a psychic girlfriend but she left me before we met." Also Steven Wright
-
MikeTheFid wrote:
listening to an orgasm festival
They still had those in the 80s? :confused:
I was channelling a previous incarnation from the time of Caligula (~35 AD). :)
Cheers, Mike Fidler "I intend to live forever - so far, so good." Steven Wright "I almost had a psychic girlfriend but she left me before we met." Also Steven Wright
-
I would argue that case sensivity is worst language part. VB.NET is too permissive if you let it be. I always have option strict on turned on and it behaves as it should. Default is stupid nod to the past so that those who rewrite VB6 apps can go over without too much trouble. Compiling same ILM matters (ease of translation if nothing else), as you would know first time you have to work in mixed company (VB.NET and C#) with C# guys being harder of the two - they know what they know, they will not change or adapt. Luckily, you get DLL from them which you can use without problems. Same with services written in VB.NET that they invoke from C#. As for "it behaves as C# except when not" - it is easy to say, give me an example. 9 cases out of 10, you'll be talking simply about something that YOU don't know how to do in VB.NET. And I'm again trying to educate C# guys and starting a flame war. Sorry about that, last post on this.
Sinisa Hajnal wrote:
case sensivity is worst
Case insensitivity made sense when we used punch cards, teletypes, or early terminals that didn't support lowercase anyway. Now it only leads to confusion and increased compile times.
Sinisa Hajnal wrote:
I always have option strict on
Does that disable the ability to leave off the parentheses on method calls?
Sinisa Hajnal wrote:
Compiling same ILM matters
Consider these two simple programs that execute the exact same statement. Do they produce the same IL? Do they behave the same?
namespace EnumTestCS
{
public static class EnumTestCS
{
public static void Main()
{
System.Console.WriteLine ( System.Text.RegularExpressions.RegexOptions.None ) ;
}
}
}namespace EnumTestVB
module EnumTestVB
sub main
System.Console.WriteLine ( System.Text.RegularExpressions.RegexOptions.None )
end sub
end module
end namespaceBear in mind what the MSDN documentation says: " The return value is formatted with the general format specifier ("G"). " -- https://msdn.microsoft.com/en-us/library/16c1xs4z(v=vs.110).aspx[^]
Sinisa Hajnal wrote:
something that YOU don't know how to do in VB.NET.
While I may be the only person in the world who needs to do this, show me how it can be done in VB.net .
namespace EventTest
{
public class EventTest
{
public delegate int F() ;
public event F E ;
private void RaiseE() { E() ; }
}
} -
Sinisa Hajnal wrote:
case sensivity is worst
Case insensitivity made sense when we used punch cards, teletypes, or early terminals that didn't support lowercase anyway. Now it only leads to confusion and increased compile times.
Sinisa Hajnal wrote:
I always have option strict on
Does that disable the ability to leave off the parentheses on method calls?
Sinisa Hajnal wrote:
Compiling same ILM matters
Consider these two simple programs that execute the exact same statement. Do they produce the same IL? Do they behave the same?
namespace EnumTestCS
{
public static class EnumTestCS
{
public static void Main()
{
System.Console.WriteLine ( System.Text.RegularExpressions.RegexOptions.None ) ;
}
}
}namespace EnumTestVB
module EnumTestVB
sub main
System.Console.WriteLine ( System.Text.RegularExpressions.RegexOptions.None )
end sub
end module
end namespaceBear in mind what the MSDN documentation says: " The return value is formatted with the general format specifier ("G"). " -- https://msdn.microsoft.com/en-us/library/16c1xs4z(v=vs.110).aspx[^]
Sinisa Hajnal wrote:
something that YOU don't know how to do in VB.NET.
While I may be the only person in the world who needs to do this, show me how it can be done in VB.net .
namespace EventTest
{
public class EventTest
{
public delegate int F() ;
public event F E ;
private void RaiseE() { E() ; }
}
}PIEBALDconsult wrote:
Case insensitivity made sense when we used punch cards, teletypes, or early terminals that didn't support lowercase anyway. Now it only leads to confusion and increased compile times.
Except when it is autocorrected to proper case by intellisense and DOES NOT cause strange uncaught errors because you were stupid enough to call a property Name, private variable name and a constant NAME. Instead, you write name, intelisense gets the best match (or asks you while you type) and voila!
PIEBALDconsult wrote:
Does that disable the ability to leave off the parentheses on method calls?
Yes. Intelisense adds the parentheses for you. I must admit, I never even considered doing it without parenthesis nor I knew it is possible. As I said, there are nods toward VB6, it doesn't make it as bad.
PIEBALDconsult wrote:
Consider these two simple programs that execute the exact same statement. Do they produce the same IL? Do they behave the same?
They do not. Because you're doing it VB6 way instead of proper way which is:
Namespace EnumTestCS
Public NotInheritable Class EnumTestCS
Public Shared Sub Main()
System.Console.WriteLine(System.Text.RegularExpressions.RegexOptions.None)
End Sub
End Class
End NamespaceNotice that you compared class and module, which are not at all the same. This is CLASS with SHARED (static) method main. You could do it with a module ofcourse and I've done it like this, but it is not equivalent.
PIEBALDconsult wrote:
While I may be the only person in the world who needs to do this, show me how it can be done in VB.net .
Sure here it is:
Namespace EventTest
Public Class EventTest
Public Delegate Function F() As Integer
Public Event E As F
Private Sub RaiseE()
RaiseEvent E()
End Sub
End Class
End Namespace -
PIEBALDconsult wrote:
Case insensitivity made sense when we used punch cards, teletypes, or early terminals that didn't support lowercase anyway. Now it only leads to confusion and increased compile times.
Except when it is autocorrected to proper case by intellisense and DOES NOT cause strange uncaught errors because you were stupid enough to call a property Name, private variable name and a constant NAME. Instead, you write name, intelisense gets the best match (or asks you while you type) and voila!
PIEBALDconsult wrote:
Does that disable the ability to leave off the parentheses on method calls?
Yes. Intelisense adds the parentheses for you. I must admit, I never even considered doing it without parenthesis nor I knew it is possible. As I said, there are nods toward VB6, it doesn't make it as bad.
PIEBALDconsult wrote:
Consider these two simple programs that execute the exact same statement. Do they produce the same IL? Do they behave the same?
They do not. Because you're doing it VB6 way instead of proper way which is:
Namespace EnumTestCS
Public NotInheritable Class EnumTestCS
Public Shared Sub Main()
System.Console.WriteLine(System.Text.RegularExpressions.RegexOptions.None)
End Sub
End Class
End NamespaceNotice that you compared class and module, which are not at all the same. This is CLASS with SHARED (static) method main. You could do it with a module ofcourse and I've done it like this, but it is not equivalent.
PIEBALDconsult wrote:
While I may be the only person in the world who needs to do this, show me how it can be done in VB.net .
Sure here it is:
Namespace EventTest
Public Class EventTest
Public Delegate Function F() As Integer
Public Event E As F
Private Sub RaiseE()
RaiseEvent E()
End Sub
End Class
End NamespaceSinisa Hajnal wrote:
Except when it is autocorrected
The compiler doesn't know whether all the capitalization is consistent or not so it still has to check everything. Be aware that not everyone uses Visual Studio with all its gimickry and the compiler needs to cope with whatever it receives.
Sinisa Hajnal wrote:
you compared class and module
You missed the point. It's the WriteLine that matters. What's the output?
Sinisa Hajnal wrote:
Public Delegate Function F() As Integer
Try compiling that.
-
Sinisa Hajnal wrote:
Except when it is autocorrected
The compiler doesn't know whether all the capitalization is consistent or not so it still has to check everything. Be aware that not everyone uses Visual Studio with all its gimickry and the compiler needs to cope with whatever it receives.
Sinisa Hajnal wrote:
you compared class and module
You missed the point. It's the WriteLine that matters. What's the output?
Sinisa Hajnal wrote:
Public Delegate Function F() As Integer
Try compiling that.
Now that VS is free there is no reason not to use the best tool around. I really didn't check the output, can you enlighten me? I looked at the code, you cannot declare delegate that returns the value as event delegate. Excellent, you found one obscure point that cannot be done in VB.NET. If you look into LinkedIn forums you'll find several discussion about advantages and disadvantages of both. And examples that cannot be done in one and can be in the other (both ways). And it is always equally pointless. If you prefer C#, use it. Don't diss other languages - this is like saying that Java is bad because it doesn't have properties, you have to write getters and setters yourself. Yay. Lets just agree that C# sucks for me, VB.NET sucks for you and leave it at that. OK?
