in reply to On Scripting versus Compiled solutions

The only thing I care about in the debate, is the security dangers of compiled code. You don't know what you are getting, and you run it based on the "trust" of the developer, or download site.

With scripts, you can see what you are getting. And as processor speeds increase, the delay caused by script compiling is becoming negligible.

I do not trust any Microsoft code anymore. I am becoming increasingly suspicious of linux binary rpms, especially from distributions with alot of "corporate ties", or whose primary goal is to make money.

I'm not really a human, but I play one on earth. flash japh
  • Comment on Re: On Scripting versus Compiled solutions

Replies are listed 'Best First'.
Re: Re: On Scripting versus Compiled solutions
by RMGir (Prior) on Mar 09, 2004 at 17:32 UTC
    With scripts, you can see what you are getting.

    You haven't been looking at the obfu section of this site much lately, have you? :)

    Seriously, given that perl offers run-time eval and a very powerful regex language with side-effects, you have to have just about the same amount of trust in the person that hands you 1000 lines of perl code as you need in 100k of executable.

    Either one could do totally unexpected things without you being able to tell by inspection.

    I'm not saying "scripting languages bad"; what I am saying is that the source being in front of you doesn't mean much.

    And as processor speeds increase, the delay caused by script compiling is becoming negligible.

    There are many areas where that's just not true. A lot of programming problems have time constraints, where if the answer is late it's just about worthless. And those constraints often get tighter just as fast as processor speeds increase.


    Mike
[reply]
      You haven't been looking at the obfu section of this site much lately, have you? :)

      Try perltidy sometime ... Similar tools exist for all major scripting languages.

      Additionally, I can do something with scripting tools I cannot do for any other language - look at how the add-ons I want to use are built ... should I care. I read Text::xSV and File::Temp. I don't read CGI or DBI. Why? I don't care about how the latter are implemented. I care very much how the former are. (Or, I have cared ... I might care about CGI at some future date.) Later, I might care how various rpms are put together, for which I can find the source code.

      The point here is that with a minimally sufficient effort, I can learn how CGI is put together, with or without crazy Perl stuff. Without reverse engineering, I cannot do the same with similar tools in a compiled setting.

      A better example might be that I can learn exactly how Mozilla is put together ... I can't do the same with IE. I probably never will ... but I can. Transparency doesn't have to be used to be effective.

      ------
      We are the carpenters and bricklayers of the Information Age.

      Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

[reply]

In Section Meditations