The Industry choice

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Cameron Laird

    #76
    Re: The Industry choice

    In article <41d7def6$0$742 73$ed2619ec@ptn-nntp-reader03.plus.n et>,
    Mark Carter <mcturra2000@ya hoo.co.uk> wrote:

    Comment

    • Roy Smith

      #77
      Re: The Industry choice

      claird@lairds.u s (Cameron Laird) wrote:
      [color=blue]
      > Let me add a cautionary note, though: Big Companies,
      > including Oracle, Software AG, IBM, Cisco, and so on, have
      > adopted Tcl over and over. All of them still rely on Tcl
      > for crucial products. All of them also have employees who
      > sincerely wonder, "Tcl? Isn't that dead?"[/color]

      A lot of people laugh at Tcl, but it's really a very useful tool. In my
      last job, we did a major component of our product (SNMP-based network
      management package) in Tcl, probably on the order of 10 kloc. It has
      its limitations, but it's very easy to learn, very easy to embed and
      extend, and reasonably fast. It certainly blows away shell scripting.

      Around here, AOL/Moviephone has been trolling for years for Tcl people;
      I guess that counts as a big company.

      Comment

      • beliavsky@aol.com

        #78
        Re: The Industry choice

        Roy Smith wrote:[color=blue]
        >I think you've hit the nail on the head. In awk (and perl, and most
        >shells, and IIRC, FORTRAN), using an undefined variable silently gets
        >you a default value (empty string or zero). This tends to propagate
        >errors and make them very difficult to track down.[/color]

        You may recall correctly, but Fortran compilers have improved. The
        following Fortran 90 program

        integer, parameter :: n = 1
        real :: x,y=2.0,z(n)
        print*,"dog"
        print*,x
        z(n+1) = 1.0
        print*,z
        end

        has 3 errors, all detected at compile time by the Lahey/Fujitsu Fortran
        95 compiler, with the proper options:

        2004-I: "xundef.f", line 2: 'y' is set but never used.
        2005-W: "xundef.f", line 4: 'x' is used but never set.
        2153-W: "xundef.f", line 5, column 1: Subscript out of range.

        At run time, the output is

        dog
        The variable (x) has an undefined value.
        Error occurs at or near line 4 of _MAIN__

        Running Python 2.4 on the Python analog,

        n = 1
        y = 2.0
        z = range(n)
        print "dog"
        print x
        z[n] = 1.0
        print z

        one error is caught:

        dog
        Traceback (most recent call last):
        File "xundef.py" , line 5, in ?
        print x
        NameError: name 'x' is not defined

        You will see the out-of-bounds error for z only after fixing the
        undefined-x error. No warning is ever given about y, which is set but
        never used. In practice, 'print "dog"' could be some operation taking
        hours. Can PyChecker find all the problems in a single run, without
        executing 'print "dog"'? If so, it would be great if it were integrated
        with the CPython interpreter.

        One reason interpreted languages like Python are recommended to
        beginners is to avoid the edit/compile/debug cycle. But I think it is
        faster and less frustrating to have many errors caught in one shot.

        Comment

        • Roy Smith

          #79
          Re: The Industry choice

          In article <cr99pd$rff$1@p anix3.panix.com >, aahz@pythoncraf t.com (Aahz)
          wrote:
          [color=blue]
          > In article <xuTBd.66280$Jk 5.42292@lakerea d01>,
          > Steve Holden <steve@holdenwe b.com> wrote:[color=green]
          > >Aahz wrote:[color=darkred]
          > >> In article <7xacrs230c.fsf @ruckus.brouhah a.com>,
          > >> Paul Rubin <http://phr.cx@NOSPAM.i nvalid> wrote:
          > >>>
          > >>>I was pretty skeptical of Java's checked exceptions when I first used
          > >>>them but have been coming around about them. There's just been too
          > >>>many times when I wrote something in Python that crashed because some
          > >>>lower-level function raised an exception that the upper level hadn't
          > >>>been expecting, after the program had been in use for a while. I'd
          > >>>sure rather find out about that at compile time.
          > >>
          > >> That's funny -- Bruce Eckel talks about how he used to love checked
          > >> exceptions but has come to regard them as the horror that they are.
          > >> I've learned to just write "throws Exception" at the declaration of
          > >> every method.[/color]
          > >
          > >Pretty sloppy, though, no? And surely the important thing is to have a
          > >broad handler, not a broad specification of raisable exceptions?[/color]
          >
          > Yes, it's sloppy, but I Don't Care. I'm trying to write usable code
          > while learning a damnably under-documented Java library -- and I'm *not*
          > a Java programmer in the first place, so I'm also fighting with the Java
          > environment. Eventually I'll add in some better code.[/color]

          The whole point of exceptions is that they get propagated automatically.
          If I'm not going to catch it, why do I have to even know it exists? I
          don't consider "throws Exception" to be sloppy, I consider it to be
          programmers voting with their feet.

          Comment

          • Mark Carter

            #80
            Re: The Industry choice

            Cameron Laird wrote:[color=blue]
            > In article <41d7def6$0$742 73$ed2619ec@ptn-nntp-reader03.plus.n et>,
            > Mark Carter <mcturra2000@ya hoo.co.uk> wrote:
            > .
            > [tale of *very*
            > typical experience
            > with non-software
            > engineers]
            > .
            > .
            >[/color]


            Don't start me! Dammit, too late ...

            I've noticed that they have an overwhelming obsession with GUIs, too.
            They design wizards for everything. Damn pretty they are, too. Albeit a
            bit flakey. They seem to conflate pretty interfaces with good interfaces
            and good software.

            I used to joke that since our software wasn't particularly magical, it
            didn't need wizards. But I think I just ended up sounding bitter.

            We once had a bit of software that we thought we'd like to turn into a
            generic application. The focus on improvements was, predictably enough,
            that we should design a GUI that could do anything a client would likely
            to want to do. It was my opinion, though, having seen the very
            "special-cases" nature required in the original software, that it was
            almost impossible to predict exactly how a customer might want the
            product tailored. I suggested that what they really needed was a library
            (Python would have been good for this, Lisp might have been even better)
            that could be extended as required. GUIs second, functionality first.
            But hey, what would I know. Fortunately, the whole thing's been put on
            the back burner.

            And trying to get through to them why source control makes sense, that
            when more than one person works on a project, some form of coordination
            is required, that copying and pasting code is evil, and that Excel
            probably isn't the hammer for every nail.

            Honestly, I thought (real) engineers were supposed to be clever.

            Comment

            • Donn Cave

              #81
              Re: The Industry choice

              Quoth Paul Rubin <http://phr.cx@NOSPAM.i nvalid>:
              | "Donn Cave" <donn@drizzle.c om> writes:
              |> Yes, it would be really weird if Python went that way, and the
              |> sort of idle speculations we were reading recently from Guido
              |> sure sounded like he knows better. But it's not like there aren't
              |> some interesting issues farther on downstream there, in the compare
              |> function. cmp(), and str() and so forth, play a really big role in
              |> Python's dynamically typed polymorphism. It seems to me they are
              |> kind of at odds with static type analysis
              |
              | I don't understand that. If I see "str x = str(3)", then I know that
              | x is a string.

              Sure, but the dynamically typed polymorphism in that function is
              about its parameters, not its result. If you see str(x), you can't
              infer the type of x. Of course you don't need to, in Python style
              programming this is the whole point, and even in say Haskell there
              will be a similar effect where most everything derives the Show
              typeclass. But this kind of polymorphism is pervasive enough in
              Python's primitive functions that it's an issue for static type
              analysis, it seems to me, especially of the type inference kind.
              cmp() is more of a real issue than str(), outside of the type
              inference question. Is (None < 0) a valid expression, for example?

              Donn Cave, donn@drizzle.co m

              Comment

              • Peter Dembinski

                #82
                Re: The Industry choice

                Peter Dembinski <pdemb@illx.org > writes:

                [...]
                [color=blue]
                > str = foo(x)[/color]

                (ick!) it should be:

                bar = foo(x)

                Comment

                • Peter Dembinski

                  #83
                  Re: The Industry choice

                  Peter Dembinski <pdemb@illx.org > writes:
                  [color=blue]
                  > Peter Dembinski <pdemb@illx.org > writes:
                  >
                  > [...]
                  >[color=green]
                  >> str = foo(x)[/color]
                  >
                  > (ick!) it should be:
                  >
                  > bar = foo(x)[/color]

                  Besides, shouldn't str be a reserved word or something?

                  Comment

                  • Peter Dembinski

                    #84
                    Re: The Industry choice

                    Bulba! <bulba@bulba.co m> writes:

                    [...]
                    [color=blue]
                    > The point is obviously "cover your ass" attitude of managers:[/color]

                    Managers get paid for taking risk :)

                    Comment

                    • Terry Reedy

                      #85
                      Re: The Industry choice


                      "Peter Dembinski" <pdemb@illx.org > wrote in message
                      news:87llbba55t .fsf@hector.dom ek...[color=blue]
                      > Besides, shouldn't str be a reserved word or something?[/color]

                      It is a name in the builtins module which is automatically searched after
                      globals. Many experienced Pythoneers strongly advise against rebinding
                      builtin names *unless* one is intentionally wrapping or overriding the
                      builtin object. The latter are sometimes valid expert uses of masking
                      builtins. Newbies are regularly warned on this list against making a habit
                      of casual use of list, dict, int, str, etc.

                      None has been reserved because there is no known good use for overriding
                      it. True and False will be reserved someday. There have been proposals to
                      turn on reserved status for all builtins on a per-module status.

                      Terry J. Reedy



                      Comment

                      • Alex Martelli

                        #86
                        Re: The Industry choice

                        Roy Smith <roy@panix.co m> wrote:
                        [color=blue]
                        > Stefan Axelsson <crap1234@hotma il.com> wrote:[color=green]
                        > > Yes, ignoring most of the debate about static vs. dynamic typing, I've
                        > > also longed for 'use strict'.[/color]
                        >
                        > You can use __slots__ to get the effect you're after. Well, sort of; it
                        > only works for instance variables, not locals. And the gurus will argue
                        > that __slots__ wasn't intended for that, so you shouldn't do it.[/color]

                        There's a simple, excellent recipe by Michele Simionato, on both the
                        online and forthcoming 2nd edition printed Cookbook, showing how to do
                        that the right way -- with __setattr__ -- rather than with __slots__ .


                        Alex

                        Comment

                        • Terry Reedy

                          #87
                          Re: The Industry choice


                          <beliavsky@aol. com> wrote in message
                          news:1104689464 .828070.309990@ c13g2000cwb.goo glegroups.com.. .[color=blue][color=green]
                          >> 2004-I: "xundef.f", line 2: 'y' is set but never used.[/color]
                          > 2005-W: "xundef.f", line 4: 'x' is used but never set.
                          > 2153-W: "xundef.f", line 5, column 1: Subscript out of range.[/color]

                          None of these are syntax errors. The first two of these would be caught by
                          lint or pychecker (I am presuming).
                          [color=blue]
                          > One reason interpreted languages like Python are recommended to
                          > beginners is to avoid the edit/compile/debug cycle. But I think it is
                          > faster and less frustrating to have many errors caught in one shot.[/color]

                          True syntax errors often result in such a cascade of bogus errors that it
                          may often be best to fix the first reported error and then recompile. Of
                          course, compilers vary in their recovery efforts.

                          Terry J. Reedy



                          Comment

                          • Terry Reedy

                            #88
                            Re: The Industry choice


                            "Bulba!" <bulba@bulba.co m> wrote in message
                            news:qcagt0l3u4 aou1le4phu257n6 embo98kv0@4ax.c om...[color=blue]
                            > On Sat, 01 Jan 2005 15:08:01 -0500, Steve Holden >[color=green]
                            >>whereas when a company goes
                            >>bust there's no guarantee the software IP will ever be extricated from
                            >>the resulting mess.[/color]
                            >
                            > There is a good _chance_ here: money. Somebody has poured a lot
                            > of money into this thing. It's not going to get dropped bc of that.[/color]
                            [color=blue]
                            >From what I have read, the amount of proprietary code which *did* get[/color]
                            effectively shredded after the dot-com bust is enough to make one cry.
                            There were a few companies that would buy code at bankruptcy sales for
                            maybe 1% of its development cost, but even then, with the original
                            programmers long gone, it could be hard to make anything from it.

                            Terry J. Reedy



                            Comment

                            • Roy Smith

                              #89
                              Re: The Industry choice

                              "Terry Reedy" <tjreedy@udel.e du> wrote:[color=blue]
                              > None has been reserved because there is no known good use for overriding
                              > it.[/color]

                              Should I infer from the above that there's a known bad use?
                              [color=blue]
                              > True and False will be reserved someday.[/color]

                              I remember a lisp I used many years ago. If you tried to rebind nil,
                              you got an error message -- in latin!

                              Comment

                              • Terry Reedy

                                #90
                                Re: The Industry choice


                                "Steve Holden" <steve@holdenwe b.com> wrote in message
                                news:_rTBd.6627 5$Jk5.46@lakere ad01...[color=blue]
                                > Well clearly there's a spectrum. However, I have previously written that
                                > the number of open source projects that appear to get stuck somewhere
                                > between release 0.1 and release 0.9 is amazingly large, and does imply
                                > some dissipation of effort.[/color]

                                And how do the failure and effort dissipation rates of open source code
                                compare to those of closed source code? Of course, we have only anecdotal
                                evidence that the latter is also 'amazingly large'. And, to be fair, the
                                latter should include the one-programmer proprietary projects that
                                correspond to the one-programmer open projects.

                                Also, what is 'amazing' to one depends on one's expectations ;-). It is
                                known, for instance, that some large fraction of visible retail business
                                fail within a year. And that natural selection is based on that fact that
                                failure is normal.

                                Terry J. Reedy



                                Comment

                                Working...