Don't Make Students Use Eclipse • Hacker News Board

Re: Don't Make Students Use Eclipse

#241

Post by ethbro » Sun, Apr 12, 2020, 6:41 PM UTC

DeathArrow wrote: post #209

looperhacks wrote: post #205

Earlier quoted context omitted.

The only problem here is using the term "reference" for reference variables. If you would say "these are pointers to objects, but you can't actually do any pointer arithmetic", this would be a non-issue. The pass by value is not the problem here.

C and Pascal and even C++ have a very simple model. An address of a variable is a pointer. You can actually understand how memory is layed out on hardware and why you would want to pass references or pointers instead of copying very large data structures.

I'd sum up my feelings on intro Java as requiring too many "except when..."s.

I understand why (now), but at the time, it just added unnecessary cognitive load on top of already learning hardware models.

C and Pascal require fewer exceptions, despite a larger base knowledge requirement.

Re: Don't Make Students Use Eclipse

#242

Post by sullyj3 » Sun, Apr 12, 2020, 6:44 PM UTC

lazulicurio wrote: post #237

DeathArrow wrote: post #206

Earlier quoted context omitted.

I still feel like C# is a better Java. It has most of Java features, has other features, implemented important features before Java and it doesn't reach Java level of verbosity and bloatness.

I used to feel that way a few years ago, but my opinion has shifted over time. C# has its own issues with verbosity and bloat. For example, although I appreciate the readability increase from overloaded comparison operators, it's a lot of boilerplate to write a class that implements IEquatable and IComparable and overloads all of the related operators.

Check out Rust and Haskell, both have the ability to derive the interfaces/traits/typeclasses for equality and comparison automatically.

Re: Don't Make Students Use Eclipse

#243

Post by pkamb » Sun, Apr 12, 2020, 7:27 PM UTC

saagarjha wrote: post #60

pkamb wrote: post #46

"public static void main string bracket bracket args" "public static void main string bracket bracket args" "public static void main string bracket bracket args" kind of sad that my first exposure to programming of any kind at University was just repeating that mantra.

Wait until you learn that you can use public static void main(String... args) ;)

I gave up Java immediately after that class!

Re: Don't Make Students Use Eclipse

#244

Post by jcrawfordor » Sun, Apr 12, 2020, 8:29 PM UTC

vips7L wrote: post #85

jcrawfordor wrote: post #62

I can't help but feel like this article is less a condemnation of IDEs in introductory teaching and more a condemnation of java in introductory teaching. It feels like the use of Eclipse or IntelliJ in intro CS courses is so common in large part because Java has such relatively complex tooling and language conventions. I've never seen someone intro Python with an IDE, because it's extremely easy to use Python without…

I don't see how java tooling is any more complex than any other language, they all have learning curves. Even Python has complexities around venv, requirements, pipfile etc. C's tooling in particular is probably the worst. You have to learn the compiler, the linker, or a 3rd party tool like cmake or meson. Using an IDE in Java is a choice just like picking PyCharm is for python.

I feel like this kind of makes the point though... while all of this tooling does exist for Python, it's very easy to use Python without any of it at all. So it can be relegated to more of an advanced, 'production-ready' topic, e.g. in a software engineering course. Indeed, I've never seen an intro course in either Python or C that touches on any of this tooling, save one professor who distributed a standard makefile for his intro C course - but I'm honestly not sure why. It usually suffices just fine to have the students call gcc themselves, the projects they work on in the first year aren't big enough to make this cumbersome.

While that's partially true of Java, it's less true of Java. More of the tooling around Java is de facto required.

Re: Don't Make Students Use Eclipse

#245

Post by ineedasername » Sun, Apr 12, 2020, 8:54 PM UTC

LordDragonfang wrote: post #117

ineedasername wrote: post #91

Earlier quoted context omitted.

I think it might be more fair to say the "IDE bad" camp is comparable to folks that would say you shouldn't be able to press the "auto parallel park" button on your smart car to pass that part of the test.

Well, considering being able to parallel park is a really insignificant part of being a good driver, and the biggest complaint I hear on the internet is people apparently not knowing where the turn signal is on their car, perhaps people should be required to know more about the buttons on their car.

Agreed! I can't think of many professional trades where you aren't required to know certain fundamentals just because there are higher level tools available. A trained cabinetry carpenter, for example, likely knows how to make a fancy cabinet door without a CNC router, even if that's how they mostly do their work. I'd venture a guess that statisticians could calculate variance, t-score, f-score, z-score, etc by hand.

I'm not saying you can't be a productive professional without knowing lower-level fundamentals, though I don't think you legitimately lay claim to be an expert in the field without them.

Re: Don't Make Students Use Eclipse

#246

Post by juped » Sun, Apr 12, 2020, 8:56 PM UTC

NoraCodes wrote: post #153

Animats wrote: post #151

"Software Build Processes" is now a field in its own right. There's not just a compiler. There's a build process, a dependency manager, a package manager, a source control system, tools for updating the files those use, etc. It used to be just "make", but now each language has some kind of package management system. Crates, wheels, eggs, containers, boxes inside of boxes - it's complicated. This is all trade-school s…

I basically agree with this. This is why, at the end of the post, I recommend Python in a Ubuntu environment, where the "build process" is a single step (`python my_program.py`), and packages can generally be managed with `apt`, which is a standard tool representative of a large class of tools, which are likely to be used at some point by a large fraction of CS students.

I think Python builds have gotten nearly as confusing as Java builds (judging by how every Python project these days wants me to use virtualenv).

Re: Don't Make Students Use Eclipse

#247

Post by rubber_duck » Sun, Apr 12, 2020, 9:10 PM UTC

shawnz wrote: post #92

rubber_duck wrote: post #84

Earlier quoted context omitted.

IDEs are convenience layers, compilers are essential abstractions - if you don't know how it works underneath the GUI layer you will get stuck really fast and won't be able to troubleshoot when you eventually run in to inevitable problems with IDE, build, compiler.

What makes the CLI interface to the compiler more essential of an abstraction than a GUI interface to the compiler? Just that it is simpler, or that it's been around for longer? A GUI isn't necessarily just calling CLI apps in the background, it could be using programmatic interfaces too.

It could be - but in the majority of cases it isn't - and you will need to fall back to CLI and UNIX abstraction layers when the IDE breaks - because that's the way it's been done since forever and if you want to work with existing (and probably future) tooling and be able to solve the problems when they happen in the layer above you will need to learn the interface used to expose all the functionality to the tools under the hood.

Re: Don't Make Students Use Eclipse

#248

Post by EdwardDiego » Sun, Apr 12, 2020, 9:42 PM UTC

bmn__ wrote: post #228

EdwardDiego wrote: post #54

Earlier quoted context omitted.

It is in my country. We routinely attend jobs fairs put on by their CS departments alongside every other software dev firm, we take on interns in their 2nd CS year, etc. etc. Hell, they're even learning version control (mainly Git, some SVN) in CS degrees now, which was a nice change to see start coming through in the grads we interview. Although we're seeing universities now start offering Engineering degrees in sof…

Don't you have apprenticeships in your country? University programs as I know them prepare the enrolled for a career in science and are typically far removed from concerns of practicability or applicability.

Not hugely, although the current Labour led coalition is trying to make them more widely used. They used to be common place, I'm not really sure what happened.

And even then, we only have them for the trades - plumbers, sparkies, joiners etc.

Re: Don't Make Students Use Eclipse

#249

Post by shawnz » Mon, Apr 13, 2020, 1:14 AM UTC

rubber_duck wrote: post #247

shawnz wrote: post #92

Earlier quoted context omitted.

What makes the CLI interface to the compiler more essential of an abstraction than a GUI interface to the compiler? Just that it is simpler, or that it's been around for longer? A GUI isn't necessarily just calling CLI apps in the background, it could be using programmatic interfaces too.

It could be - but in the majority of cases it isn't - and you will need to fall back to CLI and UNIX abstraction layers when the IDE breaks - because that's the way it's been done since forever and if you want to work with existing (and probably future) tooling and be able to solve the problems when they happen in the layer above you will need to learn the interface used to expose all the functionality to the tools u…

> It could be - but in the majority of cases it isn't

I don't think that's really true, at least for the Java ecosystem which is implicated here. Eclipse does not call out to command line tools for most things, as far as I've seen

Re: Don't Make Students Use Eclipse

#250

Post by Animats » Mon, Apr 13, 2020, 3:08 AM UTC

juped wrote: post #246

NoraCodes wrote: post #153

Earlier quoted context omitted.

I basically agree with this. This is why, at the end of the post, I recommend Python in a Ubuntu environment, where the "build process" is a single step (`python my_program.py`), and packages can generally be managed with `apt`, which is a standard tool representative of a large class of tools, which are likely to be used at some point by a large fraction of CS students.

I think Python builds have gotten nearly as confusing as Java builds (judging by how every Python project these days wants me to use virtualenv).

Yes, virtualenv. A few years ago, I said that "version pinning" was not going to end well, because it would reduce the pressure on library developers to maintain backwards compatibility. Now something equivalent to version pinning is everywhere. Moving forward is tough when, three levels down, some package wants an obsolete version of some other package.