Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Smalltalk was once the #1 OO language. Of course, that was when it was the only "general purpose" OO language, before C++ was released.

    I have actually been paid to program in SmallTalk twice, and to build an interface from one Scheme to another with C. I went from C to SmallTalk to Objective-C to C++ to Perl (and Java), so perhaps I can provide some perspective. I have coded just about every "write only language" -- most of them for pay.

    Apart from Simula and the like, Smalltalk is the purest OO language still. As with Pascal, purity does not buy you traction in the real world. The other comments regarding the virtues of integration with other software and the system are right on as to why the impure languages win out over the pure. Pure elegant systems (Pascal, SmallTalk, Lisp/Scheme) have a tendency to see themselves as an end. Perl started as a scripting language, so has had extensible integration with the host OS's other programming tools from day 1. Integration wins in the real world. Ability to exec() a new process isn't enough, although even that's often not in Rev#1 of a "pure" language -- one needs call-and-return to/from legacy and 3rd party subsystems in "foreign" languages *and* call-and-return to separately maintained third-party subsystems in same language. Single "Workspace Image" systems like SmallTalk made that hard in the early days, very hard. But on the early slow systems we had in the '80's, not saving a workspace image but reloading from sources at every work session was out of the question. Forth has solved this in recent revs, I think; has SmallTalk?

    Historically, the lack of integration with legacy databases meant Smalltalk was restricted to new projects only. The selection of OODBs was initially slim and constrained to certain platforms; and of course OODBs were slow to gain the full-feature robustness of their RDB predecessors, but they came eventually.

    Smalltalk "VirtualMachine" / Browser model was actively hostile to multiple programmers and source control -- the code in the system image was the gold copy, not what was in your filesystem. The environment fought against "waterfall" development of big systems.

    With the explosion of small hardware in the 80's, there was an explosion of new projects, often outside the formal big-iron IT channels, and thus immune to the Standard Way. SmallTalk nicely fit this rebell niche, and offered a Rapid Development model with quick interaction with test users, perfect for departmental computing skunkworks -- if you put it in production before IT could complain about your project, you got to keep it. The competition for SmallTalk on Windows were MS Visual Basic and MS Visual C/C++ or Borland Turbo Whatever, not traditional technologies.

    Certain business sectors adopted SmallTalk -- those that needed ability to patch a system without taking it down; those that needed introspection in software (code aware of code and objects at runtime); AI groups who wanted a friendlier, newer framework than Lisp. I know of oil services geologists and financials and expert systems projects that found SmallTalk let them build things that they couldn't do otherwise.

    Wall Street had "programmed trading" systems on the floor to do instant arbitrage when two markets, indices or prices varied from each other. These would be patched on-the-fly to adapt trading rules to changes in market conditions and market/regulator rules-changes. SmallTalk programmers willing to wear a suit and a beeper got good money to fly into NYC every Monday to tend these systesms. Patching live code on the fly is scary ... but with SmallTalk, it's at least doable.

    I'm not sure why the early eBiz Catalog Publishing startup that I contracted for used SmallTalk, the GEODE OODB really didn't give them any business advantage beyond not needing a DBA to tune its none existant tunings.

    One reason SmallTalk lost out to other OO languages was management bias against interpretive languages. Obviously with Java and Perl they've gotten over that to some extent, but the "class" files of partially-compiled Java are still preferred by old school folks. The reputation it had of making 2+1 a message to an object stung.

    CPAN is Perl's "killer app" (along with mod_perl etc), but the fact that it's possible to have CPAN modules that work *with* other software from other languages is the real winner compared to "closed" systems.

    -- Bill
    --
    Bill
    # I had a sig when sigs were cool
    use Sig;
    • "So why aren't they used more?"
      One reason is badly dated mis-information like this!

      "Historically, lack of integration with legacy databases"
      Pre-historically! Smalltalk ORM was common from '90

      "actively hostile to multiple programmers and source control"
      From the late '80s Envy/Developer provided fine-grained (method level versioning) source code management. All the code was in a multi-user, replicated, database.

      "Wall Street had... Patching live code on the fly is scary"
      Many of those systems a
      • From the late '80s Envy/Developer provided fine-grained (method level versioning) source code management. All the code was in a multi-user, replicated, database.

        You've struck a cultural difference here.

        On this side of the fence, "source control" is an aspect of the development process independent from the platform. We generally think of source control as standalone tools like subversion, cvs, rcs, perforce, clearcase and whatnot. Source code management in Smalltalk is a different beast with the sam

        • "an observation that our favorite tools and skills aren't supported. And that's disturbing"
          I haven't seen people have difficulty learning the tools. I've seen people have real difficulty understanding object oriented design.
        • What makes you claim "Smalltalk VMs... are are inferior to, say, Java, Perl, C# or Visual Basic"?
          What comparison are you making?
          • Um, read what I wrote. I am not making the claim that Smalltalk is superior or inferior to anything.

            I am making the claim when we say "Smalltalk doesn't support source code management", it's not the same thing you hear when you respond "Envy/Developer provides SCM."

            We are saying "we are happy with cvs/p4/svn/..., and cannot use our tools in your development environment." Your response that those capabilities exist in some other form does nothing to assuage our skepticism.

            I do acknowledge that some l

      • I think Envy/Developer is another reason why SmallTalk has issues with acceptance. As a programmer, there are certain things I look for in a development environment, not just a language. I want to know about the language(s) I'll be using, how source control is managed, the database (if any), the test suite, the IDE (if any), etc. I like to learn about those things one piece at a time. Throw too many at me at once, or tell me I cannot use tools that I am comfortable with and I'll likely be less intereste

    • Historically, the lack of integration with legacy databases meant Smalltalk was restricted to new projects only.

      Visualworks 1.0 had connectors for Oracle and Sybase; later VWs had additional connectors, including one for ODBC. (Pre-merger) Digitalk Smalltalk also had database connectivity. Many of our (ParcPlace's) customers connected to legacy databases. What we didn't have was a story for connecting to "Big Iron" mainframe databases. (But then neither did Java for quite a while.)