Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #120124 > unrolled thread
| Started by | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| First post | 2017-09-21 20:50 -0700 |
| Last post | 2017-09-22 09:12 -0700 |
| Articles | 18 on this page of 178 — 26 participants |
Back to article view | Back to comp.lang.c
Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-21 20:50 -0700
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-22 01:15 -0500
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-22 01:21 -0500
Re: Something C might need fir <profesor.fir@gmail.com> - 2017-09-22 00:44 -0700
Re: Something C might need Noob <root@127.0.0.1> - 2017-09-22 11:02 +0200
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-22 12:35 -0500
Re: Something C might need Richard Damon <Richard@Damon-Family.org> - 2017-09-22 13:46 -0400
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-22 11:47 -0700
Re: Something C might need supercat@casperkitty.com - 2017-09-22 12:16 -0700
Re: Something C might need Richard Damon <Richard@Damon-Family.org> - 2017-09-22 18:10 -0400
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-22 15:24 -0700
Re: Something C might need supercat@casperkitty.com - 2017-09-22 15:52 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-23 12:29 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-23 08:29 -0700
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-23 18:06 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-24 12:28 +0200
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-22 16:17 -0700
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-22 18:20 -0700
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-22 22:45 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-23 12:22 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-23 11:29 +0100
Re: Something C might need Jerry Stuckle <jstucklex@attglobal.net> - 2017-09-23 10:25 -0400
Re: Something C might need Reinhardt Behm <rbehm@hushmail.com> - 2017-09-24 22:09 +0800
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 15:32 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-24 13:17 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 21:53 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-24 14:54 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 23:10 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-24 16:14 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-25 01:04 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-24 17:23 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 08:48 +0200
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-25 11:50 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 21:59 +0200
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-25 14:25 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-26 09:39 +0200
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-26 11:50 -0700
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-25 15:44 -0500
Re: Something C might need Jerry Stuckle <jstucklex@attglobal.net> - 2017-09-24 18:57 -0400
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-25 00:08 +0100
Re: Something C might need Jerry Stuckle <jstucklex@attglobal.net> - 2017-09-24 20:51 -0400
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-25 02:10 +0100
Re: Something C might need Jerry Stuckle <jstucklex@attglobal.net> - 2017-09-24 22:22 -0400
Re: Something C might need Thiago Adams <thiago.adams@gmail.com> - 2017-09-25 06:35 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 16:16 +0200
Re: Something C might need Thiago Adams <thiago.adams@gmail.com> - 2017-09-25 07:47 -0700
Re: Something C might need Thiago Adams <thiago.adams@gmail.com> - 2017-09-25 13:38 -0700
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-24 23:29 -0500
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-25 17:40 -0500
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-24 23:30 -0500
Re: Something C might need Jerry Stuckle <jstucklex@attglobal.net> - 2017-09-25 08:58 -0400
Re: Something C might need supercat@casperkitty.com - 2017-09-23 08:41 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-23 17:32 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-23 11:32 -0700
Re: Something C might need Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-09-25 14:43 +0000
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 22:07 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-25 13:34 -0700
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-26 10:04 +1300
Re: Something C might need Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-09-26 14:31 +0000
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-27 08:38 +1300
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-23 17:49 -0700
Re: Something C might need gordonb.w32iq@burditt.org (Gordon Burditt) - 2017-09-23 21:21 -0500
Re: Something C might need supercat@casperkitty.com - 2017-09-24 11:27 -0700
Re: Something C might need gordonb.woyvd@burditt.org (Gordon Burditt) - 2017-09-25 01:08 -0500
Re: Something C might need supercat@casperkitty.com - 2017-09-25 09:38 -0700
Re: Something C might need supercat@casperkitty.com - 2017-09-25 10:00 -0700
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-23 11:32 +0100
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-23 12:29 -0700
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-23 20:38 +0100
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-23 15:25 -0700
Re: Something C might need Richard Damon <Richard@Damon-Family.org> - 2017-09-23 20:36 -0400
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-24 01:42 +0100
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-23 18:03 -0700
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-23 22:47 -0700
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-24 12:03 -0700
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-24 15:10 -0700
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-24 16:20 -0700
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-24 16:44 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 09:00 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-24 16:51 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 09:11 +0200
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 09:04 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-23 22:10 +0100
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-24 10:19 +1300
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-24 01:38 +0100
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 02:14 +0100
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-23 18:41 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 11:16 +0100
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 11:41 +0100
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-24 12:15 -0700
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-24 12:23 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-24 14:03 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 13:59 +0100
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 16:08 +0100
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-24 21:50 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 21:40 +0100
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 09:28 +0200
Re: Something C might need luser droog <luser.droog@gmail.com> - 2017-09-26 06:28 -0700
Re: Something C might need supercat@casperkitty.com - 2017-09-26 07:47 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-27 08:26 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-27 07:22 -0700
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-27 09:01 -0700
Re: Something C might need supercat@casperkitty.com - 2017-09-27 09:42 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-28 10:42 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-27 19:22 +0100
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-28 10:48 +0200
Re: Something C might need scott@slp53.sl.home (Scott Lurndal) - 2017-09-28 17:31 +0000
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-24 22:09 +0100
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 22:44 +0100
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-25 01:57 +0100
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-25 02:02 +0100
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-24 19:10 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-27 16:27 +0100
Re: Something C might need Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-09-27 09:26 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-28 10:53 +0200
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-27 10:52 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-27 19:20 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-27 11:44 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-28 10:57 +0200
Re: Something C might need James Kuyper <jameskuyper@verizon.net> - 2017-09-24 14:49 -0400
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-24 22:06 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 20:09 +0100
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-24 12:12 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 20:46 +0100
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 09:41 +0200
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-24 21:05 +0100
Re: Something C might need gordonb.r273i@burditt.org (Gordon Burditt) - 2017-09-23 21:34 -0500
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-24 09:01 +0100
Re: Something C might need Noob <root@127.0.0.1> - 2017-09-24 19:34 +0200
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-24 23:53 -0500
Re: Something C might need "James R. Kuyper" <jameskuyper@verizon.net> - 2017-09-25 12:27 -0400
Re: Something C might need Noob <root@127.0.0.1> - 2017-09-25 20:33 +0200
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-25 15:52 -0500
Re: Something C might need Noob <root@127.0.0.1> - 2017-09-25 23:23 +0200
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-25 15:15 -0700
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-25 17:49 -0500
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-26 09:46 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-26 07:32 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-26 21:50 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-26 14:32 -0700
Re: Something C might need Noob <root@127.0.0.1> - 2017-09-26 22:34 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-26 14:39 -0700
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-25 19:38 +0100
Re: Something C might need "James R. Kuyper" <jameskuyper@verizon.net> - 2017-09-25 15:00 -0400
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-25 12:29 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 22:12 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-22 11:38 +0100
Re: Something C might need Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-09-22 04:21 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-22 14:54 +0200
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-22 08:02 -0700
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 06:49 -0700
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-22 20:24 +0100
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 12:45 -0700
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-23 09:00 +1200
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 17:34 -0400
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-23 10:49 +1200
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 19:25 -0400
Re: Something C might need "James R. Kuyper" <jameskuyper@verizon.net> - 2017-09-22 19:35 -0400
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-23 11:52 +1200
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 18:25 -0700
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-23 13:36 +1200
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 20:20 -0700
Rick says C is a dying language. (Was: Something C might need) gazelle@shell.xmission.com (Kenny McCormack) - 2017-09-23 09:15 +0000
Re: Rick says C is a dying language. (Was: Something C might need) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-23 04:40 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-23 13:00 +0100
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-23 10:28 -0400
Re: Something C might need James Kuyper <jameskuyper@verizon.net> - 2017-09-22 23:22 -0400
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-23 18:01 +1200
Re: Something C might need Jerry Stuckle <jstucklex@attglobal.net> - 2017-09-22 20:31 -0400
Re: Something C might need jladasky@itu.edu - 2017-09-22 16:27 -0700
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 16:34 -0700
Re: Something C might need scott@slp53.sl.home (Scott Lurndal) - 2017-09-26 21:44 +0000
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-26 14:53 -0700
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-23 02:14 +0100
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-22 21:31 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-22 14:02 -0700
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 17:29 -0400
Re: Something C might need supercat@casperkitty.com - 2017-09-22 09:12 -0700
Page 9 of 9 — ← Prev page 1 2 3 4 5 6 7 8 [9]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-09-23 13:36 +1200 |
| Message-ID | <f2ls4iF4nmbU5@mid.individual.net> |
| In reply to | #120179 |
On 09/23/17 01:25 PM, Rick C. Hodgin wrote: > On Friday, September 22, 2017 at 7:52:43 PM UTC-4, Ian Collins wrote: >> On 09/23/17 11:35 AM, James R. Kuyper wrote: >>> On 2017-09-22 18:49, Ian Collins wrote: >>>> On 09/23/17 09:34 AM, Rick C. Hodgin wrote: >>> .... >>>>> https://www.tiobe.com/tiobe-index/ >>> .... >>>> At first glance, the maths in those tables doesn't add up with a 15% net >>>> drop in the top 20 languages.. >>> >>> I wouldn't argue for the absolute accuracy of Tiobe's numbers, nor for >>> the validity of their algorithms - those are highly debatable issues. >>> But you seem to be objecting based upon some internal inconsistency in >>> those numbers, and I don't see that they provide enough information to >>> perform such a consistency check. >>> For instance, they show the ratings for Sep 2017, and the change since >>> Sep 2016, but they don't say what the ratings in Sep 2016 were, so you >>> can't validate the change. Since it only shows the ratings for the top >>> 50 languages, their total shouldn't add up to 100%, and it doesn't. >>> Since it only shows the changes for the top 20 languages, the total >>> change doesn't have to add up to 0%, and it doesn't, either. >>> Are you comparing these numbers with some alternative source of >>> information? If so, which one? >> >> I'm saying I find it highly unlikely that the top 5 languages can loose >> over 12% between them without some other language in the top 20 making a >> significant gain. None do. > > The RedMonk Programming Language Rankings for June 2017 show C at #9 > based on references in GitHub and Stack Overflow: > > http://redmonk.com/sogrady/2017/06/08/language-rankings-6-17/ > > For IEEE Spectrum readers, C's at #2 behind Python: > > https://spectrum.ieee.org/computing/software/the-2017-top-programming-languages > > Raw data taken from Google Trends shows C at #7 at 6.1% down 1.1%: > > http://pypl.github.io/PYPL.html > > GitHut shows the ranking based solely on GitHub software, showing > C 13K repositories behind C++ at 73K active repositories: > > http://githut.info All of the above exclude commercially developed software, which is where the bulk of C (and C++) development takes place. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-09-22 20:20 -0700 |
| Message-ID | <db2e8278-c4a9-439c-bc6b-ea3b4644a6a2@googlegroups.com> |
| In reply to | #120180 |
On Friday, September 22, 2017 at 9:36:26 PM UTC-4, Ian Collins wrote: > On 09/23/17 01:25 PM, Rick C. Hodgin wrote: > > http://redmonk.com/sogrady/2017/06/08/language-rankings-6-17/ > > https://spectrum.ieee.org/computing/software/the-2017-top-programming-languages > > http://pypl.github.io/PYPL.html > > http://githut.info > > All of the above exclude commercially developed software, which is where > the bulk of C (and C++) development takes place. I'd estimate IEEE Spectrum readers include professionals working on commercial software. Additionally, some commercially developed software is open source and/or free software, and it would show up on GitHub. That includes the Linux kernel. It's possible the GitHub metrics include private repositories given anonymously for this type of reporting. If not, then at least it's reflective of the things people are doing, not corporations. It indicates the chosen mindset of individuals and small groups, and not for-profit endeavors. Thank you, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2017-09-23 09:15 +0000 |
| Subject | Rick says C is a dying language. (Was: Something C might need) |
| Message-ID | <oq58mn$lmc$1@news.xmission.com> |
| In reply to | #120179 |
In article <71cfb4e2-bc50-4096-b2d4-2366f23cf4d6@googlegroups.com>, Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote: ... >GitHut shows the ranking based solely on GitHub software, showing >C 13K repositories behind C++ at 73K active repositories: > > http://githut.info Rick, you should stop reverently quoting these sort of stats as if they had any meaning or relevance. I say this because, assuming any of your projects ever see the light of day in any form whatsoever, the # of users column for, e.g., "CAlive" is going to be, hmmm, now what's that number I am looking for, oh, yeah, here it is: One. Not that there is anything per se wrong with that. It could well be the greatest thing since sliced cheese, but the fact is there isn't any reason for anyone else to take it up. So, bottom line, you don't want to be seen as someone who places too much weight on "popularity as the sole determinant of quality". Just sayin... -- The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL: http://user.xmission.com/~gazelle/Sigs/TedCruz
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-09-23 04:40 -0700 |
| Subject | Re: Rick says C is a dying language. (Was: Something C might need) |
| Message-ID | <4b6fe7d8-0d1b-448f-96f2-ddc401e0a08c@googlegroups.com> |
| In reply to | #120187 |
On Saturday, September 23, 2017 at 5:15:20 AM UTC-4, Kenny McCormack wrote: > In article <71cfb4e2-bc50-4096-b2d4-2366f23cf4d6@googlegroups.com>, > Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote: > ... > >GitHut shows the ranking based solely on GitHub software, showing > >C 13K repositories behind C++ at 73K active repositories: > > > > http://githut.info > > Rick, you should stop reverently quoting these sort of stats as if they had > any meaning or relevance. I say this because, assuming any of your > projects ever see the light of day in any form whatsoever, the # of users > column for, e.g., "CAlive" is going to be, hmmm, now what's that number I > am looking for, oh, yeah, here it is: One. > > Not that there is anything per se wrong with that. It could well be the > greatest thing since sliced cheese, but the fact is there isn't any reason > for anyone else to take it up. So, bottom line, you don't want to be seen > as someone who places too much weight on "popularity as the sole > determinant of quality". > > Just sayin... Well anyone who knows me knows I'm all about popularity. I don't make a move unless I'll slide up the social ladder. Thank you, Rick C. Hodgin PS -- K-k-k-kenny (to the tune of "Ch-ch-ch-chia." :-)
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-09-23 13:00 +0100 |
| Message-ID | <71sxB.1028915$QJ1.956807@fx41.am4> |
| In reply to | #120179 |
On 23/09/2017 02:25, Rick C. Hodgin wrote: > The RedMonk Programming Language Rankings for June 2017 show C at #9 > based on references in GitHub and Stack Overflow: > > http://redmonk.com/sogrady/2017/06/08/language-rankings-6-17/ > > For IEEE Spectrum readers, C's at #2 behind Python: > > https://spectrum.ieee.org/computing/software/the-2017-top-programming-languages > > Raw data taken from Google Trends shows C at #7 at 6.1% down 1.1%: > > http://pypl.github.io/PYPL.html > > GitHut shows the ranking based solely on GitHub software, showing > C 13K repositories behind C++ at 73K active repositories: > > http://githut.info I'm not sure what any of these really mean. The number of searches for tutorials may indicate a language that is hard to learn, or that is new. An established language will have lots of existing users who will not be looking up tutorials. With github, how does it figure out what language a depository uses? The ones I've seen are usually mixed. (And with github, when I used that, I chose to put C code on there so that people could compile my programs, although the true source wasn't C. But that would be untypical.) With the popularity of Java, I understand that that is closely associated with Android, so some people are least might be being pushed into using certain languages. I notice also that makefiles are on the list so that counts as a language! (I suspected that all along. It means most open source C projects aren't pure C but depend on makefiles as well as configure scripts (Shell is also on that githut dot info list).) I don't think many would be disagree that C-like languages are not the best for writing all those complicated GUIs you see everywhere, so that's another reason why those softer languages are getting more popular. If you had to do some /real/ coding however... -- bartc
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-09-23 10:28 -0400 |
| Message-ID | <oq5r1g$egd$1@dont-email.me> |
| In reply to | #120197 |
On 9/23/2017 8:00 AM, bartc wrote:
> On 23/09/2017 02:25, Rick C. Hodgin wrote:
>
>> The RedMonk Programming Language Rankings for June 2017 show C at #9
>> based on references in GitHub and Stack Overflow:
>>
>> http://redmonk.com/sogrady/2017/06/08/language-rankings-6-17/
>>
>> For IEEE Spectrum readers, C's at #2 behind Python:
>>
>>
>> https://spectrum.ieee.org/computing/software/the-2017-top-programming-languages
>>
>>
>> Raw data taken from Google Trends shows C at #7 at 6.1% down 1.1%:
>>
>> http://pypl.github.io/PYPL.html
>>
>> GitHut shows the ranking based solely on GitHub software, showing
>> C 13K repositories behind C++ at 73K active repositories:
>>
>> http://githut.info
>
> I'm not sure what any of these really mean.
Me either. :-)
> The number of searches for tutorials may indicate a language that is
> hard to learn, or that is new. An established language will have lots of
> existing users who will not be looking up tutorials.
I also think C is so difficult that it will have an exaggerated
number of searches, because one user programming in C might easily
generate 10x the number of searches than if they were coding in
another language. :-)
> With github, how does it figure out what language a depository uses? The
> ones I've seen are usually mixed.
I would say the number of new repositories is more telling, as it
would indicate what people are doing today, rather than what they
are forced into doing today from decisions made in yesteryear.
> (And with github, when I used that, I chose to put C code on there so
> that people could compile my programs, although the true source wasn't
> C. But that would be untypical.)
I think you are impacting the final numbers in a misleading way,
Bart. Shame on you for that deception. :-)
> With the popularity of Java, I understand that that is closely
> associated with Android, so some people are least might be being pushed
> into using certain languages.
I agree. I was pushed into Java. Resisted it for years, but
now there are some things I like about it. I incorporated it
into my "C Coder In Paradise" variant:
https://groups.google.com/d/msg/comp.lang.c/_oR7CPYpugM/8sKqjdOxBwAJ
Tried to amend my low-level code habits
Started learning Java last Fall.
Losing code running speed just to meet a dev need
Thinking in try..catch's now for when it goes wrong
But at night I'd have these wonderful dreams
Coding back at Low Level Street
Not in Integers or imports or Strings with ease
but in the trenches with void pointers and binary trees!
I also plan a JAlive language, which is a variant of Java that
introduces some low-level features Java is missing.
> I notice also that makefiles are on the list so that counts as a
> language! (I suspected that all along. It means most open source C
> projects aren't pure C but depend on makefiles as well as configure
> scripts (Shell is also on that githut dot info list).)
>
> I don't think many would be disagree that C-like languages are not the
> best for writing all those complicated GUIs you see everywhere, so
> that's another reason why those softer languages are getting more
> popular. If you had to do some /real/ coding however...
I think C is a wonderful language. It needs some minor tweaking
to make it more usable for developers, to shift some of the burden
of syntax and declaration from the human being into the machine,
but on the whole it's wonderful, which is why I still code in it
even moving forward with CAlive.
Thank you,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-09-22 23:22 -0400 |
| Message-ID | <oq4k2c$d04$1@dont-email.me> |
| In reply to | #120174 |
On 09/22/2017 07:52 PM, Ian Collins wrote: > On 09/23/17 11:35 AM, James R. Kuyper wrote: >> On 2017-09-22 18:49, Ian Collins wrote: >>> On 09/23/17 09:34 AM, Rick C. Hodgin wrote: >> .... >>>> https://www.tiobe.com/tiobe-index/ >> .... >>> At first glance, the maths in those tables doesn't add up with a 15% net >>> drop in the top 20 languages.. >> >> I wouldn't argue for the absolute accuracy of Tiobe's numbers, nor for >> the validity of their algorithms - those are highly debatable issues. >> But you seem to be objecting based upon some internal inconsistency in >> those numbers, and I don't see that they provide enough information to >> perform such a consistency check. >> For instance, they show the ratings for Sep 2017, and the change since >> Sep 2016, but they don't say what the ratings in Sep 2016 were, so you >> can't validate the change. Since it only shows the ratings for the top >> 50 languages, their total shouldn't add up to 100%, and it doesn't. >> Since it only shows the changes for the top 20 languages, the total >> change doesn't have to add up to 0%, and it doesn't, either. >> Are you comparing these numbers with some alternative source of >> information? If so, which one? > > I'm saying I find it highly unlikely that the top 5 languages can loose > over 12% between them without some other language in the top 20 making a > significant gain. None do. I don't find that as unlikely as you do. It seems plausible to me that there might be a broad diversification of languages going on - with people switching over from doing almost all of their work in a small number of very popular languages to doing most of it in a much larger number of substantially less popular languages. I've no idea why such a change would be occurring, but I could certainly imagine something like that occurring. I think it's premature to assume that Tiobe's ratings are incorrect just because they show such a pattern. If you've got any more specific, data-driven reason for thinking they might be incorrect, that would be a different matter.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-09-23 18:01 +1200 |
| Message-ID | <f2mblkF4nmbU6@mid.individual.net> |
| In reply to | #120182 |
On 09/23/17 03:22 PM, James Kuyper wrote: > On 09/22/2017 07:52 PM, Ian Collins wrote: >> I'm saying I find it highly unlikely that the top 5 languages can loose >> over 12% between them without some other language in the top 20 making a >> significant gain. None do. > > I don't find that as unlikely as you do. It seems plausible to me that > there might be a broad diversification of languages going on - with > people switching over from doing almost all of their work in a small > number of very popular languages to doing most of it in a much larger > number of substantially less popular languages. > I've no idea why such a change would be occurring, but I could certainly > imagine something like that occurring. I think it's premature to assume > that Tiobe's ratings are incorrect just because they show such a > pattern. If you've got any more specific, data-driven reason for > thinking they might be incorrect, that would be a different matter. While not data-driven as such, I do know my local market well and here most work in product development is still C and C++ for "embedded" devices, Java (Android) and JavaScript for UI. Desktop type application are predominantly C#. Java is still strong in back end systems and Python dominates test automation. There is very little work that I know of in other languages (except Jade, which is developed here). So the TIOBE top 5 are the top 5 and the situation hasn't changed for several years. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-09-22 20:31 -0400 |
| Message-ID | <oq4a0p$m9$1@jstuckle.eternal-september.org> |
| In reply to | #120167 |
On 9/22/2017 6:49 PM, Ian Collins wrote: > On 09/23/17 09:34 AM, Rick C. Hodgin wrote: >> On 09/22/2017 05:00 PM, Ian Collins wrote: >>> On 09/23/17 07:45 AM, Rick C. Hodgin wrote: >>>> >>>> You are exerting efforts toward ruining the advancement of this >>>> dying language, and I find it absolutely deplorable behavior, Ben, >>>> both then in 2014-2016 and now. >>> >>> Which dying language would that be? I can see an elderly but healthy >>> one and a pipe dream.... >> >> I think you use Solaris, so you might not be able to see graphics in >> your web browser LOL, but if you look at the graph in this page: >> >> https://www.tiobe.com/tiobe-index/ >> >> ....you'll see C and Java both descending rapidly from 2014 at around >> 18% or so, through until the present time, dropping down to about 8% >> or so as many other new languages are coming up, those which offer >> easier syntax than C, and less restrictions on data processing than >> Java. > > At first glance, the maths in those tables doesn't add up with a 15% net > drop in the top 20 languages.. > >> There is too much computing power available to make C worth coding >> for in most cases anymore. If it wants to survive, it needs to >> get with the times and implement some compiler features that may >> take longer to compile, but provide developer with time-saving >> additions. > > One quote of note on that page is "Applications that are written in a > single programming language are getting rarer nowadays." which is very > true. Each language has it's niche on a big project, so there's no need > for any one language to provide the kitchen sink. Contemporary software > projects are more akin to UNIX, with many small parts making up the > whole, than the monolithic Windows world view! > tiobe is known for not being very accurate. Not that they purposely fudge the numbers - they don't. But their sources aren't representative of the market. They cater to short term assignments and jobs with high turnover rates, at the expense of stable, long-term jobs with low turnover. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | jladasky@itu.edu |
|---|---|
| Date | 2017-09-22 16:27 -0700 |
| Message-ID | <6b401bf0-83e8-4434-b948-4e30dbde4392@googlegroups.com> |
| In reply to | #120163 |
On Friday, September 22, 2017 at 2:34:34 PM UTC-7, Rick C. Hodgin wrote: > There is too much computing power available to make C worth coding > for in most cases anymore. Embedded computers will take you back! I work with a system-on-a-chip which includes a 32MHz ARM Cortex-M4 CPU, 64K of SRAM, and 512K of flash. If we don't write code for such a tiny computer in C (or assembly), the language that we use instead will still have to be similarly "close to the metal" and efficient with resources.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-09-22 16:34 -0700 |
| Message-ID | <339372c7-2c73-4404-8ef8-bee95216ad29@googlegroups.com> |
| In reply to | #120171 |
On Friday, September 22, 2017 at 7:27:46 PM UTC-4, jlad...@itu.edu wrote: > On Friday, September 22, 2017 at 2:34:34 PM UTC-7, Rick C. Hodgin wrote: > > > There is too much computing power available to make C worth coding > > for in most cases anymore. > > Embedded computers will take you back! I work with a system-on-a-chip which includes a 32MHz ARM Cortex-M4 CPU, 64K of SRAM, and 512K of flash. > > If we don't write code for such a tiny computer in C (or assembly), the language that we use instead will still have to be similarly "close to the metal" and efficient with resources. In those processors, there are C compilers which already exist? Is the ISA changing over time? Is it not possible to incorporate the new changes to the existing code base? There's no reason why the extensions added to C couldn't be added for a particular release, and then they could be included or not included by real-world implementations. I have done some programming for embedded systems. Most of the algorithms I've developed have been written and debugged in Visual Studio or some other implementation. I've found the ability to debug data-processing algorithms this way the fastest way I've found. Thank you, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-09-26 21:44 +0000 |
| Message-ID | <CSzyB.133034$po2.128693@fx36.iad> |
| In reply to | #120163 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: >On 09/22/2017 05:00 PM, Ian Collins wrote: >> On 09/23/17 07:45 AM, Rick C. Hodgin wrote: >>> >>> You are exerting efforts toward ruining the advancement of this >>> dying language, and I find it absolutely deplorable behavior, Ben, >>> both then in 2014-2016 and now. >> >> Which dying language would that be? I can see an elderly but healthy >> one and a pipe dream.... > >I think you use Solaris, so you might not be able to see graphics in >your web browser LOL, but if you look at the graph in this page: > > https://www.tiobe.com/tiobe-index/ C programmers don't need to use stack overflow, so the numbers at TIOBE are completely useless. Completely.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-09-26 14:53 -0700 |
| Message-ID | <a122105a-b522-4c06-a975-ec8ec93723cc@googlegroups.com> |
| In reply to | #120354 |
On Tuesday, September 26, 2017 at 5:44:13 PM UTC-4, Scott Lurndal wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> >On 09/22/2017 05:00 PM, Ian Collins wrote:
> >> On 09/23/17 07:45 AM, Rick C. Hodgin wrote:
> >>>
> >>> You are exerting efforts toward ruining the advancement of this
> >>> dying language, and I find it absolutely deplorable behavior, Ben,
> >>> both then in 2014-2016 and now.
> >>
> >> Which dying language would that be? I can see an elderly but healthy
> >> one and a pipe dream....
> >
> >I think you use Solaris, so you might not be able to see graphics in
> >your web browser LOL, but if you look at the graph in this page:
> >
> > https://www.tiobe.com/tiobe-index/
>
> C programmers don't need to use stack overflow, so the numbers
> at TIOBE are completely useless. Completely.
Completely? Totally? In all ways? Those poor people associated
with it. If only they knew how they were wasting their time capturing
C data. And for all those decades.
Did you want to notify them? Or are you content to let them wallow
in ignorance?
--
Thank you, | Indianapolis, Indiana | God is love -- 1 Jonh 4:7-9
Rick C. Hodgin | http://www.libsf.org/ | http://tinyurl.com/yaogvqhj
-------------------------------------------------------------------------
Software: LSA/C, Debi, RDC, CAlive, ES/2, VJr, VFrP, Logician, C90/99
Hardware:
Aroxda Desktop CPU -- 40-bit multi-core 80386 with many extensions
Arxita Embedded CPU -- Low power, low pin count 80386 w/128 registers
Arlina Compute FPGA -- Scalable compute cores, large GPIO pin count
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-09-23 02:14 +0100 |
| Message-ID | <87o9q2b4ho.fsf@bsb.me.uk> |
| In reply to | #120154 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > On Friday, September 22, 2017 at 3:24:26 PM UTC-4, Ben Bacarisse wrote: >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: >> <snip> >> > CAlive handles this ... >> >> Please stop plugging your personal language. > > As I've told you repeatedly, these ideas I have for enhancements > to C are encapsulated in CAlive. They are NOT exclusive to it. > They will work for C were it to be augmented. So will my Fortran extensions to C... and my SQL extesions... Let's talk about those! No, let's not. In fact I don't mind talking about individual features (though I prefer them to be properly defined), it's the plugging of your personal language that I object to. > ... But I > will not listen to your attempts to silence me simply because you > are willing only to look as far as your myopic vision of C extends. You are not talking about C. But I accept that you won't comply with this group's topicality standard. I did not really expect anything else. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-09-22 21:31 +0100 |
| Message-ID | <kqexB.1028694$YS2.304436@fx11.am4> |
| In reply to | #120138 |
On 22/09/2017 14:49, Rick C. Hodgin wrote: > On Thursday, September 21, 2017 at 11:51:05 PM UTC-4, David Kleinecke wrote: >> But these ideal ints fail when we multiple. The >> product of two ints is - conceptually - twice the >> size of an int. Hence we need "long". But C, as >> it stands, does not implement that situation. > > CAlive handles this by automatically up-sizing the operands in > expressions to their larger form, Which form is that? If adding 8-bit and 16-bit, what is the possible result type? (Note those could require 32 bits to represent a result. But this is already how C works when int is 32 bits.) > In addition, CAlive introduces explicitly sized variables as > a native type: > > s8,u8 -- signed and unsigned 8-bit quantities > s16,u16 -- Signed and unsigned 16-bit quantities > s32,u32 -- Signed and unsigned 32-bit quantities > s64,u64 -- Signed and unsigned 64-bit quantities > f32,f64 -- 32-bit and 64-bit floating point OK, but you should stop there (unless you want s128 and u128). > I also introduce arbitrary types: > > bi,bfp -- Big integer, big floating point These may not be a good fit to such a language, assuming they are auto-sizing and automatically get bigger and smaller. They are more suited to a 'softer' language. But if you intend this to be the only language, and you need big integers, then you may have to shoehorn them in. (IME big integers are infrequently used anyway.) > And I also introduce variable sizes for storing in memory to a > particular bit size that are auto-upsized to the next largest > size in computation. These are also signed saturating in the > store: > > as8,au8 -- Auto-upsizing 8-bit to 32-bit quantities > as16,au16 -- Auto-upsizing 16-bit to 32-bit quantities > as24,au24 -- Auto-upsizing 24-bit to 32-bit quantities > > xs8,xu8 -- Auto-upsizing 8-bit to 64-bit quantities > xs16,xu16 -- Auto-upsizing 16-bit to 64-bit quantities > xs24,xu24 -- Auto-upsizing 24-bit to 64-bit quantities > xs32,xu32 -- Auto-upsizing 32-bit to 64-bit quantities > xs40,xu40 -- Auto-upsizing 40-bit to 64-bit quantities > xs48,xu48 -- Auto-upsizing 48-bit to 64-bit quantities > xs56,xu56 -- Auto-upsizing 56-bit to 64-bit quantities And this is definitely off the wall. I've no idea what these are meant to be used for. The 8 and 16 primitives introduced above should already be storage types, chosen to either reduce memory usage, or to match some foreign struct layout. They will already be expanded to int size (usually 32 bits) when used in expressions. If you want a storage type of non-standard size, ie. 24, 40, 48 and 56 bits, then fine. But it will be a variation of the one of the primitive types. > Note: These are used primarily for data translation from > other systems, Which other systems? All now use 8,16,32,64. > CAlive looks to be incredible. The more I throw stuff at it > to try and break it, the more I see it being solid. I cannot > wait until it's completed. > > I could use help in its development. But no help with its design I guess? -- bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-09-22 14:02 -0700 |
| Message-ID | <cb9f17f3-d08e-4406-bd95-1df28b21862c@googlegroups.com> |
| In reply to | #120158 |
On Friday, September 22, 2017 at 3:31:24 PM UTC-5, Bart wrote: > On 22/09/2017 14:49, Rick C. Hodgin wrote: > > CAlive handles this by automatically up-sizing the operands in > > expressions to their larger form, > > Which form is that? If adding 8-bit and 16-bit, what is the possible > result type? (Note those could require 32 bits to represent a result. > But this is already how C works when int is 32 bits.) Having numeric expressions behave as though they promote to the largest available numeric type shouldn't be particularly difficult or expensive in most cases. On a silent-wraparound implementation, something like `int x=(long long)y+z;` would yield the same code as `int x=y+z;`, so "promoting" to the longer type would cost nothing. Such promotion would add to the cost of "int x=a*b/c;", but it's unlikely that a programmer would particularly want any behavior other than that yielded by "int x=(long long)a*b/c;". A programmer may want the faster performance that might be achieved using int-sized operations, but if the language includes syntax to truncate to "int" always, or to truncate to "int" when convenient, having the default behavior promote to the longer type may be the safest course of action. In addition to "number" types, C-like languages should also include types for modular arithmetic. While C applies modular-arithmetic semantics to full-sized unsigned types, and numeric semantics to other types, it would be helpful to have types which were specified as using modular arithmetic regardless of the target platform, and others which were specified as using numeric arithmetic, again regardless of the target platform.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-09-22 17:29 -0400 |
| Message-ID | <oq3vbv$52g$1@dont-email.me> |
| In reply to | #120158 |
On 09/22/2017 04:31 PM, bartc wrote:
> On 22/09/2017 14:49, Rick C. Hodgin wrote:
>> On Thursday, September 21, 2017 at 11:51:05 PM UTC-4, David Kleinecke
>> wrote:
>>> But these ideal ints fail when we multiple. The
>>> product of two ints is - conceptually - twice the
>>> size of an int. Hence we need "long". But C, as
>>> it stands, does not implement that situation.
>>
>> CAlive handles this by automatically up-sizing the operands in
>> expressions to their larger form,
>
> Which form is that? If adding 8-bit and 16-bit, what is the possible
> result type? (Note those could require 32 bits to represent a result.
> But this is already how C works when int is 32 bits.)
There are factors which weigh in to this calculation, but as a
general rule whatever bit size you're at it goes up to the next
highest, so 16-bit goes to 32-bit. However, definition casks in
CAlive allow a person to specify that a particular value will
never exceed a range. When those casks are provided, CAlive
will analyze the range of possible results and upsize accordingly.
>> In addition, CAlive introduces explicitly sized variables as
>> a native type:
>>
>> s8,u8 -- signed and unsigned 8-bit quantities
>> s16,u16 -- Signed and unsigned 16-bit quantities
>> s32,u32 -- Signed and unsigned 32-bit quantities
>> s64,u64 -- Signed and unsigned 64-bit quantities
>> f32,f64 -- 32-bit and 64-bit floating point
>
> OK, but you should stop there (unless you want s128 and u128).
I do not support s128 and u128 apart from bi.
>> I also introduce arbitrary types:
>>
>> bi,bfp -- Big integer, big floating point
>
> These may not be a good fit to such a language, assuming they are
> auto-sizing and automatically get bigger and smaller. They are more
> suited to a 'softer' language. But if you intend this to be the only
> language, and you need big integers, then you may have to shoehorn them in.
>
> (IME big integers are infrequently used anyway.)
The bfp type allow for f128 and f256 natively, using the double-
double and quad-double libraries I've posted on this forum before:
See the "QD" section:
http://crd-legacy.lbl.gov/~dhbailey/mpdist/
For anything larger than that another algorithm is used, which
is very slow, but compared to not having the ability it's okay.
It does not automatically upsize, but computes to the specified
bfp size.
>> And I also introduce variable sizes for storing in memory to a
>> particular bit size that are auto-upsized to the next largest
>> size in computation. These are also signed saturating in the
>> store:
>>
>> as8,au8 -- Auto-upsizing 8-bit to 32-bit quantities
>> as16,au16 -- Auto-upsizing 16-bit to 32-bit quantities
>> as24,au24 -- Auto-upsizing 24-bit to 32-bit quantities
>>
>> xs8,xu8 -- Auto-upsizing 8-bit to 64-bit quantities
>> xs16,xu16 -- Auto-upsizing 16-bit to 64-bit quantities
>> xs24,xu24 -- Auto-upsizing 24-bit to 64-bit quantities
>> xs32,xu32 -- Auto-upsizing 32-bit to 64-bit quantities
>> xs40,xu40 -- Auto-upsizing 40-bit to 64-bit quantities
>> xs48,xu48 -- Auto-upsizing 48-bit to 64-bit quantities
>> xs56,xu56 -- Auto-upsizing 56-bit to 64-bit quantities
>
> And this is definitely off the wall. I've no idea what these are meant
> to be used for.
>
> The 8 and 16 primitives introduced above should already be storage
> types, chosen to either reduce memory usage, or to match some foreign
> struct layout. They will already be expanded to int size (usually 32
> bits) when used in expressions.
>
> If you want a storage type of non-standard size, ie. 24, 40, 48 and 56
> bits, then fine. But it will be a variation of the one of the primitive
> types.
The idea is storage for signed saturation. Those have traditional
value in various operations.
For the rest, they don't generally exist today so people don't use
them, but why store everything in 16-bit or 32-bit or 64-bit chunks?
Suppose I'm writing data to disk, or memory. Why waste memory that
is always going to only be filled with 0s in the most significant
bits? If I only need 40-bits, why not store 40-bits?
It wasn't a great extension to add this ability, so I added it.
>> Note: These are used primarily for data translation from
>> other systems,
>
> Which other systems? All now use 8,16,32,64.
Have you ever used bit-packed structs? This ability is really
just an extension of that logic, with some extra load and store
logic.
>> CAlive looks to be incredible. The more I throw stuff at it
>> to try and break it, the more I see it being solid. I cannot
>> wait until it's completed.
>>
>> I could use help in its development.
>
> But no help with its design I guess?
Absolutely with design. But, as Captain Queeg said in the Cain
Mutiny, you'd better have half a dozen good reasons, and you'll
still get an argument from me. :-)
Thank you,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-09-22 09:12 -0700 |
| Message-ID | <efd7f9bf-e266-4cc3-b3dd-7defc50dbab3@googlegroups.com> |
| In reply to | #120124 |
On Thursday, September 21, 2017 at 10:51:05 PM UTC-5, David Kleinecke wrote: > What we seem to need is operators, call them > ":=" and "=:" with the semantics and constraints: > a := b > means a is an int, b is a long int and the > execution is to assign the value in the > upper half of b to a. Conversely > b =: a > assigns the value in a to the upper half of b. What I'd like to see would be a more general way of specifying that an object must behave as though it is stored in a specified format, with a compiler either generating the code to accomplish that or refusing to do so (as opposed from generating code that behaves in some other fashion). What sorts of format a compiler supports would be a quality-of-implementation issue. If code specifies a 32-bit value must be stored as two "unsigned short" values in big-endian order, and retrievable from any 16-bit-aligned address, a platform where "char" is 8 bits would store the value as 4 bytes, while one where "char" is 64 bits would store it as two 64-bit words. In either case, the effect of overlaying such an object on an "unsigned short[]" would be well-defined, at least if the array contained no values outside the range 0-65535.
[toc] | [prev] | [standalone]
Page 9 of 9 — ← Prev page 1 2 3 4 5 6 7 8 [9]
Back to top | Article view | comp.lang.c
csiph-web