As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
As a student teacher I am very interested in how effective "mini languages" such as Scratch, Logo, Alice and Lego mindstorms are in teaching the pupil the core concepts of programming such as variables, functions and loops.
Is one "mini language" better than another for teaching these basic core concepts?
Depending on how young the kids you are teaching are I would just go with a simpler language like python.
Here is a free book that teaches all the basics and is only about 200 pages long:
http://www.greenteapress.com/thinkpython/thinkpython.html
This is a very difficult question. Logo and Smalltalk (to name only two obvious examples) were both originally designed specifically for use in teaching children to program. You quickly run into a problem though: it's hard to define a language that's both simple enough for a small child to understand completely, and still rich enough to avoid its quickly becoming limiting and clumsy.
At least from what I've seen, most attempts have worked out poorly in both respects. Just for example, most attempt to include verbosity intended to make the code read more like English (e.g. the "To:" in Logo). Children often have poor enough keyboarding skills that such verbosity is frustrating. They also (in my experience) expect that if part of the syntax looks like English, that the language should accept other valid English as well (I'd expect the same is true of native speakers of other languages, but my experience is primarily with English speakers).
At the same time, most children (that I've worked with) quickly get to the point that they find the mini-language limiting. Some of that probably stems from the frustrations mentioned above. Some probably also stems from lack of imagination on the part of (at least some of) their teachers in coming up with exercises that are interesting and challenging. I think it's also much more difficult today than it was (say) 20 years ago though -- back then, kids were excited with what they could draw with turtle graphics (for one example). Today, they're accustomed to games with photo-realistic 3D graphics, and drawing a 2D "rose" out of straight lines seems to strike a lot more of them as basically lame.
I think it doesn't matter that much which "mini language" you use. But I think you better stay with a real minilanguage and not a "real" language if you don't plan on explaining more than the basics.
When I learned the basics (with Java) I was really irritated that I had to remember public static void main without really knowing what that all meant.
So I'd choose a language with as little overhead as possible.
Which specific language to choose is really dependent on the age of your pupils.
There are quite a few possibilities, and ultimately this kind of question has a lot to do with "taste." I do think that scheme is a really good choice though, for a couple of reasons. One is that it is a very minimalist language, with very little in the way of syntax to complicate things. Another is that I feel like scheme expresses something really fundamental about computation, and does so very clearly. Another is that Scheme can be used in a very "multi-paradigmatic" fashion. You can do functional programming in Scheme, or imperative programming. It's also really easy to build an object system from scratch for Scheme- you can graft a simple one onto the language in less than 100 lines of code. There are also some Scheme implementations out there that have a lot of libraries, so you can do things like graphics programming or web programming in it.
And finally a great deal of attention has been devoted to developing good pedagogical materials in Scheme. "The Structure and Interpretation of Computer Programs" is justly considered a classic, but a lot of the material in it would be pretty tough for young children, I think (it was targeted at incoming freshmen at MIT.) But there are also much gentler materials, like "How to Design Programs": http://www.htdp.org/ One thing you can see really clearly in htdp is how the minimal syntax of Scheme allows you to get right to the important ideas.
The main downside to Scheme as a first language is that most of the languages that are really widely used these days don't look much like Scheme, so students might have a bit of an adjustment in store when moving to them. But I tend to think that, particularly for kids, getting the core ideas is the most important thing at first.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Not sure if this is the best place to ask or not but if it gets closed down oh well. I am in computer programming and starting on my first work term. I will be doing 2D game programming for iPhone in objective C. I was just wondering if you had any tips for learning how the code works on a big project. In college I have never worked with something in terms of this scope. I am used to a project with maybe a dozen source files while what I'll be working on has hundreds. It is very overwhelming for me.
Any Tips would be appreciated. Thanks very much
This is how I do it. Opinions and methods may vary.
Generally speaking, I find the best way to learn about a system is to go through the code while the app is running.
Pick a significant place in the UI (the startup screen, some other screen).
Find the class for that view. Generally just ask a senior developer. Developers are happy to give a pointer (no pun intended) to someone who wants to learn by himself instead of having to explain everything.
Place a breakpoint in that class and run the app in Xcode until you hit your breakpoint.
Then start tracing in there to see how things happen.
Repeat the process at different spots in the app and soon you'll get a general idea of how the app works. Then it's a lot easier to catch the details.
If the system is really enormous (like an enterprise app that runs on multiple systems), then a diagram showing all the architecturally significant pieces would probably help. For an iOS app, it's probably not needed.
Good luck...
I am a 3rd year computer engineer who has done four work terms, and I can offer the following :
Some general advice:
Compartmentalizing your approach is still very useful on a big project, as in a small one. The more specific parts you focus on at a time, the easier it will be to understand them. This is not always practical due to interdependence of programs, but it is still possible to, say, work on the graphics portion alone, or the character's movement algorithm, etc. You should know that in the past that it was possible for an educated person to know the sum of human knowledge, but that is impossible today. Even senior engineers/programmers have specific areas of expertise, and other areas where they are fuzzy. Find what you most enjoy/are talented at, and devote time to that.
A basic foundation is important. Study the basic ideas of loop structures, classes, methods and the like, and know them like the back of your hand, so when applying them across languages/platforms, all you need to do is refresh yourself on the syntax. The same basic ideas apply across a range of languages.
Most of all, do not panic. It is your first work term, and you are assigned mentors/supervisors, as well as working with a team. Doing it alone would be difficult, so network well with your teammates/superiors so you can all learn from each other, divide the work, and lessen the stress on yourself!
Good luck! :)
Short Answer :
Read less, do more, then read when you get stuck. In my opinion, that's the best way to learn any new language and also someone said :
"We learn by doing, there is no other way".
Long Answer :
Rule 1: Relax.
Rule 2: You gotta understand that this is not easy stuff to master. That is why people who do get paid really well. If you had an idea you could bang this stuff out in a couple of weeks with you need to dump that. Plan to spend months working up on it.
Rule 3: Understand that the Apple API is HUGE and it is always evolving. There is enough content to learn something new Everyday.
Rule 4: The fewer programming languages you've had to learn, the harder it is to learn new ones. You will learn slower than someone else who has learned half dozen languages/APIs already.
Rule 5: Don't be afraid to use repetition and brute force. I think the thing that slows novices down is not learning the behaviors and methods of common foundation classes like NSString, NSArray, NSDictionary etc.
Rule 6: As a learning exercise, copy-pasting might not be the right thing to do. If there's an Apple example of how to do something, rather than copy-pasting I tend to rewrite it manually. I find it sticks better in my mind.
Rule 7: Use any resources you like. There are no rules on how you should learn.
Rule 8: iPhone is a memory constrained device where network and local storage access is slow. Parts of your application can be unloaded at any time, your application is responsible for maintaining it's memory footprint (not the user), and an event (phone call, memory, etc.) may require the app to respond accordingly and quickly.
Rule 9: It isn't about you. It isn't about your code. And it isn't about your code doing this or that. It's first about the user and responding to the user. It's second about your code responding to the framework. You don't usually tell the framework what to do. It asks you for things when it needs something. You sit and wait for it to talk to you. You're not in charge. You don't control the runloop; it controls you. You register to be told when things happen, and you indicate that you're the object who knows something about something (data for a table for instance). And then you let go, and let Cocoa do the rest. It's a very different world. I like it very much.
Rule 10: Relax.
When I'm coming to a new Xcode project, I open it up in OmniGraffle Pro. If the project is well organized, you'll see a nice diagram with a summary of the classes, the methods that are present and a little bit of how things relate to each other, important enums to know about, and other helpful information for getting a good overview of the project.
After that, pick a point like #mprivat said and run it in the debugger and get a feel for how things run. I like to set breakpoints with logs of the breakpoint name and hit count (and maybe the value of some variable or parameter if it seems relevant) and automatic continue after a little while to avoid pesky timing issues that can sometimes creep up when the debugger pauses execution. I use breakpoint logging so I don't have to worry about accidentally committing clutter code. (Be careful of pulling new code though because breakpoints don't move with your changing codebase. :))
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
As an artist and musician, I often want to sit down and just let the code roll like a piece of free-form poetry, but I've found that doesn't work as well as when I have a set goal in mind. I've been experimenting lately with setting up tiny, fun goals for myself, not unlike how an artist would sketch a quick still-life, but I wonder...
What do others do when they want to code for fun, without the bondage of an already-committed project?
Design work, I find, flows much easier than just coding. I find that coding is often more of just implementation of a good design; I really like to just sit down with a pad of paper and a pen (and likely a bottle of wine) and work out an interesting design.
Project Euler is where I'm having fun at now. I can go at my own pace and work on the problems that interest me. Also, work in any language I choose.
Write documentation when coding doesn't come easy - coding will quickly seem much more appealing!
Going for a walk outside.
I tend to map my idea or build a structure in a MindMapping tool like MindMeister. And it's great for a team because it can be edited in real time by multiple persons!
I like to pick up a new language and learn how to express ideas in it. This usually has the benefit of showing me what I like and don't like about the languages I currently use. I usually pick some little tool project I've been wanting to do. Using the new language angle get's me motivated
My most recent 'new language' is Scala, in this case it will likely become a langue I use.
I like writing on whiteboards. Great for db diagrams, task lists, feature lists, (other lists,) random ideas, notes, etc. (db diagrams being the biggie for me)
Python is great for just getting things going on an idea and having the language (usually) behave like you would expect.
While it may have its drawbacks, it sounds like a great fit for what you are describing.
So to answer your question, the Python Challenge is entertaining and often gets me thinking about little things that would be fun to code, probably because it exposes you to different types of problems.
I like to code.
I like to find something interesting, code it and then see it works.
It does not have to be a project per see, it's good enough if it does something, like use Google api to get picasa albums, change song in iTunes or get details of current iTunes song, automate downloading of document from web site that is behind login and requires cookies and all that stuff, data parser in python, simple app on Mac, core data application, google codejam problems, topcoder.com problems ...
I like to learn new features of some language or some new language/technology/patterns/tool :-)
Usually I will work in Photoshop for a while. Get creative and try to come up with a new design that's not constrained by any code. Maybe even find something inspiring on the web for some new design ideas... then try to implement the design in code. That's the fun and challenging bit.
Use the REPL.
You figure out broadly the sort of thing you need to do - what APIs you need to use, what data structures you need to handle - and then prod them interactively until they start making sense. A ton of languages I use now have REPLs: Ruby, Python, Scala, Java (BeanShell, or JRuby/Jython etc.), C# ('csharp'), PHP (Facebook have made a REPL for it), Smalltalk (GNU gst) and, obviously, LISP/Scheme.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I work with many different models and simulations. Some of the older models and simulations are written in FORTRAN. Some of those models have been converted to C++, but the current trend is to create these models using MATLAB/SIMULINK. From a computer science perspective I have always felt MATLAB/SIMULINK was not a good solution. What language do you use to create models and simulations and why?
I would always try to use the language that is provided by the best modeling and simulation tool (or library, if you like) to do the job for me.
And this question can really only be answered by taking into account what kinds of models you want to implement. Continuous (e.g. ODEs), discrete (e.g. StateCharts, Petri Nets), or a combination (i.e. a hybrid model, as can be implemented with Simulink+StateFlow)? There are various tools for each kind of model.
Another important aspect would be the domain in which you are working. Simulink has pretty extensive libraries for electrical engineering, finance, or computational biology (most of them are included in additional packages, though) - if you work in one of those fields, there might simply be no better (i.e. complete, valid) component library. The same goes for other commercial simulation packages, such as AnyLogic, Arena, etc. There might also be some open-source simulation tools, depending on your modeling problem.
Finally, you might prefer a specific programming language over another, and you might have additional requirements, e.g. support for
Optimization (of model parameters)
Validation
Output analysis (statistics, plots, statistical tests)
Support for parallel and distributed simulation
Model checking
...
So I'm currently working with Java with the well-known advantages - reasonably fast, good support for multi-threading, relatively simple to use etc. But if 'reasonably fast' is not fast enough, there might be no option but going down one level of abstraction :-)
I also work with a lot of legacy code, most of it in Fortran. I really don't mind using Fortran - all the modern compilers allow variable names greater than the old and silly 6 character limit. Also, with Fortran 95, you can even do OOP if you feel that your modifications to the existing codebase would benefit.
Also, there are very good code editors for Fortran, which isn't always the case for more specialized script languages.
C++ has the great disadvantage of memory considerations. I have been programming C/C++ for 20+ years now, and I still forget to delete objects and properly fill in destructors.
On a final note, if you're using Windows, there is a Fortran.NET compiler (I think from Lahey-Fujitsu?) if you want to move your Fortran to a managed environment.
Good luck!
SIMULA of course !! :-)
What I've gotten out of MATLAB is it's ability to let me quickly prototype an algorithm. I can really get a good feel for the data by plotting it and using the built in statistics functions. When trying something new out, I can do something quick and dirty to get some initial results, then go back and clean things up to refine my results. With compiled languages, there's a lot more I have to do just to get the simulation to run. With MATLAB, I spend more time thinking about the real problem, and less about compiling, linking, memory management, etc.
However, there are many problems that MATLAB is just ill-equipped to solve. For large data sets, a compiled language with user defined data structures is almost certainly necessary.
Particle physics has been moving to C++ and python. This is not universal, and probably wouldn't even be close were it not for the ubiquity of ROOT.
Root's use of cint means you needed bother with memory management when you're dinking around with a new idea, it's capacity to run compiled allows you to have speed, the ability to mix the modes is very helpful, and the bindings for python and other RAD languages allow for great flexibility.
In a very real sense, this comes down to an endorsement of roland's point.
you can use s-funcuin block for linking fortran(c,c++) with matlab.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
With the interest of creating a roguelike RPG (such as Nethack, Rogue, and ADOM), which programming language would be most suitable and why?
With the language that you choose, be sure to list any libraries or facets of the language that make it particularly well-suited.
Way back in the day I tried to write Roguelike games using QuickBASIC out of all things (it was 1988.) Not the recommended approach...
There are still some development circles out there. Here's an FAQ on Roguelike Development and also a blog dedicated to the same.
My language of use (I'm trying to create roguelike too) is Python, because:
It's high level programming language, I don't need to think about memory allocation all the time, etc, but keep my mind on algorithms.
There's tons of useful libraries for almost everything. Recently I've found TDL/libtcod which can be useful for roguelike development.
With bindings you can easily use C/C++ libraries or even write few critical functions in C/C++, and use them.
It's the most readable programming language I've ever seen.
While programming in Python I've learned to use internal documentation. It's very helpful thing, I just read my code few months later and I still know what it's doing.
That's a very personal choice as always :-)
I wrote my Roguelike game (Tyrant) in Java for the following reasons:
Very portable (even with graphics)
Garbage collection / memory management
Lots of good free / open source libraries available (helpful for algorithms, data structures and manipulating save game files etc.)
It's a statically typed language - this has performance and robustness benefits which I judged to be worth the additional coding complexity
I wanted to hone my Java skills more generally for use in other projects
EDIT: For those interested it is open source, all code is available at SourceForge
Well I've made a couple roguelikes in C, spending a fair amount of time at roguebasin, which is a great site for anything related to roguelike development.
As for what language you should use, I don't really see it making a huge difference. I pick C because of the portability, and a lot of libraries work well with it.. But an object oriented language can clean up some things that you may not want to keep track of.
There aren't any languages that I would consider to be specifically greater than the rest for roguelikes. If you're making it graphical, you may prefer something that has that built-in, such as flash / silverlight. But even then there are libraries for any other languages that bring them to about the same degree of difficulty in that regard.
So I'd say take a language you know and like, or that you don't know and want to learn..
Most of these answers are great, but there's something to be said for the combined power of object-oriented stuff and low-level commands that can be abused in C++. If you're looking for some inspiration, the C sourcecode to NetHack is widely available and documented well enough that you can certainly poke around to learn some things. That said, it's a huge project that's been growing for decades, and not everything is as clean as you're going to want things for your own project - don't get roped into making poor design choices based off of what you find in NetHack.
Honestly, though, in terms of what you use it probably doesn't matter at all - though I'd highly recommend using an OO language. There's so much crap to handle in a roguelike (heck, any CRPG really) that OOP is the easiest way of staying sane.
The original nethack was written in C, and the source is available if you want to get some ideas about how it was written, and the challenges you may find which might be a good way to start deciding on a language.
My first question would be whether the game is going to have a web based UI or be some kind of console/window affair like the original Rogue-like games? If the former I would say that any language you're comfortable with would be a good choice. Ruby on Rails, Python/Django, PHP/CakePHP, etc. would all be great.
But if the answer is the latter, this is a game that you want people to be able to download and install locally, I'm going to go with Java. It's a great language with no memory management for you to deal with. It achieves very high performance thanks to just-in-time compilation and optimization, and it has an extremely rich library to help you with data structures, Swing makes for some really beautiful UIs, and the 2D library allows for the most rich cross-platform rendering outside of PostScript. It also has the availability across Windows, Mac OS X, and Linux that you're not going to get from some other choices.
Finally, distribution of your application is easy via Java Web Start as well, so people can download and install the game with just a couple of clicks once they have Java and keep it on their machine to run as long as they like.
For making any game, any language will be right if :
you can use it (you are able to use it, by knowledge or if it's easy enough to learn right now for you or your team)
it produce applications that runs on your client's computer
it can easily produce applications that runs fast enough for your game's needs.
I think that for a Rogue-Like, any language you know will be right as far as it runs on you target. Performances are not really a problem in this kind of game. World generation can require high performance if your world generation is really complex though...
just go with something that will handle the low-level details for you. whatever you know should work.
hey, they can write one in javascript.
I recommend Actionscript for those games.
You could consider Silverlight.
It sits on top of C# and .Net so theres not much need to worry about memory management. With SL you'll get built in support for scene graph type rendering - culling of things not on screen, Key board, mouse events, clicks on objects etc.
There's an initial learning curve, but I find it's a great environment to work in.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
We don't teach children calculus first. We first teach them arithmetic, then algebra, then geometry, the analytical geometry, then finally calculus.
Why then, do we teach our computer scientists frameworks and IDE first. Some curriculum do force students to learn computer science fundamentals, but the vast majority of graduates that I see could not compose a framework of their own to save their lives.
Where then is the next generation of tool builders?
How can we promote the understanding necessary to create frameworks and development environments?
This is of course a generality. Not all education is lacking, but it seems to be the majority and it brings down the quality of our profession as a whole.
I think the analogy is a bit off. A better analogy would be "We don't teach our kids to use calculators to add and subtract, why teach programmers to use an IDE to program?"
Get rid of HR departments that require X years experience in Y. The universities are just tailoring their course to the HR department's requirements.
I employ graduates who can code in something (I really don't care what language) and who can learn.
I see your point, although I think the math analogy doesn't quite fit. You have to know basic arithmetic to be able to get anything done in any other math discipline.
When I began programming frameworks were mostly unheard of. If you wanted a binary tree, by God, you went and wrote one. In C or Assembler. That was basically it, so to get anything done at all you had to know a lot.
Today, Frameworks and IDEs and designers make it possible for "noobs" to create actually pretty brilliant things without knowing the first thing about how to build a framework, or a compiler, or manage memory allocation.
The real issue is, what about all the dingbats that think they are awesome, great programmers because they used Frontpage or Access? Managers have a hard time telling the difference between that kind of programmer and one that really knows software development as a discipline.
So, specifically, why is it that way? Because everyone wants a job and nobody hires programmers that know how to build a binary tree. They want programmers that know .Net or J2EE, etc.
I would argue that there is probably enough work out there for 9 to 5 programmers who can start at the framework level and go up from there. The truly good ones - mostly your program as a career and/or program as a hobby - are going to get the knowledge they may have missed in college over time anyway. You can't force everyone to be a wonderful programmer no matter what curriculum you teach. Inquisitive students are going to learn about the fundamentals whether its taught to them in class or entirely on their own.
There are tool makers and tool breakers. And of course there are tools, but let's not go there.
If you have a good look at an automotive workshop, you will see a lot of funny little tools that you don't see on the shelves in hardware stores. Like the ones for pushing back brake caliper pistons. Or the clamps for compressing valve stems so you can get the collets out with one hand while talking to your mates about nailing the new secretary (instead of watching them fly across the room when the spring slips out from your screwdriver).
These were designed by mechanics. They're really effective, generally small and cheap, and totally incomprehensible until you seen them in action.
Most of the profound changes in automotive technology were bottom-up, but top-down is also needed. Individual mechanics can't make fundamental technology changes like the switch from cast iron to alloy heads. A new broom sweeps clean, an old broom knows the corners. You need both.
But I digress: the point is that the mechanics couldn't design these tools if they lacked fundamental skills and knowledge. My father built me an entire motorcycle from scrap iron when I was a kid. As an adult, because I lack his skills and knowledge and modes of thought, I can barely maintain the bike I bought from Honda, much less take to it with an oxy like Mr T in a creative frenzy.
With code, I am as my father was with steel. Donald Knuth is my constant companion, and when the wireless protocol for our GPS loggers needs to be implemented in .NET it's me they come to see. The widget monkeys wouldn't know where to start.
I think the problem is in fact the GUI paradigm in general.
Microsoft made using computers much easier, they popularized the Graphical User Interface. They brought this interface metaphor, (the desktop, the file) to the domain of programming as well and very effectively too with their Visual Basic tool.
But just as the GUI obscures what happens "under the hood" so does the IDE obscure the manipulation of bits and bytes. The question is, of course, risk to reward ratio - how much understanding do programmers lose in exchange for productivity?
A cursory look at "The Art of Computer Programming" might show why IDEs are useful; "The ultimate packing density is achieved when we have 1-bit items, because we can cram 64 of them into a single 64-bit word. Suppose, for example, that we want a table of all odd prime numbers less than 1024, so that we can easily decide the primality of a small integer. No problem; only eight 64-bit numbers are required:
p0 = 011101101101001100101101001001001100101100101001000101101101000000
p1 = . . ."
Programming is really hard, you can see how an IDE might help. :^)
Learning the abstraction is easier than learning the details when it comes to programming. It's harder to teach someone to hand-code assembler to print "Hello World" than it is to have them throw together a form with a button on it that shows a "Hello World" message when the button is clicked.
You didn't know how to build the engine of a car before learning to drive, did you? Because it's not necessary in order to drive. In the same vein, you don't need to learn how a linked list or binary tree works in order to maintain a list of names and search them.
There will always be those who want to get under the hood and learn the "why" of things, but I don't think it's required to get things done.
I always screen applications by asking difficult questions that they could only answer if they understood how something really works. I think it is a real shame colleges and universities are teaching people framework based development but not focusing on core software principles. I agree that what matters more than anything is someone who understands how programming works and has the drive to learn anything they can about it.
Most universities I know of have an introduction to computer programming course that teaches basic programming concepts. Unfortunately it is impossible to teach programming without actually writing code.
The problem is that some prefer to teach this course using some OO language such as JAVA or C# and so the students must use Visual Studio (or the Java equivalent).
It is very hard to explain the basic concepts when the IDE forces you to work in a certain way.
I think that the first language students learn should be functional language such as C. This way you have less layers of abstraction between them and the basic CS concepts.
Agree with cfeduke.
I looked at the work for the same CS courses I did from 2 years previously, and they were way harder. 5 years previously, way way harder.
The CS bar is being lowered more and more, presumably because there are more and more jobs that don't require any working knowledge of any of the complicated CS subjects. There are huge numbers of jobs for people to just cut code.
Since traditionaly people who wanted to be programmers did CS courses as coding has gotten easier this is still the case.
What really needs to happen is for CS to not be a requirement for professional software development. Instead there needs to be another curriculam that focuses more on getting people out the door and cutting code.
This would leave CS to be that course for you next generation of tool builder.