Saving newline just in case your keyboard loose them...
-
@morbiuswilters said:
Why not just have a script which tells them if the program will give them an A before they submit? Things like style or non-compiling code are what is being evaluated. But giving them an easy button which just tells them to fix their shit, you just guarantee they never learn to do that stuff on their own.
I don't know, especially when Makefiles are involved, it's not all that difficult to make something that compiles in one environment and fails to compile in another.
-
@joe.edwards said:
it's not all that difficult to make something that compiles in one environment and fails to compile in another.
Argh! I deal with this every day. Come in in the morning, the build is broken. "Works for me." Doesn't work here. "Oops, I forgot to check in one file." Every stinking day.Add in time zone differences – 12.5 hours different. Each step in broken→works→doesn't→oops takes half a day.
-
@HardwareGeek said:
Each step in broken→works→doesn't→oops takes half a day.
There you go. Strong evidence that your organization could have TWO daily builds.
-
@joe.edwards said:
@morbiuswilters said:
Why not just have a script which tells them if the program will give them an A before they submit? Things like style or non-compiling code are what is being evaluated. But giving them an easy button which just tells them to fix their shit, you just guarantee they never learn to do that stuff on their own.
I don't know, especially when Makefiles are involved, it's not all that difficult to make something that compiles in one environment and fails to compile in another.Yeah, but for class projects how complex are the Makefiles going to be? And one of the things they should be learning is how to make builds less brittle.
-
@morbiuswilters said:
@joe.edwards said:
@morbiuswilters said:
Why not just have a script which tells them if the program will give them an A before they submit? Things like style or non-compiling code are what is being evaluated. But giving them an easy button which just tells them to fix their shit, you just guarantee they never learn to do that stuff on their own.
I don't know, especially when Makefiles are involved, it's not all that difficult to make something that compiles in one environment and fails to compile in another.Yeah, but for class projects how complex are the Makefiles going to be? And one of the things they should be learning is how to make builds less brittle.
It seems that we have different grading systems in mind.
Just getting the system to accept your code didn't mean that the assignment doesn't get an F. It was a prequisite for the code getting graded in the first place.
Makefile quality counts for score. Code readability counts, too. ...How about I just say that the code was human evaluated against the strictest standards. Only after it passed the automatic system. So that the TAs didn't need to bother with the... code that was not worthy of consideration.
-
@OldCrow said:
Makefile quality counts for score.
Why are you teaching kids these obsolete relics from 1975!?
-
@blakeyrat said:
@OldCrow said:
Makefile quality counts for score.
Why are you teaching kids these obsolete relics from 1975!?
So that they have an easier time migrating to a proper build system when they finally get tired of Visual Studio's failings. It also teaches them to see the difference in quality between different makefile generation systems.
EDIT: And it's free. Let's not forget that.
-
@Ronald said:
@HardwareGeek said:
Huh? Each step takes half a day; the whole cycle takes two days:Each step in broken→works→doesn't→oops takes half a day.
There you go. Strong evidence that your organization could have TWO daily builds.
Start: Arrive at work. Find build broken. Figure out who broke it. Send email to the other side of the world. Work is blocked rest of the day. Read TDWTF.
+12.5 hours: Culprit arrives at work. Reads email. Replies "Works for me."
+24 hours: Arrive at work. Read email. Reply "Doesn't work here." Work still blocked.
+36.5 hours: Culprit arrives at work. Figures out goof. Fixes.
+48 hours: Arrive at work. Find problem fixed. Meanwhile, another culprit has broken something else. Lather; rinse; repeat.
-
@HardwareGeek said:
@Ronald said:
@HardwareGeek said:
Huh? Each step takes half a day; the whole cycle takes two days:Each step in broken→works→doesn't→oops takes half a day.
There you go. Strong evidence that your organization could have TWO daily builds.
Start: Arrive at work. Find build broken. Figure out who broke it. Send email to the other side of the world. Work is blocked rest of the day. Read TDWTF.
+12.5 hours: Culprit arrives at work. Reads email. Replies "Works for me."
+24 hours: Arrive at work. Read email. Reply "Doesn't work here." Work still blocked.
+36.5 hours: Culprit arrives at work. Figures out goof. Fixes.
+48 hours: Arrive at work. Find problem fixed. Meanwhile, another culprit has broken something else. Lather; rinse; repeat.
The solution is obviouslyviolencegated check-ins.
-
@joe.edwards said:
The solution is obviously
I told my boss last night that I had some ideas about how to solve the problem. His immediate response was "No nuclear weapons." That made me sad.violencegated check-ins.Gated check-ins? We're lucky they check in at all. When we started, the instructions to create a working environment were, "Copy person X's environment, then copy this directory from person Y, and these files from Z..." They still don't know how to use version control correctly. If there are several files that need to be modified atomically (e.g., adding a test requires at least two files -- create a test file, and modify another file to include the new file), at least one engineer appears not to know that a check-in can handle more than one file; he checks in each file individually.
I'm not sure how gated check-ins would work with our tools. But if we figured out how and asked CAD to do it; they'd have to spend 6 months* revising the process spec before they could implement it.
* Hyperbole, but not much. As of this morning, we have 38244 active specs.
-
@OldCrow said:
@morbiuswilters said:
@joe.edwards said:
@morbiuswilters said:
Why not just have a script which tells them if the program will give them an A before they submit? Things like style or non-compiling code are what is being evaluated. But giving them an easy button which just tells them to fix their shit, you just guarantee they never learn to do that stuff on their own.
I don't know, especially when Makefiles are involved, it's not all that difficult to make something that compiles in one environment and fails to compile in another.Yeah, but for class projects how complex are the Makefiles going to be? And one of the things they should be learning is how to make builds less brittle.
It seems that we have different grading systems in mind.
Just getting the system to accept your code didn't mean that the assignment doesn't get an F. It was a prequisite for the code getting graded in the first place.
Makefile quality counts for score. Code readability counts, too. ...How about I just say that the code was human evaluated against the strictest standards. Only after it passed the automatic system. So that the TAs didn't need to bother with the... code that was not worthy of consideration.
Then the automated system needs to give a single submission and auto-fail anything that doesn't pass. Otherwise, you're just making it easy for them to tweak it until it passes.
-
@OldCrow said:
EDIT: And it's free. Let's not forget that.
I love this. Here we are, working with tools which have trillions of dollars of development time invested in them; literally, some of the most complex, expensive pieces of technology in the world. And what do developers do? They turn into fucking dumpster-diving Goodwill customers.
Look, if your company is in such bad shape that "free" tools are a deal-maker, then you should consider sending out some resumes, because that place is about to go into the ground. (Don't send them in TeX format, though, because those get auto-deleted. Pony up and buy a copy of Word.)
And if your company is not in such dire fiscal straits that it can't afford a few thousand in licensing, then you're just wasting the company's time and using inferior tools to do your job.
-
@HardwareGeek said:
"No nuclear weapons."
What about insulin injections? That just causes the victims to go into a nice, peaceful seizure, followed swiftly by coma and death.
-
It's a school, remember? Not exactly rolling in budget dollars, or profiting more from streamlining student work.
Besides that, students should have to do as much as possible by hand (eg Makefiles), to ensure they understand everything that fancy IDE is doing under the hood.
-
@joe.edwards said:
Not exactly rolling in budget dollars
HA! Schools have lots of cash, especially if they want to spend it on tech. Double-especially considering the discounts they get on most software.
@joe.edwards said:
Besides that, students should have to do as much as possible by hand (eg Makefiles), to ensure they understand everything that fancy IDE is doing under the hood.
Before that we have some homework on how LCDs convert electrical signals into visible images. And let's not forget we need to cover the fundamentals of quantum mechanics so they will understand how semiconductors work.
Oh! I almost forgot: we can't delve into semiconductors until we've covered (or should I say "uncovered", heh heh) modern mining practices, so the students are familiar with where these materials come from. So I don't think we're going to have time for Makefiles this year, sorry. Maybe next year, after we cover logic gates, ASCII encoding and single-line text editors.
-
@morbiuswilters said:
@OldCrow said:
@morbiuswilters said:
@joe.edwards said:
@morbiuswilters said:
Why not just have a script which tells them if the program will give them an A before they submit? Things like style or non-compiling code are what is being evaluated. But giving them an easy button which just tells them to fix their shit, you just guarantee they never learn to do that stuff on their own.
I don't know, especially when Makefiles are involved, it's not all that difficult to make something that compiles in one environment and fails to compile in another.Yeah, but for class projects how complex are the Makefiles going to be? And one of the things they should be learning is how to make builds less brittle.
It seems that we have different grading systems in mind.
Just getting the system to accept your code didn't mean that the assignment doesn't get an F. It was a prequisite for the code getting graded in the first place.
Makefile quality counts for score. Code readability counts, too. ...How about I just say that the code was human evaluated against the strictest standards. Only after it passed the automatic system. So that the TAs didn't need to bother with the... code that was not worthy of consideration.
Then the automated system needs to give a single submission and auto-fail anything that doesn't pass. Otherwise, you're just making it easy for them to tweak it until it passes.
Believe me, students aren't going to let a repeatable will-I-get-an-A-o-matic stop them from submitting non-functional WTFs. My professor had a test suite for every assignment, and if you executed it with -v, it would tell you exactly what was causing your program to fail the test suite.
And people still managed to not get 100% on every assignment.
-
@Ben L. said:
Believe me, students aren't going to let a repeatable will-I-get-an-A-o-matic stop them from submitting non-functional WTFs.
Okay, did I say that it would? I said that holding their hand is just going to make it easier for mediocrity to slip through.
@Ben L. said:
And people still managed to not get 100% on every assignment.
Clearly you did not get 100% on reading comprehension sections..
-
@morbiuswilters said:
Before that we have some homework on how LCDs convert electrical signals into visible images. And let's not forget we need to cover the fundamentals of quantum mechanics so they will understand how semiconductors work.
Oh! I almost forgot: we can't delve into semiconductors until we've covered (or should I say "uncovered", heh heh) modern mining practices, so the students are familiar with where these materials come from. So I don't think we're going to have time for Makefiles this year, sorry. Maybe next year, after we cover logic gates, ASCII encoding and single-line text editors.
I wouldn't actually be opposed to any of that, but some belongs in a separate prerequisite class. Seriously though, understanding that compile and link are separate processes is not rocket surgery, and linking your compiled program does a pretty good job of illustrating how your program is actually connected to the shared libraries on the system. Otherwise some moron will get the brillant idea of making all programs statically linked and hundreds or thousands of ignorant programmers will not see a problem with it.
-
@joe.edwards said:
Otherwise some moron will get the brillant idea of making all programs statically linked and hundreds or thousands of ignorant programmers will not see a problem with it.
Shit, dude, that already does happen. But why do you need to write Makefiles to show that compiling and linking are two separate concepts? I didn't have to run gcc with -E before I understood how preprocessing was a separate step from lexing which was separate from parsing, etc..
-
@morbiuswilters said:
@HardwareGeek said:
That would solve the problem, but it doesn't produce quite the same level of emotional satisfaction of something more... violent."No nuclear weapons."
What about insulin injections? That just causes the victims to go into a nice, peaceful seizure, followed swiftly by coma and death.
-
@morbiuswilters said:
@OldCrow said:
@morbiuswilters said:
@joe.edwards said:
@morbiuswilters said:
Why not just have a script which tells them if the program will give them an A before they submit? Things like style or non-compiling code are what is being evaluated. But giving them an easy button which just tells them to fix their shit, you just guarantee they never learn to do that stuff on their own.
I don't know, especially when Makefiles are involved, it's not all that difficult to make something that compiles in one environment and fails to compile in another.Yeah, but for class projects how complex are the Makefiles going to be? And one of the things they should be learning is how to make builds less brittle.
It seems that we have different grading systems in mind.
Just getting the system to accept your code didn't mean that the assignment doesn't get an F. It was a prequisite for the code getting graded in the first place.
Makefile quality counts for score. Code readability counts, too. ...How about I just say that the code was human evaluated against the strictest standards. Only after it passed the automatic system. So that the TAs didn't need to bother with the... code that was not worthy of consideration.
Then the automated system needs to give a single submission and auto-fail anything that doesn't pass. Otherwise, you're just making it easy for them to tweak it until it passes.
EDIT: Forgot quotes the first time.
Depending on the complexity, 3-8 submission attempts are granted. More are granted only if someone points out (and possibly proves) a flaw in either the assignment spec or the submission tool. This has actually happened. (Usually was a whitespace character somewhere in the "example output".)
However, the style-checker tool is freely usable. Obviously students should be allowed to get their indentation just right before unleashing the horror to the TAs' scrutiny. Good TAs are hard to find.
Freely available tools have multiple good points in a school setting. For one, the students can actually write their assignments on their own machines; less strain on the school's IT resources. And even if you got a good deal on some normally-expensive tools, the lisence management schemes are usually horrible and resource-consuming.
Think about it. A machine-specific license will mean that you need to get more machines and secure them somehow. A network-access -based license means that you need to have the licensing server around, VPN servers for students working from home (if license allows), etc.. And personal licenses are right out of the question, since the softfwaremay only be needed for a course or two.
On makefiles specifically. Since Linux compilation tools always ship with Make, and most of the other systems (say, QMake) just produce a makefile anyways and then call Make, makefiles are not going to get obsolete any time soon. Imagine any other system installed on the school servers. Now imagine how often they'd have to update their instructions, and (gasp!) the submission tool itself. Whereas with makefiles the tool is near-eternal. And the instructions have to be updated maybe once a decade. A resource saved is a resource earned.
On the later courses after CS 101 the tools do get more modern. For GUI basics, for example, they used Qt. But for teaching programming basics to the untold masses, I believe the Linux/GCC/make to be the optimar route. At least nobody graduates without ever touching a command line environment.
-
@joe.edwards said:
Besides that, students should have to do as much as possible by hand (eg Makefiles), to ensure they understand everything that fancy IDE is doing under the hood.
And that is relevant because...?
-
@OldCrow said:
On makefiles specifically. Since Linux compilation tools always ship with Make, and most of the other systems (say, QMake) just produce a makefile anyways and then call Make, makefiles are not going to get obsolete any time soon.
If you're teaching Linux, just grab some 8-track recordings of lectures from 1978 because it's not like anything in fucking Linux will ever advance or change ever.
@OldCrow said:
Imagine any other system installed on the school servers. Now imagine how often they'd have to update their instructions, and (gasp!) the submission tool itself.
Once every three years? OooOOooOOoooOOO scary.
@OldCrow said:
Whereas with makefiles the tool is near-eternal. And the instructions have to be updated maybe once a decade. A resource saved is a resource earned.
Yeah but you're teaching obsolete shit.
@OldCrow said:
But for teaching programming basics to the untold masses, I believe the Linux/GCC/make to be the optimar route.
Then I think you're an idiot. You can teach someone programming in Microsoft Access without ever touching a make file, and they'll know it just as well as anybody else. Shoving that obsolete 30-year-old bullshit in their face is just going to create a generation of programmers who think that's the "right way" to do things and will never look for ways to improve the process or make it more accessible. You know, like... OH SHIT THIS HAS ALREADY HAPPENED!
Look, I learned to program in C-64 BASICv2, Microsoft MacBasic, and HyperCard before I ever touched a C compiler. (And when I did, it was THINK C 5 for MacOS which *gasp* *shock* *horror* was a complete, functional IDE which did not use Make.) My experience growing up, working on systems other than the default IBM PC bullshit, has opened my mind so that I can look at the modern software environment and confidently say: this is bullshit.
Fuck. Back in 1996, when I was on the THINK C/CodeWarriors gravy train, even *then* I'd tell you learning a fucking Make file was fucking useless, but hey look at all these great modern tools that do all that bullshit for you so you can just get to fucking work! I had better development tools in THINK C 5.0 on MacOS version fucking 7.1 than anything in the Python or Ruby community does today. You literally can't buy, for a billion dollars, a Python debugger as good as THINK C 5.0's C debugger. That's not fucking progress.
Nobody in the software development field can stand on the shoulders of giants if idiots like you keep shoving them towards Warwick Davis and saying, "here, forget those tall guys, stand on this dude's shoulders."
@OldCrow said:
At least nobody graduates without ever touching a command line environment.
Then I think you're an idiot, and you're discriminatory, for absolutely no reason except your own irrational prejudices. You're not qualified to teach a class of 5-year-olds to not eat the Play-Doh.
-
The year is 4258. blakeyrat the 187th has just completed his first year of high school. He learned how to write programs using Microsoft Visual C# 4256: simply click and drag the pre-packaged programs to the PROGRAM box and the system will design your code for you. Keyboard support was discontinued after Windows 15 (NT 5863.5.23.1) due to none of Microsoft's programs accepting keyboard input anymore. Linux is used by 90% of the population of the world. The remaining 10% are factory farmed chickens, the only surviving non-human animal species. Microsoft converted Windows to use the Linux kernel in 2039 after a year of unexplained constantly occuring crashes.
-
@Ben L. said:
The year is 4258. blakeyrat the 187th has just completed his first year of high school. He learned how to write programs using Microsoft Visual C# 4256: simply click and drag the pre-packaged programs to the PROGRAM box and the system will design your code for you. Keyboard support was discontinued after Windows 15 (NT 5863.5.23.1) due to none of Microsoft's programs accepting keyboard input anymore. Linux is used by 90% of the population of the world. The remaining 10% are factory farmed chickens, the only surviving non-human animal species. Microsoft converted Windows to use the Linux kernel in 2039 after a year of unexplained constantly occuring crashes.
Wow. This would be retarded even on Slashdot. Congratulations, you may have written the dumbest fucking thing anybody has ever written on the Internet.
-
@morbiuswilters said:
@Ben L. said:
Cut him some slack. He's just a kid. When I was his age I . . . . uh, nevermind, even I never said anything THAT stupid.The year is 4258. blakeyrat the 187th has just completed his first year of high school. He learned how to write programs using Microsoft Visual C# 4256: simply click and drag the pre-packaged programs to the PROGRAM box and the system will design your code for you. Keyboard support was discontinued after Windows 15 (NT 5863.5.23.1) due to none of Microsoft's programs accepting keyboard input anymore. Linux is used by 90% of the population of the world. The remaining 10% are factory farmed chickens, the only surviving non-human animal species. Microsoft converted Windows to use the Linux kernel in 2039 after a year of unexplained constantly occuring crashes.
Wow. This would be retarded even on Slashdot. Congratulations, you may have written the dumbest fucking thing anybody has ever written on the Internet.
-
So I take it "stupid" is some weird new way of saying "used the literary device of hyperbole"?
-
@Ben L. said:
So I take it "stupid" is some weird new way of saying "used the literary device of hyperbole"?
It's so cute
-
@morbiuswilters said:
HA! Schools have lots of cash, especially if they want to spend it on tech. Double-especially considering the discounts they get on most software.
But they like to spend it on software that's directly relevant to what they're doing (e.g., grading support software) rather than something that they don't actually use that much. I'm not convinced that they get good value for money having seen how much they spend and what they get for it, but that's a whole 'nother story. Spending on stuff that directly supports the real business isn't automatically a WTF.Plus for many disciplines, developing with any version of VS or its associated tools would make their code less able to run on the existing infrastructure and less able to run with the real data. (Physicists have their own way of doing things and aren't about to change.)
-
@blakeyrat said:
You can teach someone programming in Microsoft Access without ever touching a make file, and they'll know it just as well as anybody else.
Which creates unmaintainable messes. Excel programming does that too.
You know, most compilers will happily compile a code file without a project file. I guess that this makes Bash an IDE.
@blakeyrat said:
Look, I learned to program in C-64 BASICv2, Microsoft MacBasic, and HyperCard before I ever touched a C compiler. (And when I did, it was THINK C 5 for MacOS which *gasp* *shock* *horror* was a complete, functional IDE which did not use Make.)
And if you ever wanted to change to another compiler or another IDE, tough luck. Or, say, another operating system. Or even if you just wanted to upgrade your IDE. Backwards compatibility and all that. Of course, this depends on the IDE.
I've had to use Visual Studio on a few corporate-scale (not too Enterprise'y, thank God) projects. And I've had to recreate a project's settings by hand after the IDE barfed it's project file. And worst of all, I've had to compare Visual Studio project files in an effort to hunt down setting differences between them. It is a horrible experience that I never want to live through again.
So, the minimum that I now require from all of my tools now is that the compilation instructions are in a human-readable file.Granted, writing the makefile myself is a bit of a waste of time. So, I let my tools do that for me. QMake, for example, makes nice makefiles.
But really, all you need to ask yourself here is:Would you be willing to try to keep up an assignment submission system for projects made on some IDE?
Could you even do it?
And would you be willing to spend half your life trying to figure out why some CS 101 student's code doesn't compile on a random IDE?
EDIT: Typos
-
@OldCrow said:
I've had to use Visual Studio on a few corporate-scale (not too Enterprise'y, thank God) projects. And I've had to recreate a project's settings by hand after the IDE barfed it's project file. And worst of all, I've had to compare Visual Studio project files in an effort to hunt down setting differences between them. It is a horrible experience that I never want to live through again.I learned to program onTRS-80 Model I's and III's in BASIC, later some z80 assembly language and Pascal. A teensy/eeensy bit of C/C++, and what little I may have known about MAKE files I have purposely forgotten. So i wikipedia'd MAKEFILE. And read it. And banged my head against the wooden table on which I spell out my posts using magnetic alphabet fridge magnets before taking a picture of them with my cell phone, printing the picture, scanning it and then running OCR to convert the picture to text into notepad, and then copy/pasting it into the message box.
I may be in the vast minority here, but I've been using the Visual Studio IDE in it's various forms since VB 3 and I have never had it screw up the project file unless I did something incredibly stupid.
Of course now that I'm doing 99% web/asp.net applications I can always just delete the project file and use the open website option to bring everything right back into line. And if I want to find out if a dependency changed I can always look at the subversion log for the build. But, whatever.
-
@OldCrow said:
@blakeyrat said:
You can teach someone programming in Microsoft Access without ever touching a make file, and they'll know it just as well as anybody else.
Which creates unmaintainable messes. Excel programming does that too.So will most programming without an IDE with an auto-format command, which is exactly what you're promoting you might remember.
My point was that you can teach programming with *anything* that's reasonably programmable. Access, a graphic calculator, Lego Mindstorm or whatever it's called now, anything.
@OldCrow said:
And if you ever wanted to change to another compiler or another IDE, tough luck.
If your code's portable, it's portable. If it ain't, it ain't. I don't get why an IDE makes that any different.
@OldCrow said:
Or even if you just wanted to upgrade your IDE. Backwards compatibility and all that. Of course, this depends on the IDE.
Ok let's clarify: a non-shitty IDE.
It's pretty ridiculous to come here and say, "never use any IDEs because one IDE at one point had a bug where project files weren't compatible." By that logic we also shouldn't be using: cars, telephones, computers at all, pencils, etc.
@OldCrow said:
I've had to use Visual Studio on a few corporate-scale (not too Enterprise'y, thank God) projects. And I've had to recreate a project's settings by hand after the IDE barfed it's project file. And worst of all, I've had to compare Visual Studio project files in an effort to hunt down setting differences between them. It is a horrible experience that I never want to live through again.
You're either a liar, or working in a den of WTF.
@OldCrow said:
But really, all you need to ask yourself here is:
Would you be willing to try to keep up an assignment submission system for projects made on some IDE?
Sure why not?
If it's worth doing, it's worth doing in a non-WTF way.
@OldCrow said:
And would you be willing to spend half your life trying to figure out why some CS 101 student's code doesn't compile on a random IDE?
No. Your priorities would have to be pretty fucked to answer yes to that question.
-
@Ben L. said:
simply click and drag the pre-packaged programs to the PROGRAM box and the system will design your code for you
I don't know about you guys but this is pretty much the holy grail of our field right here, so Ben is atleast partially on the right track.
-
The benefit of teaching students to use an IDE and taking submissions as IDE project files is to prepare them for what real-life developer work is like. Things like the auto-formatting that blakey mentioned. Or learning to use the debugger. Unfortunately no school will ever teach that - CS teachers tend to be academics, not engineers.
Of course you could argue that the student is free to use any IDE he wishes to format, debug, etc. as long as he gives you a valid Makefile. Personally, I got into CS because I *wanted* to be a programmer, so if my classes wanted the assignments in Makefiles I'd have been happy to learn to write them.
That said, given the number of make alternatives (autotools, cmake, qmake etc. that compile to Makefiles; rake, etc. that don't; all of which aim to improve upon Makefile syntax and general retardation), the industry does agree that Makefiles stink for non-trivial projects.
-
@Arnavion said:
That said, given the number of make alternatives (autotools, cmake, qmake etc. that compile to Makefiles; rake, etc. that don't; all of which aim to improve upon Makefile syntax and general retardation), the industry does agree that Makefiles stink for non-trivial projects.
The biggest advantage of make is that it is there; you don't have to install it first. It can also handle a lot of complexity, provided the semantics of the language are sufficiently compatible. (That rider clause is why you don't want to build Java code with make; Java's “simultaneous definition” semantics really doesn't work nicely with make, and Java code tends to be spread across a large directory structure too, which doesn't help. Don't know the tooling for C#, but I imagine it has similar issues.)
-
@blakeyrat said:
@OldCrow said:
I've had to go through VS project files by hand (but that was a while ago) and was mainly to do with correcting links back to VSS repositories - which you may say falls under the "den of WTF", but IMHO VSS was OK if you treated it right.I've had to use Visual Studio on a few corporate-scale (not too Enterprise'y, thank God) projects. And I've had to recreate a project's settings by hand after the IDE barfed it's project file. And worst of all, I've had to compare Visual Studio project files in an effort to hunt down setting differences between them. It is a horrible experience that I never want to live through again.
You're either a liar, or working in a den of WTF.
-
@dkf said:
The biggest advantage of make is that it is there; you don't have to install it first.
Not on the OS 90% of the world uses.
@dkf said:
Don't know the tooling for C#, but I imagine it has similar issues.)
I don't know what Mono uses, but MSBuild doesn't have any issues. Even if you have to ever actually touch it. Which you don't.
-
@OzPeter said:
I've had to go through VS project files by hand (but that was a while ago) and was mainly to do with correcting links back to VSS repositories - which you may say falls under the "den of WTF", but IMHO VSS was OK if you treated it right.
VSS has been deprecated for like 8 years now. Why the fuck do people keep bringing it up as if it's relevant in 2013?
-
@dkf said:
The biggest advantage of make is that it is there; you don't have to install it first.
Which is why things like waf exist. You write your build script in Python and bundle the whole build system (waf) with your repository.
-
@dkf said:
Don't know the tooling for C#, but I imagine it has similar issues.
The default way of compiling C# is to use MSBuild on the project file. However, MSBuild project files are language-agnostic because you can write any steps you want as "targets" similar to say, Ant. The default ClCompile target compiles C++ files, for example. So it doesn't impose any restriction on whether your project must be compiled one file at a time or all files together.
VS internally uses MSBuild. Mono's IDE MonoDevelop and Mono's equivalent of MSBuild (xbuild) are designed to work unchanged with MSBuild project files and so work the same way.
-
@blakeyrat said:
So will most programming without an IDE with an auto-format command, which is exactly what you're promoting you might remember.
My point was that you can teach programming with *anything* that's reasonably programmable. Access, a graphic calculator, Lego Mindstorm or whatever it's called now, anything.
@blakeyrat said:
It's pretty ridiculous to come here and say, "never use any IDEs because one IDE at one point had a bug where project files weren't compatible." By that logic we also shouldn't be using: cars, telephones, computers at all, pencils, etc.
I never said I was against using IDEs. I'm against people not knowing what happens behind the scenes. And against non-readable project files.
And any of the tools you mentioned would have been hard or WTFy to make an automated submission framework for.
If you'd actually read with thought what I wrote before, you might have caught on to the fact that I rarely write my own makefiles these days.But makefiles are the one form of compilation instruction that is nearly universal in the Linux world. Thus it makes a prime candidate for the phase when the code no longer needs to be changed.
@blakeyrat said:
@OldCrow said:
I've had to use Visual Studio on a few corporate-scale (not too Enterprise'y, thank God) projects. And I've had to recreate a project's settings by hand after the IDE barfed it's project file. And worst of all, I've had to compare Visual Studio project files in an effort to hunt down setting differences between them. It is a horrible experience that I never want to live through again.
You're either a liar, or working in a den of WTF.
Neither. A library was made by another team. Since code re-use is generally a good thing and it was a useful library, it got integrated into a project I was in. Except that it refused to compile and the compiler error messages were not not really helpful. Visual Studio does not have a feature for comparison of settings between projects. You do the math.
That's when I learned to appreciate Qt. It has nice human-readable project files that are easy to compare side-by-side.
@blakeyrat said:
@OldCrow said:
Would you be willing to try to keep up an assignment submission system for projects made on some IDE?
Sure why not?
If it's worth doing, it's worth doing in a non-WTF way.
It's not going to stay non-WTF, since it's going to be left in place for years. CS 101 students are a continuous process. Someone would be afraid of breaking the process. Students would in 2030 have to learn to program on visual Studio 2008. At least makefiles are still good for assignment submissions even today.
@blakeyrat said:
@OldCrow said:
And would you be willing to spend half your life trying to figure out why some CS 101 student's code doesn't compile on a random IDE?
No. Your priorities would have to be pretty fucked to answer yes to that question.
My point exactly. Hence the makefiles. The TAs had an easier time finding the bugs and being actually helpful.
@Arnavion said:
The benefit of teaching students to use
an IDE and taking submissions as IDE project files is to prepare them
for what real-life developer work is like. Things like the
auto-formatting that blakey mentioned. Or learning to use the debugger.
Unfortunately no school will ever teach that - CS teachers tend to be
academics, not engineers.Of course you could argue that the student is free to use any IDE he wishes to format, debug, etc. as long as he gives you a valid Makefile. Personally, I got into CS because I *wanted* to be a programmer, so if my classes wanted the assignments in Makefiles I'd have been happy to learn to write them.
That said, given the number of make alternatives (autotools, cmake, qmake etc. that compile to Makefiles; rake, etc. that don't; all of which aim to improve upon Makefile syntax and general retardation), the industry does agree that Makefiles stink for non-trivial projects.
Oh, we were urged to make use of the auto-formatter in the editor provided, named Jed. After all, no-one wants to read code that isn't formatted right. And there was a debugger, too, although that wasn't part of the 101. And a compiler with very easy to understand error messages. All pre-installed in a cosy environment everyone could access from any public terminal or even from their dorms. ... Or from anywhere with internet. On later courses, IDEs were introduced. But only on later courses when the number of students was down to what would fit into a lab. CS 101 was taught to everyone in my university. Including the Construction- and Materials Tech. department. So, when I say "masses", I mean it.
You mean *with* makefiles, not *in*, I think?
Personally, I use QMake, as I've said. It's very good at providing for the most common tools. I haven't written a makefile by hand since CS 105, I think. But I sometimes have to go through them to check the compiler options. Especially for cross-compiling.
-
@blakeyrat said:
@dkf said:
The biggest advantage of make is that it is there; you don't have to install it first.
Not on the OS 90% of the world uses.
It is on 60% of the world's servers. (According to Wikipedia)
And with CS 101, keeping the tools on the server side is DEFINITELY a plus.
-
@OldCrow said:
I never said I was against using IDEs. I'm against people not knowing
what happens behind the scenes.Fair enough, but you can teach someone what a Conestoga wagon is without having them commute to work in one.
@OldCrow said:
And against non-readable project files.
That's just dumb.
Visual Studio project files are perfectly readable, you just need a copy of Visual Studio installed. Same as any other document type. Open it up and look at the Solution tab. Wham.
@OldCrow said:
But makefiles are the one form of compilation instruction that is nearly universal in the Linux world. Thus it makes a prime candidate for the phase when the code no longer needs to be changed.
True; but the Linux world sucks ass. The problem with teaching CS and using "the Linux world" for all your instruction is that your students will start to think that shitty environment is the state-of-the-art, and what they should emulate. Then they go on to make criminally-awful software like Git.
@OldCrow said:
Neither. A library was made by another team. Since code re-use is generally a good thing and it was a useful library, it got integrated into a project I was in. Except that it refused to compile and the compiler error messages were not not really helpful. Visual Studio does not have a feature for comparison of settings between projects. You do the math.
What math?
1) Why didn't you just use their compiled version? Was it not a DLL?
2) Why didn't you just ask for their project file, and compile it using that? Why were there even two different projects to compare settings against?
3) What math?@OldCrow said:
At least makefiles are still good for assignment submissions even today.
No they're fucking awful.
I think what you're trying to say is, "they're no more awful in 2013 than they were in 2010 or 2003" which I guess is correct.
@OldCrow said:
My point exactly. Hence the makefiles. The TAs had an easier time finding the bugs and being actually helpful.
If you didn't use Makefiles, you'd spend half your life trying to figure out one student's code. No commentary here, I'm just repeating what you said as to clarify the idiocy for people who may not have been following closely.
-
@blakeyrat said:
@OldCrow said:
And against non-readable project files.
Visual Studio project files are perfectly readable, you just need a copy of Visual Studio installed. Same as any other document type. Open it up and look at the Solution tab. Wham.
I would add that VS project files are also very readable in a text editor. As part of my work (as well as for a certain open source project) I have to deal with project files and make modifications to them that are easier to do in a text editor than in the VS GUI. Yes, the XML is more verbose than a Makefile or a qmake project file, but it's not "unreadable".
-
@Arnavion said:
@blakeyrat said:
@OldCrow said:
And against non-readable project files.
Visual Studio project files are perfectly readable, you just need a copy of Visual Studio installed. Same as any other document type. Open it up and look at the Solution tab. Wham.
I would add that VS project files are also very readable in a text editor. As part of my work (as well as for a certain open source project) I have to deal with project files and make modifications to them that are easier to do in a text editor than in the VS GUI. Yes, the XML is more verbose than a Makefile or a qmake project file, but it's not "unreadable".VS project files (at least the ones I've had to manually edit) are just XML.
-
@Arnavion said:
@dkf said:
Oh - does that mean you have to install Python 5.3 first before you can use it? What if it conflicts with Python 1.0 on my system which is used by everything else on there (I exaggerate, but I'm sure you get my point.) @Arnavion said:The biggest advantage of make is that it is there; you don't have to install it first.
Which is why things like waf exist. You write your build script in Python
and bundle the whole build system (waf) with your repository.
Hang on... you supply the whole build system with each package that uses waf? EVERY package duplicates the whole build system? Please tell me I've misunderstood this...
-
@blakeyrat said:
@dkf said:
Look, if you're going to pointlessly exaggerate and use hyperbole, why not call it 110% and be done with it?The biggest advantage of make is that it is there; you don't have to install it first.
Not on the OS 90% of the world uses.
-
@Arnavion said:
Which is why things like waf exist. You write your build script in Python and bundle the whole build system (waf) with your repository.
So you have to build python to build something else. Having seen what a python system depends on, that can take some time when bootstrapping. And then there's the problem that occurs when those other packages try to use waf! It's an infinite sequence of building python to build python!Sometimes, things have to be simple and have really cut down sets of stuff that they depend on. Those things tend to be the foundational software that everything else uses. Yes, you can do complex things like creating restricted versions of a high-level tool in order to build a complex build system, but that tends to be vomit-inducing and is either an indication that you're really needing to cross-compile (because you're building the compiler and foundational system libraries for some reason) or that you're using the tools wrong and should suck it up and use something lower level than yourself. Try to keep the build dependencies arranged as a DAG, even if that restricts your creativity…
-
@blakeyrat said:
@dkf said:
More than 90% of the world doesn't write software. (They're also switching in droves to using fondleslabs rather than Manly Computing Boxes For Real Men, alas.)@blakeyrat said:The biggest advantage of make is that it is there; you don't have to install it first.
Not on the OS 90% of the world uses.I don't know what Mono uses, but MSBuild doesn't have any issues. Even if you have to ever actually touch it. Which you don't.
Probably because it's been written to be aware of the subtleties. I've got no problem with that. That's totally what I'd do in that situation. (The “simultaneous declaration” semantics are one of the better things with Java, and C# definitely has a Java ancestry even if it's changed a lot of things since.)
Someone else mentions that it is conceptually similar to ant. Now I absolutely hate ant, as it takes so much work to make it do anything vaguely non-standard, but it does work for what it does. Maven's better, even if it does manage to totally out-magic automake (you don't want to look at automake; you'd hate it as it is both Free and utterly crappy). But I just don't know the C# toolchain at all.
-
@dkf said:
The “simultaneous declaration” semantics are one of the better things with Java
Could you expand what you mean by this? Google isn't helping and I can't figure out what this could be such that it makes sense to talk about in a conversation about make.
