crysflame writes: ActiveState announced today that they will be developing two new products for MS Visual Studio 7 - Visual Perl and Visual Python; see the press release. I'm not sure if I should give them a thumbs up or run screaming.
This is straight out of ``Shore Leave''
chip on 2000-05-31T18:01:41
We collectively made up a ridiculous product idea like ``Visual Perl''... and it appeared!
I'm expecting Finnigan to show up any minute now.
Why run screaming?
alleria on 2000-05-31T18:25:16
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 anyhoo)
...
But with PerlEZ, it's pretty much possible to just ride on VB, and write everything in Perl already anyhow, right? It
/could/ be really nice to have it be more integrated, and more convenient to use. And the graphical design without VB and its deranged and sadistic OO mechanisms would be quite welcome, IMHO.
My $0.02, -- Alleria
Re:Why run screaming? We fear change
jjohn on 2000-05-31T19:22:24
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) interface all about restricting (simplfying) the choices available to the user? WIMP UIs work best when the designer of them knows *every* task the user is likely to perform. For many applications, this interface works very effectively.
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*. In other words, Windows development is something to be done outside of the normal windows experience. I'm certain this was no accidental design.
Is there room in the world for Visual Perl? Sure! We should welcome it with open arms. After all, it's not Microsoft who is developing it. But it is also clear that VP (eek!) will appeal to a very different audience than those that use UNIX like tools (like cygwin).
As long as there's a $foo in there somewhere, I'm happy. :-)
GUIs
pudge on 2000-05-31T19:26:56
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.
Re:Why run screaming? We fear change
Maclir on 2000-05-31T22:12:32
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 environment. Now I can hack perl code in vi, then save and exit, run the program, fix the error, exit vi . . . . Actually, I edit the code with a windows editor, ftp it to my Unix machine, run, fix on windows, ftp . . . .
A good IDE will be a godsend.
Re:Why run screaming? We fear change
Abigail on 2000-05-31T23:21:21
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 in vi that will save the file, and run it as a Perl program. And there are several excellent vi clones in which you can program that macro in *drumroll* Perl.
Actually, I edit the code with a windows editor, ftp it to my Unix machine, run, fix on windows, ftp...
A simple macro can take care of the saving & ftp-ing as well. Emacs has had "ange-ftp" for a long, long time, where on save the file will be ftp-ed to the right location. vi-clones have hooks that can be triggered whenever the file is saved - and you ftp then. And depending on your machines configuration, remote execution is possible as well.
None of these requirements (save, ftp, run) are language specific, and hence you don't need them in a language specific IDE. You want to be able to do that all the time, for any language. Hence, you want that for instance in your editor.
-- Abigail
Re:Why run screaming? We fear change
Abigail on 2000-05-31T23:43:27
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 hence, we are back in having the IDE tied in to a specific application. Whether that's done by making a bunch of language specific configuration files, or a bunch of language specific wrappers are just details.
Having just the OS and its set of tools be your IDE gives you the advantage that your IDE is always the same, although you need to learn the language specific tools (like the compiler) for each language. The drawback is that because it's the same for everything, it doesn't have any specific knowledge. You can't for instance use the regex machine in vi to use token boundaries, in the same way the C or Perl lexer finds token boundaries; you are restricted to the (word) boundaries it has.
Of course, you can take very flexible, programmable editors that uses tons of macros and configuration files to provide you with the perfect IDE with your specific language. But then, the end result is the same as a Windows-IDE, you just took a different route.
After
all, isn't the Windows, Icon, Mouse, Pointer (WIMP) interface all about restricting (simplfying) the choices available to
the user?
Really? You think you can do more on a VT100 than on say an X-terminal? Or maybe you
meant KWIMPT (Keyboard, Windows, Icon, Mouse, Pointer, Terminal), and we were much better of with punch cards, or even toggle panels. Mice and windows have only given me more options - and I can ignore them if I want to.
-- Abigail
development model
excalibor on 2000-06-01T08:34:20
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 something I like of Perl is that i can do a system design, implement it, and change it on demand very easily... and that's because I am programming in the ole-days sense...
Tk and other hand-written GUI's make sense, because you add them to your program's logic...
In VB you start with a form. It's hard to detach from that development model... sure, it's plain easier to do GUI apps in VB than in VC... but, it's the same, at least in VC you can choose which design you want and take the GUI into account... in VB the GUI is always there (a console app must have the main form hidden, but it's still there)...
all in all, I don't like Visual development a great deal, although it's useful sometimes... there are loads of code you haven't written yourself... In _The_Pragmatic_Programmer_ it is said: "distrust of wizards and similar tools" or something like that (don't have my copy handy) and I think it's a good idea...
if you have to, then by all means, do it... but if you can avoid it, then do it. Your brain is always better than any wizard (even if it may be slower...)
Visual Perl? I ain't no problems, except that, again, it's a new step ahead against portability of applications...
I know many Windows people don't care about the way the rest of the Universe talks, but we Unix people do care... Perl + Tk is portable, Perl + GTL+ is portable (ditto for Qt, FLTK, etc...)
Windows is not portable (not even within different windows systems, sometimes)
and I ain't like that...
but anything useful for programmers that helps to make their life easier and to introduce Perl into management heads as something worthwhile is welcome, I guess...
Re:development model
alleria on 2000-06-01T12:48:21
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 like the idea
grufolone on 2000-06-01T16:20:12
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?
Re:Why run screaming?
indigo on 2000-06-01T16:58:57
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 dependant of Microsoft Foundation Classes for Perl? How about managers expecting you to have your MSCP certification?
Re:I like the idea
grendel on 2000-06-01T19:06:01
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
Re:development model
pudge on 2000-06-02T12:47:32
No. Don't make a program nonportable unless it needs to be.
Re:I like the idea
pudge on 2000-06-02T12:50:09
But people _are_ fired for buying Microsoft. As they often should be.
Re:Why run screaming? We fear change
rodgerd on 2000-06-02T21:27:33
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.
Re:I like the idea
Aighearach on 2000-06-03T11:42:41
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...
Re:I like the idea
grufolone on 2000-06-03T12:49:14
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 inclusion of Perl into VS we get this: they have an easy chance to try, and I dont know anyone who has used Perl who would willingly go back to VB..... and the rapid growth of XML based data exchange will make this process even more important.
So I say: thaks ActiveState! and (a-hem hum hum) thanks MS..... (forget this)
here we go again
happy on 2000-06-13T18:31:49
Lets just not hope that this turns into a Visuall J++ and make a mockery out of Perl.
