|
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.
|
|
|
|
|
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
