Recently my office was visited by a sales rep for a software tool developement company. They create tools for programmers to use for quick developement/testing and tracking. Currently our office is running MS but is being switched over to Linux servers. So when the sales rep started his speach about how it works with all of the most popular programming languages out there my boss yelled out "DOES IT WORK WITH PERL??" His answer was "No, but...." "We don't want it then" The sales rep then gave my name to the head of the department that handles questions on these products. So I asked her the question I still had on my mind. After watching his whole presentation that he gave to us, I had to laugh. The first reason was because throughout his speach he never once mentioned if his software was secure and the code it generated would be secure. Second everything that this set of software packages provided have equivelent modules at CPAN to do this. I really think this email is an open invitation for MS bashing.
I am planning a seminar for the latter part of September and will certainly
include you on the invitation list There will be a keynote speaker from the
lab that you can talk to directly about this. We will also show these new
technologies. I hope you can attend and will let you know the exact date
soon.
Regards,
XXXXX
-----Original Message-----
From: Harnish, Joe mailto:jharnish@ci.grand-rapids.mi.us
Sent: Thursday, August 17, 2000 11:02 AM
To: XXXXXXXXXXXXXXX
Subject: RE: Numega - Track Record
XXXXXX,
Is there anything in the works to make it useable with PERL?
Joseph Harnish
456-4319
-----Original Message-----
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Sent: Thursday, August 17, 2000 10:51 AM
To: 'jharnish@ci.grand-rapids.mi.us'
Subject: Numega - Track Record
Hello Joe,
Following your meeting with XXXXXXX XXXXXXX from XXXXXXXXX yesterday, I am
sending this email to introduce myself as the NuMega sales representative.
NuMega provides debugging solutions for VB, VC++, Java, and ASP.
Additionally, we have stored procedure debuggers and Oracle SQL automated
tuning. Our Track Record product provides the ability to automate workflow
and process automation including defect tracking.
Attached is a weblink for additional information. Please reference (on the
left side of the first screen) DevPartner Studio Enterprise Edition, and
under that heading, click on Tracking.
http://www.numega.com <http://www.numega.com>
My contact information is below, I look forward to hearing from you with any
comments or questions.
Regards,
The reason I posted this up was I need some information to present them about perl and that it is one of the fastest growing languages around. I want to be able to show them facts about this. Also, what do you guys think of software that generates code for the programmer?
-- BigJoeLearn patience, you must. Young PerlMonk, craves Not these things. Use the source Luke. |
RE: Something I wanted to share with the group.
by KM (Priest) on Aug 17, 2000 at 20:22 UTC
|
The reason I posted this up was I need some information to present them about perl and that it is one of the fastest growing languages around. I want to be able to show them facts about this.
Success Stories, and noone can argue with the suck-o-meter!
Also, what do you guys think of software that generates code for the programmer?
No sir, I don't like it. Maybe for toy languages like Cold Fusion, ASP, D?HTML, XML, etc... it's ok, but not for Perl. One problem I have with software which does this is that if the people who program the software to write the code, can't code well themselves, then you get crappy code. Also, it helps people stay dumb, and not learn about (and how to effectively use and program) the language which is being created for them.
Cheers,
KM | [reply] |
RE: Something I wanted to share with the group.
by Russ (Deacon) on Aug 17, 2000 at 20:28 UTC
|
I, for one, deeply distrust software that generates code
for the programmer. With the possible exception of GUI
building, I simply don't want anything to generate code for
me. Anyone who relies on code generation (look at any
HTML editor) is clearly not capable of evaluating the code
it generates.
Perl.com may have some statistics
for you. I'm not sure I would be very interested in
"helping" them corrupt our fine language with M$-style
"automation"...
:-)
Russ
Brainbench 'Most Valuable Professional' for Perl | [reply] |
|
|
Anyone who relies on code generation (look at any HTML editor) is clearly not capable of evaluating the code it generates.
Russ, I have to take issue with this. This is just *wrong*. I have some 300 HTML pages in the system I've implemented for the system at the office. Each one is not hand-coded and tuned, because it just doesn't matter. If you want to take the time in your favorite editor, and hand-type each and every HTML tag, and make sure it's perfectly optimized, then you clearly have more time than I do.
The code the HotMetalPro produces is not perfect. I know this. And I don't care. It doesn't matter. And I can crank out a page, especially with a few interleaved tables, a lot faster than I can with 'vi'. And, furthermore, I can see the results as I edit. And no, I can't use CGI.pm, because it's a template type system, and also because someone behind may have to make changes to the pages, and they don't need to be mucking around in Perl code just to change a header.
Hand tuned highly optimized HTML has a place, don't get me wrong. It's more important to be *aware* of the code that your tools generate. Use them when you can, avoid them when you can't. This same rule apples to Perl, 'C', and any other langauge you choose to pick. Perl doesn't produce perfect internal code. Neither does a 'C' compiler. It takes it best shot at it, and the majority of the time it's accurate. The only reason people are quick to judge the output of HTML, XML, and other editors is because the code is clearly much more visible than the assembly or byte code produced by a compiler. I imagine if your browser didn't have a view source button, you'd be a *lot* less aware of good vs. bad HTML.
And besides, even if you do hand tune the HTML, the next bozo who comes along behind you may use FrontPage anyway, and all that nice work is shot. And on a 100mpbs (or even a 10mpbs) network, who cares if the line is broken in the middle, or has an extra "colspan" tag, as long as the HTML is valid, and produces the output required?
I'm not advocating writing bad code, or bad HTML. I'm advocating being aware of the output you and your tools produce, be it the compiler, HTML editor, or whatever.
By the way, it's my opinion that most HTML editing tools are designed to make web pages accessible to people who don't want to or shouldn't have to learn the intricacies of HTML. If it weren't for these people, even with their "Hello, World" web page, the web would be a much smaller, and less popular place.
--Chris
e-mail jcwren
| [reply] |
|
|
If you're not a 'professional' web designer, i see no point in you learning HTML, and if you are you should only use WYSIWYG editors when the boss says, "I need a new webpage in 5 min."
In my opinion, handcoding is meant for 'template driven' sites. You just design your template, optimize your code, and populate the template with content in its reserved spot.
Anyway most WYSIWYG editors have the option to edit the actual html source, and control any and all comment that get automatically generated.
The real power of WYSiWYG editors is automation.
For example, if you have a 'template driven' site with some 500 odd pages, DREAMWEAVER or FRONTPAGE will let you change the TEMPLATE and update every page accordingly and automatically.
"cRaZy is co01, but sometimes cRaZy is cRaZy".
- crazyinsomniac
| [reply] |
|
|
While I sympathize with russ, I simply have to
agree with you. Automatic code generation off of a
data structure is a very powerful idea. In fact one of
the nice things about Perl is how easy it makes this to
do.
Anyone who disagrees should simply stop and think about
the process of pulling data out of a database and spitting
out formatted HTML...
EDIT
I thought about it and an even better example would be something
like Parse::RecDescent. Pass it a string description of
a grammar. It generates a parser for you. An example of
automatic code generation of Perl in Perl which has been
recommended several times by the likes of merlyn.
So while I absolutely think that a lot of code generation
tools are abysmal, code generation (even generation of
Perl) is a concept that should not be categorically thrown
away.
| [reply] |
|
|
Each one is not hand-coded and tuned, because it just
doesn't matter. If you want to take the time in your favorite editor, and hand-type each and every
HTML tag, and make sure it's perfectly optimized, then you clearly have more time than I do.
In my experience, I can hand-code HTML far easier than I
can deal with an "editor." The HTML will come out clean and
nicely indented, allowing much more efficient
changes and extensions later. It might be different if I
were tasked with 300 plain HTML files with no code, no
functionality.
However, I think you may have missed my point. I am
addressing the "people who don't want to or shouldn't have
to learn the intricacies of HTML." This may be acceptable
for something simple, like HTML creation. But, do you
really want people using "automatic" Perl code generators
on your servers? Those people who don't want to learn the
intricacies of Perl are the very people who should be
forced to do so, or ask for professional assistance.
Concerning the "extra colspan," I am referring to HTML that
is a few K when hand-coded, but 40-50K from some editor.
They tend to put gratuitous font tags around every element,
create nested tables for no reason, duplicate style
information and colors repeatedly and redundantly, over and
over. This mess is far from maintainable, except in
another editor, where the junk may be compounded even
further.
On a 10Mbps network, 50K files will download quickly. Are
we willing to inflict that kind of wastefulness on an
unsuspecting world (who likely do not have OC3 connections
to the internet)? How long do you like to wait while
Netscrape renders a pile of highly inefficient HTML? Bad
HTML is a more serious problem than simple download times.
Russ
Brainbench 'Most Valuable Professional' for Perl
| [reply] |
|
|
|
|
|
|
| |
|
If it weren't for these people, even with their "Hello, World" web page, the web would be a much smaller, and less popular place.
Ok, now I'm confused, your english seems to imply that this would be a bad thing somehow ;-)
Nuance
Who doesn't have a web page because it would only say something banal like "hello world"
| [reply] |
|
|
Anyone who relies on code generation (look at any HTML editor) is clearly not capable of evaluating the code it generates.
Then again, many of the functions in the CGI module generate HTML for us, and many other modules in Perl provide a cleaner user interface to some other language/system by generating the code for whatever the application is. So there is a place for it...
On the other hand, I don't think I'd really be to psyched about seeing a product that automated Perl generation...
| [reply] |
|
|
One thing to remember about the CGI module although it can generate code,
it was written by PERL programmers, for PERL programmers.
I started out using HTML generators and they NEVER looked right.
Simply because there are too many ways to write a page to look the same.
The same is true of PERL it is too smart for one programmer or company.
Anything that generates code strips the language of it's beauty.
The craft should be left to the craftsperson.
| [reply] |
|
|
Many of the functions in CGI generate HTML, but I suspect
that most people (like myself) tend to use CGI to grab
and manipulate the form input, but not to write the
html. (Of course, that doesn't include things like
CGI::FastTemplate, but functions lik &h1())
| [reply] |
|
|
The reason I brought this up is because there seems to be a nice logging application that will monitor cahnges with programs, track progress, etc. I am not looking at the generating part. That just baffles me that programmers are actually buying $1 million worth of this product.
--BigJoe
Learn patience, you must.
Young PerlMonk, craves Not these things.
Use the source Luke.
| [reply] |
|
|
If all you want to do is monitor changes, log what's
been done, and stuff like that, what's wrong with
something like rcs? Of course I don't know what this
program does, but I'm curious what it does that is
so much better than the free tools.
| [reply] |
|
|
|
|
|
|
|
|
RE: Something I wanted to share with the group.
by BigJoe (Curate) on Aug 17, 2000 at 20:08 UTC
|
I forgot the first line of the email
Joe,
Sorry, no. Customers are pulling us in the direction of Java, ASP and
process automation. Our development efforts are concentrated on enhancing
these technologies.
--BigJoe
Learn patience, you must.
Young PerlMonk, craves Not these things.
Use the source Luke. | [reply] |
RE: Something I wanted to share with the group.
by jlistf (Monk) on Aug 17, 2000 at 20:32 UTC
|
Also, what do you guys think of software that generates code for the programmer?
what?
aren't programming languages (some of them at least) already pretty high-level. its not like we're working in machine code or assembly. most Perl programs (and Java and even C++ to some extent and probably python) are reasonably easy to understand if they were written well. what exactly would the user tell the program anyway? "write a program that will validate form data, enter it into a database and send the user an email." i guarantee that it wouldn't work out. for a simple language like HTML (which has no control structures, no variables, just text processing) you could do it (and it has been done), but not for higher-level languages. some routines could be automated, but isn't that the idea of OOP, modules and CPAN?
another point. larry wall's a linguist (or was or knows the stuff or whatever). and he designed Perl to be similar to most natural languages. in order to write a program that automatically generates code, we're delving into some heavy-duty AI.
jeff | [reply] |
RE: Something I wanted to share with the group.
by BlueLines (Hermit) on Aug 17, 2000 at 22:27 UTC
|
have you played with glade before?
i don't know about most of you, but i find X/GTK programming to be highly non-trivial. Glade is a GUI builder written in C and GTK. You can set up the user interface and tie particular actions to subroutines elsewhere. I've used it in C, but it (supposedly) can generate perl and python as well. I wouldn't consider the use of something like this as a "bad thing", as it still forces you to have functional and solid code underlying the fancy top....
BlueLines
Disclaimer: This post may contain inaccurate information, be habit forming, cause atomic warfare between peaceful countries, speed up male pattern baldness, interfere with your cable reception, exile you from certain third world countries, ruin your marriage, and generally spoil your day. No batteries included, no strings attached, your mileage may vary. | [reply] |
|
|
Glade also has support for Perl. I gave this a try recently, to see if it would be usable for the Gtk/Perl Internet Chess Server client I am writing. I found it to produce pretty good code, but there are a few things I didn't like.
First of all, instead of a script it produces a module. While this is the form I want my program's interface in, this behavior should be optional. Particularly because you end up with a Gtk object that you won't know how to use if you don't already know Gtk, or fish an example out of the distribution. To me this lack of flexability means it should not be used as a substitute for learning Gtk.
Another problem is, it makes complex GUIs more difficult to build. If you just want to display a dialog with a couple buttons, fine. But if you have any sort of layered or variable layout, then it's not a good sollution. For example, drawing the board in my chess client. We need not only an 8x8 grid of colored pixmaps, but also another, initially blank, grid of pixmaps to display the pieces. Now, writing this by hand it is obvious that I want to represent the board as a data structure, populate it and show the widgets, and end up with an easy interface to access these widgets again later. Handcoding, this is fairly straightforward. But, using Glade it becomes more difficult, because you have to interact with the GUI via two different paradigms at the same time; the visual representation, and the logical representation in the code. Personally, if I am going to have to understand how the code creates the widgets anyway, then I'd rather be using my favorite editor than coding in Glade, with the other widgets in my way, and whathaveyou.
Also, what if I create my program in Glade, release it, and then people start submitting patches? After adding these in, will I still be able to use Glade? Certainly I couldn't tell everybody else to code in Glade. And, it would be an embarrassing situation if I was neglecting to include bug fixes to my code, on account of not understanding my code in the first place...
Paris Sinclair | 4a75737420416e6f74686572
pariss@efn.org | 205065726c204861636b6572
http://sinclairinternetwork.com
| [reply] |
RE: Something I wanted to share with the group.
by gumpu (Friar) on Aug 18, 2000 at 13:35 UTC
|
"Also, what do you guys think of software that
generates code for the programmer?"
We use two kind of tools that generate code.
One is Rational Rose, which can create C++ code
out of class diagrams. You just have to fill in the
body of the methods. It can also do the reverse,
that is create class diagrams out of existing code.
This allows you to do round-trip engineering.
It's quite nice idea as you can manipulate your code
and view your system
on a higher abstract level. However it's implementation
is quite buggy it looks like.
The other form of code generation we use is to automatically
install sanitychecks and dangling pointer checks in existing
C++ code. This based on the class hierarchy and attributes
of a class. This is all done in Perl (and was
a lot of fun to implement!).
So code generation is quite useful, it allows you to
manipulate programs on a higher level of abstraction.
Code generation can be a bit of a pain for the people
that have to maintain the code though. Because they
want to make changes in the generated code they have to
first understand how the code-generating code works.
Have fun, Frans.
| [reply] |
RE: Something I wanted to share with the group.
by lindex (Friar) on Aug 18, 2000 at 13:22 UTC
|
| [reply]
[d/l] |
|
|
| [reply] |
RE: Something I wanted to share with the group.
by Adam (Vicar) on Aug 17, 2000 at 20:38 UTC
|
| [reply] |
|
|
