5 ms·

It is telling that these "dark corners" all seem harmless compared to what you can find in certain other languages which shall not be named.

by copx 14y ago

dualogy 14y ago
> which shall not be named So... not that telling then.
- tobinfricke 14y ago
  The most egregious example in common usage: PHP. http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/ http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...
  - gngeal 14y ago
    Hah, a nice article. :-) My favourite sentence from the PHP documentation: string create_function ( string $args , string $code ) "Creates an anonymous function from the parameters passed, and returns a unique name for it." So there you are. Of course you can choose to be an anonymous value, but you'll get a name assigned by the state, for free. :-) Fascinating logic, captain.
    - geon 14y ago
      In this case it isn't so weird, since PHP pre 5.3 didn't have first class functions. To pass a function around, you would use a variable containing a string of it's name. create_function was a way to A) not having to define a function separately B) not getting problems with the function being re-defined, since each call would create a new function C) fake closures by generating code. All this should be moot points by now, since PHP has real anonymous functions with closures,
      - gngeal 14y ago
        That's true (except for C), because I can't see how a create_function-defined function closes over its environment), but what I had in mind was the way in which the author of the documentation, obviously one of the PHP core developers, talks casually about "returning the name of an anonymous function". It shows just how much twisted the logic of these people is. But I suppose that goes naturally hand in hand with the cargo cult approach to language design.
        geon 14y ago
        > That's true (except for C), because I can't see how a create_function-defined function closes over its environment), That's why it would be a fake closure. $foo = someNumber(); create_function('', 'return '.$foo.';'); You would generate a new string to be evaluated as the function body each time. > talks casually about "returning the name of an anonymous function". It shows just how much twisted the logic of these people is. I think you read too much into this. The point of an anonymous function isn't to make it not have a name, but to be able to define it where it is needed instead of referring to some specific function name in your code. It also fits well with the way PHP handles "pointers", by storing the name of a variable in another variable. $foo = 42; $bar = 'foo'; print($$bar); // Prints 42.
        gngeal 14y ago
        "The point of an anonymous function isn't to make it not have a name, but to be able to define it where it is needed instead of referring to some specific function name in your code." Actually, its point is to make it a value that can be referenced from any number of bindings (associations between names and values) in any number of scopes. What you're saying is just a consequence of this. "It also fits well with the way PHP handles "pointers", by storing the name of a variable in another variable." Which only shows the deficiency, since any such indirect reference should never refer to a name, but to a binding instead.
- Xion 14y ago
  I think we all know what language (s)he meant. But about those dark corners, I guess the point wasn't to present any particularly nasty gotchas, but rather some precious little lesser known tricks. C has plenty of very well known features you can be bitten by (mostly related to memory management, of course). While the presentation reiterates over some of them, the most valuable parts are about various _good_ parts of the language which are rarely heard of (viz. the usage of `static` inside brackets).
- PommeDeTerre 14y ago
  It's obviously JavaScript and PHP that are being referred to. Of the C "dark corners" that are problematic, it'd be extremely rare to run into them in most real-world code. You'd have to intentionally go out of your way to write code that will trigger them, and this code often looks obviously suspicious. It's very much the opposite with JavaScript and PHP. A world of pain and danger opens up the moment you do something as simple as an equality comparison. The problems that can and will arise are well documented, so I won't repeat them here, but it's a much worse (and unavoidable) situation than when compared to C, C++, Java, C#, Python, Ruby or other mainstream languages.
  - popee 14y ago
    Agreed. Everytime i get back to C it's like coming back home. But first you must study it hard to make it your home. On the other hand javascript (lang i'm using at current job) is like living 'Groundhog Day' with everyday finishing with suicide. Well, not saying javascript is bad language, there are some really great things about it, but it's designed with a loaded gun put on your head all the time :-) I'd also put C++ on list of dangerous languages, because it is trying to fix C problem while introducing OOP (and in newsest standard lambdas and others), so now you have huge base for new and exciting set of ways to kill yourself. It's not even funny that simple languages like lua are getting more users everyday.
pcwalton 14y ago
I'm not sure about that. Not using "restrict" properly can lead to extremely hard-to-diagnose errors which can only be resolved by reading the generated assembler. I've seen several C programs that use "restrict" everywhere as a magic "go faster" device without understanding what it means... The automatic conversions in JavaScript and PHP seem pretty harmless by comparison.
- copx 14y ago
  >Not using "restrict" properly can lead to extremely hard-to-diagnose errors But "restrict" is a low-level micro-optimization, those tend to be tricky. I don't think a sane C programmer would sprinkle that keyword all across the source base, because as you have pointed out it can cause hard-to-diagnose errors. In contrast, the automatic conversions in JavaScript and PHP are an "always on" feature you cannot avoid.

It is telling that these "dark corners" all seem harmless compared to what you can find in certain other languages which shall not be named.

by copx 14y ago

It is telling that these "dark corners" all seem harmless compared to what you can find in certain other languages which shall not be named.

dualogy 14y ago

> which shall not be named So... not that telling then.

tobinfricke 14y ago
The most egregious example in common usage: PHP. http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/ http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...
- gngeal 14y ago
  Hah, a nice article. :-) My favourite sentence from the PHP documentation: string create_function ( string $args , string $code ) "Creates an anonymous function from the parameters passed, and returns a unique name for it." So there you are. Of course you can choose to be an anonymous value, but you'll get a name assigned by the state, for free. :-) Fascinating logic, captain.
  - geon 14y ago
    In this case it isn't so weird, since PHP pre 5.3 didn't have first class functions. To pass a function around, you would use a variable containing a string of it's name. create_function was a way to A) not having to define a function separately B) not getting problems with the function being re-defined, since each call would create a new function C) fake closures by generating code. All this should be moot points by now, since PHP has real anonymous functions with closures,
    - gngeal 14y ago
      That's true (except for C), because I can't see how a create_function-defined function closes over its environment), but what I had in mind was the way in which the author of the documentation, obviously one of the PHP core developers, talks casually about "returning the name of an anonymous function". It shows just how much twisted the logic of these people is. But I suppose that goes naturally hand in hand with the cargo cult approach to language design.
      - geon 14y ago
        > That's true (except for C), because I can't see how a create_function-defined function closes over its environment), That's why it would be a fake closure. $foo = someNumber(); create_function('', 'return '.$foo.';'); You would generate a new string to be evaluated as the function body each time. > talks casually about "returning the name of an anonymous function". It shows just how much twisted the logic of these people is. I think you read too much into this. The point of an anonymous function isn't to make it not have a name, but to be able to define it where it is needed instead of referring to some specific function name in your code. It also fits well with the way PHP handles "pointers", by storing the name of a variable in another variable. $foo = 42; $bar = 'foo'; print($$bar); // Prints 42.
        gngeal 14y ago
        "The point of an anonymous function isn't to make it not have a name, but to be able to define it where it is needed instead of referring to some specific function name in your code." Actually, its point is to make it a value that can be referenced from any number of bindings (associations between names and values) in any number of scopes. What you're saying is just a consequence of this. "It also fits well with the way PHP handles "pointers", by storing the name of a variable in another variable." Which only shows the deficiency, since any such indirect reference should never refer to a name, but to a binding instead.
Xion 14y ago
I think we all know what language (s)he meant. But about those dark corners, I guess the point wasn't to present any particularly nasty gotchas, but rather some precious little lesser known tricks. C has plenty of very well known features you can be bitten by (mostly related to memory management, of course). While the presentation reiterates over some of them, the most valuable parts are about various _good_ parts of the language which are rarely heard of (viz. the usage of `static` inside brackets).
PommeDeTerre 14y ago
It's obviously JavaScript and PHP that are being referred to. Of the C "dark corners" that are problematic, it'd be extremely rare to run into them in most real-world code. You'd have to intentionally go out of your way to write code that will trigger them, and this code often looks obviously suspicious. It's very much the opposite with JavaScript and PHP. A world of pain and danger opens up the moment you do something as simple as an equality comparison. The problems that can and will arise are well documented, so I won't repeat them here, but it's a much worse (and unavoidable) situation than when compared to C, C++, Java, C#, Python, Ruby or other mainstream languages.
- popee 14y ago
  Agreed. Everytime i get back to C it's like coming back home. But first you must study it hard to make it your home. On the other hand javascript (lang i'm using at current job) is like living 'Groundhog Day' with everyday finishing with suicide. Well, not saying javascript is bad language, there are some really great things about it, but it's designed with a loaded gun put on your head all the time :-) I'd also put C++ on list of dangerous languages, because it is trying to fix C problem while introducing OOP (and in newsest standard lambdas and others), so now you have huge base for new and exciting set of ways to kill yourself. It's not even funny that simple languages like lua are getting more users everyday.

pcwalton 14y ago

I'm not sure about that. Not using "restrict" properly can lead to extremely hard-to-diagnose errors which can only be resolved by reading the generated assembler. I've seen several C programs that use "restrict" everywhere as a magic "go faster" device without understanding what it means... The automatic conversions in JavaScript and PHP seem pretty harmless by comparison.

copx 14y ago
>Not using "restrict" properly can lead to extremely hard-to-diagnose errors But "restrict" is a low-level micro-optimization, those tend to be tricky. I don't think a sane C programmer would sprinkle that keyword all across the source base, because as you have pointed out it can cause hard-to-diagnose errors. In contrast, the automatic conversions in JavaScript and PHP are an "always on" feature you cannot avoid.