5 ms·

> but static typing enforces that you always use that function, and can't forget and accidently submit an unescaped string to the database. So you're saying it

by x1 14y ago

> but static typing enforces that you always use that function, and can't forget and accidently submit an unescaped string to the database. So you're saying it is impossible to do this without static typing?

gaius 14y ago
To have the compiler trap accidents for you? How would you do this if a query and a string were the same thing?
- hotlikearobot 14y ago
  He is making the point that you can create a separation between Query and string just as easily in a dynamic language; it just gets caught at runtime (preferably during testing) rather than compile time.
- ufo 14y ago
  That is why you make them separate. You only really start taking advantage of the type system after you learn to encode system invariants and rules into the type system.
- x1 14y ago
  So when the Query is sent to the database MySQL actually receives a Query object and then parses that Query object? ...oh wait, right before it is sent to mysql it is turned back into a string again. My point is that static typing doesn't help you do anything other than verify that the objects being passed are of a particular type. I'm not saying static typing is bad or good I'm just saying that type checking itself is NEARLY USELESS unless you include some sort of validation. Query q = new Query("select * from users where id = (id)"); QueryParam qp = new QueryParam("(id)",25); q.addParam(qp); ResultSet rs = q.execute(); public class Query { public ResultSet execute() { for(QueryParam qp : this.getQueryParams()) { this.getSql().replace(qp.getId(),qp.getValue()); } super.execute(sql); } } That's all type safe. So it should be good right?
  - gaius 14y ago
    Interestingly Wikipaedia lists SQL injection as being mitigated by strong typing (no I did not just edit it!) http://en.wikipedia.org/wiki/SQL_injection http://en.wikipedia.org/wiki/SQL_injection
  - zopa 14y ago
    Yes, you can write a Query type that is vulnerable to SQL injection, if you want to. But if you write a secure version, you only have to write it once. You only have to maintain it in one place. You only need to test it in one place. And if you forget to use your secure Query type, anywhere else in your code, the compiler will yell at you. It's a significant advantage. This is easier to see in a language with a rich, flexible and expressive type system than it is in Java. The writer of the original article used Haskell for a reason.
    - x1 14y ago
      > But if you write a secure version, you only have to write it once. > You only have to maintain it in one place. > You only need to test it in one place. Again, so this cannot be done in a dynamic language? If it can be done, why bring them up? > And if you forget to use your secure Query type, anywhere else in your code, the compiler will yell at you. It's a significant advantage. The only thing the compiler will yell at you is if you passed a type that is not of a Query type. The compiler will not yell at you for getting the current session directly or creating your own jdbc driver for that matter.
      - zopa 14y ago
        > "The only thing the compiler will yell at you is if you passed a type that is not of a Query type. The compiler will not yell at you for getting the current session directly or creating your own jdbc driver for that matter." In Haskell, I'd have a module, Database, that held all my db code. That module would export functions something like query :: Query -> DBResult update :: Query -> DBAction -> DBResult (read those as "query is a function that takes a Query and returns a DBResult.") In the rest of my program, those functions would be the only way to talk to the database. There's your guarantee. Could I, rather than using my nice database module, instead drop into IO and write code to do something vicious? Surely. But now we've moved beyond bugs and into active malice. > "Again, so this cannot be done in a dynamic language? If it can be done, why bring them up?" It's harder. With duck typing, if it looks like a Query it is a Query, no? Even if it drops your table. I'm no expert on dynamic languages, and I'd believe that there are sophisticated object hierarchies that can do these things (at runtime...), but the original article is empirical evidence that real projects get this wrong. Really, though, try a language with a modern type system and see for yourself. I know we Haskell users sound like zealots, but the difference between the Java and Haskell type systems truly is night and day.
chc 14y ago
I think he's saying it won't be automatically checked for you without static typing. Since, you know, that's what type checking is.
awj 14y ago
I don't think anyone is making that claim. You can obviously do runtime inspections of types before building the query, or rely on the "runtime inspection" of getting an exception when the unescaped String doesn't support the Query method being used. It's entirely possible to do this without static typing. It's impossible to guarantee that all database calls use a Query instead of a String without running the code in some form.
papsosouid 14y ago
No, I am saying your strawman is a strawman. You were claiming static typing doesn't help since a string can contain a bad query. Now you are suggesting that you wouldn't write such code in a dynamically typed language anyways? Then why did you offer it as an example of how static typing doesn't help. Of course you can make sure you never actually run the bad query with dynamic typing. I assumed it was obvious when talking about static typing that the difference would be compile time vs run time. With a statically typed language, when you make the error, you get told about it by the compiler. With a dynamically typed language, you find out about the error later, when that code actually runs.
- x1 14y ago
  > Now you are suggesting that you wouldn't write such code in a dynamically typed language anyways? I never suggested that...? > With a statically typed language, when you make the error, you get told about it by the compiler. With a dynamically typed language, you find out about the error later, when that code actually runs. > static typing enforces that you always use that function, and can't forget and accidently submit an unescaped string to the database. So you are really just saying "static typing requires you to use static typing". This has nothing to do with actually writing good code or having any sort of validation. Just that the compiler tells you that you are sending the wrong type... that's what we are arguing about? Look my whole point is static typing by itself gives you next to nothing (See my code example below) without some form of validation beyond static typing. That obviously holds true to dynamic typing as well... I'm not even sure what we are arguing about.
  - sirclueless 14y ago
    > static typing by itself gives you next to nothing ... without some form of validation beyond static typing You mean like the validation you get when you compile a program? Yes, a statically typed program that never gets checked is strictly worse than a dynamic program, but that's the whole point of the type system: you can check it. This argument is a strawman because nearly every language with a static type system includes a validation step (maybe Dart is an up-and-coming counterexample).
  - 14y ago

by x1 14y ago

gaius 14y ago

To have the compiler trap accidents for you? How would you do this if a query and a string were the same thing?

hotlikearobot 14y ago
He is making the point that you can create a separation between Query and string just as easily in a dynamic language; it just gets caught at runtime (preferably during testing) rather than compile time.
ufo 14y ago
That is why you make them separate. You only really start taking advantage of the type system after you learn to encode system invariants and rules into the type system.
x1 14y ago
So when the Query is sent to the database MySQL actually receives a Query object and then parses that Query object? ...oh wait, right before it is sent to mysql it is turned back into a string again. My point is that static typing doesn't help you do anything other than verify that the objects being passed are of a particular type. I'm not saying static typing is bad or good I'm just saying that type checking itself is NEARLY USELESS unless you include some sort of validation. Query q = new Query("select * from users where id = (id)"); QueryParam qp = new QueryParam("(id)",25); q.addParam(qp); ResultSet rs = q.execute(); public class Query { public ResultSet execute() { for(QueryParam qp : this.getQueryParams()) { this.getSql().replace(qp.getId(),qp.getValue()); } super.execute(sql); } } That's all type safe. So it should be good right?
- gaius 14y ago
  Interestingly Wikipaedia lists SQL injection as being mitigated by strong typing (no I did not just edit it!) http://en.wikipedia.org/wiki/SQL_injection http://en.wikipedia.org/wiki/SQL_injection
- zopa 14y ago
  Yes, you can write a Query type that is vulnerable to SQL injection, if you want to. But if you write a secure version, you only have to write it once. You only have to maintain it in one place. You only need to test it in one place. And if you forget to use your secure Query type, anywhere else in your code, the compiler will yell at you. It's a significant advantage. This is easier to see in a language with a rich, flexible and expressive type system than it is in Java. The writer of the original article used Haskell for a reason.
  - x1 14y ago
    > But if you write a secure version, you only have to write it once. > You only have to maintain it in one place. > You only need to test it in one place. Again, so this cannot be done in a dynamic language? If it can be done, why bring them up? > And if you forget to use your secure Query type, anywhere else in your code, the compiler will yell at you. It's a significant advantage. The only thing the compiler will yell at you is if you passed a type that is not of a Query type. The compiler will not yell at you for getting the current session directly or creating your own jdbc driver for that matter.
    - zopa 14y ago
      > "The only thing the compiler will yell at you is if you passed a type that is not of a Query type. The compiler will not yell at you for getting the current session directly or creating your own jdbc driver for that matter." In Haskell, I'd have a module, Database, that held all my db code. That module would export functions something like query :: Query -> DBResult update :: Query -> DBAction -> DBResult (read those as "query is a function that takes a Query and returns a DBResult.") In the rest of my program, those functions would be the only way to talk to the database. There's your guarantee. Could I, rather than using my nice database module, instead drop into IO and write code to do something vicious? Surely. But now we've moved beyond bugs and into active malice. > "Again, so this cannot be done in a dynamic language? If it can be done, why bring them up?" It's harder. With duck typing, if it looks like a Query it is a Query, no? Even if it drops your table. I'm no expert on dynamic languages, and I'd believe that there are sophisticated object hierarchies that can do these things (at runtime...), but the original article is empirical evidence that real projects get this wrong. Really, though, try a language with a modern type system and see for yourself. I know we Haskell users sound like zealots, but the difference between the Java and Haskell type systems truly is night and day.

chc 14y ago

I think he's saying it won't be automatically checked for you without static typing. Since, you know, that's what type checking is.

awj 14y ago

I don't think anyone is making that claim. You can obviously do runtime inspections of types before building the query, or rely on the "runtime inspection" of getting an exception when the unescaped String doesn't support the Query method being used. It's entirely possible to do this without static typing. It's impossible to guarantee that all database calls use a Query instead of a String without running the code in some form.

papsosouid 14y ago

No, I am saying your strawman is a strawman. You were claiming static typing doesn't help since a string can contain a bad query. Now you are suggesting that you wouldn't write such code in a dynamically typed language anyways? Then why did you offer it as an example of how static typing doesn't help. Of course you can make sure you never actually run the bad query with dynamic typing. I assumed it was obvious when talking about static typing that the difference would be compile time vs run time. With a statically typed language, when you make the error, you get told about it by the compiler. With a dynamically typed language, you find out about the error later, when that code actually runs.

x1 14y ago
> Now you are suggesting that you wouldn't write such code in a dynamically typed language anyways? I never suggested that...? > With a statically typed language, when you make the error, you get told about it by the compiler. With a dynamically typed language, you find out about the error later, when that code actually runs. > static typing enforces that you always use that function, and can't forget and accidently submit an unescaped string to the database. So you are really just saying "static typing requires you to use static typing". This has nothing to do with actually writing good code or having any sort of validation. Just that the compiler tells you that you are sending the wrong type... that's what we are arguing about? Look my whole point is static typing by itself gives you next to nothing (See my code example below) without some form of validation beyond static typing. That obviously holds true to dynamic typing as well... I'm not even sure what we are arguing about.
- sirclueless 14y ago
  > static typing by itself gives you next to nothing ... without some form of validation beyond static typing You mean like the validation you get when you compile a program? Yes, a statically typed program that never gets checked is strictly worse than a dynamic program, but that's the whole point of the type system: you can check it. This argument is a strawman because nearly every language with a static type system includes a validation step (maybe Dart is an up-and-coming counterexample).
- 14y ago