How hard is C#? (1 Viewer)

prabha_friend

Prabhakaran Karuppaih
Local time
Today, 15:32
Joined
Mar 22, 2009
Messages
881
To learn, adapt and acquire the complete knowledge of it...
 
I never liked the C variants as a matter of style. I found it easier to read BASIC, FORTRAN, and PASCAL. Having said that, C is a procedure-oriented language with object-oriented programming as part of its range of applicability. If you can do VBA or VB6 programming, then the structures involved in C# are just a few steps more complex.

As to "complete knowledge of it" ... as long as the program is alive and viable, it will change, evolve, improve - probably faster than most of us can (or want to) keep up with it.
 
Depends.

If you know no computer languages, then it will take a bit.

If you only know HTML or CSS or SQL it will be slightly easier.

If you know just one other non-VB programming language, it will be a lot easier.

If you know a few other non-VB programming languages, it will be very easy.

If you are well versed in Visual Basic, then you're 95% of the way there already.
 
I think the hard part about a "complete knowledge" of C# is understanding how to structure your classes in a data-centric application. Access does not train us well in this regard, because we want to display our data immediately, directly queried from the database, in our UI. This is great for rapid development, but in a serious data-driven application you might write in C#, this is very poor design. Make one change with this short a distance between the database and the UI, and something will break, and it will break silently. If you are going to bother to write in C# and leverage its full capability for scalability, testability, reliability, encapsulation of business logic, etc, then you want a repository layer, a service layer, a data layer, a viewmodel layer, and finally your view, and I think making all these components work together is what you will find hard to get your head around.

And then there are asynchronous methods, commands, converters, and the list goes on...

Learning the syntax will be easy. Understanding what full-stack means, or what MVVM is, or whether a particular piece of logic should be performed in a command, or in the service layer, or in the viewmodel, that is hard.
 
According to Bill Gate C# is Visual Basic for snobs. He only had it created because IT professional demanded it. It's underlying engine is identical to VB.NET.
 
The reason I really don't care for it is that C's predecessor language (yes, it was called "B") was actually implemented using PDP-11 macro assembler. The syntax for -(x) or (x)+ comes direct from the auto-increment/auto-decrement features of the hardware. The language has evolved but originally, you had to run TWO utilities for compilation. First you ran LINT to clean up your language syntax... THEN you ran the real compiler. And you had to do it that way because the original compiler didn't have much in the way of data typing. Which meant you could end up with some syntax that looked more or less legal, but which would give you all sorts of data issues if you didn't fully understand the implications of the original programming paradigm.

Another reason is that we got to a point where I was contractually REQUIRED to use a different language than any C variant. In this case, when I had a possibility of using a C variant, we were required to work in PL/1-G. Talk about extremes... with early C variants you had almost no data typing in the compiler. With PL/1-G typing was so strong that two strings of different length were considered type mismatches unless you used a function to change the length of one of the string variables.
 
I am a VBA Developer and VB is no longer important in . NET core Era... That's why.
 
Just ran across this article. I have no opinion concerning this topic or how relevant the article is.
While C remains a powerful and popular language in certain contexts, its complexity and limited use in web and mobile apps — and lack of "coolness" — make it less appealing for many programmers today.
 
Past a certain point, and depending on whether the language is defined for general or targeted use (VBA is targeted; VB6 would be general), if it supports object-oriented programming to at least some degree and is a general-use language, ANY language is as good as any other, at least in terms of effectiveness. Now if someone would create a truly object-oriented COBOL, maybe I would hesitate on that one. But seriously, I've watched languages develop from the 1960s through 2020+. When any two languages originate from the same generation of languages, they are able to do the same sort of things. The proliferation of languages these days simply means that someone didn't like someone else's interface or something like that. Learning a new language CAN be necessary for employment if you are joining a pool of programmers who will ALL have to use the same language. But if language choice for a job is not an issue, use languages you already know if available.
 
Now if someone would create a truly object-oriented COBOL
Object oriented was never what it was cracked up to be. Lots of articles on the disappointment are available.

The task at hand should be what dictates the language used. This never used to be the choice of the programmer. It was always the choice of the programming manager because he understood the dialects available to his team and knew which features of a particular language were necessary for a task. It was only when COBOL lost out to C that it became clear that the inmates were running the asylum and it was time for me to leave the corporate IT world and embrace Access.

My team was usually conversant in COBOL, Fortran, and BAL and a couple of RAD tools. If we needed to twiddle bits, we used BAL which was the lowest level language available to us. We used this for Channel programs (code that controlled what passed between devices) and socket programs (TSR programs that captured data coming from other systems), although we could also use COBOL for those. Basic business application programs were always written in COBOL because it was the highest level language as well as the easiest to read and debug. If we had heavy computation requirements, we wrote Fortran subroutines. A lot of reports were written using a simple RAD tool.
 
Last edited:
To learn, adapt and acquire the complete knowledge of it...

Are you talking about c#.net?
I don't think it is any harder than VB* all flavors, and definitely more preferred in the corporate world.
Definitely encourage you to learn it if you want it - it is HIGHLY relevant to today's world!

Almost every company I have worked at or contracted at (8-10) during the last 15 years have a team doing c#.net work in heavy duty capacity

***Very relevant to be paired with SQL Server
 
I am a VBA Developer and VB is no longer important in . NET core Era... That's why.

Unfortunately, I tend to agree with you. That has been my experience in almost every company I've worked at or interviewed with in the last 10 years. VB.NET is definitely not the preferred .Net language in the corporate world
Every time I've told them I use vb.net for SSIS script tasks, they frown a bit and assure me it's OK, you can learn c# quickly :)
And the ratio of available jobs pairing c#.net with sql server vs. vb.net is 10:1
 
C can be challenging to learn initially, especially with pointers and memory management, but it's rewarding for understanding low-level programming. To get started, try Syntax Scenarios tutorials—they break down the basics of C syntax and key concepts with hands-on examples, making it easier to adapt and practice as you go.
 

Users who are viewing this thread

Back
Top Bottom