The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
You want this book[^]. Next, you want to download the free community edition of Visual Studio, so you can try the examples for yourself. Don't download examples to run them - copy them from the book and type each line.
I want to see creations come to life.
You'll need to invest some time in learning the basics, which may be tedious at points.
It is well worth it though
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
which is the most skillful and practical in the real world to learn and put to use?
Nowadays developers are expected to know several languages so there really is no one language that you will jsu be able to settle on.
That said As other have recommended - C# is a good starting point.
Learning C# will give you a good basis for other languages.
I would also say that whichever programming language you learn also learn some form of SQL at the same time.
I recommend that ALL programmers learn Assembly language first, followed by C, and then branching out o the "simple" languages.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
That was one project I had in college, not to actually load but to pseudocode it out. It was one I didn't finish.
Wife had a miscarriage at the time didn't help the brain to function. We did eventually have 3 kids and the oldest is pregnant with our first grandchild, due at the end of August so no condolences needed.
I recommend that ALL programmers learn Assembly language first,
Back in the 80s I tried my hand at assembly. At the time my only programming experience was with TI Basic on a little home computer. After a few days (daze) I finally managed to put a 8x8 colored square on the TV screen. That was the end of my "career" with assembly.
Sometimes the true reward for completing a task is not the money, but instead the satisfaction of a job well done. But it's usually the money.
The best way to begin a career in programming is to train your brain. One of the best books I read and worked through towards that goal was Structure and Interpretation of Computer Programs. The language Scheme[^] isn't the most important part here, but rather learning how to use that grey matter in your noggin to solve problems.
"I had the right to remain silent, but I didn't have the ability!"
Easy there.. that's decent learning.
People stopped doing that a while ago.
I don't think people have the patience for C++ anymore. At least not as a first language.
I still remember trying to figure out pointers when I was 12. Good times.
First time I ever yelled at a computer screen, a book, and cursed the gods.
At that age, it was a brand new concept I couldn't relate to anything.
When I understood the "how", I did still question the "why" for many years, up until the point where I learned about CPU-registers.
At it's core, it's a conceptual necessity based on the way we build our chips.
Even today I still think pointers are fundamentally pointless.
I'm not into religion really. I get the appeal, see the merit, but the custodians for each religion register as a threat to me.
I only appeal to the gods because it's biologically wired into human nature, and I'm not so obtuse as to fight my own nature.
It's stock-OS brain functionality. I'm not wasting any of that.
OO and OO are different things. I believe that simple use of OO is great for a beginner. The problems come when some code wizard comes to show all the superfancy ways you can use the most intricate details of advanced OO to do things that only code wizards will understand
I was coding C++ for a number of years, before taking over a couple of C# projects. Then, after a few years, I picked up one of my old hobby C++ projects, and got terribly frustrated: I had completely forgotten about all those messy details, having nothing to do with solving the problem, but with initialization / setup, heap management and lots of other stuff. I felt as if I had to search through an intertwingled mess of really not relevant code details to find the real problem solution parts.
So my vote goes for C# rather than C++. It also gives you basic OO "for free"; there is no way to do C# without objects - but it doesn't have the cost that it does in C++. I'd also say that Visual Studio support for C# is better than for C++, but that is partially because the language (read: the lack of explicit pointer handling) makes it easier to provide better support.
In one respect I fully agree with you: Especially for a beginner, a compiled language is essential. Then entire program code must be syntactically checked (and as far as possible, semantically checked) before any execution - that is a great help for a beginner. And the continous syntax checking while editing, done by VS, is a great help to reduce the compilation errors. So, thumbs up for compiled, strictly typed languages.
The reason I push for procedural at first is that the student needs to understand HOW the code does what it does. The single biggest problem I've seen with students who learn managed object-oriented languages first is they don't understand memory management.
For a hobbiest, C# is probably the best way to go. For someone looking at a career, what C/C++ teaches you about how computers work is invaluable. It gives you a solid foundation to effectively move to more abstract languages.
(Incidentally, several years ago, I had started to transition from C++ to C#, especially for one-off utilities. Then C++11 came out and resolved enough points of frustration that I went back to C++ save for one project. Except, toward the end of that one project, I encountered enough serious pain points with C# that I regretted not "porting it" to C++. This is not the first time, C# led me to the edge of a cliff and then said "adios.")
I meet a lot of newly educated C++ "experts" in my work. Most of them know very little about "HOW the code does what it does". They have no idea how a compiler operates, how optimization is done, how a stack is managed. They know about high level language constructs, not of the generated code. Unrolling the stack on an exception? No clue! Interrupt handler operation? No clue. OS service activation methods, with the necessary raising of privilege level etc? No clue. How OO is implemented - the class object, multiple inheritance, virtual methods, ...? No clue. They (think that they) know how it works at the object level, not at the code level. How is memory allocated for a dozen of threads in the same address space? How does the system clean up allocated resources when a thread, or a process terminates? (You do not free() the thread stack, or file control blocks, or I/O buffers!)
I learned OO concepts by studying how the C++ compiler produced K&R C source code that could be compiled on any machine. Noone does that today. C and C++ programmers alike: Tthe know more of how the job market works than how a computer works at the instruction set / register / interrupt / MMS level. Or at the system level. I commented to one of the youngsters that the elevator in our office building doesn't run a propoer elevator algorithm; it may turn even if there are other users at higher/lower levels. Elevator algorithm - huh? Once I referred to excption propagation through the dynamic or static link - they had never heard about 'static link'- this was in a discussion of abandoned languages that do have a static link; that was completely new to them. And so on. Beliving that youngsters know memory management because you stress to them what comes up (of malloc) must come down (to free) doesn't teach them how memory is managed.
They know of constructors and destructors, but not of the code behind those. And seriously: Programmers haven't had to understand compiler code generation and hardware addressing modes for a generation. Why should the average student have to know about buddy allocation an firstfit/bestfit and memory compaction, more than of different instruction set addressing methods?
Students are relieved of understanding jump instructions by high level 'for' and 'while' loops and switch statements. There is no real reason why they should spend much more attention to memory management (until they become far more advanced). The only 'excuse' is that when programming in C++, you certainly should know it! In languages with automatic memory management, it isn't an issue at all, at least not until you become quite advanced. For a beginner, it is inessential.
Fifteen years ago I gave up my confidence in assembler code for fine tuning, as I gradually accepted that all modern compilers know far more smart tricks than I do. Five years ago, I spent some time in learning how dotNet memory management works, and again and again I said to myself: Gee, I'd never have thought of that. And dotNet manages it at a binary byte level - if I were to do it 'by hand', I'd have to use a load of explicit type casts, not generating much machine code (casting doesn't) but certainly a lot of source code. And the best I could do was to detect if a program made a memory allocation mistake, and report it - I couldn't handle it.
So I realized: Just like machine code addressing modes is the responsibility of the compiler, memory management is the responsibility of the runtime system. It can handle it far better than I can, and I am a seasoned programmer.
I learned OO concepts by studying how the C++ compiler produced K&R C source code that could be compiled on any machine.
I learned C by looking at the assembly code produced by Turbo C. (On day 2 I realized that C is just a really nice macro-assembler!)
Member 7989122 wrote:
Fifteen years ago I gave up my confidence in assembler code for fine tuning,
About 20 years for me, when I was able to get a wave compressor to run within 10% of the speed of my assembly code. I've revisited assembly to write bootstrap code and to see what code is sometimes really doing, but otherwise I've only "used" it with some SSE intrinsics.
Member 7989122 wrote:
memory management is the responsibility of the runtime system
But at least you know the implications of large allocations (in .NET) and why not to do "stringval += something" in a loop!
A programming language is just a tool. Learn how to problem-solve first, then pick up the tool best suited for the problem. Universities these days are teaching how to solve problems by learning a programming language. Using that mindset, once the problem changes, the student is lost.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
I don't know of very many designed languages - and those I know of, has more or less flopped.
Now, I don't mind that Ada flopped; it was a mastadont both conceptually and implementation-wise.
APL is so curious that you never could expect it to succeed (but it wa fun to play with )
But I miss CHILL... A really well-designed language: Lightweight, yet with all the facilities for multi-threaded programming designed into the language. Clean exception handling. A type ("mode") system that beats almost any other language. Some details of the flow control structures that makes it great. Syntax is very well suited for catching errors, even semantic ones. Especially considering that the first version was standardized as early as 1980 makes it a remarkable language.
There are other designed languages as well, but the vast majority are evolved languages. Some, like Python, may not have done all the evolution steps by themselves but adopted large parts of their syntax from its predecessors, which have been through a significant evolution. It is not like the designers brought up a pile of blank sheets, agreeing "Let's do it right from the very beginning, this time!" - more like adding and removing features from an old language so much that it ends up as a "new" language.
Last Visit: 31-Dec-99 19:00 Last Update: 27-Feb-21 21:54