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.

Why not Smalltalk? 25 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Here's my theory, which I just *know* you're dying to hear:
    • Advertising. Head to your local bookstore. See the number of Perl and Java books? Now, do you see any Scheme or Smalltalk books? Many people have simply never heard of them, or only heard of them in passing.
    • Difficulty. One can read Learning Perl and have a basic grasp on the language in a very short period of time. I don't think the same can be said of Smalltalk or Scheme, at least not for your average hacker.
    • Syntax. Smalltalk's syntax is
    • You have never heard of a Smalltalk library because a huge beautifully designed class library is so inherent to the language that it is not worth mentioning.

    • I don't think any of these fully explain why Smalltalk/Scheme/whatever didn't catch on in the first place (though they would explain why it is so hard for them to catch up after other langauges took root). For instance, if Scheme was a more popular language, you would likely see a lot more Scheme books.

      I also suspect the "Difficulty" and "Syntax" reasons are non-issues if functional languages were people's first exposure to programming. LOGO, for instance, has a functional syntax and has been used to teac

      • I don't think any of these fully explain why Smalltalk/Scheme/whatever didn't catch on in the first place

        True enough.

        I also suspect the "Difficulty" and "Syntax" reasons are non-issues if functional languages were people's first exposure to programming.

        That's a pretty steep precondition for most programmers. The vast majority of programmers today did not use a functional language when first exposed to programming. The switch from an ALGOL derivative syntax and programming model to something fu

        • I agree about the steep precondition. I still remember coming from BASIC to C in the 80s. I struggled to understand how someone could program without line numbers. Even though I agree with the premise that languages such as SmallTalk and Scheme would not seem so alien if these were the first languages that people were exposed to, the reality is that they are not the first language and they're unlikely to become that. Hence, we have a chicken and egg problem that is essentially unsolveable from this appr

      • Advertising. That's reinforcement not cause - there's a market for books because the languages are widely used.
      • Difficulty.One can read "Smalltalk by Example" [unibe.ch] and have a basic grasp on the language in a very short period of time.
      • Syntax. Smalltalk's syntax is simple, consistent, powerful.
      • Libraries... but I've never heard of them Have you ever looked for them? Smalltalk's rich libraries have been growing since 1980.
      • ROV That's why people switch to Smalltalk - get more done, faster, with fewer people.

      • One can read "Smalltalk by Example" and have a basic grasp on the language in a very short period of time.

        Hardly. That book is obscure and very hard to find on the bookshelf or at the bookstore. It is freely available online now, but it wasn't 5, 10 or 15 years ago. And freely available materials do not make a programming language easier to use or learn. Some of the best materials about Python have been freely available since the project's inception, yet the size of the Python community is persists

  • Both Lisp and Smalltalk are almost hostile to cooperation with other software. Smalltalk is the poster child for this, of course -- Squeak may be a wonderful environment (it's fun, I've tried it), but using a computer productively is all about interacting with other programs, handling files, and talking to other machines, and it's hard to interact with programs outside the Smalltalk VM. In Lisp, this shows up as a "better is worse" syndrome, where you have a nice language with a large standard library, bu
    • "interacting with other programs, handling files, and talking to other machines"
      Why don't you think Smalltalk supports "handling files"?

      How do you want to interact with other programs, and machines?
      Corba? Sockets? SOAP? CGI? COM? DLLs/Shared libraries? inline C-code? [exept.de]

      Here's the VisualWorks Smalltalks documentation [cincom.com]
      • Alright, you RTFMed me pretty good there. Having only used two smalltalks (GNU ST and Squeak), and those only briefly, I made the same mistake many people do with Scheme: there are a bunch of languages out there called Scheme, some supporting practical extensions beyond the standard. Using the wrong "Scheme", or only reading the standard, you get the impression that the language doesn't have much built in. With Scheme, I've been fortunate enough to be exposed to both Bigloo and PLT, two implementations w
        • 'RTFMed me'
          We all seem to mix up language and language implementation ;-)

          'scripting in the "shell scripting" sense'
          That's something Perl was designed for, and not something Smalltalk was designed for.
          Having said that, once we start thinking about web apps, take a look at Seaside [beta4.com].
  • Another reason I suspect is the availability of the language tools. One of the big advantages of Smalltalk is supposed to be the integrated development environments. The really good ones are expensive, commercial software. There are now free versions (Squeak), but my impression was that are less powerful than the commercial environments.

    The consequences that students don't learn the language in school, they can't play around with it at home, they are unlikely to use it to solve a small problem at work

  • 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
    --
    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.)

  • Ovid, you've raised a meaningful permathread about language design.

    The short answer: academic languages are eclipsed by workaday languages because the academics are focusing on solving tomorrow's problems. It's tomorrow, and we are adopting a lot of what they discovered decades ago (memory mangement, VMs, JIT, closures, objects, etc.).

    A longer answer is in my journal [perl.org].

  • This begs an obvious question: if they solved these problems so long ago, why are they viewed primarily as academic languages?

    FWIW, some guesses, on that:

    Reputation would be the start of it, there.

    Lack of publicity might be another part of it.

    There may even be some cases (rare, perhaps, but perhaps possible) of "self doubt" (or "language doubt"?), among any users of said languages. I do not mean any sort of an odd joke by that, though; if it would be so, then it may be another matter hearkening b

  • "if they solved these problems so long ago, why are they viewed primarily as academic languages?"
    Simple ignorance. When we know what kind of software is developed with these languages (and how much money it makes) then we no longer regard them as academic languages.
    Would you have guessed that Smalltalk is used for the core of Quallaby PROVISO [quallaby.com]?
    Is there something academic about machine control software [adventact.com] or container shipping? [oocl.com]

    "So why aren't they used more?"
    The benefits of Smalltalk become obvious with
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.