|
Second that.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Werd.
".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
|
|
|
|
|
When you are reading articles about the 'best' programming language to start with, you are about to get a list of popular-easy-to-learn-but-not-really-powerful languages...
But in truth the best language should be one that influenced them and has the complexity that will demand the use of your brain and will teach you ideas, that true for all languages... Only that way you will be able to move on to almost any language you may will have to use...
To anyone serious I would tell to go for C, otherwise turn the dice and pick you number...
(And 3 is not programming language, but a UI/UX language)
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
|
|
|
|
|
For a complete beginner? As the others said, I wouldn't suggest any of those.
Peter's suggestion of C is a good one, but ... it's an old language and suffers from a lot of problems as a result, particularly if you don't know what you are doing. Because it is pointer based and doesn't use strong typing, it's very, very easy to make big mistakes without knowing and have them not show up as bugs until a lot later.
Instead, I'd suggest C# - the language itself is pretty simple (though it's getting more complicated with each revision) and it's also very powerful. It's reference based and garbage collected which means that most of the problems with C have been designed out. It'll take a while to learn properly (because the .NET framework on which it depends is very large) but once learned it can be used to write websites, desktop app,s mobile apps, ... and it's a very popular language in the job market.
All the tools you need to develop apps is available free from Microsoft as well - Google for Visual Studio Community Edition Download and you'll find it. And there are loads of books and courses on the language as well, mostly starting from the "complete beginner" level.
Sent from my Amstrad PC 1640
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
None of the above - as OG said go with c#. However
sammygirl wrote: I want to do something related solving, building, not just dealing with data. I want to see creations come to life that seems to indicate you are not interested in LOB but some more esoteric area of computing. I suggest you define you goals more completely and then choose the tool appropriate to that path.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Another vote for C# here.
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.
sammygirl wrote: 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.
|
|
|
|
|
sammygirl wrote: 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.
If you have time also familiarise yourself with the Uncle Bob videos on youtube CleanCode Episode 1 - YouTube[^]
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
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
|
|
|
|
|
Sure, and write your own microkernel to load it while you're at it
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.
|
|
|
|
|
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.
|
|
|
|
|
MarkTJohnson wrote: due at the end of August so no condolences needed. Congratulations on almost being Grandpa!
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.
|
|
|
|
|
John Simmons / outlaw programmer wrote: 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.
|
|
|
|
|
Please see this answer:
/ravi
|
|
|
|
|
That's a really good list and summary of what we need to know as software developers - I still have a way to go on some of them
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
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!"
Ron White, Comedian
|
|
|
|
|
Start with Visual Studio Community Edition and C++ in a procedural way--that is, without objects.
|
|
|
|
|
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.
|
|
|
|
|
But the thing is, ALL programming has pointers at the core, even if we pretend they are something different.
(Of course, pointers in C can get very out-of-hand. If I see something like ***pointer[offset], my eyes glaze over.)
|
|
|
|
|
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.
Heh.
|
|
|
|
|
But definitely not that last huh, unless your job title now has 'of sales' in it =)
|
|
|
|
|
Wait, are you referring to cursing the gods?
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.
|
|
|
|
|
Member 7989122 wrote: 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!
modified 9-Jul-18 19:19pm.
|
|
|
|
|