Wanna hack like in the movies?



  • I was using Stumble Upon last nigth and I came across this page:

    As soon as I read the first line, I was interested. Since as far as I know, there are three types of hacking in movies:

    1. The Steven Seagal method

    Pretend to be a cleaner, sneak into an office and go up to a computer. Type in the password (you won't need a user name, ever) and then quickly execute the script called: "Copy all the top secret information onto a disk (NEVER RUN THIS!).bat"

    2. The Hackers Movie method

    Launch Winamp and full screen the Visualisation window, now type really, really fast while staring at the swirling colours and wait for all the electricity in New York to get cut off.

    3. The Tron Method

    Find a machine that allows you transubstantiate your body into a computer program. Enter the computer main frame, which despite being a business oriented data system also happens to be running a fully realised virtual reality simulation. Make friends with a strange creature that claims to be a bit, even though it has three states instead of two. Destroy everything that stands between you and the precious, precious data.

    After reading a bit further, I was sort of disappointed to realize that it is in fact a sort of learn as you go IDE, that tries to teach children how to program in Ruby. I've downloaded it and it does seem to be quite nice, I've never used Ruby before but it did a pretty good job of teaching me the basics in a couple of hours. However, I am a 28 year old professional coder with a university degree and all sorts of experience, so the fact that it can teach me doesn't really prove too much.

    Also, it struck me that perhaps Ruby might not be the best language for children to start with, some of the syntax does seem kind of strange, for example:

    name = ask("Your name please?")
    say("Your name is #{name.length} letters long")
    sleep(name.length())

    I'm not trying to insult Ruby here, but it seems kind of inconsistent that the way you call a method in a string insertion block (without brackets) differs from how you call it in normal code (with brackets).

    So I thought I'd come here and ask you what you all thought of it. Also, do any of you have any children that you could try it out on? I'm genuinely curious to know how well a child would be able to learn using this application.



  • As far as I know, brackets are optional in ruby if you have no parameters. So name.length and name.length() do the same and just the example is inconsistent.

    As for the hackers, you forget the star treck method: To cripple a mission-critical system, simply shoot at the terminal... 



  • @PSWorx said:

    As far as I know, brackets are optional in ruby if you have no parameters. So name.length and name.length() do the same and just the example is inconsistent.

    They're also optional when you do have parameters, you only need to use parens when the parsing is ambiguous (same thing in e.g. haskell).

    So not only are name.length and name.length() equivalent, name.slice 3, 15 and name.slice(3, 15) are as well.

    In the end, the example could've been written

    name = ask "Your name please?"
    say "Your name is #{name.length} letters long"
    sleep name.length

    as much as

    name = ask("Your name please?")
    say("Your name is #{name.length()} letters long")
    sleep(name.length())

    and any intermediate.



  • Parentheses are encouraged but not required in Ruby.  The better question is why they insist that if you use parentheses, they must not be spaced away from the method.

     Also, on the subject of movie computers, why the hell do the screens always make high-pitched noises whenever they display text?
     



  • The War Games method

    1.  Show off your hobby computer to your friend.  Ask, "Wanna hear it talk?"  Plug in your DecTalk and make it say "Would you like to play a game?"

    2.  Hack into a military computer, leaving the DecTalk plugged in.  It says, "Would you like to play a game?"

    3.  Disconnect without properly logging off.  Wait for the phone to ring.  Pick it up and hear "Would you like to play a game?"

    4.  Run screaming from the house.  Every time you get near a pay phone, it rings.  Pick it up.  "Would you like to play a game?"

     



  • @newfweiler said:

    The War Games method

    1.  Show off your hobby computer to your friend.  Ask, "Wanna hear it talk?"  Plug in your DecTalk and make it say "Would you like to play a game?"

    2.  Hack into a military computer, leaving the DecTalk plugged in.  It says, "Would you like to play a game?"

    3.  Disconnect without properly logging off.  Wait for the phone to ring.  Pick it up and hear "Would you like to play a game?"

    4.  Run screaming from the house.  Every time you get near a pay phone, it rings.  Pick it up.  "Would you like to play a game?"

     

    5. Watch the world nearly end in nuclear oblivion before convincing said military computer to play lots of Tic-Tac-Toe to realize the futility of the war game.



  • So that f(x+1), 2 gets interpreted as the comma operator with f(x+1) on the left and 2 on the right, whereas f (x+1), 2 is f((x+1),2)?



  • @bstorer said:

    The better question is why they insist that if you use parentheses, they must not be spaced away from the method.

    The full answer is long-winded and complex, but basically: it's a method for removing a certain class of parsing ambiguities from the language. It isn't necessary if you're willing to use an infinite-lookahead parser or a hand-crafted Turing-machine parser, but if you want to use an LL(1) or LALR(1) parser, you have to choose two or three things from a set of about a dozen quirks. All languages with Ada-like syntax (including C and Java) have to make this choice, and most of them choose to include some of the strange rules in order to guarantee that a program of N symbols can be parsed by a push-down automaton in no more than O(N^2) time (otherwise the worst-case behaviour is exponential, although nobody should ever write a program like that).

    This particular one deals with the question of: when parsing a sequence formed by an expression, an open parenthesis, and some symbols that we haven't examined yet, is this the start of the first argument or the start of the entire argument list? 



  • @asuffield said:

    @bstorer said:

    The better question is why they insist that if you use parentheses, they must not be spaced away from the method.

    The full answer is long-winded and complex, but basically: it's a method for removing a certain class of parsing ambiguities from the language. It isn't necessary if you're willing to use an infinite-lookahead parser or a hand-crafted Turing-machine parser, but if you want to use an LL(1) or LALR(1) parser, you have to choose two or three things from a set of about a dozen quirks. All languages with Ada-like syntax (including C and Java) have to make this choice, and most of them choose to include some of the strange rules in order to guarantee that a program of N symbols can be parsed by a push-down automaton in no more than O(N^2) time (otherwise the worst-case behaviour is exponential, although nobody should ever write a program like that).

    This particular one deals with the question of: when parsing a sequence formed by an expression, an open parenthesis, and some symbols that we haven't examined yet, is this the start of the first argument or the start of the entire argument list? 

    Or:

    Because it looks stupid if you put a space.



  • @dhromed said:

    Or:

    Because it looks stupid if you put a space.



    Well said.



  • Interesting. You seem to know something about this topic, how would you describe Javascript's rule about newlines? [put simply: if the first token after a newline causes a syntax error, and it wasn't a semicolon, put a semicolon before it. What kind of parser does that make javascript?]



  • @Random832 said:

    Interesting. You seem to know something about this topic, how would you describe Javascript's rule about newlines? [put simply: if the first token after a newline causes a syntax error, and it wasn't a semicolon, put a semicolon before it. What kind of parser does that make javascript?]


    An inspiration for Internet Explorer's handling of "quirks"?



  • @Random832 said:

    Interesting. You seem to know something about this topic, how would you describe Javascript's rule about newlines? [put simply: if the first token after a newline causes a syntax error, and it wasn't a semicolon, put a semicolon before it. What kind of parser does that make javascript?]

    That's a classical error recovery rule. Pretty much all forms of parsers can support this without significant modification (off the top of my head, I don't know which ones javascript can be parsed with). It's almost never used because most people consider it better to abort with an error than to execute something unexpected. Javascript's behaviour is slightly insane here.

    Many compilers for semicolon-delimited languages implement a variation on this: if a syntax error is encountered when parsing, skip ahead until we see another semicolon, then continue - but remember the error and abort the process after parsing is complete. This lets them display (almost) all syntax errors in the first pass, rather than having to repeatedly recompile to discover them all.

    Most compiler textbooks have a small section on recovery methods, but they're rarely studied because nobody's found any other really good uses for them.



  • @asuffield said:

    @Random832 said:

    Interesting. You seem to know something about this topic, how would you describe Javascript's rule about newlines? [put simply: if the first token after a newline causes a syntax error, and it wasn't a semicolon, put a semicolon before it. What kind of parser does that make javascript?]

    That's a classical error recovery rule. Pretty much all forms of parsers can support this without significant modification (off the top of my head, I don't know which ones javascript can be parsed with). It's almost never used because most people consider it better to abort with an error than to execute something unexpected. Javascript's behaviour is slightly insane here.

    Many compilers for semicolon-delimited languages implement a variation on this: if a syntax error is encountered when parsing, skip ahead until we see another semicolon, then continue - but remember the error and abort the process after parsing is complete. This lets them display (almost) all syntax errors in the first pass, rather than having to repeatedly recompile to discover them all.

    Most compiler textbooks have a small section on recovery methods, but they're rarely studied because nobody's found any other really good uses for them.

    The disadvantage of this is of course, that such a compiler displays all statements that depend on the faulty line as syntax errors as well - in some cases generating piles of false positives.
    Example: Suppose you have a typo in a variable declaration. The compiler will skip the declaration and proceed with your variable undeclared - and consequently show a "unknown identifier" error for each line the variable is used.

    Granted, most "false positives" can easily be spotted if you have some experience, but it still makes the original, intended feature less useful, because you have to dig the real errors out of a heap of false ones.
     



  • @PSWorx said:

    The disadvantage of [continuing] is of course, that such a compiler displays all statements that depend on the faulty line as syntax errors as well - in some cases generating piles of false positives.

    Example: Suppose you have a typo in a variable declaration. The compiler will skip the declaration and proceed with your variable undeclared - and consequently show a "unknown identifier" error for each line the variable is used.

    Granted, most "false positives" can easily be spotted if you have some experience, but it still makes the original, intended feature less useful, because you have to dig the real errors out of a heap of false ones.

    For this exact reason, IE's "Do you wish to continue running scripts on this page?" question after a modal* dialog has a JS error is pointless. How can subsequent script be considered reliable if something broke further up the stream?

    *) normal windows just do the ol' triangle + vague message + unlocatable line number. Only Modal dialogs show that big, oddly shaped error dialog.



  • @PSWorx said:

    @asuffield said:

    Many compilers for semicolon-delimited languages implement a variation on this: if a syntax error is encountered when parsing, skip ahead until we see another semicolon, then continue - but remember the error and abort the process after parsing is complete. This lets them display (almost) all syntax errors in the first pass, rather than having to repeatedly recompile to discover them all.

    The disadvantage of this is of course, that such a compiler displays all statements that depend on the faulty line as syntax errors as well - in some cases generating piles of false positives.

    I rather suspect that the feature first appeared in K&R C, which had few real dependencies (anything undeclared was int or int()), and has been duplicated in all newer compilers without much serious consideration. It's probably possible to design a better mechanism, but to my knowledge, nobody has done so yet.



  • And then there's the Star Wars method:
         Tell your R2D2 to unlock the system! What? No R2D2? Then use the mighty force!



  • @wf_tmro said:

    And then there's the Star Wars method:
    Tell your R2D2 to unlock the system! What? No R2D2? Then use the mighty force!

     

    using System.Force 



  • @PSWorx said:

    As for the hackers, you forget the star treck method: To cripple a mission-critical system, simply shoot at the terminal... 

    We tried that for a while, with mixed results. Then we found the method of shooting the terminal operator, with much more success. 



  • This post is deleted!

Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.