New IEEE Language Popularity Ratings

New IEEE Language Popularity Ratings

[brbarkstrom]

http://spectrum.ieee.org/static/interactive-the-top-programming-languages-2016

has a 2016 ranking of languages.  Top two are C, followed by Java.  Ada
is down near the bottom of the list, but at least it's slightly more
popular than COBOL and FORTH.

Bruce B.

Re: New IEEE Language Popularity Ratings

[Alejandro R. Mosteo]

On 28/07/16 16:58, brbarkstrom@gmail.com wrote:
> http://spectrum.ieee.org/static/interactive-the-top-programming-languages-2016

You beat me to the punch!

>
> has a 2016 ranking of languages.  Top two are C, followed by Java.  Ada
> is down near the bottom of the list, but at least it's slightly more
> popular than COBOL and FORTH.

Well, it depends on the raking criterion :D COBOL is both trendier and 
with better job perspectives X(

Alex.

>
> Bruce B.
>

Re: New IEEE Language Popularity Ratings

[brbarkstrom]

On Thursday, July 28, 2016 at 11:05:45 AM UTC-4, Alejandro R. Mosteo wrote:

> > http://spectrum.ieee.org/static/interactive-the-top-programming-languages-2016
> 
> You beat me to the punch!
> 
> >
> > has a 2016 ranking of languages.  Top two are C, followed by Java.  Ada
> > is down near the bottom of the list, but at least it's slightly more
> > popular than COBOL and FORTH.
> 
> Well, it depends on the raking criterion :D COBOL is both trendier and 
> with better job perspectives X(
> 
> Alex.
> 
> >
> > Bruce B.
> >

Just happened to notice the note in my e-mail.  I think there may be
some ways of interacting with the article to provide various sorts
of rankings.

Bruce B.

Re: New IEEE Language Popularity Ratings

[G.B.]

On 28.07.16 22:19, brbarkstrom@gmail.com wrote:
> On Thursday, July 28, 2016 at 11:05:45 AM UTC-4, Alejandro R. Mosteo wrote:
>
>>> http://spectrum.ieee.org/static/interactive-the-top-programming-languages-2016
>
>   I think there may be
> some ways of interacting with the article to provide various sorts
> of rankings.

Just clicked on a few buttons. For example, hid all but what
remains with the phone button. Still C at 1. How on earth can C,
and C++, and C# be ranked at positions 1, 3, and 5 for smartphones?
(Because of Android/Linux (C), whatever (C++), and Xamarin (C# for
non-Microsoft phones?) They've got to be kidding.

If not, I'd hope some day they start also measuring profit generated
by languages. Public sources of $-for-language include stack*.com:
their job ads seem to be sensitive to programming languages.

Re: New IEEE Language Popularity Ratings

[Jerry]

Try setting sliders related to people seeking help--Google and both Stack Overflows, for example--to zero, and Ada moves up a lot.

Re: New IEEE Language Popularity Ratings

[brbarkstrom]

On Friday, July 29, 2016 at 2:41:07 AM UTC-4, Jerry wrote:
> Try setting sliders related to people seeking help--Google and both Stack Overflows, for example--to zero, and Ada moves up a lot.

One other factor may be of interest in thinking about these ratings:
the importance of libraries for current ways people build software.
The tendency appears to be to select standard libraries and hope they
remain stable enough to serve over a reasonable length of time.  Once
people get used to using this approach, they don't write as much code
themselves - they just figure out how to hook in a library to do the 
work.  I suppose you could call it the "cut and paste" approach to
developing software.

Bruce B.

Re: New IEEE Language Popularity Ratings

[Serge Robyns]

On Friday, 29 July 2016 14:37:21 UTC+2, brbar...@gmail.com  wrote:
> On Friday, July 29, 2016 at 2:41:07 AM UTC-4, Jerry wrote:
> > Try setting sliders related to people seeking help--Google and both Stack Overflows, for example--to zero, and Ada moves up a lot.
> 
> One other factor may be of interest in thinking about these ratings:
> the importance of libraries for current ways people build software.
> The tendency appears to be to select standard libraries and hope they
> remain stable enough to serve over a reasonable length of time.  Once
> people get used to using this approach, they don't write as much code
> themselves - they just figure out how to hook in a library to do the 
> work.  I suppose you could call it the "cut and paste" approach to
> developing software.
> 
> Bruce B.

Is this not the whole purpose of reusable libraries? Otherwise we will all still program in assembly language and write our containers the hard way for example ....

And yes this is the main driver to choose a programming environment in the field of general programming.  Writing bindings is a "patch" to have access to those libraries.  Companies prefer to pay people to do "new" things not to "reinvent" the wheel.

Re: New IEEE Language Popularity Ratings

[brbarkstrom]

> Is this not the whole purpose of reusable libraries? Otherwise we will all still program in assembly language and write our containers the hard way for example ....

I think the response on this needs a bit more nuance.  There are several
reasons one might not want to use a library from some source, even though
a developer wouldn't have a need to use assembly language.  So, if you're the
developer here are some questions to ask:

1.  Do I trust the algorithms in the library?

Numerical procedures may need care to ensure they've been implemented carefully.
For example, if one has to do matrix inversion, it's important to use a Singular
Value Decomposition (SVD) algorithm implemented with long floats (or double
precision).  I don't know whether spreadsheet inversions do that, so I might
not want to use a spreadsheet - even if the spreadsheet has matrix inversion.

Another example is random number generators.  Knuth's Art of Computer 
Programming, Vol. 2, is the basic definitive reference.  It includes ten
tests of a random number generator that anybody needing one should be sure
have been used.  Park and Miller's article many years ago in CACM provides
code for a portable version of an algorithm that they put through the Knuth
wringer.  In my own work, I've got an Ada library for generating probability
distributions that includes Park and Miller's algorithm, since it includes
a test as to whether it's been implemented correctly.  I might trust the 
algorithms in MatLab or Mathematica, but this kind of work is not for
amateur mathematicians.

2.  Do the data structures in the library fit with the ones I want to use
in my application?

For example, if you're planning to do Monte Carlo simulations of schedule
uncertainties and resource loading, it would be wise to make sure that a
library's calculations can handle a topological sort (depth-first search)
through the graph represented by the activities and links that form the
directed acyclic graph (DAG) to get the critical path - meaning that the
path through the graph needs to be able to go from beginning to end and
from end to beginning.  Again, the numerical calculations should be in
double precision numbers.  Assuming the schedule is for computation, the
duration of the activities should probably be in days or seconds, not in
work weeks that require including no work on weekends and holidays.

3.  How stable is the library?  This question also involves assessing
risks: Can I take over maintenance of the library to ensure it's stable?
How much work will my maintainers have to do to deal with upgrades in
the library - or learning to use it?

Here, Boehm's COCOMO II cost model has a good discussion of the cost of reusing
code.  As Boehm and colleagues note, reusing code may require redesign and 
actually cost more than writing new code.  Good software engineering practices
suggest that developers should evaluate this cost before undertaking the work.
In addition, organizations providing code libraries may drop them if their
priorities change or they go out of business.

Finally, the index to the Patents maintained by the U.S. Patent office had
45 PAGES listing patents for wheels.  We reinvent wheels all the time.  
It doesn't make much sense to attach bicycle wheels to aircraft landing gear 
(unless you're the Wright Brothers back a few years ago).

Bruce B.

Re: New IEEE Language Popularity Ratings

[rieachus]

On Saturday, August 6, 2016 at 11:53:56 AM UTC-4, brbar...@gmail.com wrote:

> 1.  Do I trust the algorithms in the library?
> 
> Numerical procedures may need care to ensure they've been implemented carefully.
> For example, if one has to do matrix inversion, it's important to use a Singular
> Value Decomposition (SVD) algorithm implemented with long floats (or double
> precision).  I don't know whether spreadsheet inversions do that, so I might
> not want to use a spreadsheet - even if the spreadsheet has matrix inversion.

I'm going to take potshots at the inversion advice here, random numbers to follow.

I have always used LUP decomposition for inversion of large matrices. (And scaling if the values have a wide range.)  L is a lower triangular matrix, U an upper triangular matrix, and P is a permutation matrix. (All zeroes except one one in each row and column.)  Computing the inverse from the LUP decomposition is easy, and multiplying out the LUP decomposition will tell you how badly you have mangled the data.  (And yes, you should also multiply the original matrix by the inverse to get a residuals matrix.)  

As for using double precision, consider that a default.  Packages for x86 family chips can use the x87 IEEE Extended support that is still there.  There are (mostly software) routines that provide even more precision.  Why so much precision, when you are not measuring the diameter of the galaxy to the nearest atom? Because mixing float addition and multiplication burns off precision very quickly.  In fact, for some peculiar data, I have used discrete arithmetic, and an arbitrary precision package.  Not needed often, but if you are investing your money based on the results?  An extra few minutes of CPU time are cheap.

Re: New IEEE Language Popularity Ratings

[rieachus]

On Saturday, August 6, 2016 at 11:53:56 AM UTC-4, brbar...@gmail.com wrote:

> Another example is random number generators.  Knuth's Art of Computer 
> Programming, Vol. 2, is the basic definitive reference.  It includes ten
> tests of a random number generator that anybody needing one should be sure
> have been used.  Park and Miller's article many years ago in CACM provides
> code for a portable version of an algorithm that they put through the Knuth
> wringer.  In my own work, I've got an Ada library for generating probability
> distributions that includes Park and Miller's algorithm, since it includes
> a test as to whether it's been implemented correctly.  I might trust the 
> algorithms in MatLab or Mathematica, but this kind of work is not for
> amateur mathematicians.

This is just bad advice today.  I have some RNGs that are much, much better than anything mentioned above, and which I now consider obsolete.  Why?  Computing has moved on from 16 bits, to 32, and now 64.  Generators fine for the 16 bit era are woefully obsolete today.  (Mine were explicitly designed to get 36 to 48 bit effective generators on 32 bit machines. ;-)  GNAT has a generator which is fine for the 64-bit era, and won't take much work to extend to 128 bits when needed.

Oh, and if you need cryptographically secure random numbers?  Run the output of the GNAT generator through SHA256, and you are good to go.  (SHA-1 is now deprecated and should not be used.)

Re: New IEEE Language Popularity Ratings

[brbarkstrom]

LUP decomposition is part of the tools involved in SVD.  You should consult 
either Numerical Recipes for Scientists and Engineers, or, better, 

Lawson, C. L. and Hanson, R. J., 1974: Solving Least Squares Problems, 
Prentice-Hall, Englewood Cliffs, NJ

They use Householder reductions, not just simple LUP decomposition.
They demonstrate that this approach preserves accuracy and does well with
phenomena such as truncation error.

The problems arise when the singular values get small.  The matrix inversion
takes the inverse of the singular values as part of its calculations.  This
introduces wild oscillations in the solutions. if the matrix is ill-conditioned.
Lawson and Hanson's algorithms were used in the Linpack and Lapack libraries.
The algorithms include pivoting to sort the singular values and reduce loss
of significant digits.  While the code was originally written for machines such
as the 60-bit CDC machines as well as other architectures, they work fine on Windows 32 and 64-bit machines.  You might look up the code, which is available
in FORTRAN - and try some of the examples of nearly singular matrices to see
how your LUP inversions hold up.

On RNG, the Park-Miller algorithm is written for at least 64-bit calculations.
The critical issue in this is the length of the cycles, not just the hardware.
I expect that the RNG algorithms have improved, although I haven't actively
checked their current state.  There's a lot of mathematical sophistication
involved in generating a reliable generator.  Again, Knuth should be the start
of the discussion.  His third edition of The Art of Computer Programming,
Volume 2, has about 50 pages devoted to statistical tests of random number
generators.  They include empirical tests, theoretical tests, and spectral
tests.  Knuth also describes how to do multi-byte numerical calculations
with a sound mathematical basis.

Along this line, is there documentation of which random number tests GNAT
used for its generator?

Bruce B.

Re: New IEEE Language Popularity Ratings

[Jeffrey R. Carter]

On 08/06/2016 08:53 AM, brbarkstrom@gmail.com wrote:
> 
> Another example is random number generators.  Knuth's Art of Computer 
> Programming, Vol. 2, is the basic definitive reference.  It includes ten
> tests of a random number generator that anybody needing one should be sure
> have been used.  Park and Miller's article many years ago in CACM provides
> code for a portable version of an algorithm that they put through the Knuth
> wringer.  In my own work, I've got an Ada library for generating probability
> distributions that includes Park and Miller's algorithm, since it includes
> a test as to whether it's been implemented correctly.  I might trust the 
> algorithms in MatLab or Mathematica, but this kind of work is not for
> amateur mathematicians.

These tests, while useful, are probably badly outdated for modern algorithms on
64-bit processors. More modern tests include TestU01's Crush and Big-Crush test
suites. The Threefry generator is said to be the fastest to pass all the
Big-Crush tests.

-- 
Jeff Carter
"I've seen projects fail miserably for blindly
applying the Agile catechism: we're Agile, we
don't need to stop and think, we just go ahead
and code!"
Bertrand Meyer
150

Re: New IEEE Language Popularity Ratings

[G.B.]

On 06.08.16 22:59, brbarkstrom@gmail.com wrote:
> Along this line, is there documentation of which random number tests GNAT
> used for its generator?


In only a clerkish way, not in an experts way, I found the following
answer in GNAT's s-rannum.ads, to whose body the comments in GNAT GPL 2014's
Ada.Numerics.{Discrete,Float}_Rnadom are referring (in a-nu{di,fl}ra.ads):

--  The generator currently provided by this package has an extremely long
--  period (at least 2**19937-1), and passes the Big Crush test suite, with the
--  exception of the two linear complexity tests. Therefore, it is suitable
--  for simulations, but should not be used as a cryptographic pseudo-random
--  source without additional processing.



-- 
"HOTDOGS ARE NOT BOOKMARKS"
Springfield Elementary teaching staff

Re: New IEEE Language Popularity Ratings

[brbarkstrom]

> > Another example is random number generators.  Knuth's Art of Computer 
> > Programming, Vol. 2, is the basic definitive reference.  It includes ten
> > tests of a random number generator that anybody needing one should be sure
> > have been used.  Park and Miller's article many years ago in CACM provides
> > code for a portable version of an algorithm that they put through the Knuth
> > wringer.  In my own work, I've got an Ada library for generating probability
> > distributions that includes Park and Miller's algorithm, since it includes
> > a test as to whether it's been implemented correctly.  I might trust the 
> > algorithms in MatLab or Mathematica, but this kind of work is not for
> > amateur mathematicians.
> 
> These tests, while useful, are probably badly outdated for modern algorithms on
> 64-bit processors. More modern tests include TestU01's Crush and Big-Crush test
> suites. The Threefry generator is said to be the fastest to pass all the
> Big-Crush tests.
> 
> -- 
> Jeff Carter
> "I've seen projects fail miserably for blindly
> applying the Agile catechism: we're Agile, we
> don't need to stop and think, we just go ahead
> and code!"
> Bertrand Meyer
> 150

The algorithms are mathematical artifacts and they have proofs related
to loss of digital information.  Whether or not the bits in the hardware
are 32 or 64 or 128 bits doesn't matter.  Neither does the age.  Most 
mathematical algorithms are essentially ageless.  Can we get the Big Crush
test suite to identify the specific relations between Knuth's tests and
their tests?  I'll try to find the time to see if I can use the reference
to the RNG in AdaCore.  In the mean time, some examination of the floating
point standard and rounding and truncation error may be appropriate.

Unfortunately, Lawson and Hanson's algorithm doesn't easily translate to
Ada because they rely on FORTRAN's (rather opaque) approach to memory
management within COMMON blocks for dealing with Pivoting.

Bruce B.

Bruce B.

Re: New IEEE Language Popularity Ratings

[Dmitry A. Kazakov]

On 2016-08-07 03:19, brbarkstrom@gmail.com wrote:

>> These tests, while useful, are probably badly outdated for modern algorithms on
>> 64-bit processors. More modern tests include TestU01's Crush and Big-Crush test
>> suites. The Threefry generator is said to be the fastest to pass all the
>> Big-Crush tests.
>
> The algorithms are mathematical artifacts and they have proofs related
> to loss of digital information.  Whether or not the bits in the hardware
> are 32 or 64 or 128 bits doesn't matter.  Neither does the age.  Most
> mathematical algorithms are essentially ageless.

True, but regarding pseudo-random numbers all this does not apply. These 
numbers are not random. Tests passed or not do not change this. They 
only show if a given method of generation were suitable to use the 
generated sequence for a given set of applications. Applications change 
so the tests must do.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: New IEEE Language Popularity Ratings

[Norman Worth]

On 7/28/2016 9:05 AM, Alejandro R. Mosteo wrote:
> On 28/07/16 16:58, brbarkstrom@gmail.com wrote:
>> http://spectrum.ieee.org/static/interactive-the-top-programming-languages-2016
>>
>
> You beat me to the punch!
>
>>
>> has a 2016 ranking of languages.  Top two are C, followed by Java.  Ada
>> is down near the bottom of the list, but at least it's slightly more
>> popular than COBOL and FORTH.
>
> Well, it depends on the raking criterion :D COBOL is both trendier and
> with better job perspectives X(
>
> Alex.
>
>>
>> Bruce B.
>>
>
Job preservation, and job availability, are key.  Despite its 
advantages, there is not much being done in Ada, especially in the US. 
Europe is a bit better, but still declining. Even in the mission 
critical defense area, Ada has fallen out of use.  This has been costly 
in terms of maintenance and reliability, but contractors feel they can 
not use Ada for personnel reasons.  Also, they often do not want to use 
Ada because of a perceived lack of tools.  That situation is not as bad 
as it used to be, but tools are still behind those available for C/C++, 
and the available tools are relatively unknown.  GUI and database 
interfaces are also big issues.

When I mention doing something in Ada, my very experienced peers 
shudder.  They have never been trained in the language, and they dread 
it.  Their perception is that Ada is a very large, extremely difficult 
language with an impossible learning curve.  They also feel it would be 
difficult to read, understand, and maintain.  The battle reminds me a 
bit of the Algol vs. FORTRAN battles in the 1970s.

Re: New IEEE Language Popularity Ratings

[Jeffrey R. Carter]

On 08/09/2016 12:58 PM, Norman Worth wrote:
>>
> Even in the mission critical defense area, Ada has fallen out
> of use.  This has been costly in terms of maintenance and reliability, but
> contractors feel they can not use Ada for personnel reasons.

In the defense area in the US, "personnel reasons" is an excuse. The real reason
is to maximize profits. For most US defense projects, the developing
organization's profits are proportional to the cost of the project, so anything
that increases costs is adopted. They use "Mongolian hordes" of the lowest-cost
(assuming that means least-competent) people they can find for this reason. A
poorly designed, error-prone language is an additional tool for maximizing profits.

-- 
Jeff Carter
"You tiny-brained wipers of other people's bottoms!"
Monty Python & the Holy Grail
18

Re: New IEEE Language Popularity Ratings

[Maciej Sobczak]

> In the defense area in the US, "personnel reasons" is an excuse. The real reason
> is to maximize profits.

I disagree. I can see you beating the same argument over and over again, but I don't find it to be substantial.

In defense or safety-critical industry in general, there are enough ways to generate so called "work hours" that the selection of technology is irrelevant. In some industries the statistics is that only about 5% to 10% of time is spent on actual coding, the rest is spent on maintaining all other artifacts, the set of which can be arbitrarily large, with arbitratily complex interdependencies and kept in multiple incompatible systems, etc., that can take ages to modify to reflect even a trivial functional change. Of course, all activities must be fully manual with no chance of being automated. In a such a setup it does not matter what is the implementation language, it might be anything - the treadmill of "work hours" is spinning elsewhere.

> A
> poorly designed, error-prone language is an additional tool for maximizing profits.

Then everybody would choose assembler if that was the real reason, but somehow this is not the case.
Interestingly, the choice of technology is frequently driven by the client themselves (that is, contractors have no influence on this choice), which further invalidates your argument.

A poorly designed software development process is orders of magnitude more effective in generating profits.

-- 
Maciej Sobczak * http://www.inspirel.com

Re: New IEEE Language Popularity Ratings

[Jeffrey R. Carter]

On 08/09/2016 02:18 PM, Maciej Sobczak wrote:
> 
> I disagree. I can see you beating the same argument over and over again, but I don't find it to be substantial.

I don't know what your experience with US defense projects is, but I have seen
it again and again. Anything that can be done to increase costs is done.
Language choice is only one of many things, and yes, when they think they can
get the customer to accept it, they will propose assembler.

-- 
Jeff Carter
"You tiny-brained wipers of other people's bottoms!"
Monty Python & the Holy Grail
18

Re: New IEEE Language Popularity Ratings

[Anh Vo]

On Tuesday, August 9, 2016 at 3:26:36 PM UTC-7, Jeffrey R. Carter wrote:
> On 08/09/2016 02:18 PM, Maciej Sobczak wrote:
> > 
> > I disagree. I can see you beating the same argument over and over again, but I don't find it to be substantial.
> 
> I don't know what your experience with US defense projects is, but I have seen
> it again and again. Anything that can be done to increase costs is done.
> Language choice is only one of many things, and yes, when they think they can
> get the customer to accept it, they will propose assembler.

The Co that I work for makes more $$$ if more problems are found. Thus, there is no incentive to improve time and quality. I wish fixed price contract is used instead variable price contract. In addition, if the contract is behind schedule, a penalty will be imposed in term of money subtracted from the original contract cost. This amount will be proportional to time behind schedule.

AV

Re: New IEEE Language Popularity Ratings

[Stu Hollander]

On 2016-08-09, Norman Worth <nworth@comcastNOSPAM.net> wrote:
> On 7/28/2016 9:05 AM, Alejandro R. Mosteo wrote:
>> On 28/07/16 16:58, brbarkstrom@gmail.com wrote:
>>> has a 2016 ranking of languages.  Top two are C, followed by Java.

That's because the two of the three most popular "operating systems" are
written in C and top one uses mostly Java.

> When I mention doing something in Ada, my very experienced peers 
> shudder.  They have never been trained in the language, and they dread 
> it.  Their perception is that Ada is a very large, extremely difficult 
> language with an impossible learning curve. 

And C++ isn't?

>They also feel it would be difficult to read, understand, and maintain.

And C++ isn't?

It's really quite the opposite. C is an unsafe language, C++ is unreadable,
error-prone and builds on C's worst attributes. Ada is readable, safe, and
maintainable and was designed (as opposed to C and C++!) from the beginning
to deal with large systems. It's unfortunate and we all realize it's going
to stay that way but people really missed out and continue to miss out by
not looking into Ada and other alternatives. They prefer to stay with the
broken tools they already think they know. The devil you know vs. the devil
you don't know. In reality the situation is quite the opposite of what most
people imagine. C++ is enormous and complicated. I don't believe anybody
knows it all. Those people are afraid of Ada? They're the ones who would
probably benefit from it and enjoy the refreshing change the most.

As you said the tools are not there. That is enough to kick Ada out the door
no matter how good the language is. If C and C++ had no libraries they'd
also be unusable...

> The battle reminds me a bit of the Algol vs. FORTRAN battles in the
>  1970s. 

I don't remember that because outside of academia nobody cared about ALGOL
and we all there wasn't a snowball's chance in hell FORTRAN was going to be
displaced. To some degree FORTRAN and Fortran are still hanging on. Not that
ALGOL wasn't an interesting language but it fell off the radar 40 years ago
and there hasn't been a sighting since.

Stu

Re: New IEEE Language Popularity Ratings

[Paul Rubin]

Stu Hollander <s.hollander@ghrt.com> writes:
> It's really quite the opposite. C is an unsafe language, C++ is unreadable,
> error-prone and builds on C's worst attributes. Ada is readable, safe, and
> maintainable and was designed (as opposed to C and C++!) from the beginning
> to deal with large systems.

Oh come on, C++ really is an improvement over C, and it was also
designed to deal with large systems.  Whether it does so successfully is
of course debatable, but at least that was the intent.  

I've messed with Ada enough to be convinced it's better than C in just
about every way, and I'd agree it's better at safety and critical
systems than C++, but there are some types of coding that C++ does
easily where I don't know if there's an Ada equivalent.  RAII, the way
the STL fits together, move semantics, etc.  C++11 and later almost feel
like in a scripting language.  Using it for a while makes C seem
unbearable.  I'm nowhere near expert at C++ (I'm maybe intermediate
level by now) but I'm quite comfortable with it and if there's a feature
I don't understand, I can read about it online.  Realtime and embedded
stuff being a niche, Ada's most serious competitor is probably Java
rather than C++.  My buddy who told me about Ada worked on a huge Ada
program that controlled a communications network back in the day, so it
had high reliability requirements but wasn't realtime or close to the
hardware.  Today something like that would probably be written in Java,
or anyway certainly not C.

> As you said the tools are not there. That is enough to kick Ada out
> the door no matter how good the language is. If C and C++ had no
> libraries they'd also be unusable...

C++ certainly loses a lot without the libraries.  C is lower level and
still has its attractions.  I thought Ada had a good FFI anyway, so it
should be possible to wrap the more useful C and C++ libraries for use
by Ada programs.  A lot of good Python and Haskell libraries come from
basically doing that.

Lately I've been looking at this C++ concurrency framework:

  http://www.seastar-project.org/

I'd be interested to know if could map reasonably to Ada.

Re: New IEEE Language Popularity Ratings

[gautier_niouzes]

Stu Hollander:

> If C and C++ had no libraries they'd also be unusable...

Libraries are the key. Let's write more of them!

> [...] there wasn't a snowball's chance in hell FORTRAN was going to be
> displaced. To some degree FORTRAN and Fortran are still hanging on.

That's the encouraging part, because 40 years later, FORTRAN *has* been displaced, and we can safely say that in its turn C{++} (0, 2 or 4 "++") "hasn't a snowball's chance in hell" (love this expression!) to be displaced :-). Now, travel a few decades further...
_________________________ 
Gautier's Ada programming 
http://www.openhub.net/accounts/gautier_bd

Re: New IEEE Language Popularity Ratings

[G.B.]

On 10.08.16 09:13, Paul Rubin wrote:
> Realtime and embedded
> stuff being a niche

A rather large and well funded niche, I understand.
Witness also the number of people who say "IoT".


-- 
"HOTDOGS ARE NOT BOOKMARKS"
Springfield Elementary teaching staff

Re: New IEEE Language Popularity Ratings

[G.B.]

On 10.08.16 08:08, Stu Hollander wrote:
> It's really quite the opposite. C is an unsafe language, C++ is unreadable,
> error-prone and builds on C's worst attributes. Ada is readable, safe, and
> maintainable and was designed (as opposed to C and C++!) from the beginning
> to deal with large systems. It's unfortunate and we all realize it's going
> to stay that way but people really missed out and continue to miss out by
> not looking into Ada and other alternatives.

Part of the reason why people feel right about not looking
into Ada is because Adaists keep telling them how stupid they
are. Would you like Joe Plumper tell you his opinion with you not
even asking for advice? That's not how a salesmen can succeed.
At the same time, people are being payed for producing products
using C++, the money coming from sales of their working programs.

No valuating statement is convincing per se, and, frankly,
typically uninformed about how languages become attractive.
The politics of Ada's initiation, the MBAs' predictable reaction,
and the ads-failure for Ada95 could be telling, but, no...

-- 
"HOTDOGS ARE NOT BOOKMARKS"
Springfield Elementary teaching staff

Re: New IEEE Language Popularity Ratings

[G.B.]

On 10.08.16 08:08, Stu Hollander wrote:
> Not that
> ALGOL wasn't an interesting language but it fell off the radar 40 years ago
> and there hasn't been a sighting since.

http://www.russbishop.net/swift-call-by-name

-- 
"HOTDOGS ARE NOT BOOKMARKS"
Springfield Elementary teaching staff

Re: New IEEE Language Popularity Ratings

[Maciej Sobczak]

> > Their perception is that Ada is a very large, extremely difficult 
> > language with an impossible learning curve. 
> 
> And C++ isn't?

> C++ is enormous and complicated. I don't believe anybody
> knows it all.

This is not a convincing argument. First, nobody knows the whole of Ada, either - even the experts on this group occasionally get into troubles with some language corners and with each language edition, there are more and more of them. Second, in embedded and safety-critical systems it is an established practice (sometimes even a requirement) to use a language subset, the more constrained the more critical the system is supposed to be. This applies to any language and if you get any strict coding standard, the language subsets are comparable in their size and learning curves.

In other words, it does not matter how dirty or difficult is C++ in any of its corners that is not going to be used in the project anyway.

Another point worth noting, especially in the embedded industry, is that hardware vendors heavily push C to their customers in terms of compilers, IDEs and HAL libraries. Go to any ARM vendor website and see what they have. It is not surprising that engineers coming to the market automatically fall into the trap... and stay there, as the potential advantages of Ada are not obvious if not backed by existing references from the hardware vendors. Consider that many people in this business are hardware (electronic) engineers who are new to programming, not the other way round.
Without support from hardware vendors, Ada will have a very difficult time getting any attention.

-- 
Maciej Sobczak * http://www.inspirel.com

Re: New IEEE Language Popularity Ratings

[Paul Rubin]

"G.B." <bauhaus@futureapps.invalid> writes:
>> Realtime and embedded stuff being a niche
> A rather large and well funded niche, I understand.

Is it?  Maybe I'm in an insular world but I only know one or two people
who work on stuff like that, vs. any number of web or application
programmers (generally server-side).

> Witness also the number of people who say "IoT".

Hmm ok, but most of that stuff (report your refrigerator temperature to
a server once an hour or whatever) is non-realtime and is or should be
written in scripting languages.  Admittedly there's some low level
realtime stuff in the devices too (RF protocols etc), but that part is
usually done by the hardware manufacturer or some other specialized
niche programmers.

Re: New IEEE Language Popularity Ratings

[Dmitry A. Kazakov]

On 2016-08-10 17:50, Paul Rubin wrote:
> "G.B." <bauhaus@futureapps.invalid> writes:
 >
>> Witness also the number of people who say "IoT".
>
> Hmm ok, but most of that stuff (report your refrigerator temperature to
> a server once an hour or whatever) is non-realtime and is or should be
> written in scripting languages.

No. Actually time constraint is interchangeable with load. If you have 
many thousands of metering devices, then even if they report once in 5 
minutes, with about 100 variables it does a lot of traffic and load no 
scripting language can handle on either side.

> Admittedly there's some low level
> realtime stuff in the devices too (RF protocols etc), but that part is
> usually done by the hardware manufacturer or some other specialized
> niche programmers.

One of the ideas of IoT (an extremely dangerous one, of course) is to 
build layered controlling systems stretching over a large network of 
individual devices. E.g. a virtual power plant out of a couple a 
households and larger plants out of them and so on.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: New IEEE Language Popularity Ratings

[Paul Rubin]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> No. Actually time constraint is interchangeable with load. If you have
> many thousands of metering devices, then even if they report once in 5
> minutes, with about 100 variables it does a lot of traffic and load no
> scripting language can handle on either side.

On the client side that's almost nothing.  On the server side, scaling
horizontally is the in thing. ;).  30k devices each reporting every 5
minutes is still just 100 per second which is no big deal for a
reasonable server these days no matter what it's written in.  3 million
devices gets more interesting.

Re: New IEEE Language Popularity Ratings

[Dmitry A. Kazakov]

On 2016-08-10 20:43, Paul Rubin wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> No. Actually time constraint is interchangeable with load. If you have
>> many thousands of metering devices, then even if they report once in 5
>> minutes, with about 100 variables it does a lot of traffic and load no
>> scripting language can handle on either side.
>
> On the client side that's almost nothing.

Client is a small board that has issues with load and multiple 
connections. There is also a big problem of data consistency. You may 
read/write infrequently, but there is no guaranty that the server pulls 
data or ready to be pushed with data in time. That is how it is similar 
to real-time.

> On the server side, scaling
> horizontally is the in thing. ;).  30k devices each reporting every 5
> minutes is still just 100 per second which is no big deal for a
> reasonable server these days no matter what it's written in.

It is a big deal because clients are slow, that inflicts latencies 
accumulating on the server side. Then if you start 30k threads your 
server will freeze. Then it is not really scalable because there are 
usually databases and web portal behind.

> 3 million devices gets more interesting.

A couple of thousands is already a huge problem for scripting 
environment, layered XML protocols with an FTP transfer on top, a 
typical kind of "architecture" used.


-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: New IEEE Language Popularity Ratings

[Paul Rubin]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> Client is a small board that has issues with load and multiple
> connections. 

If it has a TCP stack (and hopefully a TLS stack these days), it's not
THAT small.  It can deal with pushing something every few minutes.

> but there is no guaranty that the server pulls data or ready to be
> pushed with data in time. That is how it is similar to real-time.

There might be no server connection at all (forgot to pay ISP bill).
Either the client has to store data for later retry, or has to drop data
that can't be uploaded in a reasonable amount of time.  Neither of those
is anything like realtime in the traditional sense of something like
motor control.

> It is a big deal because clients are slow, that inflicts latencies
> accumulating on the server side. Then if you start 30k threads your
> server will freeze. Then it is not really scalable because there are
> usually databases and web portal behind.

An IOT thing would usually use a simple service that doesnt send whole
bloated web pages, and with 30k connections you wouldn't use an OS
thread for each one.  Async frameworks like node.js can handle that load
easily, or lightweight processes like in Erlang can also do it.  See the
famous "C10k Problem" article from 1999 and realize how much has
happened in hardware and software since then.  Scripting languages on
today's hardware are much faster than C was on 1999 hardware.  The db
would be something like redis which can easily handle 1000s of updates
per second.  Many giant web sites are written in scripting languages:
Wikipedia (PHP), Youtube (Python), Paypal (node.js), Facebook (a
compiled version of PHP), Yelp (Python), Reddit (Python), Github (Ruby),
etc.  A usual IOT server is far more lightweight.

Re: New IEEE Language Popularity Ratings

[G.B.]

On 10.08.16 17:50, Paul Rubin wrote:
>  Admittedly there's some low level
> realtime stuff in the devices too (RF protocols etc), but that part is
> usually done by the hardware manufacturer or some other specialized
> niche programmers.

Still the low level stuff's structure and dynamics had better be
understood by the glue coders building it into this electric kettle?

With the new fondness of collecting "big" data for statistical
analysis---reshaping legal ideas of privacy on the way---if a car's
embedded data collection system will be capable of transferring
real-time data (to the insurance company, to the traffic surveillance
organization, to some customer research agency, or to Central
Services, I'm not familiar with the specifics), then the more the
better. And it turns out that some encryption might be in
order(*). The question then becomes one of cost: comparing N powerful
embedded computers for scripting per car to adding M programming
effort to the production of some |sensors-collector-sender|.
I'm reminded of The Market's effect on clean Diesel in non-vans:
can we use a single core 16 bit µController, not a quad-core ARM,
please?

Anyway, a nice example of a real, real, real-time system,
showing when you cannot afford any non-predictable behavior
in time:

https://www.youtube.com/watch?v=Oym7B7YidKs

__
(*) Some LED light bulbs can be made to send bits coded above 60 Hz,
apparently when the buyer selects the low security profile.

Re: New IEEE Language Popularity Ratings

[G.B.]

On 11.08.16 00:55, Paul Rubin wrote:
> A usual IOT server is far more lightweight.

As Dmitry mentioned, there may be databases (also of the
"temporal" kind, I assume) to be fed. They might be the basis
of computed input to business decisions. Also, when a production
process is controlled (in the BA sense) by the IoT, then adjusting
processes requires some computation.

-- 
"HOTDOGS ARE NOT BOOKMARKS"
Springfield Elementary teaching staff

Re: New IEEE Language Popularity Ratings

[Paul Rubin]

"G.B." <bauhaus@futureapps.invalid> writes:
>> level realtime stuff in the devices too (RF protocols etc)
> Still the low level stuff's structure and dynamics had better be
> understood by the glue coders building it into this electric kettle?

If you mean the RF stuff, no they don't need any clue about it.  I don't
have much clue about it myself.  I'm making an internet teakettle and
I'm suppposed to understand Viterbi encoding or whatever the radio uses?
I've probably never even heard of it.  It's just a peripheral that bits
go into and come out of, that looks to the software like a network
adapter.

If you mean something like a temperature control PID, then maybe I have
to understand what PID is, but again there's not much issue of realtime.
I can write it in Python and it there's a few msec of GC pause now and
then, it won't affect the kettle temperature detectably at all.  

> I'm reminded of The Market's effect on clean Diesel in non-vans: can
> we use a single core 16 bit µController, not a quad-core ARM, please?

Do they even design new 16-bit stuff any more?  There's cheap 8-bit
stuff and powerful 32-bit stuff, and then the MSP430 is dying on the
vine.

The typical IOT gizmo has an ESP8266, which is comparable to a Cortex M3
without the ARM royalties (different instruction set inspired by MIPS).
It runs at 80 mhz and has 128k or so of on-chip ram and there's usually
a megabyte or so of SPI flash on the module.  The wi-fi RF stuff is on
the chip too so there's a few tiny analog parts and a PCB trace antenna
on the board, besides the 8266 itself.

Type ESP8266 into ebay to see how ridicuously cheap this stuff is
(around 3 dollars in hobbyist quantity).  Quite a powerful 32-bit cpu
that can run Micropython (micropython.org), Lua (NodeMCU.com), or
Javascript (espruino.com) nicely.  It's nothing like a quad core ARM.
Although with the Raspberry Pi Zero at $5 retail, maybe that's coming.

> https://www.youtube.com/watch?v=Oym7B7YidKs

Nice!  That's the best one of those I've seen so far.  

Re: New IEEE Language Popularity Ratings

[Paul Rubin]

"G.B." <bauhaus@futureapps.invalid> writes:
> Also, when a production process is controlled (in the BA sense) by the
> IoT, then adjusting processes requires some computation.

Obviously if every IOT report sets off a 6 hour machine learning
calculation then you need a lot of server hardware.  Usually you just
check for some simple conditions (refrigerator is out of proper temp
range, user needs to order more pickles, etc.), trigger some event if
conditions match, otherwise just log the report, then there's not much
happening.  I can't remember the last time I saw a web service
programmed in C or Ada or anything like that (I do know they exist).
They're either in scripting languages or in Java.  Do you actually work
on internet stuff?  The server guys always want to deal with scaling
problems by adding more hardware.

Re: New IEEE Language Popularity Ratings

[rrr.eee.27]

On Thursday, August 11, 2016 at 2:04:29 AM UTC+2, Paul Rubin wrote:
> The typical IOT gizmo has an ESP8266, which is comparable to a Cortex M3
> without the ARM royalties (different instruction set inspired by MIPS).
> It runs at 80 mhz and has 128k or so of on-chip ram and there's usually
> a megabyte or so of SPI flash on the module.  The wi-fi RF stuff is on
> the chip too so there's a few tiny analog parts and a PCB trace antenna
> on the board, besides the 8266 itself.
> 
> Type ESP8266 into ebay to see how ridicuously cheap this stuff is
> (around 3 dollars in hobbyist quantity).  Quite a powerful 32-bit cpu
> that can run Micropython (micropython.org), Lua (NodeMCU.com), or
> Javascript (espruino.com) nicely.  It's nothing like a quad core ARM.
> Although with the Raspberry Pi Zero at $5 retail, maybe that's coming.
> 

The really determined can also run Ada on ESP8266

https://github.com/RREE/esp8266-ada
https://github.com/RREE/esp8266-ada-rts

I created the repositories and got a working compiler on my home machine about 4 months ago. Unfortunately my hard disk crached before uploading the files to github. I will have to reinstall my computer and redo the work before actually uploading my files. Be patient or try it yourself.

Rolf

Re: New IEEE Language Popularity Ratings

[Paul Rubin]

rrr.eee.27@gmail.com writes:
> The really determined can also run Ada on ESP8266
> https://github.com/RREE/esp8266-ada
> https://github.com/RREE/esp8266-ada-rts

Wow, that's really cool.  Sorry to hear about the drive crash.

Re: New IEEE Language Popularity Ratings

[G.B.]

On 11.08.16 02:53, Paul Rubin wrote:
> "G.B." <bauhaus@futureapps.invalid> writes:
>> Also, when a production process is controlled (in the BA sense) by the
>> IoT, then adjusting processes requires some computation.
>
> Obviously if every IOT report sets off a 6 hour machine learning
> calculation then you need a lot of server hardware.  Usually you just
> check for some simple conditions (refrigerator is out of proper temp
> range, user needs to order more pickles, etc.), trigger some event if
> conditions match, otherwise just log the report, then there's not much
> happening.  I can't remember the last time I saw a web service
> programmed in C or Ada or anything like that (I do know they exist).
> They're either in scripting languages or in Java.  Do you actually work
> on internet stuff?  The server guys always want to deal with scaling
> problems by adding more hardware.

More recently, the web service programmers want others to do the job
of handling the computing resources. Amazon Lambdas, Azure, ...  micro
services. This trend, given the state of the art, necessitate a
rewrite of a fair amount of algorithms, as architectures become
segmented again, in SPACE and TIME, and little automatic compilation is
in place. The effort is multiplied when gradual roll-out of changes to
single nodes is wanted, with monitoring. Also by the slow progress
towards non-trivial storage and retrieval of data structures across
nodes. Some languages used had been changed quite a bit, e.g. "yield"
meaning a whole lot in Python on Google App Engine. Others like Java
didn't address it at the language level.  In either case one has a lot
to learn at least once, if using one of these architectures. Scripting
languages or something like Java, neither is really there yet.

Certainly, I don't expect web services that aren't special purpose to
be written like maybe a Unix daemon, in C or Ada. Who would? Using
sockets and light weight protocols may be the privilege of those
processing massive amounts of stock exchange data, or do online
traffic control, or ...  Which OTOH shows that it "usually" need not
be just the occasional fridge that has something to report.  Move that
robot arm differently. Correlate it with the quality of new coating
measured a few minutes up the assembly line. Compare assembly
lines. Or vertical plant production lines. Someone has to develop the
automation hardware and associated software so that others can just
mount the electrical things on their shelves, after some configuration.

But, from the point of view of program design, e.g. being "responsive"
has been recognized to be related to the concept of a deadline in
real-time programming. At the client side (smart phone), this kind of
predictable response may dictate that jQuery's or AngularJS's AJAX
calls would have to be served in a timely fashion. At the server side,
this, then, is no longer just a question of servlets et al. being
fast. I need to more carefully distribute computations and guide
communication in this "big system". Logically, I need to arrange for
scheduling. Not necessarily because of an algorithmic requirement,
but because that's what the "OS" wants.

Micro Python is a nice example. It frees the programmers of
needing to tackle a sophisticated composition like C or Ada, or the
usual Python libraries (or even Django), which they don't need for
turning LEDs on or off in some loop.  Or sending a ready-made bunch of
data over USB via a "Micro Python system call".  No knowledge of
ptrdiff_t is required for that. And then it has inline assembler, and
a garbage collector that, if run, took (takes?) between 1-2msec on the
Micro Python device ...  OTOH, it should be obvious that this is a specially
written version of compiled Python---I think they could have chosen
any nice little language with that bit of O-O structure and simple
data representation---made for special purposes.  So, a single programmer
in a garage can happily focus on getting his or her job done.  The
system library seems growing.

Other languages are getting Ada features. Just learned new Swift types
marked Beta and named using "time", "time interval", or "wall time",
and "queue".  These types describe objects for concurrent
processing.


-- 
"HOTDOGS ARE NOT BOOKMARKS"
Springfield Elementary teaching staff