|
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.
|
|
|
|
|
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
|
|
|
|
|
sammygirl wrote: 4.Javaschript
Definitely the one to go for. You would be a world expert in no time. No one else has even heard of this language! Whatever you do, do not confuse it with JavaScript.
|
|
|
|
|
Hands down Python. JavaScript is ubiqitous, but let's say, it wasn't designed, it evolved. And it shows. Same goes for PHP. HTML/CSS isn't programming, it's markup. Python is in high demand, it's (mostly) well-structured and it tends to be recommended as a beginner's/learner's language a lot.
|
|
|
|
|
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.
|
|
|
|
|
Can't you just do C# in Visual Studio Code like a normal beginner?
If you can figure out how to set up Visual Studio Code to compile, run, and debug your code, you will have gained a valuable real-world practical skill.
If you get started with .NET Core 2.1 today (= the thing that runs your C# code) you'll be somewhat good at it when they reach version 3.
Version 3 will introduce a bunch of UI stuff. If you time it right, you can get on that gravy train when it starts chugging.
If I have to pick something from that list, do Python.
But don't get bamboozled: starting with python is really easy, but it takes forever to get good at it.
C# is harder to pick up, but you get good at it much faster.
Also, number 2 is a raging dumpster-fire, number 3 ian't a damn programming language, and number 4 is spelled wrong.
But those are just details you can safely ignore for now. We all have to start somewhere.
|
|
|
|
|
KBZX5000 wrote: and debug your code
Still surprised at how many developers don't know how to effectively debug code. During my career, I've run across more than one "experienced [in years] developer who didn't know how to run a debugger and so used a form of console output and/or logs.
|
|
|
|
|
That made me laugh.
It's funny because it's true.
Debugging and reading the damn errors you get are essential skills beginners often don't see.
It does tick me off immensely when a developers ignores every error message / log and starts speculating on what went wrong instead.
It usually end up with me yelling at them to:
A) become literate
B) investigate "what the words mean"
C) do their damn job
Pet peeves.
|
|
|
|
|
Examples of what you want to do goes a long way to help with suggestions.
sammygirl wrote: see creations come to life
You could write the game of life John Conway's Game of Life[^] in language. Some you might spend more time on getting the visuals to work, and others may be the reverse where visuals take a short time, but the code behind is more tricky.
If you like things like this Draggable | jQuery UI[^] and want to make a picture puzzle
- HTML + Javascript
- you can skip the "hardcore" css for inline styling on first pass.
- 2-3 days (10 hours) on the middle amount of time to do something.
- then 2+ years of adding features to cloud save, different sized pieces, cross platform support, fixing that weird bug your number one user keeps getting but you cant replicate. Customizable colour schemes, individual user styles, performance inprovements, ai helper, machine learning auto solver, color bind support, other alternative usability support, rewritting it from scratch.
|
|
|
|
|
1) HTML/CSS - HTML is simple, and you can learn enough to get by in an afternoon. Same with CSS, but expect things not to look like you expect for a while, till you get the hang of it.
2) Javascript --Specifically, ES6 or later, or better, TypeScript. It has the lowest barriers to enter (no compiler; just a text editor & browser), and give you the basics of OO design.
3) Python.
4) Php -- actually, I can't offer any reason to learn PHP.
Truth,
James
|
|
|
|
|
VB.net
I currently have a high school sophomore/Junior interning for me who had no idea about programming to start with. I thought PHP/html/js would be a good start, following a book. Boy was I ever wrong.
We switched this intern to VB.net and the immediate feedback and seeing results made all the difference. And I think the language is far easier to pick up than C#, while allowing you to do everything you need to.
This is not necessarily what I would have a true CS student learn. There is a value to continually hitting your head against a wall and feeling the relief of breaking through only to do it again, that you experience with other languages. This is how I describe development to new engineers. Learning this fortitude is a useful skill.
But for a self taught newbie, I would go with VB.net. Once you know one language, the rest are all about understanding various types of syntax.
<hr>
"Qulatiy is Job #1"
-- modified 9-Jul-18 14:23pm.
|
|
|
|
|
100% Agree! 
"Go forth into the source" - Neal Morse
|
|
|
|
|
One more thing about C++ or C#; being able to step through your code in a debugger is invaluable for learning and the Visual Studio debugger[s] beat all others by a very wide margin. (JetBrains makes excellent IDEs, but I haven't tried PyCharm, so perhaps it may qualify, though I still don't like python as a beginner language.)
|
|
|
|
|
I think HTML and Javascript are your best bet, for a number of reasons:
1) You visually see changes on a website that you're building, as opposed to just printing "hello world" messages to a shell.
2) Your work is publicly available via the web (assuming you put it on a real website), so it's easy to ask for help/feedback from friends even if they're far away.
3) It's easy/cheap to get started. You can buy your own web domain for $20/year, and a basic hosted website for $6/month or so.
4) You only need a text editor like Notepad to start writing code; you don't need to worry about compiling it.
5) It gives you a good sense of how the web stuff works, how the browser talks to the server.
6) The skills are in high demand right now.
I wouldn't get into any back-end languages like PHP or Python at this point. Learn how to manipulate the HTML using Javascript, and you'll learn a lot.
|
|
|
|
|
sammygirl wrote: I want to do something related solving, building, not just dealing with data
That's kind of vague.
There's lots of really interesting and cool things you can work on with any of those languages. Since those things are obviously not what you're interested in doing, and you haven't been specific, then I suggest you look at job postings for the kind of work you want to do. Learn the language that seems to come up the most in them. That won't get you the job you want, but it's a step in that direction.
|
|
|
|
|
Scratch - Imagine, Program, Share
Scratch uses "components" to program (versus "code"). It's the future.
(See Unreal Game Engine and Lego Mindstorms EV3 for other examples of component / blueprint based programming).
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
