use Perl

• seaside (Score:1)

  by slanning (5049)

  I read an article [ed-diamond.com] (increase URL number from 40 for more pages) in GNU Linux Magazine / France [ed-diamond.com] recently about Seaside [seaside.st], which is web framework in Smalltalk. I found it very interesting, since I think that it (finally) abstracts away (in principle, at least) the HTTP session / webpage crap that you always have to worry about with web app programming. I was a bit disappointed by the syntax, though; not sure if that's due to Smalltalk itself (which I'm not familiar with) or what.

  For example, this stuff for m [seaside.st]
  • Smalltalk syntax (Score:1)

    by ferreira (5993)

    The point of Randal was that objects are the realm of Smalltalk. Objects, classes, methods, messages, blocks/closures, metaclasses, collections and other tens of concepts and tools we know by heart (maybe with other names) for the sake of our knowledge of OO. But Smalltalk is surprisingly minimalist in semantics and syntax. Some things are weird: for example, 1+1*3 evaluates to 6 = (1+1)*3. Other things are just easy: like playing with objects with expressions like message cascading. Smalltalk urges for sm
• Squeak is a Horrible Environment (Score:2)

  by Shlomi Fish (918)

  See what I wrote about my encounter with Squeak [joelonsoftware.com] when the topic was raised in the Joel on Software Forum. I also ranted about it a bit in a mostly-Hebrew thread in discussions@hamakor.org.il. Generally, I feel that Squeak is so unconventional that an old dog like me can never get used to it without losing his sanity in the process.
  • Squeak looks like a Smalltalk Environment (Score:1)

    by ferreira (5993)

    I am not quite sure - because of my limited experiences - but I think Squeak is quite a decent Smalltalk environment. Of course, it doesn't care if you don't get the point of a Smalltalk environment. You have to educate yourself with the operational hocus-pocus of the system to appreciate it. (Just like you need to get familiar to the weird ways of Perl - for those who come along from all other languages: be it C, Scheme, Prolog, Pascal, etc.) Books like "Smalltalk 80: The Language" and "Smalltalk 80: The I
    • Re: (Score:2)

      by Shlomi Fish (918)

      I am not quite sure - because of my limited experiences - but I think Squeak is quite a decent Smalltalk environment.

      Maybe it is. But it still does not play nicely with the other kids on the block, and has its own (antiquated and obnoxious) ways of doing things.

      You have to educate yourself with the operational hocus-pocus of the system to appreciate it. (Just like you need to get familiar to the weird ways of Perl - for those who come along from all other languages: be it C, Scheme, Prolog, Pasc
      • Re: (Score:1)

        by Aristotle (5147)

        No, they’re not problems. Be careful. You are stuck in your comfort zone.

        Smalltalk just doesn’t work the way everything you know works. It’s a different world view, and it’s self-consistent, and doing things the way it does provides opportunities that your traditional approach does not give you. That is part of why Smalltalk has had trouble gaining traction – it requires complete buy-in to its world view, which it then rewards richly.

        Remember, a language that doesn
      • Re: (Score:1)

        by Aristotle (5147)

        After the last reply, where I wasn’t very specific about why the Smalltalk way makes sense (which bothered me), I went running errands, and on the way back home it occured to me how to explain it: basically, developing in Smalltalk means using a graphical read-eval-print loop. All your code is live, all the time, and you use the browser to tweak and prod while it keeps running in the background.

        When you’re finished, the running VM instance is your program.

        The source code you see is a mirag
• I agree; which makes me puzzled (Score:1)

  by Aristotle (5147)

  What amazes is that, knowing you are an old-time Smalltalker, you say stuff like CGI parameter parsing and form generation need tight coupling [mail-archive.com]. It just makes no sense coming from someone who I know understands OOP really well.

  I’m not bringing this up here to ridicule you or anything; it honestly bewilders me that you would make (and then, in fact, fervently insist on) such a claim.
  • Re: (Score:2)

    by merlyn (47)

    Perhaps it's inconsistent to you because you don't realize that while I believe objects are the key to larger programs, I'm also very practical.

    In the thread you cited, I'm arguing for tight coupling only for small programs, but since many programs are small programs, the tight coupling will help many and harm no-one. Clearly, once the "CGI Application" gets above two or three pages of forms, you'll want to go into "big program mode", and use a proper templating system and all that. I'm not arguing agai

    --
    

    • Randal L. Schwartz
    • Stonehenge
• Version control (Score:1)

  by jplindstrom (594)

  With everything in the image, how is source/version control handled?
  • Re: (Score:1)

    by Aristotle (5147)

    The live objects are versioned within the image. I didn’t get that far so I don’t know specifics, but every Smalltalker I’ve listened to raves about how versioning in Smalltalk completely leaves text-based source control in the dust.