The author claims that students won’t be able to do real-world programming without learning this esoteric stuff, but actually this is the exact stuff they don’t need to know: full teams can and have built huge java projects just by using the intellij project wizard and maybe a tiny bit of Gradle from stack overflow. Actually students can solve most of the author’s problems by spending 5 seconds on Stack Overflow.

I’m not saying that these more esoteric details are completely useless. Learning e.g. the difference between char and UTF8 “character” is actually pretty important so that emoji inputs don’t crash your website. But this is stuff that should come in later classes, particularly for students who are interested in those details. Not everyone needs to know it.

In fact my experience is that some colleges have the exact opposite problem: they teach students old tools and techniques which are tedious and not actually used much later on. Like writing code by hand and deducting points for syntax errors, or using some outdated framework e.g. jQuery. When I saw the title my first thought was literally “yeah stop making students use eclipse, they should be using IntelliJ!”

> full teams can and have built huge java projects just by using the intellij project wizard and maybe a tiny bit of Gradle from stack overflow.

I would not ever want to work with anyone from those types of teams. They are the kind of programmers who have a very narrow range of abilities, and whenever they see a problem outside those abilities, they get completely lost.

> But this is stuff that should come in later classes, particularly for students who are interested in those details. Not everyone needs to know it.

Yes, they do. They absolutely do. There seems to be this mindset that's starting to infect software development that pushes the idea that people can be good at programming computers without actually knowing anything about how those computers work. I just do not understand how anyone could seriously believe that. My experience over the past 20+ years tells me that people who avoid learning about these topics are generally just not good at their jobs, or at best can do a decent job of things, but then completely freeze when they encounter something outside of their narrow comfort zone.

> In fact my experience is that some colleges have the exact opposite problem: they teach students old tools and techniques

That's lame, but has nothing to do with the point you're trying to make.

Students by definition are not experienced engineers. They’re in a given class to learn the topic for that class, and hopefully that class with be a challenging program of learning. In CS often the fact they’re even working in Java is incidental, they’re not even there to learn Java, but generalisable CS concepts.

I’ve got no problem teaching students practical software engineering skills, sure, that can be very valuable. It should be on a course on that topic though.

That's not what I said at all. Inexperienced in general is fine. I benefited from mentorship earlier in my career, and I'm happy to pay it forward.

Inexperienced with my specific tooling is a weird point to make, because it directly contradicts my point. If you teach people how things work: the underlying computer, OS, system libraries, and teach people the nuts and bolts of how to do their jobs: version control, the command line, filesystems, etc., then I especially don't care if they've used my specific tooling before, because they probably have enough foundational and background knowledge to be able to pick up different tooling and languages without too much trouble.

The people who are just taught to open an IDE, click "new project", and never leave the IDE, are the kinds of people that I expect will have trouble if they join my team and we're using different tooling than they're used to.

"What does this have to do with cooking?"

"Well, you want to use a knife to cut your vegetables don't you? How on earth do you expect to get a knife to cut your vegetables if you don't mine for iron slag, refine it, build a forge, learn blacksmithing, make thousands of inferior and useless knives until by trial and error you finally have a knife you can cut vegetables with!"

"Ok, so once that is done then I can be a cook, right?"

"What? are you a fucking moron? Look at this asshole who thinks he can be a chef if he knows how to make a knife! What an idiot! You need a pot and a pan and a kitchen, but to get a kitchen you need a house and to get a house you have to buy the land and then to get the food you have to learn agriculture and animal husbandry, woodworking, stone-masonry, how to quarry, political intrigue, bartering, build a working economy you and 7 other people can all agree on using..."

It isn't that difficult. All I really needed was a problem and a line on the tools I needed to solve them. All the other stuff may make me competent should I need to rebuild the world's technology stack from the ground up a.k.a Dr. Stone but it never earned me a dime of income of served the most basic of purposes in attempting to dissuade me from a computer career.

if, while, and other programming concepts? I'd agree on that.

But the article suggests learning about files, file formats and other low level stuff.

So maybe they should first learn how a filesystem works, how it keeps internal consistency, and how the bytes are mapped into some physical storage. That's pretty fundamental too, right?

What we have here are "leaky abstractions"[1]. If the abstraction an IDE provides is not good enough that students can work with it without knowing about the lower layer, then the abstraction is leaky. And that is the problem. Not "should I teach them with an IDE or without".

[1]: https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...

Do you suggest teachers fix Eclipse so it no longer has leaky abstractions rather than just teach students how to work in a modern file system?

> They are the kind of programmers who have a very narrow range of abilities, and whenever they see a problem outside those abilities, they get completely lost.

How does one follow the other? How does not learninging unnecessary skills hinders ability to solve new problems? If skill is really needed later one person from the team can learn it and share most important bits of knowledge. If skill is not needed now why learn it? YAGNI can also be applied when learning things.

I find that not understanding how compilers works or how to use them in low level tasks is minor problem when developing. I never met developer who had problem like that. Much bigger problem during developing is not listening to and understanding your users and IDE will not help you with that. This is much better skill to learn than compiler CLI.

I disagree here. Life is not so easy that you can ignore many problems. If you don't know certain skills you don't know the best way to solve it and it can lead to various problem.

Its like saying why learn chemistry, advance math, physics in high school when you might not even use them other than few simple formula and if you need them just learn it from team. I don't think this is how real world works.

the point of learning all that in high school is not to learn about these things specifically, just to teach you how to learn things fast so that you can easily learn what's useful when you work.

No one cares about what you learned in chemistry class at 15 y.o, it's all approximations if not outright wrong stuff sometimes and it does not matter in the slightest.

A great driver understands how engines work. A great wood carpenter understands about different kinds of Timbers and their properties.

I don't think that's true. I think learning things that are related to your work will almost always make you better at your work, even if you don't use that specific knowledge directly. Human brains are big pattern matching machines, and the more data you can feed it, the better it will be at looking at problems and truly understanding them.

> I find that not understanding how compilers works or how to use them in low level tasks is minor problem when developing.

I'm not saying that you need to understand enough to build your own toy compiler (though that can also be very useful in understanding how to write better programs). But at least understanding it from a basic level, like "javac takes in my source code, turns it into some kind of machine-readable intermediate representation, does optimizations, and outputs bytecode" is something that I expect every Java programmer to know.

The vast, VAST majority of programming is of the type OP described. It ugly and has warts, but is good enough to deliver business value. I’ve seen it first hand.

The truth is that developers working on projects like that outnumber everyone else probably 10-1. See https://www.hanselman.com/blog/dark-matter-developers-the-un...

Sure, maybe they can still get things done without that knowledge, and it'll work, but that's not really the point.

Okay but what matters is not who you want or do not want to work with, but "can it make a business that works". That's the only metric.

The first job I was in the owner did "code" pretty much everything on a visual programming language (Max/MSP). Was it pretty ? No. Did it allow him to start a business and sell things ? Definitely, and that's the only thing that matters

With this myopic attitude you'll get your business up and off the ground fast. Good job.

Then you will be mercilessly hacked.

Once you rename your startup to avoid the negative publicity, you'll hit a performance wall.

You'll lose customer data (and the associated customers) while you try to figure out what the four letters in ACID actually mean.

AWS will take 80% of your profits.

A different company will have taken their time, done it properly, and eat your lunch. They'll take the customers that lost data, as well as the customers that couldn't stand your slow-ass website.

Then they will mercilessly undercut you, because they're not scaling to infinity to compensate for an O(n^3) algorithm being used to scan database tables in their entirety by Mr I Know How to Bang Out Code.

Optimizing is a different item, it reduces costs... More profit, better costs for customers, potentially undercut other companies with prices that are not feasible / offer more features.

Now they are niche when these issues do matter...

One wants to get things done to the exclusion of all else. Possibly trapping you into a corner if you need to ever scale.

And the other wants to “do it the right way from day one“. An undertaking that would cost more than a small business could ever hope to afford or slowing you down giving rivals time to catch up.

Doing it right, to me, means hiring people who can adapt to changing conditions and needs, and who can make (or help you make) the right trade offs when you have to balance faster time-to-market (which can involve cutting corners) against avoiding technical debt.

The team that lives inside IntelliJ and can't do anything outside it is not going to do that for you.

Well, we’re only discussing a specific dimension of software development here. In reality there are a whole bunch of things not even related to software that will cause problems.

My thought when people only have one solution to a problem: If you can only think of one solution, how do you know it's not the worst one?

I don't have an opinion where these people develop these attitudes/skills

And what happens after you get that business running and bringing in some revenue, but you need to start tackling harder problems in order to keep your current customers happy and attract new customers? You're stuck with a bunch of developers poorly suited to solving those problems, and a bunch of infrastructure that wasn't designed with this sort of feature expansion in mind.

So you hire some new people who have to rewrite a bunch of things, or who have to spend months or quarters untangling the mess. You could even miss your market opportunity. Even if you don't, you've still wasted a lot of time and money.

What I want doesn't matter any more than what you want regarding this. What matters is what the society as a whole wants, and the current situation is in big part the manifestation of it.

> And what happens after you get that business running and bringing in some revenue, but you need to start tackling harder problems in order to keep your current customers happy and attract new customers? You're stuck with a bunch of developers poorly suited to solving those problems, and a bunch of infrastructure that wasn't designed with this sort of feature expansion in mind.

you're assuming that you would even have gotten the first customers if things were "done right". My experience seeing entire businesses held by 1kloc of "academic" (I'm not saying this as a compliment) python scripts with 20% of it being globals succeeding says otherwise.

For how long? Until it needs a rewrite because it’s completely unmanageable. Yes I know, the rewrite cycle is part of the business now, but I don’t think it’s necessary. We can do better.

It's not lame, it's fine. It is just fine, and usually better, to teach basic concepts using a simple tool - even if it is not fashionable or up-to-date.

Agree that teaching old techniques can be useful in the cases where the current techniques build on what came before.

Undergrad CS students aren't learning software development first and foremost. They're learning logic and math, data structures and algorithms. They need a low friction environment so they can learn the academic stuff without wasting their (or their TA's) time.

So while I agree that many "real world" programming jobs require dealing with the kind of boring minutia that IDEs try to abstract, this stuff shouldn't necessarily be a prerequisite for students on a CS track. There's plenty of time for the real world later :)

Interesting. In other fields, like surgery, narrow specialization is desirable.

And many developers I know do end up specializing in particular sub-fields (ML, databases, whatever), but they already have a wide breadth of knowledge and experience to serve as a foundation underneath that. In contrast, I also know some developers who didn't take that route, and jumped into specialization early, and who are completely useless at productionizing their work.

IDEs can be great, but in the hands of someone just learning they encourage a cargo cult style that becomes a barrier to actually knowing what you're doing. I've had to work with people who are still stuck cargo culting thing 15+ years into their careers. Not fun.

Relatedly, they can also assist people who to get just enough success (in the cargo cult sense) to get a degree, when they would be much better off in a different field. It does them (and their future team mates) a disservice.

The thing is, they are the ones least likely to cause difficult to debug build issues due to "very clever" features and using the latest version features of build tools in the first place.

Regardless, I don't think "I don't want knowledgeable people because they might write something 'too clever' that causes problems in the future" is a particularly winning strategy. You're basically saying you want dumb people because they will never try to be too smart for their own good.

For example, recently I spent more time than I'd like finding out that we linked two incompatible versions of a library. All the visible dependencies were correct, but at some point someone bundled an old version in a fat jar and that got included transitively via another dependency. If you understand the details you know why you don't distribute libraries as fat jars. But if you're just following some guide it's easier to fat jar it than correctly specify your dependency tree.

If your education was really effective you recognize this is just the static/dynamic linking problem again in new clothes.

It was only later once I was interested in web development that I started picking up linux, learning more deeply about the compilation process, learning algorithms etc. For a beginner all that stuff is just more roadblocks to building your interest and foundation. But later I started hitting a wall when trying web development or 3d game programming where I didn’t have the fundamentals and thats when I started learning all the other skills besides just typing some code and hitting the green run button. In the transition from beginner programmer to Intermediate programmer is where I would say one should learn the behind the scenes concepts not while you’re still building an interest and foundation.

Also interesting aside the programming environment I started on was called “Kids Programming Language” it was like a kind of simplified blackbox environment that I compared to flash (but didnt cost money). Even today I prefer to introduce coding in such blackbox environments like processing.js maybe because of that.

So for the simple for loop for(int i = 0; i< something; i++){} there is a large number of syntax errors a beginner can do, he can forget to open or close the () , he can forget about the : or placed them in the wrong place, he can forget about the {}.

For sure I do not start teaching my son about the c++ compiler, linker though I show him how the program runs in the IDE debugger and how changes update.

Low level stuff is needed much later for maybe parts of the students, at the beginning is too much junk that needs to be learned like a parrot.

You could, or at least the tip of that iceberg. Compiling a simple program often is a simple one-line command. Perhaps you can show him how to automate this with a shell script or (gasp) a makefile.

The reason why it is not "junk" is that it will teach him a bunch of important things: that you can "talk" to a computer using different languages, that those languages have different capabilities, different properties and different grammars (syntax), and that languages are all about grammar and semantics.

> Low level stuff [...] at the beginning is too much junk that needs to be learned like a parrot.

I see a problem with teaching there, rather than a problem with what to teach. Anytime you make people learn by heart something that needs to be understood first, there's a failure to teach.

It seems these days that we are trying to rush people who are not even comfortable with files and folders to "code". That's stupid in itself.

How about teaching them how to use a computer before trying to program it? Is it not a saner approach? Even if they don't get programming at least they'll know a bit better how those things actually work.

(And why the hell your son has to learn C++ first thing in the morning when there are more beginner-friendly languages. That's another major failure, if that's true.)

It follows the general philosophy that a computer is just a tool that should be at people's command. But that approach only makes good customers, people that are helpless when problems come. Farmers had that sort of problem and had to fight to have the right to repair their "tool".

The correct and actually beneficial philosophy is user-tool co-evolution, that is mutual adaptation. And for this to happen, the user has to really understand their tool.

This would be a good point if the year where 2003. Compiling code and setting up a proper coding environment is a solved problem that isn't worth the headspace of a young and aspiring programmer. In the modern day, you can open up the console on your browser and start writing and running code just like that.

What's far more important for a beginner is to learn algorithms and data structures, which are timeless concepts that are highly valued and can be applied to any language or environment (and to give OP credit, C++ is a fine language for learning these concepts). Recursion vs iteration, control flow, data structures, time-complexity -- gaining a mastery of these topics will enable the student to write programs that make it worth while to then learn the auxiliary technologies that can make their programs usable and sharable -- unix commands, compilers, linkers, etc -- learning these tools as a means to an end.

> The correct and actually beneficial philosophy is user-tool co-evolution, that is mutual adaptation. And for this to happen, the user has to really understand their tool.

I would argue that a lot of existing technologies such as unix are less so philosophy driven and more so backwards-compatibility driven where things exist purely for historic reasons. The idiosyncrasies of say unix can be a headache for a beginner, and it'd be a better use of their time to only interact with those technologies when absolutely necessary.

"Modernity" has nothing to do with it. In the old days you could switch on you family computer and start entering Basic just like that too. The only difference between yesterday and now, is that the leverage is much stronger.

Adding and multiplying matrix has been a solved problem too for an even longer time, yet we teach students how to do it manually. It's a solved problem, yet we expect them to understand the solution and be able to execute it.

I don't know why it shouldn't be the case also in CS, unless what you want is code monkeys [1]

> Recursion vs iteration

You cannot explain that properly without explaining first that compilers to stack machines, routine calls and jumps. If you skip that you just end up saying "anyway use iteration when your program mysteriously blows up". Actually if you do go all of a sudden low-level like this, your students will discard your explanation and remember the previous rule of thumb. That's one of the reasons why some people bad mouth us, saying we abuse the terms "science" and "engineering" in "computer science" and "software engineering".

CS 101 should always be in assembly language on some 8bits micro-controller. If you don't do that, you are cutting corners.

[1] https://www.joelonsoftware.com/2005/12/29/the-perils-of-java...

Isn't this a implementation detail? I mean it depends if your course is focused on teaching programming first level (how to get some simple problem then math and code it with if, for and while and some variables) or if you actually have a course about say c++ where you get in detail about why this old languages are designed how they are.

Just to make things clear, I don't like "magic", I too prefer to understand how the computer works from the logic gates up though I am still missing some stuff in my knowledge. But what I noticed is the introduction to programming is very hard, I remember me wasting hours explaining stuff to a student colleague and after those many hours he had the revelation " so this computer is dumb, we have to tell it to do everything step by step , all details..." , so you have the problem of teaching the students algorithms where for myu son they use some C-like pseudo code, then you want them to start running those algorithms ASAP so they can get feedback from the machine , but the syntax is a big issue. It would not be efficient to teach them to also use the command line(Windows and Linux), run the compiler, troubleshoot if the command fails to run(maybe wrong directory or paths), then do the parse the syntax errors and try to find the actual error that produces that sometimes unrelated message. With and IDE you might get the red squiggly lines as you type with some hints on what is missing (before you write 10 new lines and not know what is the problematic one.

But I agree with you if the student is not in the first year of learning programming and indeed the people that do computer science they will study compilers and CPu architecture, and data structures and lot of stuff.

As much as the fact that numbers are stored on a finite number of bits. Your iterative factorial won't blow up for 100! but gives an obviously wrong result, like a negative number.

Don't blame C/C++; blaming the tool is generally a bad idea (now if your school teaches cooking using flamethrowers that's a different story...). Many languages don't make promises about tail call optimization. A lot of languages don't have "big numbers" (as in Lisp) support - even "modern" ones. Very few languages will accept recursive data structure definitions without using pointers (or references if you want, but the label you put on this can of worms doesn't make much difference). Some will actually give the right-ish result because they use floating point numbers internally, but then you might have to explain why the hell 1/10 does not give exactly 0.1 (which is why, in some algorithms, you compare not-so-real numbers using <= instead of ==).

You cannot escape the fact that computers are mechanical machines, not abstract math machines (unless you load a program that does precisely that). Part of "the Art of Programming" is about overcoming that limitation.

Abstractions are lies by definition. Lies are sometimes a necessary evil, but abstraction abuse is a poison.

> Compiling code and setting up a proper coding environment is a solved problem that isn't worth the headspace of a young and aspiring programmer. In the modern day, you can open up the console on your browser and start writing and running code just like that.

Noone should get into writing more complex programs without understanding the basics of the tooling, and we at most only have a few auto-generators that will create a skeleton that can and will break with ever so slightly a change.

>The reason why it is not "junk" is that it will teach him a bunch of important things: that you can "talk" to a computer using different languages, that those languages have different capabilities, different properties and different grammars (syntax), and that languages are all about grammar and semantics.

My point is not that he should not know about the low level stuff eventually, but keep that for the second or third year.

But int he end the reality s that we write text and some tool makes it run and print stuff on screen, is not important that everyone understands that the compiler has 3 parts/stages and that the linker searches for stuff in some weird paths using some weird algorithm... for first years of teaching I think is OK we focus on understanding the fundamentals and not the tools, we would waste our time teaching them about the c++ linker or Java classpath if they will use Python or JS in the real world.

I identified 2 hard parts

1 create the solution for the problem, like say add all numbers from 1 to n , my son can't invent the solution, I have to make with him similar problems over and over again until things connect (is the same for Math and physics, we repeat same type of problem until it makes sense and he can solve them himself)

2 the syntax, I can work with him, make some simple programs and next week he fails to use "cout" and "cin" properly , this means I failed to identify that he did not properly understand how this crap works and have to do more examples with cout and cin too.

However it's not entirely a matter of when you started to touch the keyboard. Around me I see "people who understand" and "people who use" of various ages. Guess who helps who more often.

The only time I have ever used javac was for fun. Not once professionally.

There's not much point in teaching specific things, because there are thousands of specific things that make a program work. Yesterday my code failed because the whitelist at the server was checking my ipv6 address instead of the ipv4 on the website interface. The day before I was stumped on a Rust borrow checker thing.

You end up learning the things that you run into. If you've never needed compiler flags, it's actually not that easy to learn without a motivation. Same goes with memory barriers, garbage collection, and so on.

There's just so many rabbit holes. Telling people they need to know this or that is futile, what they need to know is how to figure out whatever their issue is. Some common tools with some common comments about pros and cons, warnings about where the caves are and what's more trivial than it looks.

My wife is starting a CS degree, and I'll be looking over her shoulder providing this kind of advice, rather than recommending anything in particular.

Good education should give you understanding of the basics, not just higher-level stuff. It's easier to learn high-level stuff when you got the basics down than to unlearn the "magic black box" approach and dive into basics when you need it.

Too late for what, though? At any point in time there's a certain subset of knowledge that's most relevant that you're trying to do. If it's learning overall programming concepts not the internals of a language which you may or may not use, then NOT using the IDE automation would be detrimental.

Furthermore, in every single project that i've worked on professionally, attempting to manually manage dependencies and the way things are compiled would earn me odd looks, since that's far more tedious and less productive than just using Maven/Gradle. Not only that, but manually attempting to manage imports as opposed to letting my IDE do everything that's needed in the background would provide me precisely 0 benefit.

In my eyes, "It just works", isn't a bad thing at all, as long as you:

  - can look into the lower level mechanisms (but only once actually needed)
  - can find information about all of it, to make the above easier

Of course, we're not talking about doing javac manually when you're working, we're talking about learning the basics before going on to use the automation. BTW Maven and Gradle have plenty of gotchas of their own. If you don't understand what exactly happens you won't solve "magical" problems like old builds of non-snapshot versions remaining in the repo for example.

> manually attempting to manage imports as opposed to letting my IDE do everything that's needed in the background would provide me precisely 0 benefit.

you say that, and just last month I've had to help a guy manually remove an import of Token class from a wrong package that "magically broke his code" :)

> Why would you "unlearn" something if you'll still use it in 95% of the cases, the lower level approaches being the outlier?

Because I've seen a lot of people decide something that always worked is not their responsibility to fix when it doesn't work. That's how you end up with 1 guy in the company that understands the build system :)

Hmm, the IDE should offer you multiple classes to import from in a dropdown if there's any ambiguity, as well as highlight any of the methods that aren't present or whose signatures differ and provide popups with essentially the same information that you'd get from the compiler, without even having to compile the project. In that regard, i'd say that IDEs are actually superior. A single ctrl+click that'd take you to the source of the class that you've imported should also clear up any confusion about the import.

Importing the wrong thing and not bothering to figure out why their code doesn't work honestly feels like not being familiar with the language itself (as opposed to the tooling) and for some reason not trying to figure it out on their own by reading what the IDE is telling them - to me, that does sound more like learnt helplessness than anything else, which would also manifest itself when writing code and running into design patterns that they don't understand, as well as any number of other situations.

> Because I've seen a lot of people decide something that always worked is not their responsibility to fix when it doesn't work. That's how you end up with 1 guy in the company that understands the build system :)

To me, this also feels like more of an organizational issue: if companies don't have a RACI matrix (https://en.wikipedia.org/wiki/Responsibility_assignment_matr...) and have a low bus factor (https://en.wikipedia.org/wiki/Bus_factor), then that's on them. If no one takes initiative and the company fails to find employees who will, that's also on them. If only one person understands how things work and doesn't document it, nor are there processes in place to ensure any sort of knowledge transfer, then that's also on them.

That does sound like a dysfunctional environment and at that point builds will be the least of your worries - figuring out how to get code to prod, how to work with the DB and run tests (if any are present), as well as any other steps that haven't been formalized with an "Infrastructure as Code" approach will cause far worse problems down the road. Good luck if any of your servers ever go down and you haven't used something like Ansible for configuring them, but instead it was done N years ago by someone who's long gone along with their knowledge about how to do that.

If you work in such an environment and care about personal success, consider either changing the company or changing companies.

To be fair they have 30 files open in the IDE and 100 lines are highlighted cause of spelling errors, it's easy to miss the line highlighted in red as opposed to yellow or black. If you look at the console output you will know the reason build failed immediately, but that's hidden behind 5 different things begging for your attention.

It is learned helplessness, but there's a reason people learn it - they went straight for the industrial tools with dozens of variables that were never explained. They never learnt how it works under the hood and what all the knobs do. They were taught to follow the tutorial, ignore the warnings, leave the defaults as is and click the big green triangle to run the program. 99% of the time it works and when it doesn't maybe start from the beginning again and follow the tutorial more carefully :)

It's a generalization of course, there are people who problem solve better and worse in any demographic, but in my opinion the tendency is - depending on tools and automation early in your education makes you a worse problem-solver.

> If no one takes initiative and the company fails to find employees who will, that's also on them. If only one person understands how things work and doesn't document it, nor are there processes in place to ensure any sort of knowledge transfer, then that's also on them.

There's organizational goals and processes, and there's company culture. The latter is far more important in practice. And it's mostly shaped by the attitudes and expectations of people, not by putting a document on company's wiki or talking about it in a meeting.

Then why not address those things first? Most IDEs should allow you to set up inspection profiles or customize the spellchecker and version this configuration so all developers would get a consistent and noise free experience, just like you should be doing anyways when not using an IDE but instead using a code editor together with a linter/formatter and Git hooks.

JetBrains products are actually pretty good in that regard, personally i've sometimes enabled almost all of the warnings, apart from some of the conflicting ones, just to learn about more concerns that i would have otherwise not thought about myself. Not that most people should do in their everyday lives when they want to get things done, but being able to do so is nice.

> They were taught to follow the tutorial, ignore the warnings, leave the defaults as is and click the big green triangle to run the program.

That sounds like that joke about everyone ignoring 99 warnings within their project because the code compiles and runs. Once again, i do believe that this is a bit orthogonal to the IDE vs code editor debate, because if there are warnings within your project you should address them regardless of the tools that you use. If it's a bad tutorial, then why are you using it?

Of course, one can also talk about how defaults should be sensible and the default configurations/examples should never have warnings, but i guess that's just what you get when people don't pay attention to the quality of the things that they make, which is at the very least understandable in our current world.

> It's a generalization of course, there are people who problem solve better and worse in any demographic, but in my opinion the tendency is - depending on tools and automation early in your education makes you a worse problem-solver.

This is an interesting argument. I don't necessarily agree that the automation is the cause for this, merely a canary of sorts. Perhaps the people who don't have the patience to struggle with the "traditional/old" way of doing things would simply not stick around in the industry for long (this probably applies to situations where they'd have to write ASM instead of Python, as an example) due to the frustration they'd experience with all of it and not getting any demonstrable results early on, which is extremely discouraging, as opposed to the more patient and persistent people? In that regard, IDEs indeed enable a wider variety of people to stay within the industry.

I cannot comment on whether that's a bad thing or a good thing, much like some people said that we'd not always have calculators with us and yet almost everyone does have a smartphone in their pocket.

> There's organizational goals and processes, and there's company culture. The latter is far more important in practice. And it's mostly shaped by the attitudes and expectations of people, not by putting a document on company's wiki or talking about it in a meeting.

This is debatable. Those two are not mutually exclusive. Look for environments where both live up to your standards and contribute to both in a positive way.

I certainly have, for example, in one of our projects now all of the configuration lives in Git and is managed through Ansible, so we know when, why and who changed things. I've also made running services more consistent, have containerized apps to get rid of the dependency hell and have written plenty of scripts for automating the bits where people made mistakes, e.g. long DB migration names that need a particular format like V20211107.5.4.2.21.1.0_Alter_Some_Table_Do_Something

At the same time i've also onboarded new people, helped them get started and have explained things both about the projects as well as things in the industry in general, as well have pointed them towards useful learning resources. Being pleasant to work with and having a healthy environment doesn't need to come at the expense of anything else, apart from maybe people's egos sometimes (including mine).

Of course, no one wants to do things for just putting a checkbox in some corporate form, but in practice most of the meaningful ways to minimize risks and make people's lives easier down the line are worth it and there are no excuses not to implement them in any mature company. That's why having documentation and enforcing that it's present is a good idea, especially if you do IaC and most of it is actually code, that's commented as well as the rest of your codebase should be.

This has not been my experience, at least with IntelliJ in the context of Java projects. Bad imports result in IDE highlighting the erroneous usages of the imported class, by showing which methods aren't available. The red squiggles provide immediate feedback and let you know whether any problem lies within the method parameters, or whether the method itself isn't found, before you try to compile/run anything manually. Tooltips about the error contents are also pretty useful, no need to manually go to the file/line based on some text output in a terminal.

Bad language targets/JDK choices are far "louder" as far as the amount of errors output go, but they're easy to figure out, since if you ignore everything being red in the IDE and instead try to compile the project, you'll get the exact same output that the compiler will generate. It's just a matter of Googling those errors, regardless of how you compile your projects.

The only problems of such sort that i've run into have all been because of the Spring framework and its configuration mappings not being detected properly because some developer decided to initialize it in a non-standard way which confuses the IDE. Then again, using a code editor instead of an IDE wouldn't really provide any useful functionality/hints for Spring either, so i guess that ended up being roughly equivalent.

Sure you can play Google whackamole but a lot of times the compiler message alone isn't going to help you and when you Google the message you there are 20 questions on SO where the top answer has 1000 votes and says something like, delete the bin folder and restart.

But that's not the issue. The issue is your importing two projects that are targeting different dotnet frameworks.

The dependency project builds fine on its own.

They project using the dependency just loudly proclaims that the imported type doesn't exist.

Rider gives you a few squiggly lines and tells you "Computer says no"

You yourself have to figure out that one of the projects has changed targeting framework while the other one hasn't

And you know what happens when people use a black box and that stops working? They start learning how it works then. When it has actually any relevance for them. Until then it's just a more complicated way of doing things that doesn't benefit them in any way whatsoever.

This is fixable though, instead of just telling them to use the tools you can teach students how to use them well. It also doesn't hurt to inculcate a mindset that shows them how to look for help when they are stuck. Discarding the IDE entirely is like throwing the baby out with the bathwater in my opinion.

> instead of just telling them to use the tools you can teach students how to use them well

Yes, that would be great. If only I'd ever met a teacher able and motivated enough to do that. Coincidentally, it's easier to teach about how to run a couple CLI commands and read the documentation than explaining a behemoth including everything from version control to debuggers that's all thrown in your face at once.

Hmm, what would the lesson look like? I doubt there is a way to teach everything about out-of-IDE/advanced Java development in just a single hour or two. You mentioned CLASSPATH, but there are also JARs with manifest files, there are multitude of build systems with their own configuration languages/plugins/conventions, there are ClassLoaders, there are Java Compiler Plugins... Just too much.

You either list terms for two hours straight without any details and exercises or you choose some semi-random subset of topics, which may very well not include CLASSPATH for some reason. Alternatively, you teach for ten hours instead of two.

This part stays intact either way though. You're not wrong that teaching students to run a couple of CLI commands is easier, but they still need to understand what they're doing, otherwise it can be just about as opaque as clicking a button in a graphical program.

Considering the vast majority of them will be using IDEs if they are coding in Java professionally, personally I feel it is worth taking some extra time to at least give them a starting-off point and then letting them access the documentation that the IDEs themselves provide. Whether this comes after teaching them the basics of the language through the barebones text editor + CLI tools approach or is what they are taught from the ground up is a matter of choice.

I'm confused. Where did I describe doing something as example of not being able to do it? Maybe I worded something wrong. My point was just that I was completely lost and confused in many areas for years until I went out of my way to learn things properly, despite everyone teaching me to not do it like that.

"No, they don't. Because they don't even know where to start. They never learned anything outside of the compile button and the project settings. I know because I was in that boat once."

The original statement was that people can learn about lower-level details when stuff breaks. You quoted this statement, and then add the claim they can't learn [when stuff breaks], "because they don't even know where to start". You support that by adding personal experience: "I know because I was in that boat once".

However, for other people in that proverbial boat, it seems to me that they can do the same thing that you apparently did, which is to learn what they need to know - something you deny is possible: "no, they don't."

Also, since we are quibbling about text interpretation, I'm fairly confident that nobody is _teaching_ you not to use a non-IDE approach to development. Maybe they are advising it (on the basis of IDEs being more approachable to a student) or demanding it (on the basis of an entire team working with the same tools), but _teaching_? I don't think that's right.

That ship sailed long ago. There’s honestly no need for majority of programmers these days to go cli, vim/emacs way or whatever the one true way is these days. It’s just not needed.

And the ones who need it for their work they learn it, know it, and do it.

Or for the fun and satisfaction of maintaining, running, and keep oiling something antique and/or analogue.

Cross the bridge when you get there.

Jokes aside, it’s a decent part of my day job and never faced any problem. Neither do my younger colleagues who never ever were even exposed to those esoteric programming thingies.

The problem is the belief that cli or mildly esoteric CS practises and skills have to be some kind of mandatory initiation.

I never did CS classes (I taught a couple once).

I agree that you don't need to learn CLI in the first year.

The idea that the majority of "programmers" can tackle production code without ever being introduced to a CLI is terrifying, though. I'm astonished to learn that some people think you can get a Computer Science degree without learning processor architecture, IO, operating systems and so on.

FWIW, I hate git. It's the devil to learn, and it solves a load of problems I've never had. I wouldn't inflict it on a first-year student.

Of course you need to know what a file is to use git; but you need to know what a file is to use any VCS. I don't see how you can teach someone programming before they know what a file is.

Is a CS course now little more than a way to get an introductory programming qualification?

What is `SyntaxError: invalid syntax` for `print(hello world)`? What is `NameError: name 'Print' is not defined`? I don't have any names, I just want to show a string.

The only differences are: a) amount of new things to learn (e.g. students already know how to use GUI, but learning CLI is a whole separate skill); b) quality of the tool (e.g. how relevant/readable error messages and configuration are); c) your ability to get help with the specific tool you're using.

You have to stop digging into details somewhere. You can always go deeper, if you want.

In my opinion, it's perfectly reasonable to learn one thing at a time. You can start with learning CLI and then learn Java using javac. You can also start with learning some IDE and its build facilities and use Java completely inside it.

Figuring out compilation errors when using the configuration of the IDE versus using known system environment variable that are using different values. Notably the resolution of classpaths.

The fact you are asking about it, is scary.

I've programmed java professionally for 6+ years, never had to deal with that.

Talking about implicitly learning from your IDE is a lot like learning to program with React versus the browser console (or a sandbox). I'm not sure how 'purism' applies.

I don't think there's any difference between using javac and using an IDE. They're both tools that you configure and the press a button to run. What's the difference?

And the danger with saying 'you should understand it at the lower level' is anyone can challenge you if you understand the tools you use at a lower level, and at some point you won't, because nobody understands it all, and then they can point and laugh at you like you're pointing and laughing at others.

But I do most of my work in Visual Studio, which I prefer over vim+make+gdb because a powerful IDE does give you a significant advantage over a 'mere' text editor. I also find that working in vim imposes a much higher mental load than doing the same in MSVC (and don't get me started on vi without the 'm'...).

The whole reason computers work at all is because of the many many layers of abstraction. At some point everything seems like a mystical black box to you too.

Sure it might be at a lower level. But there's always a point where you get to "I just do this and it does what it says it should. I don't understand how it works." Do you feel like a terrible thing has been inflicted on you because you don't know how the Linux kernel works internally, or how `idiv` is implemented, or which SRAM cells your CPU uses?

You have to stop somewhere, and running javac manually is something almost no Java developers do so learning it definitely seems like a terrible thing to inflict on beginners.

Yeah we’ve all heard that one before

Every rebuttal and complaint against this seems to centre around how the moment someone touches an IDE they become a gibbering idiot who is unable to ever learn anything else, as if it is impossible that the next course could be about how the programs they've been writing are all processed and put together by the tool chain.

I once spent a very frustrating and miserable day in the computer labs at university unable to make a program work, and got zero points on that homework, because of a missing bracket. Did I learn anything about programming? Or how computers work? Did the application of anything I'd previously learned about computer science or programming work? No. I learned nothing. I had no time for that, because none of it was relevant. I'd simply missed a bracket very early on in the program, wasn't experienced enough to see it, and that was that.

I did learn something critical though, later on, from a friend: "here, use this NetBeans program and turn on 'syntax highlighting' and check out how it points out 'syntax errors' just like how a word processor highlights spelling mistakes". And from then on I could actually learn programming, and later on that semester we learned about javac and putting stuff together on the command line and big O notation, and all the rest of that good stuff that people have moral panics about not starting with.

It's like everyone's decided to have absolutely zero concept of time, or parallelism, or that students spend more than 15 minutes in their entire life studying before being ejected into the workforce to spam tech debt everywhere. They're taking multiple courses in parallel per semester, followed by more semesters of more courses, followed by more years or more semesters. There's time to learn more than one thing, and space to not have to learn it all in the same place, and a student studying one thing at a time when they're starting from zero is not mutually exclusive with them becoming a skilled programmer who enters the workforce and writes quality code to create useful programs.

A better idea might be two-pass learning:

The first pass: Something pure like Structure and Interpretation of Computer Programs, but more approachable for freshmen. And a more beginner-friendly language like Python is preferable. The key is to: 1) Focus on the idea of computation without any distractions. 2) Be less scary. I remember how I gave up C++ several times when I tried programming all by myself when I was a kid. A decade later I decided to try again, and it's fun because it's JavaScript and I can make useful stuff from day 1.

The second pass: Something like Computer Systems: A Programmer's Perspective. It goes down to the implementation rabbit hole, don't skip the essential details and tools, making the students well equipped to deal with real-world problems.

They do have the examples at https://composingprograms.com/pages/17-recursive-functions.h... but no where one the whole page is the word "overflow" or "stack" even mentioned. Almost as if one does not want to mention, that recursion is a bad idea in Python in cases, where you do not know about recursion depth, because of the limitations of Python itself. So the book is teaching an approach, that often might not be a viable good solution, simply ignoring the problems of the chosen tool. On the surface the book looks like good teaching material, but these problems need to be stated, so that beginners know about them.

Don't get me wrong. This is already a much better learning experience than with most C/C++ tutorials, but it definitely leaves things to be improved.

Knowledge about the lower level stuff is probably nice to have, yet not really needed to be productive in a professional capacity within the industry, unless you're not using any sort of a build system (a red flag, if you expect to manage dependencies easily), or are doing something more advanced and specific. It's like using a Linux distro daily but not really knowing how to or caring for compiling your own software - when the Wi-Fi drivers fail to work in new hardware that'll probably become relevant, but otherwise not necessarily.

However, i'd also like to go into the opposite direction and warn against the dangers of not introducing students to higher level tools like IDEs and linters properly. I was one of the unfortunate few who were also taught Java in university and had to write it on paper, as well as in Eclipse/NetBeans. The problem was that none of the staff ever introduced us to the actual capabilities of the IDE, or told us about alternatives like the JetBrains products, or talked about readability or refactoring at all (neither in Bachelor's, nor Master's courses in CS).

Thus, i saw some students write code without readable indentation, comments or understandable variable names, treating the entire Java language like some pseudo assembler and happily ignoring any and all of the IDEs suggestions to fix errors or improve the way their code was written. Not only that, but they were also not familiar with any of the refactoring tools, even the more basic ones like extracting a variable or a method, or renaming variables, or even code generation capabilities like getters/setters, equals/hashCode, toString, constructors/builders and so on.

To them, these IDEs were just like using Vim at a very basic capacity - knowing how to enter the insert mode and not much more, thus gaining no actual benefit from the tool in the first place, though actually working in the industry would probably teach this to them, due to the necessity to follow code style guides or refactor code in legacy codebases.

TFA doesn’t say that. It says to teach entry level students about control structures and such, and then, after two semesters or so, to teach them about those internals.

Moreover, most are thinking that all who are thought programming are going to become professional programmers - like the class success rate of a 100% is a given.

But unfortunately, no. Most intro into programming courses are dealing with the issue "how to get these people over the 'hump' and not quit" and nothing more.

But I saw this as the main barrier at ALL levels and in all classes. People who could understand algorithms and linear algebra being unable to write a counting for loop that iterates over an array without looking it up and carefully copy pasting it.

There's just an innate familiarity with the text of your program and how it translates to an AST that you MUST command. And having tools that can "did you mean" auto-fix things doesn't help, especially with imports, when almost languages have non-trivial import systems.

I obviously encourage teaching modern IDEs but I think we would do students a disservice if we didn't make them use a fairly plain text editor for most learning. I started with BlueJ which provided a "compile" button and syntax highlighting and that was about it, and I was then later (after having stopped using bluej of course) confused by people who were using eclipse but couldn't get their imports working right.

Maybe that's my main point actually: none of these tools are good enough that they let you actually not understand the underlying system. They're just time-savers/auto-completes, which can confuse newbies.

All those misspelled import errors and command line tools help make it far more easy than configuring an intimidating tool like eclipse/jetbrains.

By all means, introduce students to coding using the easiest, most engaging method possible. To me, that's seeing something big, visual, and getting right into the code as soon as possible, like using an IDE with a mostly working sample project they just need to finish something easy in.

Thing is, a good course should then, at some point, force the learner to understand what's happening under the hood, or at the very least, be interesting enough to draw them to want to understand it.

I don't really use eclipse, but the Visual Studio example, it would be as simple as looking at the output window after hitting "run" and walking through what the IDE is actually doing in the background.

I disagree with this point. Universities should stop driving students into the arms of proprietary software vendors. Eclipse does the job and works well enough, with a license, which does not limit students later on. If they learned Eclipse, they will be able to learn other IDEs later on, if the job requires it.

Of course it would be good, if somehow for a low cost in frustration and time, students could learn about what it all translates to on the command line.

We dance around it all the time, but there is no way around inherent technical complexity of this field.

I started out with Python and Project Euler, went through JS and web apps "ELO hell", picked up some C to understand lower levels, ended up with a microcontroller - then went all the way up to category theory and Haskell / Scala coding.

If you ask me if I know how to code, my answer is all the more resolute - It depends.

More practical personalities will definitely manage better in current landscape.

But the sands are always shifting.

The problem is that those students will end up in the workplace one day and someone in the team will have to help them solve problems that are out of the scope of the project and could be worked around by knowing the proper tools

anecdotal example: I spend at a least 4 hours a week helping colleagues fix Jetbrains shenanigans that could be non-blocking if only they knew basic mvn or git CLI

It's not uncommon to see astronomy and biology professors lamenting that their students don't understand file directories, or realize that a file can be opened by different programs.

Exactly the same

We like to discuss the gap between university and enterprise but for once both a totally (ironically) aligned: interviews in big companies are like this, with a whiteboard instead of a sheet of paper.

It's a good primer before they write compilers in their latter years in a CS degree.

Erm what? Click "build", and IntelliJ shows all compilation errors with their locations

Then you see them in package/project view too. Each package, project and file with error has red icon with it.

IntelliJ does not show them in project view at all. It shows them only after you pressed "build", so you need to develop the habit of pressing it constantly. Oh, and the console shows exactly one error. The others are hidden in separate view view, inside collapsed nodes and you have to click multiple times to see them.

It does better than that: it shows them directly inline with your code, with all the tips and hints and refactorings to make it work.

When you change something to be incompatible with existing code, it will immediately show a handy link inline to display all the places across your code that depend on this code and are now problematic.

There's a problems view that has an overview of all problems in the current file and in the entire project (but true, a single overview of the entire project only appeared sometime in 2020)

I was forced to program Java without an IDE and my experience is that I learned less in all those lessons over a year than in a few select days at work during my first year.

Furthermore, according to a friend who is a specialist teacher this is a common problem:

Most kids are inclined to see how things works as a whole while most teachers want to teach analytically by tearing everything apart.

I'm grown-up now and don't mind diving deep into stuff (in fact I enjoy it) but in my understanding we really should try to go with the flow when teaching:

Teach kids the wonders of programming (and everything else) and then go into the details as needed.

Because, if my friend is right and I understood him right (he doesn't teach programming) most kids doesn't want to learn programming because they want to know how to please javac but because they want to create cool stuff.

It doesn't say you shouldn't use and IDE to teach students.

It says you should avoid professional IDEs and at some later point you shouldn't neglect teaching them about other things like compilers and files. At some point they should have an understanding of how some of the underlying mechanics that a professional IDE abstract away.

Also it's about teaching adults at University, not kids

Do one (ideally) start in a new, safe car or in an old one with unsyncronized stick shift (the ones where you need to match the engine RPM before the gear lever will enter).

Because that, in my eyes, is how programming is taught many places.

Edit:

What is the result of all this?

It takes longer time to grasp the easy parts and the parts that fuel motivation. People drop out.

What if we instead taught students using proper tools (e.g. non nerfed versions of Eclipse, IntelliJ or NetBeans for Java) and then used the time we saved in the beginning to dive deeper and deeper towards the end of the course?

The article suggests using a simpler IDE.

You don't learn to drive in a formula 1 car

So if we go with the assumption that university is meant to prepare for a job in the industry, and that industry uses “professional” IDEs in 99% of the circumstances, then university shuold use IDEA and Eclipse too.

Virtually everything is designed such that there are different versions for people if different skills. Golf clubs, bikes, skiis, you name it.

University is about education. Learning about computer science concepts, not churn out Java eclipse programmers.

There's no reason to use a tool designed to do work on an enterprise codebase to teach the concepts behind a linked list.

A debugger makes it far better to understand the execution of code line by line, and should be standard in education, but it's not.

I feel that visual studio code, with some modifications, would be perfect to begin with. Then when building things at a higher level, introduce why to use eclipse, like how it handles packages, etc.

In practice, from what I've seen teaching programming (not using Eclipse nor Java), this tends to cause "debugging tunnel-vision" instead, where someone will just keep stepping through code that has a problem, and not even know what happened until the wrong result was seen.

Anyway, when I was a student in University, most of my colleagues knew the command line and had a strong understanding of operating systems. By the time we did the OS courses the only things we had to learn was about the more advanced architecture, system calls.

As a working professional the IDE is a huge time saver. From quick refactoring to debugging, to step through, to step into, to watch memory, to renaming, to jumping to definition, to method or variable exploring, to function definition, to writing common patterns, to running unit tests, everything sits at one keyboard shortcut away. And the IDE is smart enough to correct my mistake as I am typing, so by the time I hit build, the software builds without errors.

Without an IDE, my development time will take longer.

And why shouldn't someone who is aspiring to become a professional not use the tools a professional uses?

If anything the IDE showing his mistakes might make it a more pleasurable experience since he doesn't have to search Google or Stack Overflow as often. And by having a good experience, he will be encouraged to learn.

I'm glad someone mentioned this. When I was learning programming for the first time, the Eclipse debugger help me to understand for/while loops, because I could see exactly how the computer behaves, as it runs through my code line by line.

The trick is to 'teach' debugging with the least friction possible. Evaluating the code in your head and comparing with what you observe is the underlying concept, the rest is tools, and they need to get out of the way.

As for the OP, I learned java with notepad+CLI and it was terrible. So demotivating. When I discovered Eclipse, I became so happy with java and programming, 'create class', move stuff around, nice autocompletion, find class, refractor, automatic online build, correction suggestions. And I'm a 'using the mouse breaks my flow' old fart. Yes eclipse is buggy, heavy, but damn does it make a difference. It's the standard I compare any IDE to.

I understand CLI is useful for scripting, but outside of that I'd rather not deal with it.

For example, in my C++ course there are some strict requirements on how the code should be formatted. They're specified like this: install this specific version of clang-format on this specific Ubuntu 20.04.3 and run it with this flags having this config in this directory. Fortunately enough, installing and using clang-tidy on Windows and macOS yields exactly the same results in about 90-95% cases (the probability space is the space of all programs that students write during the year; not the space of all configurations).

Of course, one can and is encouraged to attach clang-format to their favorite IDE like CLion.

It's impossible to make all students use the same OS comfortably: macOS wouldn't run on non-Macs, Windows costs extra money, Linux consistently does not work on about 10% of laptops unless a specialist spends five hours messing with Wi-Fi firmware/touchpad drivers on each laptop individually. Installing Desktop Linux in a VM is terribly slow as well.

However, requiring command-line only version of Linux is much better: it takes less HDD, it requires less RAM, it does not have slow GUI (as it does not have any GUI), and you don't really need to use it all the time, only when you submit the solution.

Switching to web-based IDEs do not help: there are some power students who want to use their favorite vim/emacs configuration and compile locally instead of trying to catch 3G signal while commuting in a subway from the dorm to the university.

Linting/formatting with the same configuration should provide the same results on all operating systems, unless there is an issue with the tool used.

Easy workaround would be to provide a Docker image with necessary tools to perform linting/formatting, which would ensure everybody can use it, and should produce the same result everywhere.

Docker is a good idea, actually. Should be easier to set-up than a Linux VM. Still, it's a CLI tool.

Exactly. So the flexibility and power to pretty much anything you want.

Compile and test every single commit on this branch, easy.

Being fast, responsive and working on remote machines is also a big plus.

You can also use CLI tools at the same time as using an IDE

At which point, you are using an IDE, instead of running javac!

My first programming intro (I did EEE) was in MATLAB, where this isn't an issue. When we moved onto C/C++, though, this was an enormous headache. Even after a couple of years in industry it could be a massive pain the arse in terms of configuring CI/CD and porting it cross platform.

To be honest, I think the best way to solve this is not so much to use IDEs that handwave over things, but a beginner-friendly, useful language where the problem simply doesn't exist - namely Python.

Python? I would rather tech my child Lisp or C , white space being important is very confusing.

For first time programming I would make a simple language that uses syntax like: if end_if for end_for function end_function then it would make more sense then tons {} or stupid tabs and spaces.

More generally, no program will be easily readable to a human without indentation. Having to scan aheas to find the endif, then find back where I was, then keep a mental note of the "block" of code that I'm looking at is really annoying, while indented blocks make that separation visually obvious. So if we already have to use indentation for our own sanity, why do we make ourselves add clutter like end statements for the compiler's benefit, when in reality, it has absolutely no problem understanding our indentation directly?

I don't like identation, it is easy to mess it around if you copy and paste code, or if you make edits, is like we would background color the blocks of code, it might look more visual but will cause issue when we actually manipulate the text.

It is a shame that at the beginning of learning to program you are hit with this many concepts and on top of that with this complex programming languages , why we did not invent a simple , more limited but perfect for teaching one? I assume some will say why should we waste time teaching a toy language when we can teach the real thing.

But when it comes to teaching the core idea of encoding an algorithm with lines of text, the main thing seems to be that the less syntax there is to think about, the better. Parentheses, brackets, semicolons, variable declarations, etc. are all in the way. We have two very good languages for this - Python and Lua. I much prefer Python for many reasons, some of which I explained earlier, but Lua also works very well.

The copy-paste issue is real though, I'll give you that. Modern editors (e.g. PyCharm) completely solve it, but when using less sophisticated tools, it is a pain. Still, I can't imagine teaching programming without indentation being an important part of it and Python conveniently forces you into it. Perhaps Lua with format-on-save would be better in this regard I might try that some day...

When I teach my son I always tell him "when you open the ( or { always add it's matching closed one (if teh editor does not do it and only after you closed it you add your stuff in.

So for a for I teach him to start with for(){} then fill in the stuff. It makes sense to be more explicit. We did not have issues with types though, it makes sense that int and float are different things and you need to be clear about it.

With Python, that last issue was basically gone, since the layout of the code is the thing that instructs the interpreter. Getting the syntax correct wasn't an issue in either of the languages, but this time, correct syntax necessarily also meant nice layout. The students' code was much more similar and that made it easier to guide a large group through analyzing their code to find problems.

The way I transition students from flowcharts to code is through an intermediate "step list" notation that they're already used to from procedures they learn in chemistry and other lab classes, as well as generally in instruction manuals. That notation often uses nested (indented) sub-lists, which are almost directly copyable to Python. If I didn't have that step, perhaps the benefit of Python code layout wouldn't be as pronounced, but I think this way of teaching is generally beneficial, even when not targeting Python.

Some notes from the Python classes: the editor should be configured to turn tabs into spaces - no tab character should ever reach the file, even if copy-pasted (I'm 100% on team tabs, but they're horrible for beginners in Python). Skip "idiomatic" things that seemingly simplify code (open file contexts, "or default" expressions, ternaries...) and instead use longer versions - the less knowledge required the better, despite the resulting code being more "complex". Use f-strings and ignore string concatenation for as long as you can. The turtle library is your friend.

The first experience of most children here (in the UK) at school and elsewhere with programming is Scratch, a visual block-based programming language. So no typing or syntax errors, and very quickly you can makes games etc. It's got its pros and cons.

I'm tempted to share this xkcd, called "Python Environment": https://xkcd.com/1987/

I'd say that Python is an absolutely stellar language when it comes to readability and getting things done thanks to its rich ecosystem, but at the same time is about as bad as Ruby when it comes to managing dependencies.

In my eyes, something like Java/.NET/Go could be better choices for when you need to work with dependencies as a beginner, whereas Python is probably the better choice when you don't.

The only issue comes up when you have multiple apps with conflicting dependencies, but at that point you're probably not a beginner anymore and someone will have taught you about pipenv. Just remember to type "pipenv install" instead of "pip install" and all your dependency problems go away. Most IDEs pick it up automatically too.

That's often not the case in my experience. I've had several Python packages fail to compile on my machine (x64, so not even something less common like ARM). Others failed because of missing system libraries without any clear indication what library they're looking for.

It's not as bad as NodeJS's package management, but Python certainly has problems.

Then again, most of these problems aren't really problems for most use cases if you use virtualenvs. I've seen many (ex)academics use Python without venvs and cursing their system for not working properly. This results to pip being invoked as root, subsequently conflicting with the OS package manager and then some cursing about how Python has broken their system. venvs really need to be in the spotlight more often because I think a lot of people have terrible experiences with Python purely because they don't know they exist (or how to use them).

In particular, i remember problems when trying to compile DB drivers for a project, what worked in Windows didn't work in Linux containers and vice versa. I remember having to mess around with the system configuration manually and track down .wheel packages, rather than just being able to do a "pip install" inside of a venv. That was in Python 3, though i don't remember which version it was or the particulars of that situation, so sadly i can't comment more, merely comment that i had problems.

That's actually been the case with most languages and toolchains so far, so maybe my computer is just cursed, or maybe that's just the fact that i use Windows for development some of the time, other times i boot into Linux, whereas containers might run something different like Alpine Linux which has plenty of its own idiosyncrasies.

To import matplotlib, for example, you type "pip install matplotlib" into the terminal to install it.

Then, you add "import matplotlib" to the top of your .py file.

That's it.

also NuGet is no better than pip

For a university software engineering course, it's more than adequate. It's representative of what people in the industry would use, or would have used until a few years ago. It's open source and easily customizable. It has most of the bells and whistles you could want in such a tool. And it runs on modest hardware and more than meets the requirements for implementing some simple toy project for school; which is a big deal when you deal with students working on old/slow laptops.

Are there other alternatives? Of course, many. But it helps having students all use the same thing when supporting them and it helps when that tool is not Notepad or something similarly backwards. I actually taught Java to students back in 1996-1998, trust me dealing with weird/odd/misguided choices as to what to use to edit files was a thing I had to deal with. Actually one of the key things to learn in university is learning new things. So, a slightly complicated but genuine IDE is exactly the right kind of thing to learn to wrap your head around in university.

Unfortunately, it's gotten pretty buggy over the years, and their tooling and process seems very unwelcoming towards new contributors.

I am trying really hard to ween myself off of weighing into this discussion every time it comes up, because it's getting to be the emacs-vs-vi of IDEs, but we should at least stick to factual arguments

Feature comparison: https://www.jetbrains.com/idea/features/editions_comparison_...

Please do stick to factual arguments.

If a student can't handle C/C++ in nano/vim/emacs and debugging with gdb, maybe a computer science degree just isn't right for them.

Also, learning Computer Science has very little to do with programming language or tools. Computer Science is a Science (it's in the name). You can learn about logic, grammars, discrete math, computational complexity etc, without knowing anything about Java or C#.

The point with learning with simple tools is that you learn from first principles with as much as possible stripped down. Most of the time C has a straightforward correlation with the instructions emitted by the compiler, and the language rarely does something behind your back. Try explaining memory management (in detail) to a first year student using JavaScript or Python.

No, it's not. But it's purpose is almost certainly not teaching people how to use CLIs.

None of those CLIs have a lick to do with the 'not writing software' parts of CS. They are an implementation detail, that either helps you solve a particular problem, or get in the way. Most of the time in the undergraduate curriculum, they get in the way.

It is to teach a person how to learn and how to approach problems. If someone does not get it then yes bootcamp will be better for him.

Thought experiment: so where's the degree for people who want practical and applicable skills and an in depth knowledge of actually building systems with the modern tools that are popular within the industry, as opposed to just being familiar with the theoretical aspects? Surely you'll agree that a bootcamp is in no way equivalent to a degree of any sort (due to time constraints in most cases, the very concept means that you won't get 4-5 years of material's worth), nor do the current degrees actually focus on the practical aspects that much.

After getting a Bachelor's and then a Master's in CS, i still feel that the degrees left me unprepared for software development in the industry, since a lot of the things that i learnt while working within a company in parallel wasn't covered at all! And surely we can't expect people to gradually pick up all of the tools and practices as they go along, because not everyone is going to end up in companies that follow the best practices?

Some examples of things that i feel weren't covered enough:

  - organization: issue management systems, versioning policies, team organization (silos vs open communications) and other management aspects
  - organization: release management, ways of shipping software (public repositories of various sorts, using SFTP servers, container registries etc.)
  - practical system design: when to use SOAP, REST, gRPC, GraphQL or others
  - practical system design: the tradeoffs of event based systems, distributed systems, what happens when you have message queues, other ways of dealing with backpressure
  - practical system design: more about horizontal scalability and how to achieve it, versus vertical scalability as well as eventual consistency/single source of truth
  - practical system design: how to do DDD properly and work with bounded contexts, to split systems into logical chunks
  - security: talking more about permission management, ACLs, as well as encryption algorithms and systems for managing credentials (e.g. Vault) and identities/permissions (e.g. OAuth2)
  - security: talking more about VPNs, tunnels, encryption, service meshes, observability/auditing, intrusion detection etc.
  - development: how to efficiently use all that IDEs offer you and how to work with large legacy codebases while limiting the impact of everything breaking, like in the book "Working Effectively with Legacy Code"
  - development: proper testing, not just saying that tests are important and giving vague examples of unit testing, but a course that would focus on nothing but the many ways of testing, everything from unit tests, integration tests, browser automation, performance testing and getting to 100% test coverage whilst also ensuring that no CI steps pass when it falls below that
  - development: speaking of which, CI should also be covered more, everything from Jenkins, to GitLab CI, GitHub Actions, the benefits of all of these, as well as the tradeoffs that are there, how to setup your project's build steps and tests in a fully automated way
  - ops: how to manage servers, use something like Chef, Puppet or Ansible, install packages, properly configure permissions and a bit more about all of the POSIX cruft that has accumulated over the years and that you'll have to deal with as well as everything from creating systemd services properly, to navigating the filesystem
  - ops: using log shipping systems (like Graylog), monitoring systems for the servers (like Zabbix), performance monitoring systems for the applications (like Skywalking APM), analytics systems (like Matomo)
  - and so on...

Yet, the current outcome is that people learn a lot about theory and two people with similar knowledge in that regard might have wildly different outcomes overall, because one of them would get to work in a company that follows best practices and lets them learn a lot of new things, whereas the other ends up in a body shop where their knowledge is silo'd and they can't learn much, instead just writing code to meet the business goals.

Perhaps universities fail at doing this, because they're not even trying to - since apparently the industry moves too fast for them to maintain a relevant curriculum. But if that's the case and we as society value formalized education, what other approach would let me learn about all of the above and more, even the concepts and practices that i'm not aware of? It feels like we're still stuck in the medieval approach of "guilds", where people are handed over to those more knowledgeable (senior devs & teams) and learn by doing, which has certain tradeoffs and perhaps isn't the best approach overall.

Many European countries have a two-tiered system of higher education. There are research universities that teach both theoretical subjects (such as CS and history) and research-based applied subjects (such as medicine and law). Then there are vocational universities where the teaching focuses on more immediately applicable skills.

The drawback of a system like that is that people generally consider degrees from research universities more prestigious. As a result, research universities can be more selective with their student intake and their graduates have better employment prospects.

Also, when we are talking about degree-based education, the focus should always be on what is needed 10-20 years from now. The delay from making decisions to getting a nontrivial number of graduates to positions where they are ready to contribute is easily a decade. When there are more immediate needs, the industry has the responsibility to provide the necessary education.

Sounds like a software engineering degree to me.

  - Professional Master Degree in Computer Systems and Qualification of Programming Engineer
  - Bachelor Degree Of Engineering Science in Computer Control and Computer Science

The curriculum was too slow to move otherwise, at least in my opinion - i guess that their way out of that situation is having the "Professional" degree, which requires you to do case studies and spend months working in an actual company, which in my case was just continuing to work at the company that i was already working at during my Bachelor's, which sort of reminds me of the guild/apprenticeship systems that i mentioned previously.

I might be wrong, but the balance between theory and practice ends up at an impasse often. Maybe degrees should just take longer to complete and cover things more thoroughly? Or do we as a society expect them not to be enough to make someone ready for working in the industry, and accept that as something normal?

I started years ago with C++ in HS with Codeblocks and felt like this is painful environment to operate, getting external libraries felt like I needed to copy files manually from the internet; idk whether I eventually figured it out

because then somebody showed me C# and I quickly realized how it makes my life 10 times easier just due to allowing me to focus on actual problem solving instead of fighting with obscure language at its ancient version with probably some random compiler and random IDE cuz in CPP world there's many versions of everything with its own quirks. Bonus points when I have to compile LLVM and it takes 30min and eats whole avaliable RAM where compiling .NET's Roslyn is order of magnitude "cheaper'

Thus, dealing with CPP's "weaknesses" is not a good proxy on your performance during your engineering or master's degree in comp sci.

Let alone that computer science ain't school of programming or using X debugger, it's mostly math and theoretical informatics

2. You're mixing "low-level tools" and "ancient user interfaces". An argument could be made that a student should understand low-level tools, just like a mechanical engineer should understand physics. But there is absolutely no argument to be made for using old-school UIs the same way there's no reason for an engineer to use compasses and rulers instead of CAD. Actually, even that makes more sense, because there might be situations where they won't hve anything else, like in the field. There is no situation where the average programmer would only have access to CLIs.

3. CompSci !== SWE. A CS student developing novel learning-based image processing methods has no need for knowledge of obscure gdb commands and C++'s pointer and dependency voodoo. A SWE student could benefit from that knowledge, but even then, will rarely need more than a surface understanding of it when not actually developing using those tools.

It was fairly typical for me to have SSH-only access to the production/staging server and no other tools than Vim/git to alter/store its configuration.

Not to mention you probably shouldn't be doing that directly in the first place, especially as "just" a programmer. Sysadmins need to deal with CLI stuff, but programmers generally have no reason to. Of course many of us have both of these roles, but that's beside the point. As programmers, we should not even need to see the production server and as sysadmins, we shouldn't need to know things like gdb and proper development in CLI editors.

We have the tools, we just don't use them. How many issues from bad edits in remote scripts could've been prevented if we used an IDE with linting via sftp instead of barebones vim?

Absolutely not always. The SSH may be provided through multiple proxies by a mess of convoluted Bash scripts. Because reasons or compliance or whatnot.

> Not to mention you probably shouldn't be doing that directly in the first place, especially as "just" a programmer.

Yeah, if you have a dedicated sysadmin to start with, and not just a team of five-ten-fifty enthusiasts who are fully comfortable with managing servers themselves.

> How many issues from bad edits in remote scripts could've been prevented if we used an IDE with linting via sftp instead of barebones vim?

Yeah, that would be wonderful.

Mastering vim/git/cli has been the most productive thing I've learnt as a software engineer. It's something I would recommend. Not to freshman student but at some point

I guess you could argue that AlexNet was the product of one very motivated CS student who was very proefficient with C++ and CUDA. This particular skill set had a very deep impact on the computer vision community. Today, how ever, you don't need it because all that has been abstracted away. But someone had to lead the way.

The best progress happens when you have both of these groups, not just one. As well as some application development plebs like myself (jk) to allow end users to benefit from all of that progress.

Having already some experience with other similar but simpler things will enable the students to pick up later on those more advanced things more quickly with less effort, and especially with much less pain.

Also things become simpler to teach as more background is already know to the students. Needing to explain "everything" at once is not a simple task. This will cause a lot of confusion usually as people don't have yet the proper mental models to sort things into. It becomes harder to actually teach things.

My point is: Lessons in itself shouldn't be "the worthiness test".

The goal is to teach people programming, not torture them. You can test and verify the understanding of the things taught in the next step.

Also it's in general much simpler to teach things along a structure where you go form the big picture gradually down to the details instead the other way around — otherwise people may not see the forest for the trees for a long time. Needing to much details only to get basic things going will cause confusion and a lot of unnecessary frustration in my opinion.

Perhaps though the root of these endless discussions seems to be that the name of the degree means different things to different people.

Some see that degree as a way to learn programming, some see it as a route to a doctorate, ultimately to a career in theoretical science, some see it as understanding how hardware works, and so on.

Ultimately since schools, and students, have such a wide interpretation of the term, making blanket statements in any form about compurt science education is always both right and wrong depending on context.

It's perfectly easy to learn to write simple programs using a text-editor and a command-line. If that's too challenging, please stay away from production code!

There's an approach to teaching that's been referred to as "circular learning" - the first time around, you cover most of the basics, then you go around again, deepening your understanding - lather, rinse, repeat. "Spiral learning" is probably a better term. It does require the curriculum to be somewhat integrated, though - not just a bunch of independent, standalone modules.

Like, you can't learn to program without some understanding of computer architecture. It's very helpful when learning computer architecture to have some programming skills. But you get taught these things in separate, supposedly-standalone modules that don't reinforce one-another.

OP wasn't saying "you can't pass the designated curriculum of a CS degree without this arcane knowledge", they were saying you shouldn't pursue it in the first place. There are many reasons to pursue a CS degree, therefore there are many different situations you'd need to evaluate their statement on. It's quite ambiguous.

I did the slog part before I went to university, but there were people who, at the age of 21, decided to try CS, and did the intro courses. Thank goodness for Eclipse, that an English major can feasibly learn enough in a semester not to back out.

Not everyone wants to Go Build Real World Programs, either. Please let’s not raise the bar to exclude anyone who isn’t already and won’t soon be hooked up to a terminal speaking in tongues and reciting the fast inverse square root incantations of their forebears.

Computer science is about conceptual development and research. It's learning what Turing-complete means etc.

Computer engineering is about systems and processes and practical application of the concepts of CS. It's about things like why TLA+ is a good approach to developing safe and effective systems, it's about the SDLC generically and the potential different approaches and their cost/benefits.

Computer programming is a technical skill. It's learning the specifics of a particular environment and language.

Any CS graduate should understand programming, because it's a basic required skill, same for a CE graduate. But specific skills in Java vs C++ vs etc is virtually irrelevant to a grad getting their 1st job. It's also something that any student should have already picked up as a side effect of a competent CS/CE course.

But does a CS grad need to know the difference between agile and Agile and iterative development and CI/CD and...

I'd say no, because it's not particularly relevant to type theory or provability etc. It's also not particularly relevant to ongoing CS research.

Our industry is well short of good CE graduates, because the focus is on the stupid details of languages instead of the conceptual grounding needed to actually engineer.

Same with the dumb interviewing about reversing a list on a whiteboard.

We've adopted the language of engineering, without the actual approach.

Are there any? My son had a summer job in a small recruiting firm in Silicon Valley. Customers (you know them all) had just two requirements:

- a proper degree from top 10 universities;

- 5+ years of experience in the field;

All others need not apply (and there were so many of them - recent Berkeley/Stanford graduates…)

Question is if this should be taught as a part of a degree or of the onus is on the institution. I don't know. But these can be hard and intimidating topics to learn on your own.

That said, I agree with the title but for different reasons. Eclipse is terrible compared to other available options (JetBrains is so vastly superior).

I do agree that Java is a terrible first language to teach, it has so much arcane boilerplate to get through before doing anything useful. Especially the whole "public static void main(String[] args)" incantation you're taught up-front. So many meaningless words for a beginner.

And yes I do agree "how to use your computer" type stuff should be covered at least after the first assignment, things like how to use a terminal and the filesystem as mentioned. And IMO git should never be taught CLI-first, it's way too hard to wrap your head around without the visual of the commit graph. GitKraken does it best, and is free for students.

The boilerplate is annoying, but it's an obstacle that can be overcome. My lecturer/lab tutor for introductory Java just gave us a pre-prepared:

    public class Main {
    
    }

Figuring stuff ON YOUR OWN is what higher education is all about. It is not about teaching one tool or the other and if someone is learning tools instead of "how to learn to use those tools" he is doing it wrong.

Dev work is from my experience mostly about "figuring stuff on your own" and I expect that this should still be main goal of higher education.

I share this view. Not everyone agrees.

Maybe it depends on what you mean by "higher education". I mean a degree. If you have a degree, that should signify that you know how to study on your own, and have a general overview of your degree subject. You should be able to make some sense of a research paper in your subject, even if you can't follow it in detail.

A degree isn't a vocational training course. If you hold a good batchelor's degree, then you should be qualified to undertake a master's degree, which in itself isn't much use, IMO; the purpose of a master's degree is entry-level training in research. You get to find out whether you want to/have the ability to undertake a doctorate.

If what you want is to learn how to do a certain job, then surely a vocational course is more appropriate (the hint is in the word "vocational").

I will not subject my students to managing compilation, classpaths, and dependencies to get on with jdbc (and other abstraction layers).

This sounds strange, but learning how to compile or run a program is, in my opinion, not necessary in the academic context, if that's not one of the goals of that special subject.

I can't find anything on the author's page about being an educator, so I assume they're talking about what they themselves would have preferred.

My contention with the article is that instead of bringing up any real issues that educators have with Eclipse (my list goes on and on), it instead posits that students would be better served by using the command line and `javac`. It strikes me as completely ignorant toward the realities that come from a diverse group of students with varying degrees of prior knowledge. Unfortunately, this opinionated pedagogical thinking makes its way into curriculum all the time.

My opinion, supported by years of physical presence at the head of many classes, is that students are most successful when they have fun. Dealing with the terminal, or really any repetitive process, is not fun. This is why my entire Java curriculum explained concepts through animation and game design (https://www.youtube.com/watch?v=KNphPVif26I), while trying to lift as much of the burden of syntax and the runtime environment.

Eclipse is open-source, and I'd love to see an article that motivates an Eclipse developer to create a kid-friendly version of the software for classrooms.

They are parts of syntax, and any language will have some syntax to learn, and there are always syntactic quirks.

Granted, Python has lighter syntax than Java, but I don't think Java is too verbose for beginner's purposes.

what's out

why is there a period, what does that mean

what's ln

what's pubic

what's static

what's void

what's main

what's String[]

what's args

Java is as verbose as it gets with lots of unnecessary information at a beginner level