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.
  • We collectively made up a ridiculous product idea like ``Visual Perl''... and it appeared!

    I'm expecting Finnigan to show up any minute now.

  • I honestly think that VB is *excellent* in terms of rapid development in the User Interface department -- so much so that snot nosed kids like me can click a few buttons and drag the mouse a few times, and end up with windows that are fully laid-out and ready for programming.

    The idea of having to write hundreds of lines just to get "Hello World" in C++ is horrifying. And while Tk is really nice, it's still not as fast as developing with an integrated environment like VB. (and I never got SpecTcl to work
  • Perl is clearly rooted in the command line world of UNIX. Because of this tradition, Perl began to fill the needs of win32 administrators who were given no such tools by M$ to design "outside of the box" solutions to their problems.

    Windows Programmers expect different things of their development environment then UNIX folks. The very notion of using a mouse for *any* sort of activity that can be called "programming" will make many UNIX folks shudder. After all, isn't the Windows, Icon, Mouse, Pointer (WIMP

  • GUIs (Score:1, Interesting)

    GUIs work best when they are highly configurable, or when alternatives are available. For instance, in BBEdit, I can add in my own tools or plugins (written in C or Perl), attach any key sequence to any command, etc. In maccvs, I can use the GUI, or for actions where the GUI does not suffice, type directly into the command line.

    For programming GUIs like these, it is not best when the designer knows every action a user might take, but when the designer knows that he can't.
  • After all, isn't the Windows, Icon, Mouse, Pointer (WIMP) interface all about restricting (simplfying) the choices available to the user?

    I would suggest the opposite. The intent the "WIMP" interface is to make the user interface more natural, and to approximate the way a person works in a non-computer environment, like an office desk, or a bench in a engineering workshop.

    More generally, I believe a proper integrated development environment will make Perl (and no doubt Python) an even more productive env

  • Now I can hack perl code in vi, then save and exit, run the program, fix the error, exit vi

    Now while I don't object to Microsoft and ActiveState developing whatever IDE for Perl (after all, the more choices the better - even if they develop something where you'd need smokesignals to program, it still won't take away someone elses favourite way of coding), the above reason is just silly. There's no reason to create an IDE for a language just because you don't know your current editor. You can write a macro

  • When we talk about a programming IDE, UNIX folks will smile and say "that's what my operating system is". Windows folks expect development to be done in an *application*.

    And nowadays many people prefer to use, for instance, syntax coloring. Unix doesn't give you that. An editor might, but only if it's being told about the syntax rules of your favourite language. Often, a configuration file can be used for that, but if I move from, say, vim to emacs, I would need a different configuration file. And

  • I find VB a good tool, and I think it's good its development team is not integrated with the development studio gang, etc...

    the problem with VB (which using VB itself is not a big problem, even though it's there) is that people tend to design the GUI and then stick behavior related to user generated events (and other events as well).

    That's OK, you are sticking COM (ActiveX) components together and tying their behavior into a single system...

    But doing this in Perl... it may work, by the way... but some
    --
    $ pugs -M6 -e 'say "use 6 :)"'
    use 6 :)
  • I agree in general. But to bring up Practice of Programming again:

    Don't make a program portable unless it _needs_ to be portable.

    Many Windoze apps are likely never to be ported, and the time saved with a RAD tool is often well worth the loss in flexibility, and *gasp* in some cases, even a loss in stability. (all depends on the app, of course).
  • I work in VB all day and code in Perl all night; I believe that the integration of Perl into VS will make it more widely accepted at the enterprise level and therefore I hope I will be using Perl even by day. :-D What I mean is that this move will surely expand the audience of Perl and will make it a glue language even for highly componentized windows apps. And then, would you *really* use VB if you have tried doing the same thing in Perl?
    --
    "Love, work and knowledge are the well-springs of our life. They should also govern it." - W. Reich
  • I don't think there is anything inherently wrong with Visual Perl. There are a lot of people who want to program, but who don't want to be programmers, and cutsie IDE's work for them. But this is what people are scared of. Large companies like to take open standards, throw a bunch of proprietary crap into them, lock up a chunk of market share, then hijack them completely. Microsoft had some success doing this with C++, and tried again with Java. Are you looking forward to a generation of programmers de
  • I think grufolone makes an essential point. Making perl and python a component of Microsoft's visual IDE will really legitimize the language in the eyes of the business public in a way that regular community evangelizing just can't do. The new-saw, "No one was ever fired for buying Microsoft," isn't a cliche for nothing...

    chris

  • No. Don't make a program nonportable unless it needs to be.
  • But people _are_ fired for buying Microsoft. As they often should be.
  • Windows folks expect development to be done in an *application*. In other words, Windows development is something to be done outside of the normal windows experience.

    This is certainly the case at my workplace. Asking any of our Windows developers to work in an environment which isn't the standard MS visiual development suite is like asking rms to use vi.

    So if it makes perl more accesible to people, it's good.

  • Well, certainly if any of my employees choose MS, this saying would instantly be proven wrong. But then, I wouldn't ever be that sloppy in hiring...
    --
    Paris Sinclair | 4a75737420416e6f74686572 pariss@efn.org | 205065726c204861636b6572 I wear my Geek Code on
  • I work for an international IT consulting firm making huge software projects, and everybody (mostly on the clients' side) seems to prefer MS as the logo of every software box we use. This somehow makes sense, because they feel it will be much easier to find someone trained in MS sloppy stuff if next year the 10,000 day/man apps should break than finding a Perl coder to do it (ofcourse if the whole proj had been written in Perl it would have been a 5,000 d/m one, but give them time to learn...)
    With the inc
    --
    "Love, work and knowledge are the well-springs of our life. They should also govern it." - W. Reich
  • Lets just not hope that this turns into a Visuall J++ and make a mockery out of Perl.
    --
    #print "Hello World\n"; print "Have A Nice Day\n";