Slashdot Mirror

← Back to Stories (view on slashdot.org)

Extensible IDEs?

Posted by Cliff on from the adding-your-own-functionality dept.

Whatever Fits queries: "We are trying to integrate our own specialized development environment. We are currently using Visual Studio and the add-in feature of that, but would like to get away from the Microsoft tax and have had to rewrite our software from scratch for reasons outside this scope. The current project includes adding specialized features to the IDE to handle our project types, extra tool-windows for user interaction, and an external process to run the compiled code. The compiled language is even open for debate right now, but would have to be something rather common or easy to learn. I really want to try to run Perl with SOAP for our backend. This is going to run on Windows systems but I am hoping to go for something cross platform for future extensibility if possible. What IDEs can be recommended that offer this kind of extensibility and keep the price per copy reasonable? I have a small list already built, but I have no experience with any of these but Visual Studio and would like to hear both success and horror stories of integration."

5 of 87 comments (clear)

  1. Bad Idea by Anonymous Coward · · Score: 0, Insightful

    Any company that imposes an IDE (or for worse extends an IDE) for their people is doomed to be irrelevant, wrong and full of bad ideas.

    Having worked for several years in several software projects, I cannot imagine a good reason why I would want to impose some kind of IDE to people.

    Call me inflexible, old, or retarded, but I would not want to work for a company that imposes its IDE (for 'christ' sake! an IDE! IDEs are religion! (emacs? vim? vi?))

    koen

  2. You're doing it backwards by AuMatar · · Score: 4, Insightful

    Ok. Let the flaming begin.

    You're really making a very stupid, and potentially very costly, mistake. You NEVER dictate the language you use based on the tools. Thats a sure way to make a project come in over-budget and late. You base the language off two things- developer familiarity, and ease of use for the application. If the developers are not familiar with the language, no matter what whiz-bang features your tool has, they will be slow at writing it, and come up with ugly, inefficient, buggy code. The other factor is how good the language is for the job. Perl is great for scripting, if you dont need bleeding edge speed. C if you need every last bit of speed you can get. C++ if you want to lose a little speed for its OO features. Java if you need multiplatform capability. And so on. No matter how great the tool is, it will not turn C into a scripting language, or make perl as fast at math as C.

    Here's what you ought to do. Pick a language. Make the decision off of what the program needs to do, its speed/memory requirements, and developer familiarity to pick the best language for your progra and team. THEN research tools. Remember, a tool can help ease a process, but it won't make anywhere near as big a difference as using the right language for the job, or as big as programmer experience. Trust me, your project will run smoother for it.

    --
    I still have more fans than freaks. WTF is wrong with you people?
    1. Re:You're doing it backwards by fperez · · Score: 2, Insightful

      If "The language choice is based upon features, extensibility, and ease of learning", I'd take a serious look at using Python instead of Perl.

      I know these things get religious quickly, but I say this as someone who used to love Perl and write lots of it. Eventually I looked at Python and now I just can't stand the mountain of misfeatures and backwards design that Perl is. Fine for impressing people with cryptic 3-liners which do lots, absolutely useless for implementing large, clean, maintainable systems. Yes, I know full well that it _can_ be done in Perl, but you have to fight at every line to get there.

      OTOH, you can obviously also write bad code in Python (or any other language). But the point is that in one (Python) the design 'flows' with you for making things clean, modular and readable, while in the other (Perl) you're swimming always upstream. You can eventually get there, but you'll be exhausted and it will have taken much longer.

      Besides, Python has very easy integration with C/C++ (in case you ever need speed in certain critical parts) and bindings for pretty much every GUI toolkit out there.

      Just an opinion... Good luck.

  3. The OS is the IDE by chromosundrift · · Score: 2, Insightful

    Some more than others.

    This is key to thinking about development, otherwise you're prey to continually building new extensible systems on top of old inextensible systems.

    c

  4. Re:jEdit by Anonymous Coward · · Score: 1, Insightful

    That's like saying Word is just notepad but with smarts. Yes, you can type stuff into both of them but that's where the similarites end. A full fledged IDE is the only efficient way to handle code in a large product. For making stupid little edits in some piss ant php page a text editor is fine, for building a 300 source file C++ application you would be insane or stupid to use a text editor in place of an IDE.