|
Well, with you recommending Troy Hunt's series, which is using your article, you are giving yourself a non-biased pat on your back. That is flattery of the second order, good stuff
|
|
|
|
|
I've seen it mentioned a couple of times here on CP, "language [x] is just a tool that gets a job done. Use the right tool for the right job."
But how many of you actually know more than one or two languages that don't look like each other?
And how many of you actually consider different languages before starting a project?
I've been using C# and SQL Server which are both pretty all-round. So basically any project could probably be written with those tools. And in my experience every project will be written using those tools because that's what we know. Sure you'd use Objective-C or Swift if you'd write an app for iOS and Java for Android, but that's more of a necessity than a choice.
But where I've worked we made the problem fit the tools instead of vice versa.
Perhaps Haskell was a better tool for a project I've written in the past. I wouldn't know because I'm not that familiar with Haskell. And maybe Mongo was a much more obvious choice if I knew more about Mongo, but I don't.
So how many of you actually do use different languages for different projects because those languages better suit that project?
And how many of you consider yourself knowledgeable enough to make such an informed decision? (you all do, of course )
Myself, I try to keep up-to-date with what options are available, and I occassionally recommended another language, database or library for some problem, but I'm not quite in a position to make such decisions at work...
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
Were the deadline a little less tight I may try something different (like MEAN, or Java), depending on the project.
My blog[ ^]
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
These days, I mostly use C# (with some SQL, of course)
But that's down to "it just works" and it allows me to reuse my existing code base of utilities and such like.
But when I was doing a wider range of projects, I considered which language(s) to use pretty carefully: Assembler, C and / or C++ was the norm for me.
I guess it's down to environment to a large extent: if you are coding Windows apps and know C#, why would you bother with Java?
If you want to code Android or iOS (and don't want to give a large chunk of money to Xamarin) then you'd probably consider Java or ObjectiveC.
I must get round to learning Java / Android one day soon (But I've been saying that for over two years now... )
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Almost everyone I know wrote/said: I must get round to learning [x] one day soon (But I've been saying that for over [y] years now... )
I've got a lot I want to do. I still need to finish my blog about web programming. I started a series of blogs, but I've been busy these last months moving into my own house, making it livable and also starting out for a new employer and studying to get up-to-speed.
I want to do something MEAN before the summer and after that maybe look into graph databases and Neo4j specifically. Not because I need it, but because it's something else than what I'm used to
OriginalGriff wrote: Assembler, C and / or C++ was the norm for me. I must get around to learning those...
My blog[ ^]
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
I almost never get to pick the language for the project. Currently I use a mix of C++ (core code), SQL, Python (tests) and JavaScript (front-end). On my previous job it was mostly C# + JavaScript + PowerShell.
|
|
|
|
|
SSIS is a tool I use a lot though I wouldn't consider it a language.
I have used DCL (Digital Command Language, scripting on OpenVMS) quite a bit in the past.
I also used Procomm scripts for a few tasks long ago. The last time was in 2004, but I eventually wrote my own scripting language for that job. CommScript[^]
Most things I need to do just require an ordinary work-a-day language and any will pretty much do. Currently I prefer C#, but I have had employers who specified C, Perl, or VB.net .
|
|
|
|
|
PIEBALDconsult wrote: VB.net I have a few reasons to love/hate this language
It's my first, but even compared to C# there's some stuff I like about it.
I understand all the hate, but I can truly say knowing VB.NET makes me a better programmer
Your CommScript article looks really nice! It's not something I'd currently need, but I've bookmarked it just to read it sometime
My blog[ ^]
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
I can understand icon for VB6, but what did VB.NET do to earn this?
Sure, it looks a lot like VB6, but it behaves (and compiles into same ILM) as C#. I'm seeing lots of bad code in QA forum which are mostly in C#...so what gives?
Why not C# ?
It has worst "feature" of any language - its keywords are case sensitive. For years it had worse debugger then VB.NET and is still catching up in some areas (returns of functions in Watch window), it still has worse autocomplete / intellisense.
Note that I work in C# out of necessity and VB.NEt out of preference. VB6 and VBScript when I have to (and I hate it) - so I know what I'm talking about. Do you?
|
|
|
|
|
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.
|
|
|
|
|
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 namespace
Bear 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 Namespace
Notice 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
|
|
|
|
|
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?
|
|
|
|
|
The nature of the work has dictated c# and SQL, now that the nature is changing I find I am way too focused on those tools.
Thankfully we have a senior dev who does have a wide appreciation of the tools out there. Saved my bacon .
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
For personal projects I generally have 3 categories: GUI-based Windows programs where I use VB.NET, console (or occasionally GUI) programs where I use C++ for cross platform compatibility, and web projects where I use PHP/HTML/SQL.
Those languages work absolutely fine for 99% of the applications I want to make. Of course, the main reason why you would want to use another language is because you don't get to decide, but then it all becomes moot.
|
|
|
|
|
I stick to just the bare essentials. C#, Java, Javascript, HTML, CSS, Ruby, SQL [My SQL or SQL Server], Mongodb, freemarker and a scatter gun approach to scripting.
veni bibi saltavi
|
|
|
|
|
I worked for a fire alarm manufacturer in the late 1980's, at a time when you absolutely had to fit 10 lbs of code+data into a 5 lb E2PROM.
The project leads chose to implement an extraordinarily tiny, elegant, and fast, FORTH kernel/interpreter and made the rest of us do the main implementation using that mind warping stack-based RPN.
We all balked and bitched and chewed our fingernails, but in the final analysis, we would not have been able to fit everything in that had to be there.
Now, the kernel was elegant, tiny, and fast in and of itself. But overall, the performance of the system as a whole sucked.
Coming from the lab was a constant, "c'mon baby! c'mon baby! c'mon baby! YEAH!!!" It was like standing outside the fence listening to an orgasm festival.
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?
|
|
|
|
|
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
|
|
|
|
|
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?
My blog[ ^]
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
|
|
|
|
|
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 ).
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?
My blog[ ^]
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 file, LOL).
The case being that the environment determines the right tool for the job, as you mentioned.
But honestly, most decent programming languages can do it all. It is a matter of effort,
and understanding of how to solve the original problem...
HTH,
Kirk Out!
|
|
|
|
|