Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #140005 > unrolled thread
| Started by | Bart <bc@freeuk.com> |
|---|---|
| First post | 2019-01-20 00:03 +0000 |
| Last post | 2019-01-21 00:13 -0600 |
| Articles | 20 on this page of 160 — 17 participants |
Back to article view | Back to comp.lang.c
Compiler tests Bart <bc@freeuk.com> - 2019-01-20 00:03 +0000
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-20 16:52 +1300
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-20 10:27 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-20 12:37 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-20 13:08 +0000
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-20 15:02 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-20 17:31 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-20 17:08 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-20 21:40 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-20 22:41 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 00:39 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-21 00:36 +0000
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-21 16:33 +1300
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-21 11:58 +0000
Re: Compiler tests Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-21 04:15 -0800
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-22 07:53 +1300
Re: Compiler tests BGB <cr88192@hotmail.com> - 2019-01-23 01:15 -0600
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 12:00 +0000
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-24 08:13 +1300
Re: Compiler tests BGB <cr88192@hotmail.com> - 2019-01-23 13:30 -0600
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 08:22 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-21 12:23 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 14:42 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-21 14:17 +0000
Re: Compiler tests Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-21 12:46 -0800
You guys really, really need to get a room (Was: Compiler tests) gazelle@shell.xmission.com (Kenny McCormack) - 2019-01-24 14:05 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-20 17:27 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-20 17:19 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 09:44 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-21 12:49 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 15:31 +0100
Re: Compiler tests jacobnavia <jacob@jacob.remcomp.fr> - 2019-01-21 14:38 +0100
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-21 15:15 +0100
Re: Compiler tests jacobnavia <jacob@jacob.remcomp.fr> - 2019-01-21 16:05 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 16:39 +0100
Re: Compiler tests Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-21 12:51 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-22 00:16 +0000
Re: Compiler tests jacobnavia <jacob@jacob.remcomp.fr> - 2019-01-22 08:43 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-22 12:31 +0000
Re: Compiler tests jacobnavia <jacob@jacob.remcomp.fr> - 2019-01-22 17:49 +0100
Re: Compiler tests jacobnavia <jacob@jacob.remcomp.fr> - 2019-01-23 11:04 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 11:18 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 15:35 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-21 15:49 +0000
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-21 17:42 +0100
Re: Compiler tests BGB <cr88192@hotmail.com> - 2019-01-23 03:18 -0600
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 11:11 +0100
Re: Compiler tests BGB <cr88192@hotmail.com> - 2019-01-23 12:18 -0600
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 13:56 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-22 10:55 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-22 12:07 +0000
Re: Compiler tests fir <profesor.fir@gmail.com> - 2019-01-22 04:29 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-22 12:52 +0000
Re: Compiler tests mark.bluemel@gmail.com - 2019-01-22 05:04 -0800
Re: Compiler tests fir <profesor.fir@gmail.com> - 2019-01-22 05:18 -0800
Re: Compiler tests fir <profesor.fir@gmail.com> - 2019-01-22 05:45 -0800
Re: Compiler tests fir <profesor.fir@gmail.com> - 2019-01-22 05:35 -0800
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-22 15:10 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-22 17:30 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-22 23:02 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-22 23:14 +0000
Re: Compiler tests Keith Thompson <kst-u@mib.org> - 2019-01-22 15:45 -0800
Re: Compiler tests Robert Wessel <robertwessel2@yahoo.com> - 2019-01-22 17:57 -0600
Re: Compiler tests Keith Thompson <kst-u@mib.org> - 2019-01-22 16:36 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 01:37 +0000
Re: Compiler tests Keith Thompson <kst-u@mib.org> - 2019-01-22 18:53 -0800
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 09:42 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 09:22 +0100
Re: Compiler tests James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-01-23 08:52 -0500
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 15:13 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 14:33 +0000
Re: Compiler tests James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-01-23 07:30 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 16:05 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 17:17 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 16:29 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 22:04 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 21:50 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-24 10:45 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-24 11:55 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-24 13:58 +0100
Re: Compiler tests mark.bluemel@gmail.com - 2019-01-24 05:07 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-24 14:10 +0000
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-24 14:18 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-24 15:51 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-24 15:44 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-24 17:32 +0000
Re: Compiler tests scott@slp53.sl.home (Scott Lurndal) - 2019-01-24 19:07 +0000
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-24 20:14 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-24 22:24 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-24 22:46 +0000
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-25 12:34 +1300
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 01:01 +0000
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-25 14:15 +1300
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 10:05 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 14:51 +0000
Re: Compiler tests Mateusz Viste <mateusz@wont.tell> - 2019-01-25 09:48 +0000
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 10:56 +0100
Re: Compiler tests Mateusz Viste <mateusz@wont.tell> - 2019-01-25 12:08 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 13:28 +0100
Re: Compiler tests Mateusz Viste <mateusz@wont.tell> - 2019-01-25 13:33 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 15:38 +0100
Re: Compiler tests Mateusz Viste <mateusz@wont.tell> - 2019-01-25 15:08 +0000
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 13:53 +0000
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 12:25 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 10:03 +0100
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 10:08 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 11:14 +0100
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 12:02 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 13:37 +0100
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 13:58 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 14:26 +0100
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 15:01 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 15:42 +0100
Re: Compiler tests Keith Thompson <kst-u@mib.org> - 2019-01-25 10:25 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 14:37 +0000
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 16:33 +0100
Re: Compiler tests Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-25 07:44 -0800
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 17:53 +0100
Re: Compiler tests Keith Thompson <kst-u@mib.org> - 2019-01-25 10:33 -0800
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 20:43 +0100
Re: Compiler tests Keith Thompson <kst-u@mib.org> - 2019-01-25 12:17 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 18:31 +0000
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 20:41 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 21:19 +0000
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-26 10:24 +1300
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 22:27 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 22:39 +0000
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-25 18:46 +0000
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 12:43 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 14:37 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 14:19 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 15:47 +0100
Re: Compiler tests Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-25 07:17 -0800
Re: Compiler tests Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-02-03 07:28 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-02-03 12:35 +0100
Re: Compiler tests Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-02-03 21:47 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-02-03 22:57 +0100
Re: Compiler tests Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-24 06:47 -0800
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-23 20:22 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 22:12 +0100
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-23 21:54 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-24 11:41 +0100
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-24 23:17 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 11:11 +0100
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-25 12:04 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 14:05 +0100
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-25 18:40 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 22:36 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 22:15 +0000
Re: Compiler tests scott@slp53.sl.home (Scott Lurndal) - 2019-01-25 14:48 +0000
Re: Compiler tests scott@slp53.sl.home (Scott Lurndal) - 2019-01-25 14:46 +0000
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-25 17:48 +0000
Re: Compiler tests James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-01-23 08:23 -0800
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 16:41 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 16:18 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 17:28 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 20:23 +0000
Re: Compiler tests Robert Wessel <robertwessel2@yahoo.com> - 2019-01-22 17:52 -0600
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-20 20:17 +0000
Re: Compiler tests BGB <cr88192@hotmail.com> - 2019-01-21 00:13 -0600
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-25 15:38 +0100 |
| Message-ID | <q2f71m$rqu$1@dont-email.me> |
| In reply to | #140246 |
On 25/01/2019 14:33, Mateusz Viste wrote: > On Fri, 25 Jan 2019 13:28:42 +0100, David Brown wrote: >> FreeDOS development? Is this just for fun, or do you really have to use >> these antiques? > > Not FreeDOS itself, but DOS-related toys, yes. Things like these: > > http://dosmid.sourceforge.net > http://etherdfs.sourceforge.net > http://zboy.sourceforge.net > (more on my homepage) > > I find working with 1980-1990 technologies very refreshing. Relaxing, > even. It helps one to understand what really matters in software > development and focus on essentials. Sadly, nowadays many (most?) > programmers display a toxic "meh, just use faster hardware" attitude. > > Some videos! > https://youtu.be/8ssDGBTssUI > https://youtu.be/aumz51RCqZ0 > > Mateusz > I'd recommend small embedded systems development instead. You get to use all the tools and toys you want on the host (like a modern gcc), while the target is limited, controlled and focused. RAM might only be a few KB, not MB, and you know /all/ the software on the board because you just compiled it and downloaded it.
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Viste <mateusz@wont.tell> |
|---|---|
| Date | 2019-01-25 15:08 +0000 |
| Message-ID | <5c4b2673$0$21609$426a74cc@news.free.fr> |
| In reply to | #140252 |
On Fri, 25 Jan 2019 15:38:46 +0100, David Brown wrote: > I'd recommend small embedded systems development instead. You get to > use all the tools and toys you want on the host (like a modern gcc), > while the target is limited, controlled and focused. RAM might only be > a few KB, not MB, and you know /all/ the software on the board because > you just compiled it and downloaded it. Embedded platforms are cool as well, yes. But they miss the 'nostalgia' part :) Mateusz
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-01-25 13:53 +0000 |
| Message-ID | <4xE2E.392094$Fi6.329457@fx12.am4> |
| In reply to | #140234 |
On 25/01/2019 12:08, Mateusz Viste wrote: > On Fri, 25 Jan 2019 10:56:41 +0100, Pascal J. Bourguignon wrote: > >> Mateusz Viste <mateusz@wont.tell> writes: >> >>> 2. The "one single *.c file" you boast about is, I assume, a monolithic >>> mess. As such, it will take forever for a C compiler to compile, and it >>> will require humongous amounts of memory to do so (memory which may or >>> may not be available for the task). The modular approach is by far more >>> economical in that aspect as well. >> >> The sources of firefox, one of the biggest program, are 50 MB. >> I have 32 GB of RAM in this old computer, ie. 3 order of magnitude more. > > You must certainly be aware that a compiler requires a lot more memory > than source size to compile it. > > Few days ago I ran out of DPMI memory when trying to compile a single > 400K module with DJGPP. The computer had 64 MiB of available memory, ie > (as you say) orders of magnitude more. 400KB or 400Kloc? What about headers? In any case, that means 150KB of RAM either per byte of source, or per line. Both seem excessive. If try my compiler on sqlite3 (220Kloc), then it uses 70MB and that's with a strategy of never relinquishing memory it no longer needs. That's about 300 bytes per line. (Call it 500 bytes bearing in mind that sqlite3 is 40% comments.) And that compiler uses more memory than the single-pass Tiny C. So I'd suggest something is wrong with your system: either your figures, or with DJGPP, or maybe the memory was already full of something else.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-01-25 12:25 +0000 |
| Message-ID | <efD2E.137414$gE1.96823@fx07.am4> |
| In reply to | #140226 |
On 25/01/2019 09:48, Mateusz Viste wrote: > On Fri, 25 Jan 2019 01:01:29 +0000, Bart wrote: >> See how with these larger building blocks, scripting is still possible, >> but the steps are fewer. Each mm step involves 22 modules and 13 >> embedded text files, but these details are taken care of. >> > I see two major problems with your approach: > > 1. Each time you change a single byte in a big project, you need to > compile everything again. And that can take a lot of time when the > project is really big. How about when the project isn't really big? My current system (which isn't even the most efficient it can be, and runs on a somewhat slow PC), is usable for projects up to 100Kloc in one executable, before build times hit 0.5 seconds (my personal threshold beyond which they become annoying). This applies to a single .exe or .dll. Larger projects I would structure differently, using independent libraries. Then the modularity is back, but with bigger building blocks. (I would also switch much of the code to interpreted languages.) A Makefile will only recompile the one little > module that changed, and relink the rest. MUCH faster. > > 2. The "one single *.c file" you boast about is, I assume, a monolithic > mess. So what? You don't need to develop anything using that source; it's just an intermediate file. And it only comes up as an artefact of my language and my compiler. I generate it very infrequently: * When I need the best optimised production program * When I need to test on an otherwise unsupported platform * When want someone else to build my project and binaries are no good I don't do it very often because, while my C compiler project for example takes 0.17 seconds to build from scratch (some 30Kloc), generating C and running gcc-O3 takes 16 seconds, nearly 100 times longer. > As such, it will take forever for a C compiler to compile, and it > will require humongous amounts of memory to do so (memory which may or > may not be available for the task). The modular approach is by far more > economical in that aspect as well. The sqlite3 project mentioned in the thread (250Kloc plus OS headers for a working program) takes MSVC 3 second to build a 1.25MB executable. (My C compiler does it in 0.5 seconds.) That's unoptimised, but I presume we are talking about edit-compile-run cycles for development. Much, much bigger projects with a team of people, then it is up to the team to devise its own build systems for the best throughput. There is another aspect to this, which is in keeping projects small and manageable. If you are MS and have created a 1.5 million file monster called Visual Studio (and even that figure is years out of date), then sorry I can't help. (Reportedly a full production build on that took 60 hours.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-25 10:03 +0100 |
| Message-ID | <q2ejd5$cor$1@dont-email.me> |
| In reply to | #140211 |
On 24/01/2019 23:46, Bart wrote:
> On 24/01/2019 21:24, David Brown wrote:
>> On 24/01/2019 18:32, Bart wrote:
>
>>> What makes you think my project isn't modular?
>>>
>>
>> Your obsession with single giant files, along with your dismissal of
>> sensible development tools and editors.
>
> You don't seem to understand how a module system works in this kind of
> language.
>
> When you write 'python prog.py' then it will automatically seek out and
> load any dependencies of prog.py, you don't need to list them all in an
> auxiliary file.
Python is an interpreted language, C is not.
>
> The same with my languages.
Fine. C is not like that. So what?
Don't misunderstand me. I have nothing against simple compilation, and
nothing against a module system that finds the files automatically. I
think it would be crazy to invent a new, modern language that did /not/
have automatic module handling. C's method is old fashioned, and comes
from an age of much slower systems - it is highly flexible, but that
often gives programmers too much flexibility and some people write
really jumbled code masses as a result.
So I agree that C has no good module system, and that a module system is
useful. In effect, I use make to compensate for that - so C's lack of
modules is not a problem at all.
What I object to is your attitude to all this. You get several things
completely wrong, IMHO:
1. You think C has a "problem" because it needs a build system to track
multiple files, compilation flags, etc. It does not have a problem - it
simply lacks a particular feature you like in some other languages. The
solution is simple - you use a build system. It really does not matter
if the build system is part of the language, or an external tool you use
with the language. Having it external means it is not standardised - it
also means developers have choices. (Some like make, some like IDE's,
etc.). View it in the same class as an editor.
2. You think that when you have automatic dependency handling in a
language, you don't need a build system. This is wrong - no language
has everything it needs built in. I use "make" along with my Python
projects. If I used your language, I'd use make too. People use "make"
(or other build systems) for compilation, pre-processing,
post-processing, testing, deployment, documentation extraction, and many
other tasks associated with program development.
3. You think "make" is incomprehensible. This is a combination of
laziness on your part, and that some makefiles /are/ hard to understand.
You can choose to write simple or complex makefiles - different people
put different things there. Consider it a program - part of the
project. The more flexible and generic it is, the more complex the
makefile will be to write, but the simpler it will be to use. A simple
makefile might list the source files and dependencies manually. A
complex one will figure them out automatically - simply adding a new C
file to the project directory adds it to the build.
4. You think it is an overwhelming concern that the tools and programs
used are small in size and small in number. Sure, it is convenient if
you need fewer bits and pieces, but it is a very minor issue. What is
important is how convenient they are to use, not what lies behind them.
It is important that when you type "make", you get an appropriate build
of your project - it does not matter if that invokes 2 programs at 1 MB
each, or 200 programs with 10 GB of files behind them.
5. You think that /your/ method of solving problems is inherently
superior to everyone else's. Most programmers are perfectly happy using
a build system of some sort to handle dependencies and modules. For
many, that means an IDE - for others, it means "make", "cmake", "ninja",
or whatever suits their tastes and needs best. Having a language that
lets you do your build with a single command "solves" a non-existent
problem.
>
> I don't use giant files except for C distributions, where they are a
> by-product of how my translator works.
>
> Most build systems will take N source files and produce 1 .exe or .dll
> file.
>
OK.
> My compiler will take N source files and produce 1 .exe or .dll file, or
> sometimes 1 .c file. So the principle is no different. But my compiler
> will do it all in one go and without needing any extra information, by
> making use of its module system.
>
> That means it's more sophisticated that your tools.
>
No, it means it is more limited. If it does the job you need, fine. It
won't do the job I need. I need more from my tools than you can give -
if I were to do my development in your language, with your tools, I
would still need "make" for everything around the build. (And I'd still
use "make" for compilation, even if it were just a single command from a
single C file, because that lets me track the exact version of the
compiler and the exact flags.)
>
>>> gcc cc.c
>>
>> How is it that you think it's fine to give lists of modules to compile
>> in a C file (or "mm" file, or whatever language you use) but if the
>> list is in a file called "Makefile", you'd rather poke your eyes out
>> with a sharp stick?
>
> The vital information needed to build, is primarily a list of modules.
> My language can work that out. C can't (except for specially written
> programs using my experimental -auto option, the idea proposed by Anton
> Shepelev).
For the C language, the concept does not even make sense. For a C
implementation, it does. With an appropriate filesystem layout, gcc and
make can happily find the C files needed and handle dependency
generation. When I add a new C file or header to a project, I put it in
the project directory and type "make". It all works automatically.
People who use IDE's for handling their project builds get the same
level of convenience.
>
> So it needs an explicit list of modules. That's fine. But no makefile
> I've seen has ever been that simple. This is the @ file I use to build
> Seed7:
It is entirely possible to have equally simple makefiles:
CFILES = s7.c runerr.c option.c primitiv.c ...
HFILES = runerr.h option.h primitiv.h ...
CFLAGS = -Os -Wall
program.exe : $(CFILES) $(HFILES)
gcc $(CFLAGS) $(CFILES) -o $@
If you want to find the C files and H files automatically, you can use this:
CFILES = $(wildcard *.c)
HFILES = $(wildcard *.h)
instead of a manual list.
With this, make will recompile everything whenever a C or H file
changes, which is what you like.
The next step up would be to compile to object files, then link:
# Simple generic makefile
CFILES = $(wildcard *.c)
HFILES = $(wildcard *.h)
OFILES = $(CFILES:.c=.o)
CFLAGS = -Os -Wall
LDFLAGS = -Os -Wall
%.o : %.c $(HFILES)
gcc $(CFLAGS) -c $< -o $@
program.exe : $(OFILES)
gcc $(LDFLAGS) $(OFILES) -o $@
That makefile will take all the ".c" files in your directory, compile
them to ".o" object files, then link them to "program.exe". It will
re-compile a C file any time that C file changes, or any of the header
files change. And it will relink program.exe whenever any of the object
files change. It will work fine with parallel builds ("make -j"), and
does incremental building.
It is possible to get a great deal here from just a dozen lines of
makefile. I am sure you can figure out most of what the lines do.
It is also possible to get a lot more complex - I do my builds in trees,
with the generated files separated from the code files, with much more
sophisticated dependency handling, and lots of flags. But you certainly
don't have to do that.
>
> There is nothing to understand about this, it's just a list. The same
> list can work for different compilers. And I could chose to submit the
> list by hand. Or invoke the compiler one at a time for each .c file. It
> is not an obstacle or hindrance to overcome like a makefile file.
>
> This information /HAD TO BE PAINFULLY EXTRACTED FROM AN ACTUAL
> MAKEFILE/. (And there were 17 variations to choose from. Think about it
> - why were there 17 variations? Aren't they just script files and
> therefore ultimately flexible?).
Or you could just use make - adapting one of the makefiles to suit. I
don't know why there are 17 different makefiles here - I did not write
the "seed7" project, nor have I looked at it. It is quite possible to
write makefiles that handle multiple build environments - it's up to the
project developer to choose what suits them.
By the way, "make -n" will print a list of the commands make would have
run. That might make things easier for you in the future.
>
>> That word doesn't even begin to describe you - after all, the
>> technology you reject is decades old.
>
> Yes, it is. Maybe that's why I reject it.
>
Note that it is 40 years old, and still with us. Alternatives have come
and gone, and there are plenty of situations where other build systems
are a better choice. But the fact is, "make" remains popular because it
is really good at the job. It works fine, people use it. It is not
perfect by any means, but none of its problems are enough to stop it
being the tool of choice for a huge number of developers and projects.
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2019-01-25 10:08 +0100 |
| Message-ID | <m2r2d1gl4i.fsf@despina.home> |
| In reply to | #140222 |
David Brown <david.brown@hesbynett.no> writes: > On 24/01/2019 23:46, Bart wrote: >> On 24/01/2019 21:24, David Brown wrote: >>> On 24/01/2019 18:32, Bart wrote: >> >>>> What makes you think my project isn't modular? >>>> >>> >>> Your obsession with single giant files, along with your dismissal of >>> sensible development tools and editors. >> >> You don't seem to understand how a module system works in this kind of >> language. >> >> When you write 'python prog.py' then it will automatically seek out and >> load any dependencies of prog.py, you don't need to list them all in an >> auxiliary file. > > Python is an interpreted language, C is not. What do you mean? There are python compilers, there are C interpreters. -- __Pascal J. Bourguignon__ http://www.informatimago.com
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-25 11:14 +0100 |
| Message-ID | <q2enii$390$1@dont-email.me> |
| In reply to | #140224 |
On 25/01/2019 10:08, Pascal J. Bourguignon wrote: > David Brown <david.brown@hesbynett.no> writes: > >> On 24/01/2019 23:46, Bart wrote: >>> On 24/01/2019 21:24, David Brown wrote: >>>> On 24/01/2019 18:32, Bart wrote: >>> >>>>> What makes you think my project isn't modular? >>>>> >>>> >>>> Your obsession with single giant files, along with your dismissal of >>>> sensible development tools and editors. >>> >>> You don't seem to understand how a module system works in this kind of >>> language. >>> >>> When you write 'python prog.py' then it will automatically seek out and >>> load any dependencies of prog.py, you don't need to list them all in an >>> auxiliary file. >> >> Python is an interpreted language, C is not. > > What do you mean? > > There are python compilers, there are C interpreters. > I mean Python is an interpreted language, and C is a compiled language, in the way people usually mean when they classify languages as interpreted or compiled. Of course there can be exceptions - such classifications are not really absolute. And it would be a little more accurate to say Python is bytecode compiled, then run on a virtual machine. Yes, you can (to some extent) compile Python. In particular, you can use PyPy with JIT compilation. And yes, you there exist some C interpreters. But those are not the normal mode of operations for the languages.
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2019-01-25 12:02 +0100 |
| Message-ID | <m2imydgfu3.fsf@despina.home> |
| In reply to | #140229 |
David Brown <david.brown@hesbynett.no> writes: > On 25/01/2019 10:08, Pascal J. Bourguignon wrote: >> David Brown <david.brown@hesbynett.no> writes: >> >>> On 24/01/2019 23:46, Bart wrote: >>>> On 24/01/2019 21:24, David Brown wrote: >>>>> On 24/01/2019 18:32, Bart wrote: >>>> >>>>>> What makes you think my project isn't modular? >>>>>> >>>>> >>>>> Your obsession with single giant files, along with your dismissal of >>>>> sensible development tools and editors. >>>> >>>> You don't seem to understand how a module system works in this kind of >>>> language. >>>> >>>> When you write 'python prog.py' then it will automatically seek out and >>>> load any dependencies of prog.py, you don't need to list them all in an >>>> auxiliary file. >>> >>> Python is an interpreted language, C is not. >> >> What do you mean? >> >> There are python compilers, there are C interpreters. >> > > I mean Python is an interpreted language, and C is a compiled language, > in the way people usually mean when they classify languages as > interpreted or compiled. Yep, but my point is that people usually are dumb. That this classification is meaningless. Compiling or interpreting are unrelated to languages. > Of course there can be exceptions - such classifications are not really > absolute. And it would be a little more accurate to say Python is > bytecode compiled, then run on a virtual machine. It would still be dumb. > Yes, you can (to some extent) compile Python. In particular, you can > use PyPy with JIT compilation. And yes, you there exist some C > interpreters. But those are not the normal mode of operations for the > languages. Languages don't operate. You're still in the meaningless domain. -- __Pascal J. Bourguignon__ http://www.informatimago.com
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-25 13:37 +0100 |
| Message-ID | <q2evuv$ikb$1@dont-email.me> |
| In reply to | #140230 |
On 25/01/2019 12:02, Pascal J. Bourguignon wrote: > David Brown <david.brown@hesbynett.no> writes: > >> On 25/01/2019 10:08, Pascal J. Bourguignon wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>> >>>> On 24/01/2019 23:46, Bart wrote: >>>>> On 24/01/2019 21:24, David Brown wrote: >>>>>> On 24/01/2019 18:32, Bart wrote: >>>>> >>>>>>> What makes you think my project isn't modular? >>>>>>> >>>>>> >>>>>> Your obsession with single giant files, along with your dismissal of >>>>>> sensible development tools and editors. >>>>> >>>>> You don't seem to understand how a module system works in this kind of >>>>> language. >>>>> >>>>> When you write 'python prog.py' then it will automatically seek out and >>>>> load any dependencies of prog.py, you don't need to list them all in an >>>>> auxiliary file. >>>> >>>> Python is an interpreted language, C is not. >>> >>> What do you mean? >>> >>> There are python compilers, there are C interpreters. >>> >> >> I mean Python is an interpreted language, and C is a compiled language, >> in the way people usually mean when they classify languages as >> interpreted or compiled. > > Yep, but my point is that people usually are dumb. What a strange "point" to make, and what a strange way to try to make it. > That this > classification is meaningless. No, the classification is often very helpful. It is true that a particular implementation of a language may work in a different way from more common implementations - but it is useful to classify languages based on certain characteristics, including the way they are usually implemented.
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2019-01-25 13:58 +0100 |
| Message-ID | <m2a7johp1d.fsf@despina.home> |
| In reply to | #140239 |
David Brown <david.brown@hesbynett.no> writes: > On 25/01/2019 12:02, Pascal J. Bourguignon wrote: >> David Brown <david.brown@hesbynett.no> writes: >> >>> On 25/01/2019 10:08, Pascal J. Bourguignon wrote: >>>> David Brown <david.brown@hesbynett.no> writes: >>>> >>>>> On 24/01/2019 23:46, Bart wrote: >>>>>> On 24/01/2019 21:24, David Brown wrote: >>>>>>> On 24/01/2019 18:32, Bart wrote: >>>>>> >>>>>>>> What makes you think my project isn't modular? >>>>>>>> >>>>>>> >>>>>>> Your obsession with single giant files, along with your dismissal of >>>>>>> sensible development tools and editors. >>>>>> >>>>>> You don't seem to understand how a module system works in this kind of >>>>>> language. >>>>>> >>>>>> When you write 'python prog.py' then it will automatically seek out and >>>>>> load any dependencies of prog.py, you don't need to list them all in an >>>>>> auxiliary file. >>>>> >>>>> Python is an interpreted language, C is not. >>>> >>>> What do you mean? >>>> >>>> There are python compilers, there are C interpreters. >>>> >>> >>> I mean Python is an interpreted language, and C is a compiled language, >>> in the way people usually mean when they classify languages as >>> interpreted or compiled. >> >> Yep, but my point is that people usually are dumb. > > What a strange "point" to make, and what a strange way to try to make it. > >> That this >> classification is meaningless. > > No, the classification is often very helpful. It is true that a > particular implementation of a language may work in a different way from > more common implementations - but it is useful to classify languages > based on certain characteristics, including the way they are usually > implemented. You really don't understand. A language is defined by a set of sentenses (often characterized by a grammar), and a mapping to a semantic system. This is a purely mathematical object, and it has absolutely no relation to compilers, interpreters, bytecode compilers, just-in-time compiler, native processors, microcoded processors, virtual machines, or hungarian dancers. https://www.youtube.com/watch?v=3San3uKKHgg If I implement a C compiler with a troup of hungarian dancers, will you say that C is a choregraphied language? Do you realize how dumb this is? You can executed programs written in a given language using a compiler to translate it, and the execute the resulting translated program using another processor (which can be implemented using also a compiler, or an interpreter, or a hardware processor, or a firmware (microcode) processor, or with dancers. This is just totally unrelated to the language and its semantics. -- __Pascal J. Bourguignon__ http://www.informatimago.com
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-25 14:26 +0100 |
| Message-ID | <q2f2po$292$1@dont-email.me> |
| In reply to | #140242 |
On 25/01/2019 13:58, Pascal J. Bourguignon wrote: > David Brown <david.brown@hesbynett.no> writes: > >> On 25/01/2019 12:02, Pascal J. Bourguignon wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>> >>>> On 25/01/2019 10:08, Pascal J. Bourguignon wrote: >>>>> David Brown <david.brown@hesbynett.no> writes: >>>>> >>>>>> On 24/01/2019 23:46, Bart wrote: >>>>>>> On 24/01/2019 21:24, David Brown wrote: >>>>>>>> On 24/01/2019 18:32, Bart wrote: >>>>>>> >>>>>>>>> What makes you think my project isn't modular? >>>>>>>>> >>>>>>>> >>>>>>>> Your obsession with single giant files, along with your dismissal of >>>>>>>> sensible development tools and editors. >>>>>>> >>>>>>> You don't seem to understand how a module system works in this kind of >>>>>>> language. >>>>>>> >>>>>>> When you write 'python prog.py' then it will automatically seek out and >>>>>>> load any dependencies of prog.py, you don't need to list them all in an >>>>>>> auxiliary file. >>>>>> >>>>>> Python is an interpreted language, C is not. >>>>> >>>>> What do you mean? >>>>> >>>>> There are python compilers, there are C interpreters. >>>>> >>>> >>>> I mean Python is an interpreted language, and C is a compiled language, >>>> in the way people usually mean when they classify languages as >>>> interpreted or compiled. >>> >>> Yep, but my point is that people usually are dumb. >> >> What a strange "point" to make, and what a strange way to try to make it. >> >>> That this >>> classification is meaningless. >> >> No, the classification is often very helpful. It is true that a >> particular implementation of a language may work in a different way from >> more common implementations - but it is useful to classify languages >> based on certain characteristics, including the way they are usually >> implemented. > > You really don't understand. > Yes, I understand about the difference between a language and an implementation of the language. But I am not particularly interested in arguing with someone who is being unhelpfully pedantic. The thing I don't understand is why you feel your original "What do you mean?" comment was a useful contribution to the discussion. Was it just so that you could show off that /you/ know the difference between a language and its implementations?
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2019-01-25 15:01 +0100 |
| Message-ID | <m21s50hm43.fsf@despina.home> |
| In reply to | #140245 |
David Brown <david.brown@hesbynett.no> writes: > On 25/01/2019 13:58, Pascal J. Bourguignon wrote: >> David Brown <david.brown@hesbynett.no> writes: >> >>> On 25/01/2019 12:02, Pascal J. Bourguignon wrote: >>>> David Brown <david.brown@hesbynett.no> writes: >>>> >>>>> On 25/01/2019 10:08, Pascal J. Bourguignon wrote: >>>>>> David Brown <david.brown@hesbynett.no> writes: >>>>>> >>>>>>> On 24/01/2019 23:46, Bart wrote: >>>>>>>> On 24/01/2019 21:24, David Brown wrote: >>>>>>>>> On 24/01/2019 18:32, Bart wrote: >>>>>>>> >>>>>>>>>> What makes you think my project isn't modular? >>>>>>>>>> >>>>>>>>> >>>>>>>>> Your obsession with single giant files, along with your dismissal of >>>>>>>>> sensible development tools and editors. >>>>>>>> >>>>>>>> You don't seem to understand how a module system works in this kind of >>>>>>>> language. >>>>>>>> >>>>>>>> When you write 'python prog.py' then it will automatically seek out and >>>>>>>> load any dependencies of prog.py, you don't need to list them all in an >>>>>>>> auxiliary file. >>>>>>> >>>>>>> Python is an interpreted language, C is not. >>>>>> >>>>>> What do you mean? >>>>>> >>>>>> There are python compilers, there are C interpreters. >>>>>> >>>>> >>>>> I mean Python is an interpreted language, and C is a compiled language, >>>>> in the way people usually mean when they classify languages as >>>>> interpreted or compiled. >>>> >>>> Yep, but my point is that people usually are dumb. >>> >>> What a strange "point" to make, and what a strange way to try to make it. >>> >>>> That this >>>> classification is meaningless. >>> >>> No, the classification is often very helpful. It is true that a >>> particular implementation of a language may work in a different way from >>> more common implementations - but it is useful to classify languages >>> based on certain characteristics, including the way they are usually >>> implemented. >> >> You really don't understand. >> > > Yes, I understand about the difference between a language and an > implementation of the language. But I am not particularly interested in > arguing with someone who is being unhelpfully pedantic. The thing I > don't understand is why you feel your original "What do you mean?" > comment was a useful contribution to the discussion. Was it just so > that you could show off that /you/ know the difference between a > language and its implementations? Clearly, you didn't know it, before I explained it. Otherwise you would have answered to my first question, and that would be about it. -- __Pascal J. Bourguignon__ http://www.informatimago.com
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-25 15:42 +0100 |
| Message-ID | <q2f77r$t7o$1@dont-email.me> |
| In reply to | #140249 |
On 25/01/2019 15:01, Pascal J. Bourguignon wrote: > David Brown <david.brown@hesbynett.no> writes: > >> On 25/01/2019 13:58, Pascal J. Bourguignon wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>> >>>> On 25/01/2019 12:02, Pascal J. Bourguignon wrote: >>>>> David Brown <david.brown@hesbynett.no> writes: >>>>> >>>>>> On 25/01/2019 10:08, Pascal J. Bourguignon wrote: >>>>>>> David Brown <david.brown@hesbynett.no> writes: >>>>>>> >>>>>>>> On 24/01/2019 23:46, Bart wrote: >>>>>>>>> On 24/01/2019 21:24, David Brown wrote: >>>>>>>>>> On 24/01/2019 18:32, Bart wrote: >>>>>>>>> >>>>>>>>>>> What makes you think my project isn't modular? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Your obsession with single giant files, along with your dismissal of >>>>>>>>>> sensible development tools and editors. >>>>>>>>> >>>>>>>>> You don't seem to understand how a module system works in this kind of >>>>>>>>> language. >>>>>>>>> >>>>>>>>> When you write 'python prog.py' then it will automatically seek out and >>>>>>>>> load any dependencies of prog.py, you don't need to list them all in an >>>>>>>>> auxiliary file. >>>>>>>> >>>>>>>> Python is an interpreted language, C is not. >>>>>>> >>>>>>> What do you mean? >>>>>>> >>>>>>> There are python compilers, there are C interpreters. >>>>>>> >>>>>> >>>>>> I mean Python is an interpreted language, and C is a compiled language, >>>>>> in the way people usually mean when they classify languages as >>>>>> interpreted or compiled. >>>>> >>>>> Yep, but my point is that people usually are dumb. >>>> >>>> What a strange "point" to make, and what a strange way to try to make it. >>>> >>>>> That this >>>>> classification is meaningless. >>>> >>>> No, the classification is often very helpful. It is true that a >>>> particular implementation of a language may work in a different way from >>>> more common implementations - but it is useful to classify languages >>>> based on certain characteristics, including the way they are usually >>>> implemented. >>> >>> You really don't understand. >>> >> >> Yes, I understand about the difference between a language and an >> implementation of the language. But I am not particularly interested in >> arguing with someone who is being unhelpfully pedantic. The thing I >> don't understand is why you feel your original "What do you mean?" >> comment was a useful contribution to the discussion. Was it just so >> that you could show off that /you/ know the difference between a >> language and its implementations? > > Clearly, you didn't know it, before I explained it. Otherwise you would > have answered to my first question, and that would be about it. > Yeah, sure, whatever you say. As I said, the challenge was to figure out what your question meant and why you were asking it, not how programming languages work. And that should, hopefully, be the end of this branch. (Reply if you want, of course.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-01-25 10:25 -0800 |
| Message-ID | <lnpnskzjan.fsf@kst-u.example.com> |
| In reply to | #140254 |
David Brown <david.brown@hesbynett.no> writes:
[68 lines deleted]
> Yeah, sure, whatever you say.
>
> As I said, the challenge was to figure out what your question meant and
> why you were asking it, not how programming languages work.
>
> And that should, hopefully, be the end of this branch. (Reply if you
> want, of course.)
It's not necessary to quote the entire conversation in each followup.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-01-25 14:37 +0000 |
| Message-ID | <MaF2E.143089$9E1.86748@fx35.am4> |
| In reply to | #140224 |
On 25/01/2019 09:08, Pascal J. Bourguignon wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 24/01/2019 23:46, Bart wrote:
>>> On 24/01/2019 21:24, David Brown wrote:
>>>> On 24/01/2019 18:32, Bart wrote:
>>>
>>>>> What makes you think my project isn't modular?
>>>>>
>>>>
>>>> Your obsession with single giant files, along with your dismissal of
>>>> sensible development tools and editors.
>>>
>>> You don't seem to understand how a module system works in this kind of
>>> language.
>>>
>>> When you write 'python prog.py' then it will automatically seek out and
>>> load any dependencies of prog.py, you don't need to list them all in an
>>> auxiliary file.
>>
>> Python is an interpreted language, C is not.
>
> What do you mean?
>
> There are python compilers, there are C interpreters.
C is meant to be statically compiled, and nearly always is. Python is
meant to be dynamically interpreted, and usually is.
That there are odd versions of them that do the opposite is no surprise.
(I've dabbled with compiled dynamic code, and interpreted static code,
myself.)
Take this code fragment:
A = B + C
What native code would it compile down to in either C or Python?
In C that is easy, as those names have static types, so perhaps: Load
R,B; Add R,C; Store C,R where R is a suitable register size.
And if the line was repeated, then the same thing (bar some compilers
optimising things).
What about in Python? You can't do it, because A, B, C can each be (or
refer to) any of a whole range of object types, and the "+" can mean any
possible operation, including overloads of "+" between user-defined classes.
And if you repeated the line, then they can all be different.
You can try and write native code, but it would be along the lines of:
push B; call pushobject; ... call addobject;....
Or, through a vastly complex JIT process, you might deduce that on a
particular 'hot' path, A, B, C are all floats and you can generate
direct native code for that path. But that is at runtime, unless you do
equally complex whole-program analysis.
It should be clear that C code would naturally be compiled, and Python
is naturally interpreted.
That is, if you interested in practicalities. (Your other replies
suggest not.)
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2019-01-25 16:33 +0100 |
| Message-ID | <m2womsg3bf.fsf@despina.home> |
| In reply to | #140251 |
Bart <bc@freeuk.com> writes: > On 25/01/2019 09:08, Pascal J. Bourguignon wrote: >> David Brown <david.brown@hesbynett.no> writes: >> >>> On 24/01/2019 23:46, Bart wrote: >>>> On 24/01/2019 21:24, David Brown wrote: >>>>> On 24/01/2019 18:32, Bart wrote: >>>> >>>>>> What makes you think my project isn't modular? >>>>>> >>>>> >>>>> Your obsession with single giant files, along with your dismissal of >>>>> sensible development tools and editors. >>>> >>>> You don't seem to understand how a module system works in this kind of >>>> language. >>>> >>>> When you write 'python prog.py' then it will automatically seek out and >>>> load any dependencies of prog.py, you don't need to list them all in an >>>> auxiliary file. >>> >>> Python is an interpreted language, C is not. >> >> What do you mean? >> >> There are python compilers, there are C interpreters. > > C is meant to be statically compiled, and nearly always is. Python is > meant to be dynamically interpreted, and usually is. Bullshit! Compilation and interpretation are implementation strategies to evaluate PROGRAMS. They're totally unrelated to the LANGUAGE in which those programs are written. Classically, interpreters are used in the bootstrap process of implementing a new compiler. Again, independently of the language! (Other bootstrapping strategies are possible of course). > That there are odd versions of them that do the opposite is no > surprise. (I've dabbled with compiled dynamic code, and interpreted > static code, myself.) > > Take this code fragment: > > A = B + C > > What native code would it compile down to in either C or Python? Obviously, very different native code, since the semantics of C and Python are very different. > You can try and write native code, but it would be along the lines of: > push B; call pushobject; ... call addobject;.... So what? Compiler or interpreter, you have to implement the SEMANTICS of the language! > Or, through a vastly complex JIT process, And of course, there's a whole gradation of implementation strategies. This is one more reason why trying to use the terms "compiled" or "interpreted" to characterize languages is silly. Do you realize that your "native" code running on Intel processors is actually COMPILED JIT into the real native microcode of the Intel hardware? > It should be clear that C code would naturally be compiled, and Python > is naturally interpreted. Nope, not clear at all. > That is, if you interested in practicalities. (Your other replies > suggest not.) -- __Pascal J. Bourguignon__ http://www.informatimago.com
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-01-25 07:44 -0800 |
| Message-ID | <4af80090-fbeb-4b21-92dc-d5c0fb7d73e7@googlegroups.com> |
| In reply to | #140263 |
On Friday, 25 January 2019 15:33:19 UTC, Pascal J. Bourguignon wrote: > Bart <bc@freeuk.com> writes: > > > > > C is meant to be statically compiled, and nearly always is. Python is > > meant to be dynamically interpreted, and usually is. > > Bullshit! > > Compilation and interpretation are implementation strategies to evaluate > PROGRAMS. They're totally unrelated to the LANGUAGE in which those > programs are written. > Everyone understands the simple point you are making. But it's quite easy to write a Lisp interpreter, rather more difficult to write a Lisp compiler. On the other hand, C is designed to make a reasonably efficient compiler easy to write. Most of the constructs map to single instructions on typical processors.
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2019-01-25 17:53 +0100 |
| Message-ID | <m2lg38fzlq.fsf@despina.home> |
| In reply to | #140266 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Friday, 25 January 2019 15:33:19 UTC, Pascal J. Bourguignon wrote: >> Bart <bc@freeuk.com> writes: >> >> > >> > C is meant to be statically compiled, and nearly always is. Python is >> > meant to be dynamically interpreted, and usually is. >> >> Bullshit! >> >> Compilation and interpretation are implementation strategies to evaluate >> PROGRAMS. They're totally unrelated to the LANGUAGE in which those >> programs are written. >> > Everyone understands the simple point you are making. > > But it's quite easy to write a Lisp interpreter, rather more difficult > to write a Lisp compiler. On the other hand, C is designed to make a > reasonably efficient compiler easy to write. Most of the constructs > map to single instructions on typical processors. If you read closely the ANSI C standard and the ANSI CL standard, you will notice that there's no difference in implied implementation choices. It's only a matter of ecosystem culture if the usual tools turn out as they are. -- __Pascal J. Bourguignon__ http://www.informatimago.com
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-01-25 10:33 -0800 |
| Message-ID | <lnlg38zixu.fsf@kst-u.example.com> |
| In reply to | #140268 |
"Pascal J. Bourguignon" <pjb@informatimago.com> writes:
[...]
> If you read closely the ANSI C standard and the ANSI CL standard, you
What is the "ANSI CL standard"? If "CL" means "C library", the
language and library are defined by the same standard (which is
maintained by ISO, not by ANSI).
> will notice that there's no difference in implied implementation
> choices. It's only a matter of ecosystem culture if the usual tools
> turn out as they are.
5.1.1.2 Translation phases:
8. All external object and function references are
resolved. Library components are linked to satisfy external
references to functions and objects not defined in the current
translation. All such translator output is collected into a
program image which contains information needed for execution
in its execution environment.
That clearly implies a compile-and-link implementation.
A C interpreter could be conforming, and a footnote says:
The description is conceptual only, and does not specify any
particular implementation.
But your statement that "there's no difference in implied implementation
choices" is incorrect.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2019-01-25 20:43 +0100 |
| Message-ID | <m2d0okfrpi.fsf@despina.home> |
| In reply to | #140276 |
Keith Thompson <kst-u@mib.org> writes: > "Pascal J. Bourguignon" <pjb@informatimago.com> writes: > [...] >> If you read closely the ANSI C standard and the ANSI CL standard, you > > What is the "ANSI CL standard"? ANSI Common Lisp. >> will notice that there's no difference in implied implementation >> choices. It's only a matter of ecosystem culture if the usual tools >> turn out as they are. > > 5.1.1.2 Translation phases: > > 8. All external object and function references are > resolved. Library components are linked to satisfy external > references to functions and objects not defined in the current > translation. All such translator output is collected into a > program image which contains information needed for execution > in its execution environment. > > That clearly implies a compile-and-link implementation. Not at all: > A C interpreter could be conforming, and a footnote says: > > The description is conceptual only, and does not specify any > particular implementation. > > But your statement that "there's no difference in implied implementation > choices" is incorrect. Try to reconcile your differences! -- __Pascal J. Bourguignon__ http://www.informatimago.com
[toc] | [prev] | [next] | [standalone]
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web