Re^4: [EMACS] "Emacs as Perl IDE" - Abstract for YAPC::EU 2016 ( A tale about IDE usage )

> I have worked in languages and technologies that are near unusable without an IDE.

I had a colleague once who was considered a "Perl expert".

His work pattern was pretty consistent:

When assigned a new task, he'll

Fire up Komodo IDE
As a start: rename an older, similar but incomplete script from the same problem group
Google for a missing part with "Perl" included in the query
Paste new chunks and wait if Komodo complains by underlining some line
( something like "fly-make perl -c " is activated by default here)
Make some adjustments, always waiting if lines are underlined
Repeat the googling process with other missing functionality
Occasionally run it from the editor
If it fails add a break point by clicking the line, it now runs under the debugger and stops there
If inspecting the variables which are shown in a extra pane don't reveal problems stop at the next break-point
In 80+x % cases he's "successful" with this strategy
In the other 20-x % cases he came ranting into my office saying that Perl is totally inappropriate for the job ...
... and that obviously Python, Ruby, * (fill it in) is FAR better

OK you might say this is not a real "expert" ...

... he doesn't even know how

to read documentation
to use perl -c
to start the debugger and use it's commands
and other things

But management - which is non IT and has no clue about programming and the long term costs of boiler plating and cargo cult - will say

that our group has a cheap company license for Komodo
he gets most his jobs "done"
that the investment was obviously justified.
and he can't be blamed for Perl's complexity

Needles to say this "expert" will tell the world that:

Perl is near unusable without an IDE like Komodo.

Punchline? Already one week after I started in this project I knew Komodo (V6 back then) better than the rest of the team together. To be fair ... with all my Emacs experience I knew what to look for.

For instance I tried to help them to switch the internal REPL from Python to Perl - for vain.

That much about bundles with useful defaults.

Cheers Rolf
_{(addicted to the Perl Programming Language and ☆☆☆☆ :)

Je suis Charlie!}

Comment on Re^4: [EMACS] "Emacs as Perl IDE" - Abstract for YAPC::EU 2016 ( A tale about IDE usage ) Download Code

Replies are listed 'Best First'.
Re^5: [EMACS] "Emacs as Perl IDE" - Abstract for YAPC::EU 2016 (A tale about IDE usage) by RonW (Parson) on Jul 19, 2016 at 22:41 UTC
I wonder how he "programmed" in any of those other languages he kept suggesting. I suspect the same way - and made the same complaints about them.	[reply]
Re^6: [EMACS] "Emacs as Perl IDE" - Abstract for YAPC::EU 2016 (A tale about IDE usage) by LanX (Saint) on Jul 19, 2016 at 23:07 UTC
> I wonder how he "programmed" in any of those other languages he kept suggesting. Oh he never did ... he only read about them. :) Perl has a bad reputation and idiots like spreading the word. > I suspect the same way Most coders do (don't ask about the JS code I've seen so far)! And if people google for Perl they'll find plenty outdated content from the 90s - simply because Perl is much longer popular and gave birth to the internet. (BTW similar problem for Emacs which is 40 years old now !) Ruby raised to stardom with Rails, compare the pretty webpages with the monastery and guess the appeal for this kind of IT-lers. I bet just reformatting and coloring the code sections in PM-posts with perltidy will give a popularity boost after a year. Maybe also automatically included back-links to newer discussions might help ( there must be a reason why an older discussion was linked later, so let's show the newer one, too) > and made the same complaints about them. he has his preferred compiled language + IDE which is "far superior" but practically fell out of grace nowadays. It's so obscure I can't possibly name it without identifying him. And after all he's only an example for a big part of the business, that's the reality, no need to point him out. My message is: IDEs are very important! Cheers Rolf _{(addicted to the Perl Programming Language and ☆☆☆☆ :) Je suis Charlie!}	[reply]
Re^5: [EMACS] "Emacs as Perl IDE" - Abstract for YAPC::EU 2016 ( A tale about IDE usage ) by soonix (Chancellor) on Jul 20, 2016 at 11:30 UTC
For instance I tried to help them to switch the internal REPL from Python to Perl - for vain. perhaps there is a global configuration that you could alter, and "sell" it to them as being a part of the regular system updates (I'd assume somewhere in `C:\Program Files\...`) :-) P.S. I assumed a Windows "Terminal Server". if everyone is working on their own 'puter, perhaps your sysadmins might help you with a GPO or something...	[reply] [d/l]
Re^6: [EMACS] "Emacs as Perl IDE" - Abstract for YAPC::EU 2016 ( A tale about IDE usage ) by LanX (Saint) on Jul 20, 2016 at 15:37 UTC
> a Windows "Terminal Server". if everyone is working on their own 'puter, A mix of both, but I rather spend time improving my Emacs than evangelizing their Komodo. :) Cheers Rolf _{(addicted to the Perl Programming Language and ☆☆☆☆ :) Je suis Charlie!}	[reply]
Re^5: [EMACS] "Emacs as Perl IDE" - Abstract for YAPC::EU 2016 ( A tale about IDE usage ) by doom (Deacon) on Jul 20, 2016 at 19:05 UTC
Well, that's a scary story, in a lot of ways... when I first started playing with the perl debugger I found that some people have a prejudice against debuggers, essentially because they argue that the debugger makes it possible to get code working without understanding it very well. There's at least a bit of truth there... it's true that I resort to stepping through code when I'm having trouble just reading it... but it's always seemed to me that using the debugger encourages me to be a little neater (e.g. all of a sudden I care about having explicit return lines a lot, because that's a place where the debugger can pause... otherwise it returns on you and you lose the scope and can't examine any of the intermediate values any more). (The difference in perspective between management and programmer's is always a problem... the last place I was working it was hard to convince management that writing tests and doucmentation is not a waste of time. I had the feeling that there were people there who were adrenaline junkies who kind of enjoyed it when things broke... then the whole team comes together and scrambles around finding a fix, and there's a sense of group accomplishment.)	[reply]