They reference an improved student centered IDE and then jump into what IDEs are good for and finally that in first or second year:
>What they can’t do, unless they’ve figured it out on their own, is operate a computer outside of the confines of the IDE they’ve been taught. In none of the curricula I’ve seen, through personal experience or reading syllabi provided by other students, is there a place for students to get past the myriad of barriers that constitute the use of a computer in the modern day.
I have to unpack this but first of all, the use of a computer in the modern day for many engineers does involve an IDE, so I question whether that is even a true claim, but continuing the things missing from an IDE are:
> First, in a Java-focused curriculum, it insulates the student from the javac command line program, and the command line environment itself. Second, it catches some basic mistakes and allows the student to defer learning about the finnicky language requirements that aren’t deemed core to the curriculum, like imports and file naming requirements.
I don’t know about others but this didn’t fill me with horror. Those are the things that would make a student in an introductory class want to quit, and the number of drops in CS is already very high. If as the author said it takes 2 to 3 years to grasp control structures, why mess with the finicky software engineering headaches when it’s an added load on the students? By the time they graduate they should have a complete view of the system and in my experience things like the stack, logic gates, and compilation are taught in intro CS, the students are just not forced into it when coding which is really another endeavor.
Here I do agree with the author that some more granularity in the department of CS would help, but I’d argue that would lead to more specialization and fewer graduates who understand the entire system.
>What they can’t do, unless they’ve figured it out on their own, is operate a computer outside of the confines of the IDE they’ve been taught. In none of the curricula I’ve seen, through personal experience or reading syllabi provided by other students, is there a place for students to get past the myriad of barriers that constitute the use of a computer in the modern day.
I have to unpack this but first of all, the use of a computer in the modern day for many engineers does involve an IDE, so I question whether that is even a true claim, but continuing the things missing from an IDE are:
> First, in a Java-focused curriculum, it insulates the student from the javac command line program, and the command line environment itself. Second, it catches some basic mistakes and allows the student to defer learning about the finnicky language requirements that aren’t deemed core to the curriculum, like imports and file naming requirements.
I don’t know about others but this didn’t fill me with horror. Those are the things that would make a student in an introductory class want to quit, and the number of drops in CS is already very high. If as the author said it takes 2 to 3 years to grasp control structures, why mess with the finicky software engineering headaches when it’s an added load on the students? By the time they graduate they should have a complete view of the system and in my experience things like the stack, logic gates, and compilation are taught in intro CS, the students are just not forced into it when coding which is really another endeavor.
Here I do agree with the author that some more granularity in the department of CS would help, but I’d argue that would lead to more specialization and fewer graduates who understand the entire system.