6 ms·

pakage int_io is new integer_io (num=>integer); and then int_io.putline(num);

shakna 7y ago
with Ada.Text_IO; use Ada.Text_IO; with Ada.Integer_Text_IO; use Ada.Integer_Text_IO; ... PutLine(num); As far as I can tell, Ada has had Integer_Text_IO that does that all for you, since the early days. [0] (Note that the reference is the first "public" release of Ada outside of the DOD). [0] https://www.adahome.com/LRM/83/RM/rm83html/lrm-14-03.html#14.3.7 https://www.adahome.com/LRM/83/RM/rm83html/lrm-14-03.html#14... (Ada 83 Manual)
- kazinator 7y ago
  That's an awful amount of boilerplate for a simple integer hello world. Languages with these modules and import statements should be burned. (Starting with Python.) For pete's sake, couldn't they at least combine this with and use into one keyword so you don't have to repeat yourself? Or can't use be made to forgive a missing with and just get on with the show? Do defense contracts pay by the byte or what?
  - shakna 7y ago
    'use' allows you to integrate namespaces, that's all. You can have multiples of those within the same file. Not all 'with' statements will only expose a single namespace. Nothing different than std in C++.
    - kazinator 7y ago
      C++ is awful also; it is not a good choice of benchmark for brevity. Though a single use declaration will get you the identifier in C++, the right header file has to be #included. At least it's possible for a single include to bring in lots of material: #include <biglib> // just one of these use bigfoo::bar; // one per identifier use bigwidget::zark; But C++ has lots of irritating repetition like: class foo { foo(); ~foo(); }; foo::foo() { } foo::~foo() { } Seven repetitions of foo just to set up an empty class skeleton with non-inlined constructor and destructor. (The C++ people are self-conscious about verbosity, and trying to fix the problem; unfortunately, in wrongheaded ways that are making the language worse.)
      - shakna 7y ago
        I'm not sure brevity is a benchmark for a good language either. So far as I can tell, you dislike how verbose the Ada "hello world" is, because it supports namespaces, and uses them. That wouldn't be something I'd agree with, especially not when dealing with any program of significant size.
        Supermancho 7y ago
        > I'm not sure brevity is a benchmark for a good language either. It's the only benchmark that we have any kind of analysis for (https://www.researchgate.net/publication/3188171_The_Confounding_Effect_of_Class_Size_on_the_Validity_of_Object-Oriented_Metrics https://www.researchgate.net/publication/3188171_The_Confoun...), which correlates to less defects and less time per feature. Less code is better. Until I see evidence to the contrary, I think it's a valid criticism. YMMV
        shakna 7y ago
        I agree with less code, but the tokens themselves needing to be shorter, not so much - so long as they remain easily readable.
        kazinator 7y ago
        > When we controlled for class size all of the effects disappeared, providing compelling evidence for a confounding effect of class size Holy crap; are they really saying that all the various correlations seen between numerous software metrics and fault proneness are actually the effect of nothing but raw size? That's so intuitive. Because in our daily experience, almost all reasonable approaches to to various aspects of program organization actually work fine in programs of a size that one programmer can comfortably fully understand and maintain. Even for any technique reviled as "bad" and discouraged in coding standards, there are counterexamples of it working fine. Those counterexamples are in the context of small programs, so we are told, "just wait, that approach will burn you in a big program". But it looks like what will burn you is just the size of that big program, no matter what techniques you wield, whether blessed or not. That little paper you pointed to there (thank you) looks pretty darn important.

with Ada.Text_IO; use Ada.Text_IO; with Ada.Integer_Text_IO; use Ada.Integer_Text_IO; ... PutLine(num); As far as I can tell, Ada has had Integer_Text_IO that does that all for you, since the early days. [0] (Note that the reference is the first "public" release of Ada outside of the DOD). [0] https://www.adahome.com/LRM/83/RM/rm83html/lrm-14-03.html#14.3.7 https://www.adahome.com/LRM/83/RM/rm83html/lrm-14-03.html#14... (Ada 83 Manual)

kazinator 7y ago
That's an awful amount of boilerplate for a simple integer hello world. Languages with these modules and import statements should be burned. (Starting with Python.) For pete's sake, couldn't they at least combine this with and use into one keyword so you don't have to repeat yourself? Or can't use be made to forgive a missing with and just get on with the show? Do defense contracts pay by the byte or what?
- shakna 7y ago
  'use' allows you to integrate namespaces, that's all. You can have multiples of those within the same file. Not all 'with' statements will only expose a single namespace. Nothing different than std in C++.
  - kazinator 7y ago
    C++ is awful also; it is not a good choice of benchmark for brevity. Though a single use declaration will get you the identifier in C++, the right header file has to be #included. At least it's possible for a single include to bring in lots of material: #include <biglib> // just one of these use bigfoo::bar; // one per identifier use bigwidget::zark; But C++ has lots of irritating repetition like: class foo { foo(); ~foo(); }; foo::foo() { } foo::~foo() { } Seven repetitions of foo just to set up an empty class skeleton with non-inlined constructor and destructor. (The C++ people are self-conscious about verbosity, and trying to fix the problem; unfortunately, in wrongheaded ways that are making the language worse.)
    - shakna 7y ago
      I'm not sure brevity is a benchmark for a good language either. So far as I can tell, you dislike how verbose the Ada "hello world" is, because it supports namespaces, and uses them. That wouldn't be something I'd agree with, especially not when dealing with any program of significant size.
      - Supermancho 7y ago
        > I'm not sure brevity is a benchmark for a good language either. It's the only benchmark that we have any kind of analysis for (https://www.researchgate.net/publication/3188171_The_Confounding_Effect_of_Class_Size_on_the_Validity_of_Object-Oriented_Metrics https://www.researchgate.net/publication/3188171_The_Confoun...), which correlates to less defects and less time per feature. Less code is better. Until I see evidence to the contrary, I think it's a valid criticism. YMMV
        shakna 7y ago
        I agree with less code, but the tokens themselves needing to be shorter, not so much - so long as they remain easily readable.
        kazinator 7y ago
        > When we controlled for class size all of the effects disappeared, providing compelling evidence for a confounding effect of class size Holy crap; are they really saying that all the various correlations seen between numerous software metrics and fault proneness are actually the effect of nothing but raw size? That's so intuitive. Because in our daily experience, almost all reasonable approaches to to various aspects of program organization actually work fine in programs of a size that one programmer can comfortably fully understand and maintain. Even for any technique reviled as "bad" and discouraged in coding standards, there are counterexamples of it working fine. Those counterexamples are in the context of small programs, so we are told, "just wait, that approach will burn you in a big program". But it looks like what will burn you is just the size of that big program, no matter what techniques you wield, whether blessed or not. That little paper you pointed to there (thank you) looks pretty darn important.