Computer Science Canada Turing's Future |
Author: | [Gandalf] [ Sat May 02, 2009 12:02 pm ] |
Post subject: | Turing's Future |
The great debate... Are you anticipating the death of Turing, after all these years? Or would you like to see Turing revived, in the form of OpenT, a source code release, or another revival project? Remember, if Turing were to be revived, it could also be change and improved upon at the same time. |
Author: | BigBear [ Sat May 02, 2009 1:01 pm ] |
Post subject: | RE:Turing\'s Future |
I want Turing to be continued because I only know a little Python and if it was improved with access to API's, fullscreen, speed, and had a lot of the not implemented. I think OpenT and a source code realease are not going to happen, so it will dead even though I wish both of these things to happen. |
Author: | saltpro15 [ Sat May 02, 2009 1:02 pm ] |
Post subject: | RE:Turing\'s Future |
Let it die. It's a good fundamentals language and probably the easiest to start graphics with, but... I'd prefer to see python or even C++ being taught and there's just too many bad memories from using it... like "random environment crashes" "Compile time expression needed" "Stack overflow" "Length of substring index is greater than length of string" <--- I've MEMORIZED that one I've seen it so much |
Author: | Dan [ Sat May 02, 2009 1:03 pm ] |
Post subject: | RE:Turing\'s Future |
I think it is fair to say Turing in it's current form is dead. However i have been working on making the context free grammar for Turing in BNF. Once i have that done i will post it and it could be used by any project to start work on the lexiconal anyaliser. |
Author: | Clayton [ Sat May 02, 2009 2:16 pm ] |
Post subject: | RE:Turing\'s Future |
saltpro15 wrote: "Compile time expression needed"
"Stack overflow" "Length of substring index is greater than length of string" These are not Turing-specific errors. These are distinct logic problems in your code. You'd see the same thing in other high-level languages as well. |
Author: | saltpro15 [ Sat May 02, 2009 2:36 pm ] |
Post subject: | RE:Turing\'s Future |
well I've never had any of them happen in C++... anyway, my point is how the heck is someone new to programming supposed to know how to fix "compile time expression needed" |
Author: | DemonWasp [ Sat May 02, 2009 3:39 pm ] |
Post subject: | RE:Turing\'s Future |
saltpro, your errors are pretty general: "random environment crashes" -> environment setup issues, cross-platform compilation issues, issues with ill-defined portions of C/C++, etc. "Compile time expression needed" -> this shows up as "syntax error on line X at Y" in most other languages. It's the exact same thing. "Stack overflow" -> Usually just "stack overflow", though depending on your compilation flags this one turns into "segfault" or worse "BSOD/Kernel Panic" if you did it really badly, and in root access. "Length of substring index is greater than length of string" -> this usually turns into an index-out-of-bounds exception or a segfault...or worse, incorrect but not failing memory access. There is no way in hell that students should be taught C++ as their first language. |
Author: | bbi5291 [ Sat May 02, 2009 4:25 pm ] |
Post subject: | Re: RE:Turing\'s Future |
DemonWasp @ Sat May 02, 2009 3:39 pm wrote: There is no way in hell that students should be taught C++ as their first language. I am not so sure about that. Yes, C++ has many flaws. But what about the alternatives? Contrast the computer science programs and software engineering programs at UW at most other universities. Computer science is not about graphics, sound, writing games, or impressing friends - at least it was not about these things at my school, although some of them are taught as a minor part of the course - and this is why Woburn students are among the best in computer science in the country. You might argue in favour of programming languages that make things "easier" like Python. I don't think making it easier to code graphics, sound, or anything like that is especially useful to computer science. Turing has been criticized up and down on this forum; I will not say anything more about it. Functional programming languages are more difficult than C++ for sure (I'm trying to learn Haskell right now, and it is certainly quite hard). Virtually everyone here will agree that declarative programming languages are unsuitable (HTML for example). Many scripting languages such as Perl encourage people to write worse code than they would write in C/C++. And as for Java and C#? I see that they have better OO support and better standard libraries. But at the first-year level they basically are C++. On a more general, philosophical note, the flaws of programming languages echo the imperfection of real life, of the people and organizations that we will deal with. No subject taught in school is perfect (with the possible exceptions of mathematics which is perfectly rigorous, and arts that are taken to a sufficiently liberal extent) and we all have the capabilities to deal with these imperfections. |
Author: | Prabhakar Ragde [ Sat May 02, 2009 5:03 pm ] |
Post subject: | Re: RE:Turing\'s Future |
saltpro15 @ Sat May 02, 2009 2:36 pm wrote: well I've never had any of them happen in C++... anyway, my point is how the heck is someone new to programming supposed to know how to fix "compile time expression needed"
As opposed to this error when one tries to use square brackets to index into a C++ string (as you can do with the array-of-characters representation that C strings use and that is still valid in C++): last.cpp: In function `int main()': last.cpp:7: error: no match for 'operator[]' in 'last[last.std::basic_string<_CharT, _Traits, _Alloc>::length [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]]' /usr/include/gcc/darwin/4.0/c++/bits/basic_string.h:680: note: candidates are: typename _Alloc::const_reference std::basic_string<_CharT, _Traits, _Alloc>::operator[](typename _Alloc::size_type) const [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>] /usr/include/gcc/darwin/4.0/c++/bits/basic_string.h:697: note: typename _Alloc::reference std::basic_string<_CharT, _Traits, _Alloc>::operator[](typename _Alloc::size_type) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>] |
Author: | saltpro15 [ Sat May 02, 2009 5:09 pm ] |
Post subject: | RE:Turing\'s Future |
well Prabhakar, all you really need to read is the first 2 lines of the error to fix that... |
Author: | Prabhakar Ragde [ Sat May 02, 2009 5:13 pm ] |
Post subject: | Re: RE:Turing\'s Future |
saltpro15 @ Sat May 02, 2009 5:09 pm wrote: well Prabhakar, all you really need to read is the first 2 lines of the error to fix that...
It's not a beginner-friendly error message. |
Author: | Prabhakar Ragde [ Sat May 02, 2009 5:33 pm ] |
Post subject: | Re: RE:Turing\'s Future |
bbi5291 @ Sat May 02, 2009 4:25 pm wrote: Yes, C++ has many flaws. But what about the alternatives? Contrast the computer science programs and software engineering programs at UW at most other universities. Computer science is not about graphics, sound, writing games, or impressing friends - at least it was not about these things at my school, although some of them are taught as a minor part of the course - and this is why Woburn students are among the best in computer science in the country. You might argue in favour of programming languages that make things "easier" like Python. I don't think making it easier to code graphics, sound, or anything like that is especially useful to computer science. Woburn is successful because the teachers there pay attention to the right details. It is not because they use C++. Introductory programming should be about expressing basic computations in a fashion that lets the student have a reasonable chance of predicting what the result of running their program will be and gives them the tools to resolve a difference between their expectations and the actual result (and by "tools", I do not mean more software, but mental tools). That could involve graphics, sound, or what have you as long as the expressivity is there and the ability to predict is there. What is "hard" about C++ for a beginner is not what is "hard" about computer science. You're conflating several things here. Quote: Functional programming languages are more difficult than C++ for sure (I'm trying to learn Haskell right now, and it is certainly quite hard).
Scheme is far less difficult. Haskell is not a good first language, but after exposure to another functional programming language (Scheme, Lisp, ML) the basics of it are easier than C++. The far reaches of it (type classes, monads) are not, but it's the right kind of hardness (conceptual) rather than the wrong type (esoteric syntax and error messages). (With the right book, e.g. Hutton's "Programming In Haskell", it is much easier, but I know people here are not inclined to purchase and read books.) Quote: Virtually everyone here will agree that declarative programming languages are unsuitable (HTML for example). HTML is not a declarative programming language. It is a declarative markup language. Is Prolog (which is a Turing-complete declarative programming language) harder to learn than C++? I don't think so. Quote: Many scripting languages such as Perl encourage people to write worse code than they would write in C/C++. Many scripting languages are a total mashup of imperative and OO ideas with whatever else looks attractive tossed into the mix. Perl mashes in Unix shell syntax, which only makes sense to those deeply immersed in it. But I don't think you could argue that Ruby encourages people to write worse code than C/C++. Quote: And as for Java and C#? I see that they have better OO support and better standard libraries. But at the first-year level they basically are C++.
Only because Java made a conscious attempt to lure away C++ programmers, and C# made a conscious attempt to lure away Java programmers. Though I agree that neither is suitable for first year, I would rather use either of them than C++. (My agreeing to use any of these would require major coercion. The term "waterboarding" comes to mind.) Quote: On a more general, philosophical note, the flaws of programming languages echo the imperfection of real life, of the people and organizations that we will deal with. No subject taught in school is perfect (with the possible exceptions of mathematics which is perfectly rigorous, and arts that are taken to a sufficiently liberal extent) and we all have the capabilities to deal with these imperfections. You sound like my colleagues who excuse their ill-specified assignments on the grounds that real life provides many ill-specified problems for people to solve. Programming environments, and the machines on which they run, are entlrely human-made. We have not inherited the flaws of a knee joint or teeth equipped for a diet we no longer eat. We can do better. We need to understand the status quo, but we do not need to excuse it, or accept it as inevitable. |
Author: | bbi5291 [ Sat May 02, 2009 6:07 pm ] |
Post subject: | Re: RE:Turing\'s Future |
I did not say that Woburn was successful due to the use of C++. And I stand corrected - I admit to not knowing many of the things you said (you somehow managed to convey that "you don't know what you're talking about" message; am I making an ass of myself?) But I do not mean to assert that C++ is the best language to use for introductory-level courses - I just feel that DemonWasp's assessment was too harsh. There are some things about C++, for example, that really bother me. For example, when it comes to arrays - the inability to dynamically allocate a 2d array and still guarantee its contiguity, or the inability to use anything but a default constructor when allocating an array. I agree that Woburn's success can be attributed to focusing on the right things. And yet we do use C++, with all its flaws - indeed its esoteric syntax and confusing error messages. Perhaps we would be better if we didn't use C++. At least, though, it is clear that actual understanding of computer science is not affected so much by the choice of language, and focusing on the right things is most important. So whereas we might, for example, criticize the use of C++ for professional development, it is not really a key factor in sub-standard introductory computer science education. Quote: You sound like my colleagues who excuse their ill-specified assignments on the grounds that real life provides many ill-specified problems for people to solve. Programming environments, and the machines on which they run, are entlrely human-made. We have not inherited the flaws of a knee joint or teeth equipped for a diet we no longer eat. We can do better. We need to understand the status quo, but we do not need to excuse it, or accept it as inevitable.
I assure you that I despise ill-specified assignments as much as you do. Yes, we can do better than C++. We might even create a programming language some day that combines all the good features of today's languages and dispenses with their bad ones. However, this is not going to be easy to do, and isn't going to happen any time soon. Until then, we still have to choose one of the programming languages that exist today. And the programming language doesn't make the programmer. |
Author: | Prabhakar Ragde [ Sat May 02, 2009 6:43 pm ] |
Post subject: | Re: RE:Turing\'s Future |
bbi5291 @ Sat May 02, 2009 6:07 pm wrote: I did not say that Woburn was successful due to the use of C++. And I stand corrected - I admit to not knowing many of the things you said (you somehow managed to convey that "you don't know what you're talking about" message; am I making an ass of myself?)
No, you're not making an ass of yourself. You are leaning heavily on conventional wisdom, but that's to be expected. Quote: There are some things about C++, for example, that really bother me. For example, when it comes to arrays - the inability to dynamically allocate a 2d array and still guarantee its contiguity, or the inability to use anything but a default constructor when allocating an array. These things are really minor. How about the desire to have its low-level unsafe cake and its high-level sort-of-safe cake at the same time? How about breaking backward compatibility with C for no really good reason (counterexample: Objective-C)? How about a grammar that cannot be written unambiguously, and a template mechanism that is Turing-complete (so possibly non-terminating, with no way for a compiler to tell)? Quote: I agree that Woburn's success can be attributed to focusing on the right things. And yet we do use C++, with all its flaws - indeed its esoteric syntax and confusing error messages. Perhaps we would be better if we didn't use C++. At least, though, it is clear that actual understanding of computer science is not affected so much by the choice of language, and focusing on the right things is most important. So whereas we might, for example, criticize the use of C++ for professional development, it is not really a key factor in sub-standard introductory computer science education. I think you have it backwards. It is not difficult to accept the use of C++ by experienced programmers, but much harder to justify it for beginners. Good instruction can overcome a multitude of sins, but when only average (or worse) instruction is involved, wouldn't it be better to not have those sins to overcome? In other words, when considering an educational recommendation, we have to think about what might happen if it is implemented by someone other than a top instructor. Quote: We might even create a programming language some day that combines all the good features of today's languages and dispenses with their bad ones. However, this is not going to be easy to do, and isn't going to happen any time soon. Until then, we still have to choose one of the programming languages that exist today. And the programming language doesn't make the programmer.
People create better languages all the time. But they're not taken up by others, or there's just one implementation, or they're "not practical", or "there aren't enough libraries", or "Microsoft/Google aren't using it so why bother?". Turing itself is a counterexample to "we still have to choose one of the programming languages that exist today". It was created specifically for introductory CS education, and at the time it was created, it improved on everything else that was available. It was not without its flaws, and as I've said, more were introduced later. But the main criticism I hear of it (besides the fact that it is no longer maintained) is that it isn't used by industry. And the main virtues of C++ and Java seem to be, in the minds of many, that they are. |
Author: | saltpro15 [ Sat May 02, 2009 9:06 pm ] |
Post subject: | Re: RE:Turing\'s Future |
Prabhakar Ragde @ Sat May 02, 2009 wrote: saltpro15 @ Sat May 02, 2009 5:09 pm wrote: well Prabhakar, all you really need to read is the first 2 lines of the error to fix that...
It's not a beginner-friendly error message. I suppose you are right. I guess I set the bar high for what I consider beginner programming. I just love the raw speed of C++. It reminds me of a Ferrari almost, albeit one that likes to randomly explode xD |
Author: | wtd [ Sat May 02, 2009 11:39 pm ] |
Post subject: | RE:Turing\'s Future |
In summation, I believe what Prabhakar Ragde is saying (from a great depth of experience) is that introductory computer science should focus on introducing students to concepts. In theory, it'd almost be best to not even use a computer. But, as in many other pursuits, theory should not always be pursued blindly. Programming becomes necessary as a way to provide students with feedback on what they're learning. If we accept that, then the goal has to be choosing programming languages which are, for lack of a better way to express it, straightforward. Or, at least languages which allow concepts to be expressed in a straightforward manner. I suspect that the creators of Turing actually understood this. It is a reasonably straightforward language in which to demonstrate statically-typed procedural concepts. Aside from its primary logistical failure of not being (at least in a user-friendly manner) cross-platform, and until recently not being freely available, Turing suffers from the fact that it is a reasonably straightforward way to demonstrate statically-typed procedural programming, but is pretty terrible at expressing anything else. |
Author: | Prabhakar Ragde [ Sun May 03, 2009 11:08 am ] |
Post subject: | RE:Turing\'s Future |
Good summary. Yes, the feedback provided by a computer attempting to interpret one's program is invaluable. But that feedback should be as clear as possible for the beginner, as should be the ways in which said beginner is shown how to express computations initially. And the more we use massive industrially-oriented infrastructure in introductory courses, the less this will be the case. |
Author: | saltpro15 [ Sun May 03, 2009 11:43 am ] |
Post subject: | RE:Turing\'s Future |
+karma for Prabhakar from me, wtd will get one too as soon as I can change it again, both excellent points. |
Author: | wtd [ Sun May 03, 2009 11:54 am ] | ||||
Post subject: | RE:Turing\'s Future | ||||
As an example of the feedback being discussed, consider the DrScheme environment vs. Turing. Let's say an intro CS class has just discussed adding two numbers. Now we want to use a programming tool to try this out. Let's fire up DrScheme. After selecting a language and clicking run (this need be done only once), we simply type our expression at the prompt, hit enter and are immediately greeted with the result.
Let's do the same in Turing. I'll type "1 + 2" and click "Run". Hmmm... it tells me there's a syntax error, even though this expression is written correctly. Sadly it doesn't tell me what kind of error it found, or how to fix it. Oh, wait, Turing is a procedural language, so I know I have to tell the computer to print the result for me. But, as a student in an introductory class, I wouldn't know this, so I'd probably be pretty confused. I'll input "put 1 + 2" and click "Run". Okay, now the expected result of 3 appears in a new window. Winner for providing feedback to students on what they've just learned about adding numbers? I'd say DrScheme, but I'll leave that to the reader to decide for him or herself. Of course, we could use C++, as has been suggested. Step 1: open a text editor and start a new file. Step 2: type the following code.
Step 3: save that file. Step 4: teach your students about directories. Step 5: set up g++ on your platform of choice (and heaven save you if its Windows). Step 6: teach your stduents how to use the command-line. Step 7: teach your students how to compile a C++ program with g++. Step 8: have them compile the program they input in step 2. Step 9: have them run the program they just compiled. Step 10: observe that the program outputs 3, assuming they didn't typo. Step 10.5: remind everyone of why they were writing a program to output 3. Step 11: if they did typo, teach them how to debug C++ code. Depending on how competent your students are with basic computing skills, this may take two to five meetings of the class. Neither C, nor Java nor C# are going to be especially more straightforward. |
Author: | Prabhakar Ragde [ Sun May 03, 2009 1:54 pm ] | ||||
Post subject: | Re: Turing's Future | ||||
What is even more impressive about DrScheme is what happens when you do something wrong. The expression that wtd used is in fact a complete Scheme program. You could put it into the Definitions window, hit Run, and see the value 3 in the Interactions window (where he typed in the expression). Suppose the user forgot that + is a function, not an operator, and typed this into the Definitions window and hit Run:
Here is what DrScheme responds with in the Interactions window:
and it highlights the 1 in the Definitions window. This sort of care is not a feature of the programming language, of course, but of the IDE. But all of this is implemented in full-blown Scheme plus many useful extensions. The full power of the language is put to work in the service of its humblest users, the absolute beginners. We need to see more of that. Lots more of that. |
Author: | Prabhakar Ragde [ Sun May 03, 2009 1:57 pm ] |
Post subject: | RE:Turing\'s Future |
(OT: Hmmm, interesting rendering changes in both wtd's message and mine after the second code block, in three different browsers on a Mac. Tony?) |
Author: | Brightguy [ Sun May 03, 2009 6:07 pm ] |
Post subject: | Re: Turing's Future |
Prabhakar Ragde @ Sun May 03, 2009 1:57 pm wrote: (OT: Hmmm, interesting rendering changes in both wtd's message and mine after the second code block, in three different browsers on a Mac. Tony?) Code blocks have a spurious span closing tag and posts are wrapped in two spans for some reason. |
Author: | Dusk Eagle [ Mon May 11, 2009 10:03 pm ] |
Post subject: | Re: RE:Turing\'s Future |
Prabhakar Ragde @ Sun May 03, 2009 2:57 pm wrote: (OT: Hmmm, interesting rendering changes in both wtd's message and mine after the second code block, in three different browsers on a Mac. Tony?)
That really annoys me too. It's best to just type [size=12] and [/size] around your text. Although I would like to know why this occurs. |
Author: | Tony [ Mon May 11, 2009 10:51 pm ] |
Post subject: | RE:Turing\'s Future |
The second code block breaks out of the "postbody" span, so the rest of the post doesn't get the same styles applied to it. I think it might be that the actual generated HTML at fault, not the interpretation of it. Though I wasn't the one to implement the syntax tags. OT of OT: what's the current plant for v4? I would like something that renders a topic page with less than 41 <table> tags (I've counted)... |