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.
I started with C in University. If I was teaching now, I'd start with C# move to C++ then to C. Then and only then would I move lower to .NET, IL and maybe a little on assembly to help them get a better idea of what is going on under the hood.
The idea is to move on to the "candy" languages after you fully understand pointers.
The idea is to master "pointers", get a feel for some of the most difficult concepts early.
When I went to school the professors were very strict when they taught statics and dynamics for the engineers; the idea was to separate the "wheat from the chaff", early in the program. For example, my younger brother said he got a "D" on his first 4 week exam, because he forgot the -> vector symbols on his equations, even though every answer was correct with all the work shown.
The idea is to let the student determine if the subject matter is right for them very early on, so they don't make too much of an investment and bail later than they could have.
Pointers are not something I would teach to a beginner, you can screw up your code so easily and make it so hard to debug that way.
These days, a lot of companies cannot get programmers. So the concept of weeding out the lousy students is old-fashioned and should be deprecated. Modern teaching methods can help weaker students become as good as the strong starters, by the end.
All programming languages have strengths and weaknesses, if you study computer science in a University, you will probably have used 7 or 8 languages by the end of it so it will be second nature at that point to pick up a language and start using it fairly quickly.
That's exactly my point. The idea is to help the student decide whether they have the aptitude for the profession really early before any real investment is made. When I was a student we learned assembly language. Writing code has lots to do with personality, it's all about solving puzzles, and sometimes you spend lots of time trying to figure things out. If you have "the personality" you will certainly enjoy this book, perhaps people should read this book before they decide to take a software class: The Bug by Ellen Ullman
Hi and welcome I will offer some advice about selecting a language from my perspective as a want to be professional programmer. I am a retired Hospital Pharmacist and started playing with computers way back when an Apple /// was my first computer. Your job in constructions requires you to solve problems that require computed task. Take a few of those task and write out a narrative of the information you use to solve a task. I may get push back here but once you learn one programming language other languages become easier to learn. I suggest BASIC or Java (Kotlin). The other BIG learning curve that will slow you up is the Integrated Development Environment for the language you select. Just Google this "IDE for kotlin" Next consideration is Web-Pages or the device you plan to run your program on Desktop Windows or Apple Mackbook My Bias is an Android Tablet or use the language JavaFX for Windows Desktop applications. NOT to overwhelm you but all programs tend to store data which leads you to explore the use of a Database. Cloud is nice IMO on device storage provides learning that is very advantageous as the lessons learned for using device storage transfers to Cloud Storage. What is roof rafter length ?
Hello, I guess to start out, I should point out that gig work can be hot and cold just as it is with construction work. However, if you gain a reputation then you can definitely make a fairly steady income. You can get some decent courses online, check out MIT's open courseware if you haven't already. I do think however, you should consider taking courses at a University when you can, they tend to teach better than many of the online resources do.
If you want to try programming out, download microsoft's community version of Visual Studio, it's free and pretty nicely featured. I recommend learning C# first, it's sufficiently powerful to be used to write apps, and it is much easier to use and debug than many of the other popular languages. Difficulty in debugging with unstructured languages like Java has stopped many new programmers in their tracks. A good starting book would be: Learning C# 2005, Second edition by Jesse Liberty and Brian MacDonald. Copyright 2006 O'Reilly Media, Inc, 0-596-10209-7. It's an oldy but a goodie.
Hi, member (hint: let us know your name, it will make this a much more personal experience for everyone!)
I've worked in IT over 40 years, now semi-retired. The first 15 I worked as an employee. You get training, holidays, pension, mentoring, but limited opportunity. (I'm talking about larger employers, i.e. those with an IT department). But it's not a job for life - redundancy can hit you whatever field you're in. You can also end up in a "dead-end" job, not learning new skills, and risk getting to a point where you're no longer useful to your employer nor anyone else. I was headed that direction so went "contract": working for 3 - 9 months on each contract, on-site with big companies. It gave me great exposure to many industries, development strategies, tools and environments. After 10 years of that I started picking up what you call "gig" work - working remotely, multiple clients, projects ranging from an hour to three years or more in length. Eventually - with a lot of hard work and even more luck - my income was far more than it could have been as an employee. I'm now semi-retired, expecting a call from a potential new customer in the next hour (recommended by a past client whose systems I still support).
The thing about gig work is that it is inherently unpredictable. You need to be psychic to work out what a buyer might be looking for. You need experience in literally hundreds of different technologies/tools to match the highly specific requirements of the buyer. You are competing not just against a couple of hundred local job-seekers, but against (literally) hundreds of THOUSANDS of other remote-working freelancers across the globe (for many of whom $10/week is a big deal, whereas you need $100/hour just to pay the rent). To break into that marketplace you MUST have either the ability to apply for 100s of gigs per week (and the ability to provide a perfect solution regardless of the tools / vagueness of request); OR you must have a proven track-record of outstanding results. For a while I was the top-ranked UK developer on Rent-a-Coder, and with 100+ 5* reviews I could bid on jobs I wanted and get a very high success rate. But once I'd not picked up any work for a while and dropped to #2, the success rate plummeted. I did a £100 job for a client who couldn't really describe what he needed, he gave me my first-ever 4* rating, and my success rate plummeted even faster. I switched to PeoplePerHour and built up a new reputation there (and picked up my biggest ever client, who then recommended me to others, and I no longer needed to respond to gigs posted on those sites).
If you've got a good education in general IT and development, AND a good portfolio of hobby projects / pro-bono work, AND you can devote 18 hours a day to it, I'd say go for it. But as a newbie, with no experience, no portfolio, a day job (and probably financial responsibility) this is not the way to go. Get a full-time, steady job as a junior developer, find out if you're any good and if you like it. Let someone else pay for your training and build up experience there.
Finally, bear in mind that IT is still generally seen as a young person's career; once you're past 30 you may be expected to take a more managerial role, and find more barriers in your way (though this is where remote working is great - no-one knows how old you are!). It's also an INDOOR job, sitting down - and as a gig worker, generally on your own. You need to be 100% self-reliant, though having said that, join good communities (e.g. CodeProject, and in the UK things like IPSE to look after your business interests. You need to be thoroughly familiar with contract law, employment law, tax law, accounting, marketing and more. You'll be learning new skills + technology continuously and spending a significant amount of your time studying and researching trends for the rest of your career.
Whatever you decide, kudos to you for not just leaping in, but asking the right people in the right places. Best of luck whatever you decide.
I got LALR(1) table generation done and parsing mocked (it works, but it's not a production ready parser)
the trouble is, it doesn't do error and continue unlike my LL(1) parser and right now i have no idea how to do it. The other issue is it won't collapse nodes or show hidden terminals through the parser (sometimes useful - esp for syntax highlighters to show comments and such)
and i don't know how to get it to collapse nodes because of the way it works beyond a vague idea and the idea is *ugly*. i don't like it, and that means its brittle. =(
so this is gonna take some work.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
When you edit a file, it doesn't look to see if the project has new code, and subsequently, doesn't prompt you to get latest for the project. This leads to inevitable "conflict/merge" process which is very problematic in its own right.
But that's okay, we have new icons and the ability to more easily theme VS2019, and that's vastly more important to devs.
(It only sucks during the week because that's when I have to use it.)
".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