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=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Running a preprocessor from GPS? Date: Tue, 28 Jul 2015 16:12:51 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <2df4698f-4c8e-457c-822d-209cb2f8ab5e@googlegroups.com> NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1438117973 16119 24.196.82.226 (28 Jul 2015 21:12:53 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 28 Jul 2015 21:12:53 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:27101 Date: 2015-07-28T16:12:51-05:00 List-Id: "EGarrulo" wrote in message news:2df4698f-4c8e-457c-822d-209cb2f8ab5e@googlegroups.com... >On Monday, July 27, 2015 at 10:26:39 PM UTC+2, Randy Brukardt wrote: >> Besides, if you're going to be writing Ada, you're going to be writing >> code >> that's more verbose (in many ways) than C-family languages. It might take >> some getting used to, but there is no time better than the present to >> getting used to that. > >I don't mind verbosity when it serves a purpose, but I have little >tolerance for >boilerplate code, and this is one such case. Let's add the lack of a >facility like "printf", Not strongly typed. >along with a generic type system that can't perform basic type inference, Would have to weaken the type system. > and I am beginning to understand why engineers opposed the adoption of Ada > by the US Department of Defense. Ada is not for people that want to write quick sloppy code (and then debug it for months). Besides, the C++ generics that you are implicitly referring to didn't exist until long after Ada was designed. And they do things which would destroy the Ada contract model of generics (in C++, generics are glorified macros). > Requiring programmers to state their intentions explicitly is beneficial, > but > requiring programmers to "spoon-feed" the compiler and/or write bloated > code is not. "Real Ada Programmers" don't even use the shortcuts built-into Ada: (1) Real Ada Programmers don't use "use clauses" - objects are named by their expanded names; (2) Real Ada Programmers don't use anonymous access types or anonymous array types; (3) Real Ada Programmers don't use positional calls; (4) Real Ada Programmers don't use Ada 2012 conditional expressions (unless they need the expression to be static). And so on. [I'm being a bit tongue-in-cheek here. I don't quite qualify as a "Real Ada Programmer" under this definition, as I'll use targeted "use type" clauses for operators, and "use clauses" for some language-defined packages (like Text_IO), and for a project-specific core type package (there are several of these in Janus/Ada). And I definitely use positional calls 'cause I'm too lazy to find and write out the parameter names. But I'm surely pretty close to the spirit here.] Most Ada programmers quickly find the value of the verbosity, because it means that the compiler can catch a lot of errors before anyone has to spend time debugging. But I can see that it is a hard sell, because as with many of the real advantages of Ada, it's not really apparent until you've used the language a while and realized that it detected things that you normally would have had to find some other way (typically, hours in a hot debugger or lengthy trace log). My recommendation (as always) is to do things "the Ada way" and you'll find that it starts to make sense after a while. It's especially true about worrying about perceived "verbosity" or micro-performance (the cost of evaluating unused trace messages). Those things are really premature optimization -- a trap that we all fall into from time-to-time, but a trap nevertheless. They end up having no impact on the quality of the resulting application, and take up valuable time that could have been better used doing something that does impact the quality of the application. Randy.