From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=3.4.4 X-Google-Thread: 103376,e7151167e0767ecc X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!proxad.net!usenet-fr.net!enst.fr!melchior!cuivre.fr.eu.org!melchior.frmug.org!not-for-mail From: Stephen Leake Newsgroups: comp.lang.ada Subject: Re: Feasibility of using Ada in new development Date: 04 Sep 2004 11:06:02 -0400 Organization: Cuivre, Argent, Or Message-ID: References: <8429999a.0408231027.2850e800@posting.google.com> <19b0e504.0408251305.73ed26c8@posting.google.com> <87brgxkbol.fsf@insalien.org> <19b0e504.0408280957.5e266d7@posting.google.com> <877jrjhzx4.fsf@insalien.org> <19b0e504.0408300906.15164bf3@posting.google.com> <19b0e504.0408310911.1e885c26@posting.google.com> <0Q2Zc.2443$TG.1908@trndny01> <19b0e504.0409020718.40a57082@posting.google.com> <9tednWJ_s_4bBarcRVn-qw@megapath.net> NNTP-Posting-Host: lovelace.ada-france.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: melchior.cuivre.fr.eu.org 1094310382 23660 212.85.156.195 (4 Sep 2004 15:06:22 GMT) X-Complaints-To: usenet@melchior.cuivre.fr.eu.org NNTP-Posting-Date: Sat, 4 Sep 2004 15:06:22 +0000 (UTC) To: comp.lang.ada@ada-france.org Return-Path: In-Reply-To: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at ada-france.org X-BeenThere: comp.lang.ada@ada-france.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Gateway to the comp.lang.ada Usenet newsgroup" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Xref: g2news1.google.com comp.lang.ada:3318 Date: 2004-09-04T11:06:02-04:00 "Randy Brukardt" writes: > Actually, I have less tolerance for IDEs that try to 'help' by reorganizing > my carefully structured program text. Or by changing identifiers to match > some capitalization "standard", even if they don't make sense: "Text_Io", > anyone? Emacs solves the "Text_IO" case by allowing users to specify exceptions to the default capitalization rule. I expect a "good IDE" to do the same. > In any case, my MS-DOS editor is multi-window, does auto-indenting, > and allows all commands to be operated on blocks (even rectangles) > of text. This last capability is invaluable, because it is often the > case that you want to replace something is a section of text, not > the whole file, and there often are enough mods that OKing each one > isn't sane. I don't use it much, but I believe Emacs can do this as well, although not all commands will respect rectangles. > As far as creating the program goes, any decent Ada compiler will do > that with a single command (gnatmake for GNAT, make for Janus/Ada, > and there are similar commands in IBM/Rational Ada and in > ObjectAda). Nothing complicated about it, even if the program is > split into shared libraries and the like. The complicated part is fixing errors reported by the compiler. A "good IDE" will capture the compiler output, parse it, and pull up the source code with the cursor at the point of the and the error message in another window. An "excellent IDE" will then, at a keystroke, fix simple errors (like "= should be :="). Emacs (and GPS) does this. This ability is a _large_ productivity gain. Ada reports lots of good errors at compile time on "fresh" code; it must be easy to fix them. It is also essential when refactoring; that also produces lots of error messages. > Let me assure you, if a GUI really would help me be more productive, > I'd be using it. But short of building one myself (which I may do > someday, the one we provide with Janus/Ada is garbage), I don't > expect to see it. I don't think of Emacs as a GUI, but it is and excellent IDE. > > > all the GUI will do there is make it more likely to lose the > > > settings (because they're in some obscure settings file in the > > > registry or some remote directory, rather than in a batch file > > > that gets backed up daily with the source code...) > > > > I would hope a high-quality IDE would not. > > An IDE is in a lose-lose situation here. If it clutters up the users space > with all kinds of files with obscure contents, then people (rightly) will > complain about the clutter. If it hides the files, they are likely to not > get backed up. The "quality" of the IDE isn't going to fix this. I have two project files for each Ada project; one for GNAT and one for Emacs. The GNAT one sets compiler search paths and options; the Emacs one sets error parsing search paths and capitalization rules. Both are ASCII, human-editable. That's a very good compromise between your two extremes. > > > That said, I understand the many modern programmers are looking > > > for GUIs to hold their hands, and certainly we support that. > > > > Maybe not hold my hand but at least help speed up tedious tasks. > > And that is my point. There are almost no tedious tasks in creating programs > from the command line in Janus/Ada, or in GNAT. So a GUI simply doesn't buy > much. The only thing I find tedious is waiting for the compiler to finish - > and no GUI is going to help with that! One tedious task is fixing compiler errors, as I discussed above. Another is synching with a source code configuration management repository. Emacs pcvs mode is hands down the best user interface for this I have ever seen. It presents a list of files that need attention, and offers advice on what to do with each. Rational ClearCase doesn't come close to that; neither does GPS or any other CVS GUI. This is an absolute requirement for IDE's used by my team; consequently, they are all using Emacs (and I'm not getting complaints after the first month :). > ... > > Of course, that's just part of a general dumping-down of > programming. And > > that's what managers want: they want any idiot > to be able to build software, > > so they can hire minimum wage > people (or outsource) to do the job. But > > you're never going to > get anything well-designed and maintainable that way. > > > > I assume you made a typo above and mean dumbing-down? > > Yes, it was a typo. I agree here. Emacs is a powerful tool, and takes time to learn and skill to use well. One guideline in judging a potential team member is to ask if they like Emacs. If they've never tried it, I give them a chance. If they have tried it and don't like it, they are suspect. Same for whether they like Ada. -- -- Stephe