Hacker Newsnew | past | comments | ask | show | jobs | submit | locci's commentslogin

She was involved in a scandal involving a drug called Cronassial, a pharmaceutical industry called Fidia and the Nobel committee. Through various donations, Fidia (at the time a small pharmaceutical company) used the scientist from 1975 onwards to market a new panacea drug called Cronassial (which was banned in the Nineties across Europe as it was linked to Guillain-Barré syndrome and possibly because of the human spongiform encephalopathy scare). The drug was approved thanks to the corrupt hand of Duilio Poggiolini (with the ministry of health) who was finally arrested in 1993. Fidia's "collaboration" with the scientist culminated in 1986 with the Nobel prize, for which Fidia seems to have corrupted at least one of the committee members with 8 million dollars [1], fact that came out during the Italian corruption trials in the first part of the Nineties.

It seems that Fidia's revenue jumped a 1000 folds thanks to Cronassial, apparently from 600 million Lire to 420 billion, with the drug representing 82% of the revenue, but I wasn't able to find a source for that.

It's quite unfortunate Levi-Montalcini never came clean of this scandal, refusing to comment on anything related to Cronassial and claiming ignorance of the facts.

Disappointing as all this might be, NGF is a great discovery which is well worth a Nobel prize and she seems to have been a very good scientist too.

1) Nilsson M. Nobel committee refutes allegations of corruption. Lancet 1995; 346: 763-4.


I have always thought the point of this kind of questions is that as a candidate you are supposed to provide the right answer which you are expected to provide despite all the ambiguities. This, I guess, should measure some kind of broader intelligence which overthinkers might lack.


bind was introduced in ES5 (and previously in most libraries) to fix this

https://developer.mozilla.org/en-US/docs/JavaScript/Referenc...


And trivially easy to shim for older browsers. I would really recommend using Function.prototype.bind instead of the 'var self = this' or library bind functions (such as $.proxy), it's just the way it should be written :)


To confirm my understanding, would the erroneous line from the comment above be rewritten like:

    button.onclick = obj.func.bind(obj);
So un-DRY! It's almost admirable, how blatant a hack this is.


They don't even dodge, which is the staple movement in UT games.


Soren Johnson talks about AI cheating in "Playing to lose: AI and Civilization" http://www.youtube.com/watch?v=IJcuQQ1eWWI&feature=playe...


I'm no pythonist, but I think setdefault would be perfect for the case

http://docs.python.org/library/stdtypes.html#dict.setdefault


I agree. The author uses exception for something that is not at all exceptional. In fact, it will occur at least once. This is misuse of an exception. No one expects Spanish Exception!

Earlier, he uses the map function for no apparent reason. I mean - list comprehension would perfectly fit here.

I still think I have something to learn from the article, though.


it seems there are many tricks you can use: check out the first reply here () (explaining the batman equation)

() http://math.stackexchange.com/questions/54506/is-this-batman...



I tend to use document.forms['foo'].elements['bar'], here's why:

I use the elements collection because the behaviour of adding each input as a property to the parent form element is a mistake.

I use the bracket notation because it highlights the difference between the implementation symbols and the actual data which is being manipulated. What I mean is that I see a property specified with the dot notation on the same level as an identifier and as such its name is just to remind us humans of its purpose, whereas a property accessed using bracket notation is important both to us and to the program since it specifies a data point.


I think this is a recurring discussion from the dawn of coffeescript. See for example: https://github.com/jashkenas/coffee-script/issues/238

I really don't understand why this isn't being fixed: doesn't global by default break encapsulation? I'm probably missing something, but this is the main reason I haven't tried coffeescript yet.


Just to be completely clear, variables are only at top level scope if you declare them at top-level scope. The variables "x" below are completely encapsulated within f1 and f2. The variables at top-level scope are intentional in the code below--I really do intend f1, f2, and how_many_times_functions_have_been_called to refer to the same entity throughout the file.

  how_many_times_functions_have_been_called = 0

  f1 = ->
    how_many_times_functions_have_been_called += 1 # refers to top-level scope
    console.log x # undefined
    x = 1
    console.log x # 1

  f2 = ->
    f1() # refers to f1 at top-level scope
    how_many_times_functions_have_been_called += 1 # refers to lop-level scope
    console.log x # undefined
    x = 2
    console.log x # 2

  f1() # you can call f1, it's at top-level scope
  f2() # you can call f2, it's at top-level scope
  console.log how_many_times_functions_have_been_called # 3, refers to top-level scope
  console.log x? # false, x does not exist at top_level scope


Yes, I probably wasn't very clear: what I meant is that a programmer writing a function somewhere in a program must have a complete knowledge of the scope where the function is and will be in the future, including changes in global variables exposed by the interpreter/browser. In the end I would find me forced to add a prefix to all the variables in order to avoid collisions, just like I would be forced to do, if the language only had a single global scope.

This behaviour seems quite unreasonable to me, but I haven't been able to find explanations about it, other than it's expected behaviour.


Fortunately, what you're describing isn't how it works.

CoffeeScript will automatically declare all variables in the nearest lexical scope it can find. The top-level scope in CoffeeScript isn't global -- it's the top of the file. You don't have to know anything about what values may or may not exist in global scope at any given moment ... all you have to know is what variables are visible in your function's enclosing scopes, just within the file you're working in.


Oh, I see. And you fiddle with globals by manipulating the window/exports object, which I assume are reserved identifiers.

Thanks a lot for clarifying that, it doesn't look that bad this way.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: