Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re^3: [EMACS] "Emacs as Perl IDE" - Abstract for YAPC::EU 2016

by Erez (Priest)
on Jul 19, 2016 at 07:51 UTC ( #1168036=note: print w/replies, xml ) Need Help??


in reply to Re^2: [EMACS] "Emacs as Perl IDE" - Abstract for YAPC::EU 2016
in thread [EMACS] "Emacs as Perl IDE" - Abstract for YAPC::EU 2016

> which can be used to force a code-style across the company (hence the name), which is a good counter argument to those that claim perl is unsuitable for large companies/projects.

Doesn't this contradict your later claim that Perl doesn't need an IDE??? ;-)

I like your line of reasoning. As I should state, this boils down to personal preference. I have worked in languages and technologies that are near unusable without an IDE. In many ways, it's also because the environment (read: Windows) doesn't support many of the userspace tools readily available to *NIX users, like grep, or has no readily-available way of printing out data-structures to STDOUT (e.g. Data::Dumper), and if and when you do inspect structures, they are unreadable.

Perl, OTOH, can dump any structure at any point, and you can always figure out "what does perl think X is" which is basically what you need debugging for. There's also less need of the "Intellisense" feature since you're not dealing with tens of thousands of classes and methods, and the libraries you choose have usually a simple and well documented API (yey CPAN Kwalitee).

As for company-mode and code style, I don't think this is an integral part of an IDE. It's more of a feature of existing IDEs, and you can accomplish the same in many other editors and tools, without having to lock-in to an IDE.

Emacs is not an IDE it's an IDE construction set!

That is definitely *the* selling point of emacs, and you can construct it to better suit your needs. Whether you want a debugger, or a code-style, or some sort of CI, it's all available in emacs. You can also integrate emacs with a bug-tracker or similar, and I again point to Org-mode as an excellent project management tool. Also, it has one of the better git integration with magit, which can be seriously helpful in development.

Come to think about it, I would say that, while perl doesn't need an IDE, software development of large projects or in a large company does need a lot of tools to assist the streamlining of the development, and emacs has all of those, and then some.

Principle of Least Astonishment: Any language that doesn't occasionally surprise the novice will pay for it by continually surprising the expert

  • Comment on Re^3: [EMACS] "Emacs as Perl IDE" - Abstract for YAPC::EU 2016

Replies are listed 'Best First'.
Re^4: [EMACS] "Emacs as Perl IDE" - Abstract for YAPC::EU 2016 ( A tale about IDE usage )
by LanX (Bishop) on Jul 19, 2016 at 22:12 UTC
    > 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!

      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.

        > 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!

      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...
        > 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!

      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.)

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1168036]
help
Chatterbox?
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (5)
As of 2018-01-21 07:34 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    How did you see in the new year?










    Results (227 votes). Check out past polls.

    Notices?