Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #126692 > unrolled thread
| Started by | G B <gb@gb.com> |
|---|---|
| First post | 2018-02-14 11:47 -0400 |
| Last post | 2018-02-25 20:12 +0000 |
| Articles | 20 on this page of 168 — 30 participants |
Back to article view | Back to comp.lang.c
Text Files G B <gb@gb.com> - 2018-02-14 11:47 -0400
Re: Text Files Ed Prochak <edprochak@gmail.com> - 2018-02-14 08:45 -0800
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-14 08:47 -0800
Re: Text Files already5chosen@yahoo.com - 2018-02-15 01:17 -0800
Re: Text Files gordonb.ea2mq@burditt.org (Gordon Burditt) - 2018-02-14 11:10 -0600
Re: Text Files "James R. Kuyper" <jameskuyper@verizon.net> - 2018-02-14 12:28 -0500
Re: Text Files jt@toerring.de (Jens Thoms Toerring) - 2018-02-14 21:07 +0000
Re: Text Files Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-14 15:31 -0700
Re: Text Files Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-15 06:59 +0000
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 10:20 +0000
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-14 22:51 +0000
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-15 11:04 +0100
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-15 06:16 -0800
Re: Text Files "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-02-15 22:22 +0800
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-15 15:58 +0100
Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 16:31 +0000
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-15 21:31 +0100
Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 21:21 +0000
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 22:17 +0000
Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 23:36 +0000
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 23:48 +0000
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 10:09 +0100
Re: Text Files bartc <bc@freeuk.com> - 2018-02-16 12:57 +0000
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 15:50 +0100
Re: Text Files bartc <bc@freeuk.com> - 2018-02-16 15:50 +0000
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 17:07 +0100
Re: Text Files bartc <bc@freeuk.com> - 2018-02-16 20:44 +0000
Re: Text Files Ian Collins <ian-news@hotmail.com> - 2018-02-17 11:22 +1300
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-16 17:48 +0000
Re: Text Files GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-16 17:06 +0100
Re: Text Files Ian Collins <ian-news@hotmail.com> - 2018-02-17 11:10 +1300
Re: Text Files supercat@casperkitty.com - 2018-02-16 14:48 -0800
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-16 15:14 -0800
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-16 23:25 +0000
Re: Text Files supercat@casperkitty.com - 2018-02-16 15:50 -0800
Re: Text Files already5chosen@yahoo.com - 2018-02-16 07:19 -0800
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 17:13 +0100
Re: Text Files Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-19 17:55 +0000
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-19 19:14 +0100
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-19 11:48 -0800
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-16 08:14 -0800
Re: Text Files Robert Wessel <robertwessel2@yahoo.com> - 2018-02-17 18:32 -0600
Re: Text Files jacobnavia <jacob@jacob.remcomp.fr> - 2018-02-15 22:57 +0100
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 22:58 +0000
Re: Text Files bartc <bc@freeuk.com> - 2018-02-16 00:19 +0000
Re: Text Files bartc <bc@freeuk.com> - 2018-02-16 02:26 +0000
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-16 02:57 +0000
Re: Text Files asetofsymbols@gmail.com - 2018-02-16 00:21 -0800
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-16 11:30 +0000
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 10:36 +0100
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-16 11:36 +0000
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 13:10 +0100
Re: Text Files bartc <bc@freeuk.com> - 2018-02-16 12:25 +0000
Re: Text Files Ike Naar <ike@iceland.freeshell.org> - 2018-03-06 19:33 +0000
Re: Text Files bartc <bc@freeuk.com> - 2018-03-06 20:55 +0000
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-16 04:42 -0800
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 16:58 +0100
Re: Text Files bartc <bc@freeuk.com> - 2018-02-16 20:02 +0000
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 21:43 +0100
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-17 04:01 -0800
Re: Text Files bartc <bc@freeuk.com> - 2018-02-17 13:10 +0000
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-17 05:27 -0800
Re: Text Files bartc <bc@freeuk.com> - 2018-02-17 14:20 +0000
Re: Text Files Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-16 09:04 -0700
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-16 14:31 +0000
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-16 06:42 -0800
Re: Text Files bartc <bc@freeuk.com> - 2018-02-16 14:58 +0000
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-16 07:23 -0800
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-16 15:24 +0000
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-16 04:13 -0800
Re: Text Files Siri Cruise <chine.bleu@yahoo.com> - 2018-02-16 04:29 -0800
Re: Text Files Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-20 16:41 +0000
Re: Text Files Siri Cruise <chine.bleu@yahoo.com> - 2018-02-20 09:39 -0800
Re: Text Files Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-20 19:16 +0000
Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 12:46 +0000
Re: Text Files GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-15 14:52 +0100
Re: Text Files Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-02-15 17:07 +0300
Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 14:23 +0000
Re: Text Files Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-02-15 18:52 +0300
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 14:39 +0000
Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 15:43 +0000
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 20:32 +0000
Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 22:06 +0000
Re: Text Files GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-15 23:12 +0100
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-15 15:12 -0800
Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 23:43 +0000
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 23:54 +0000
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 23:35 +0000
Re: Text Files Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-16 17:07 -0800
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-17 02:38 +0000
Re: Text Files Ian Collins <ian-news@hotmail.com> - 2018-02-17 17:26 +1300
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-17 11:22 +0000
Re: Text Files bartc <bc@freeuk.com> - 2018-02-17 12:07 +0000
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-17 04:17 -0800
Re: Text Files Anton Shepelev <anton.txt@gmail.com> - 2018-02-17 16:25 +0300
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-17 07:35 -0800
Re: Text Files GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-17 15:24 +0100
Re: Text Files Ian Collins <ian-news@hotmail.com> - 2018-02-18 11:10 +1300
Re: Text Files Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-19 12:05 -0800
Re: Text Files already5chosen@yahoo.com - 2018-02-19 15:32 -0800
Re: Text Files Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-21 10:34 -0800
Re: Text Files already5chosen@yahoo.com - 2018-02-21 15:35 -0800
Re: Text Files bartc <bc@freeuk.com> - 2018-02-22 00:11 +0000
Re: Text Files Robert Wessel <robertwessel2@yahoo.com> - 2018-02-21 18:26 -0600
Re: Text Files Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-21 21:39 -0800
Re: Text Files Robert Wessel <robertwessel2@yahoo.com> - 2018-02-23 03:08 -0600
Re: Text Files supercat@casperkitty.com - 2018-02-23 16:16 -0800
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-23 16:46 -0800
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-24 02:49 -0800
Re: Text Files asetofsymbols@gmail.com - 2018-02-24 05:16 -0800
Re: Text Files "F. Russell" <fr@random.info> - 2018-02-24 14:35 +0000
Re: Text Files Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-24 08:48 -0700
Re: Text Files supercat@casperkitty.com - 2018-02-25 15:09 -0800
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-25 15:54 -0800
Re: Text Files supercat@casperkitty.com - 2018-02-26 11:04 -0800
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-26 11:52 -0800
Re: Text Files supercat@casperkitty.com - 2018-02-26 14:12 -0800
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-26 14:40 -0800
Re: Text Files already5chosen@yahoo.com - 2018-02-22 04:58 -0800
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-22 05:33 -0800
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-22 13:59 +0000
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-22 07:24 -0800
Re: Text Files supercat@casperkitty.com - 2018-02-20 12:14 -0800
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-15 21:37 +0100
Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 21:34 +0000
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-15 14:15 -0800
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 10:47 +0100
Re: Text Files "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-02-15 22:20 +0800
Re: Text Files "F. Russell" <fr@random.info> - 2018-02-15 15:24 +0000
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 16:05 +0000
Re: Text Files "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-02-16 00:22 +0800
Re: Text Files Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-15 13:35 -0700
Re: Text Files Anton Shepelev <anton.txt@gmail.com> - 2018-02-25 00:13 +0300
Re: Text Files bartc <bc@freeuk.com> - 2018-02-24 21:24 +0000
Re: Text Files Anton Shepelev <anton.txt@gmail.com> - 2018-02-25 14:55 +0300
Re: Text Files bartc <bc@freeuk.com> - 2018-02-25 13:00 +0000
Re: Text Files Real Troll <Real.Troll@Trolls.com> - 2018-02-24 17:35 -0400
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-24 21:36 +0000
Re: Text Files Real Troll <Real.Troll@Trolls.com> - 2018-02-24 17:45 -0400
Re: Text Files Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-24 22:51 +0000
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-24 23:56 +0000
Re: Text Files bartc <bc@freeuk.com> - 2018-02-25 00:14 +0000
Re: Text Files bartc <bc@freeuk.com> - 2018-02-25 00:22 +0000
Re: Text Files Anton Shepelev <anton.txt@gmail.com> - 2018-02-25 15:16 +0300
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-25 15:20 -0800
Re: Text Files Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-25 20:27 -0700
Re: Text Files gazelle@shell.xmission.com (Kenny McCormack) - 2018-02-26 06:19 +0000
Re: Text Files Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-02-26 15:35 +0300
Re: Text Files Reinhardt Behm <rbehm@hushmail.com> - 2018-02-26 20:53 +0800
Grammar Patrol (Was: Text Files) gazelle@shell.xmission.com (Kenny McCormack) - 2018-02-26 17:54 +0000
Re: Text Files Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-26 15:27 +0000
Re: Text Files Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-02-26 18:50 +0300
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-26 09:26 -0800
Re: Text Files scott@slp53.sl.home (Scott Lurndal) - 2018-02-26 19:46 +0000
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-27 09:04 +0100
Re: Text Files already5chosen@yahoo.com - 2018-02-27 00:56 -0800
Re: Text Files Ian Collins <ian-news@hotmail.com> - 2018-02-27 22:07 +1300
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-27 14:37 +0100
Re: Text Files already5chosen@yahoo.com - 2018-02-27 07:38 -0800
Re: Text Files supercat@casperkitty.com - 2018-02-27 09:18 -0800
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-27 10:15 +0100
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-27 08:53 -0800
Re: Text Files Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-26 23:14 -0800
Re: Text Files Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-26 08:32 -0700
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-26 09:17 -0800
Re: Text Files Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-26 22:55 -0800
Re: Text Files Anton Shepelev <anton.txt@gmail.com> - 2018-02-25 15:02 +0300
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-25 20:12 +0000
Page 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-02-15 23:48 +0000 |
| Message-ID | <87bmgp7r2n.fsf@bsb.me.uk> |
| In reply to | #126766 |
bartc <bc@freeuk.com> writes: > On 15/02/2018 22:17, Ben Bacarisse wrote: >> bartc <bc@freeuk.com> writes: > >>> You say that is simpler and clearer than writing: >>> >>> readln a, b, c >>> >>> OK. >> >> This is not a fair exchange of views. All languages have winners and >> losers in the trade-off between providing general mechanisms and >> specific ones, but no one but you has access to the documentation for >> your language so it's impossible to tell what, if anything, the cost is >> of having that simple input line. > > There is no cost because you can do it the hard way too (I'm sure I > can do it how Python does it). But the benefit is easier coding and > extra productivity. You see why it's not a fair exchange of views? >> It's not that I want to know the answers -- the point is that this is >> rapidly going turn into a fruitless exchange without full documentation >> for all the languages involved. > > You don't need any docs except to know such simple input possible in > many languages without fuss, But the issue is yours, not many others. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-02-16 10:09 +0100 |
| Message-ID | <p6673c$7j6$1@dont-email.me> |
| In reply to | #126756 |
On 15/02/18 22:21, bartc wrote:
> On 15/02/2018 20:31, David Brown wrote:
>> On 15/02/18 17:31, bartc wrote:
>
>>> Here it is in my script language, but reading 6 numbers per line:
>>>
>>> file:=openfile("input")
>>> while not eof(file) do
>>> readln @file,a,b,c,d,e,f
>>> println a+b+c+d+e+f
>>> od
>>> closefile(file)
>>>
>>> Simple constructs that everyone understands.
>>
>> It is certainly not simpler or clearer than the Python code, IMHO.
>
> Really? I believe the Python code just to read three numbers from the
> console would be something like:
>
> a, b, c = map(float, input().split())
>
> (with the problems i that every number is a float, and it only allows
> white-space separators.
>
> You say that is simpler and clearer than writing:
>
> readln a, b, c
What I said was that the Python code /I/ wrote was simpler and clearer
than the script code /you/ wrote. I stand by that assertion - amongst
other things, there is no indication from your code where these
variables a, b, etc., come from, what they are, or what they do. There
is no indication about types. How would this look different if the user
wanted floats rather than ints (or vice versa), or concatenated strings?
How would your code work if you wanted floats, but using the
continental European convention of a decimal comma?
I also said that the Python code could be written in many different ways
- that does not mean that every other way of writing it is clear. /I/
am happy with "map", and I am sure Ben is, but many other people are not.
>
> OK. I seem to to remember you said some horrendous C x-macro was better
> than the beautifully tabulated version in my language, so you do seem to
> have some odd opinions.
>
Yes, the x-macro version there was better than your mess, AFAIR. But
"beauty" is in the eye of the beholder, and you will obviously be highly
biased towards your own languages. After all, since they have no use
beyond /your/ own programming, they would be rather pointless if they
did not suit the way you like to write code!
> You
>> are biased from familiarity with your own language.
>
> And my own language was developed from familiarity with others.
It was developed first and foremost from familiarity with your own
preferences, experiences, and way of thinking. Don't kid yourself in
thinking you have made a solid study of programming languages,
programmers, and code, and come up with a good general programming
language. It is entirely about how /you/ want to write code for the
programs /you/ want to write.
Or am I mistaken, and you can give me links to your extensive user group
of people whom you worked with to get ideas for the language, to discuss
the best way to write it, to talk about how it could be used to solve a
wide range of problems, to consider its limitations or improvements, to
write sample code, tutorials, documentation, etc.?
Don't get me wrong here - making your own language and writing the tools
for it is no mean achievement, and deserves respect. It is thinking
that you have a language of significance or that is, in a general sense,
"better" than other languages that is the problem.
>
> Reading a bunch of numbers from a line is classically done by some
> command like:
>
> read a, b, c
>
> as done in the OP's pseudo-code, and I'm sure I've done it that way in
> Basic, Algol, Fortran and Pascal (too longer ago to remember, but my
> language started about then too and I tended to copy what I'd used).
>
> Python, however, specifically can't do as simple as that (except perhaps
> with some hairy extensions, but I'm not sure it can as clean as that).
>
> You /have/ to apply string processing to get the numbers out of a line
> of input as I showed in my example.
>
Different languages handle this sort of thing in different ways and have
their pros and cons. Basic might be simpler for reading these 6 numbers
- and then harder when the number of items is unknown. That is not the
point - the key issue is merely that /C/ is an extremely poor choice of
language for this sort of thing in comparison to many others.
>
>> Having some sort of type indication is essential - that's how you can
>> tell that you are treating these as numbers and not strings. Support
>> for floating point instead of integers in the Python is a matter of
>> changing "int" to "float".
>
> Then you will always get a float, not either int or float. (That may or
> may not be what is wanted, but you have to be aware of it.)
Of course you have to be aware of what you are doing. The OP didn't
give a detailed specification, so any guesses about the details or
restrictions are no more than guesses.
>
>> ubiquitous, except on Windows, at around that time. Your scripting
>> language exists nowhere but your own machine.
>
> I've posted versions of it from time to time. But availability isn't the
> issue. It shows alternative, usually much simpler ways that things can
> work. Same with my alternative to C.
>
>>>> This kind of script /is/ easy to run on almost every platform. The
>>>> exception to ease-of-use is, as always, Windows - but it is still /far/
>>>> easier to run a Python script on Windows than to deal with a C
>>>> compiler.
>>>
>>> Rubbish.
>>>
>>
>> Installing Python is a single download. Installing a decent C
>> compiler on Windows seems to be beyond your capabilities - but now you
>> think it is easier than Python?
>
> You made an unwarranted comment about Windows. If something is hard to
> install, it's usually the fault of the thing being installed.
No, in this case it is absolutely and undeniably a Windows-only issue.
Virtually every Linux (and BSD, and other *nix) distribution for the
last couple of decades has included Python by default. All but the most
minimalist of embedded Linux systems have at least had it in their
repositories - installable by "apt-get install python" or similar
command, or selecting it from their standard "install software" system.
Windows is the /only/ desktop system where you would have to find the
Python webside, find the downloads page, figure out which version you
want, download it, start the installer, and click through the setup
system. And it is the only system where you can't start the interpreter
by typing "python" at the command prompt. I am not saying that
installing Python on Windows is /hard/ - but it is still infinitely
harder than using it on a system that already has it installed by default!
Similarly, many Linux systems already have gcc installed - and for
others, it is a quick apt-get away (as is clang, gcc-mingw cross
compiler for windows, several embedded system cross compilers, and even
tcc for Linux, at least on my system).
Again, don't get me wrong here - the "Linux way" for installation is far
better than the "Windows way" for most purposes, but it can be a lot
harder if you want software (or versions) that are not in the repositories.
>
> /My/ C compiler is no problem at all. The base compiler is a single
> executable; what can go wrong? The following compiles the C program I
> posted today:
>
> c:\c>mcc d
> MCC/TCL Compiler 2018.1.18
> Compiling d.c to d.a64
>
Of course your C compiler is a problem. First, no one knows about it,
and few sane people who happened to find it on the net would choose an
unknown little C compiler from an unknown source. Secondly, it is very
limited - you wrote it to compile the C code generated by your other
tools, not to be a realistic choice of C compiler. Thirdly, even if it
were a /perfect/ tool, you still need to download it, install it, figure
out how to run it, write your C code (how is your IDE?), compile it (how
are your warning messages?), debug it (how's your debugger?), test it -
and then, finally, you can run your program on the real input file of
numbers.
Or you can write 3 lines of Python code and have them run as you type
them in.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-02-16 12:57 +0000 |
| Message-ID | <nyAhC.85999$Ii5.20344@fx19.am4> |
| In reply to | #126777 |
On 16/02/2018 09:09, David Brown wrote:
> On 15/02/18 22:21, bartc wrote:
>> And my own language was developed from familiarity with others.
>
> It was developed first and foremost from familiarity with your own
> preferences, experiences, and way of thinking. Don't kid yourself in
> thinking you have made a solid study of programming languages,
> programmers, and code, and come up with a good general programming
> language.
I bet that's how the Fortran developers started out. Or maybe they just
had problems to solve.
It is entirely about how /you/ want to write code for the
> programs /you/ want to write.
>
> Or am I mistaken, and you can give me links to your extensive user group
> of people whom you worked with to get ideas for the language, to discuss
> the best way to write it, to talk about how it could be used to solve a
> wide range of problems, to consider its limitations or improvements, to
> write sample code, tutorials, documentation, etc.?
I see, you favour designing languages by committee. Many start out as
individual efforts, /then/ they get user groups when (if) they become
very popular.
> Don't get me wrong here - making your own language and writing the tools
> for it is no mean achievement, and deserves respect. It is thinking
> that you have a language of significance or that is, in a general sense,
> "better" than other languages that is the problem.
Over a period of about 15 years me and my very small company sold
software to the tune of perhaps $10m. Not including the market for
add-on packages developed in my scripting language by other people.
All developed 100% using my languages and compilers.
That's small beer these days compared with billion-dollar turnovers,
even if adjusted for inflation. But it shows my languages aren't exactly
just hobbyist toys. They can do real work.
> Different languages handle this sort of thing in different ways and have
> their pros and cons. Basic might be simpler for reading these 6 numbers
> - and then harder when the number of items is unknown. That is not the
> point - the key issue is merely that /C/ is an extremely poor choice of
> language for this sort of thing in comparison to many others.
I gave an example before of where an older language of mine (one of
those involved above), statically typed like C, could do exactly this:
int a,b,c,d,e,f
readln #file, a,b,c,d,e,f
There is no reason why C couldn't do exactly the same. Then it could be
used for quick throwaway programs just as easily as any other language.
(My current version still has this statement, but I haven't bothered
implementing it.)
So it is a language design issue: C has decided not to have simple
line-based input built-in, and so has Python. Even though this was
common in languages as far back as Fortran.
>> /My/ C compiler is no problem at all. The base compiler is a single
>> executable; what can go wrong?
> Of course your C compiler is a problem. First, no one knows about it,
> and few sane people who happened to find it on the net would choose an
> unknown little C compiler from an unknown source. Secondly, it is very
> limited - you wrote it to compile the C code generated by your other
> tools, not to be a realistic choice of C compiler.
It compiles Tiny C, Lua, SmallC, PicoC amongst others. It compiles all
the examples of C I've posted here for the last year (except one, due to
an ABI incompatibility), and will compile most examples of C posted by
others, except for Ben's.
So it's a useful, working product and my first choice when writing
native C code (with its no-nonsense approach to error reporting).
I haven't bothered with some little-used features as I consider them too
effort, given that the language lacks so many things I would find more
useful.
Effectively, it compiles a C dialect.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-02-16 15:50 +0100 |
| Message-ID | <p66r3l$dt4$1@dont-email.me> |
| In reply to | #126788 |
On 16/02/18 13:57, bartc wrote: > On 16/02/2018 09:09, David Brown wrote: >> On 15/02/18 22:21, bartc wrote: > >>> And my own language was developed from familiarity with others. >> >> It was developed first and foremost from familiarity with your own >> preferences, experiences, and way of thinking. Don't kid yourself in >> thinking you have made a solid study of programming languages, >> programmers, and code, and come up with a good general programming >> language. > > I bet that's how the Fortran developers started out. Or maybe they just > had problems to solve. Real programming languages are made by groups - or at least one or two language designers that talk to others. When you sit by yourself and make your own language, you can be sure it is a language primarily for /you/. > > It is entirely about how /you/ want to write code for the >> programs /you/ want to write. >> >> Or am I mistaken, and you can give me links to your extensive user group >> of people whom you worked with to get ideas for the language, to discuss >> the best way to write it, to talk about how it could be used to solve a >> wide range of problems, to consider its limitations or improvements, to >> write sample code, tutorials, documentation, etc.? > > I see, you favour designing languages by committee. Many start out as > individual efforts, /then/ they get user groups when (if) they become > very popular. No, they usually start out as individual efforts or a collaboration of two or three people. But they need a group effort and group input before they have a chance of becoming popular - that needs to happen before the details start getting too fixed. I favour programming languages that are designed to fit the needs of many people, not just one or his idea of what other people should be wanting. That does not mean designed by committee, or maintained by committee, but it means a collaborative effort. I have experience of using a language designed and implemented by one person. When that one person's goals diverged from other users, the language collapsed into oblivion. > >> Don't get me wrong here - making your own language and writing the tools >> for it is no mean achievement, and deserves respect. It is thinking >> that you have a language of significance or that is, in a general sense, >> "better" than other languages that is the problem. > > Over a period of about 15 years me and my very small company sold > software to the tune of perhaps $10m. Not including the market for > add-on packages developed in my scripting language by other people. > > All developed 100% using my languages and compilers. And if your customers are left with code that is unmaintainable because you have retired and there is no one else who can update or fix the code (never mind the tools behind it), then they have bought a cat in a bag. Maybe it was good enough at the time - far from all software projects are expected to last forever, or be maintained. But the reality is that any use of a single-person or single-company language has a far shorter shelf life than standard languages. It might still be the right business decision, especially many years ago when the alternative choices might not have been as good, and code with source in a weird language is more maintainable than a binary-only solution. > > That's small beer these days compared with billion-dollar turnovers, > even if adjusted for inflation. But it shows my languages aren't exactly > just hobbyist toys. They can do real work. I am sure they have done real work. That does not stop them being languages specifically designed to suit /you/, the way /you/ think, and the problems /you/ are trying to solve. There is no contradiction there. > >> Different languages handle this sort of thing in different ways and have >> their pros and cons. Basic might be simpler for reading these 6 numbers >> - and then harder when the number of items is unknown. That is not the >> point - the key issue is merely that /C/ is an extremely poor choice of >> language for this sort of thing in comparison to many others. > > I gave an example before of where an older language of mine (one of > those involved above), statically typed like C, could do exactly this: > > int a,b,c,d,e,f > readln #file, a,b,c,d,e,f > > There is no reason why C couldn't do exactly the same. Then it could be > used for quick throwaway programs just as easily as any other language. There are lots of reasons why C could not do that. You complain about C99 features like VLAs not "fitting the C philosophy", despite them being nothing more than a multiply and pointer addition, but you want to add features like this? > > (My current version still has this statement, but I haven't bothered > implementing it.) > > So it is a language design issue: C has decided not to have simple > line-based input built-in, and so has Python. Even though this was > common in languages as far back as Fortran. C's features for text input are very low level, and very limited. Python's are high level and very flexible, but that means it is takes a little more effort for this simple case. Change the problem slightly - such as to have floating point values with decimal commas and semicolon field separators, and you'll value the flexibility of python compared to your solution of specialised behaviour for the particular circumstances the language's designer thought was important. (And yes, I have worked with data in that format - it is not hypothetical.) > >>> /My/ C compiler is no problem at all. The base compiler is a single >>> executable; what can go wrong? > >> Of course your C compiler is a problem. First, no one knows about it, >> and few sane people who happened to find it on the net would choose an >> unknown little C compiler from an unknown source. Secondly, it is very >> limited - you wrote it to compile the C code generated by your other >> tools, not to be a realistic choice of C compiler. > > It compiles Tiny C, Lua, SmallC, PicoC amongst others. It compiles all > the examples of C I've posted here for the last year (except one, due to > an ABI incompatibility), and will compile most examples of C posted by > others, except for Ben's. > > So it's a useful, working product and my first choice when writing > native C code (with its no-nonsense approach to error reporting). > > I haven't bothered with some little-used features as I consider them too > effort, given that the language lacks so many things I would find more > useful. > > Effectively, it compiles a C dialect. >
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-02-16 15:50 +0000 |
| Message-ID | <v4DhC.11285$gS1.4803@fx26.am4> |
| In reply to | #126791 |
On 16/02/2018 14:50, David Brown wrote:
> On 16/02/18 13:57, bartc wrote:
>> All developed 100% using my languages and compilers.
>
> And if your customers are left with code that is unmaintainable because
> you have retired and there is no one else who can update or fix the code
> (never mind the tools behind it), then they have bought a cat in a bag.
I think that happens anyway even when an application uses mainstream
languages. Because it is poorly written. Or the author leaves. Or the
vendor goes out of business. Or just withdraws support.
> Maybe it was good enough at the time - far from all software projects
> are expected to last forever, or be maintained. But the reality is that
> any use of a single-person or single-company language
Or single-company product?
Because, of course, relying on a monstrously large language, that can
only be built with the help of dozens of complex tools and tens of
thousands of lines of scripts, and that is too big and complex to be
completely understood by any single individual, is /much/ better.
> I am sure they have done real work. That does not stop them being
> languages specifically designed to suit /you/, the way /you/ think, and
> the problems /you/ are trying to solve. There is no contradiction there.
They were designed to solve exactly the same problems that thousands of
other people wanted to solve. But they relied on someone else's slow
cumbersome tools badly ported from bigger computers.
And I made a living from them which is what counts.
Anyway, in the case of my own tools, then these days the main tools can
be expressed in portable C that can work across C compilers, and across
OSes, and can be trivially built by anyone on anything. They have been
made publicly available from time to time, and include these one-file C
source files:
qcc64.c Script language byte-code compiler
pcc64.c Script language byte-code interpreter
mxa64.c x64 assembler
mcc64.c C dialect compiler (which compiles all these)
On the other hand, I haven't yet, myself, been able to build my own
version of CPython for Windows.
I've rarely seen any open source programs as simple, self-contained or
as easy to build.
As a bonus, qcc works at up to 1M lines per second, mxa at up to 4M, and
mcc at over 0.5M, if you're interesting in programs that are nippy.
>> So it is a language design issue: C has decided not to have simple
>> line-based input built-in, and so has Python. Even though this was
>> common in languages as far back as Fortran.
>
> C's features for text input are very low level, and very limited.
How high level do you think that read statement is? I've already shown
that 'read a' maps to:
call _qreadi4
mov [a],rax
when a is a 32-bit signed int. How much lower can it be?
_qreadi4 (which reads the next item from a line buffer) is little
different from atoi().
> Python's are high level and very flexible, but that means it is takes a
> little more effort for this simple case.
You can have high level, and still be able to read a few numbers from a
line.
The very first programming exercise I ever did, back in '76, involved
first reading three numbers from the console. Then deciding if those
numbers can form the sides of a triangle.
Then, reading the numbers was the easy bit.
These days it would be a more challenging exercise than the main problem!
What's happened?
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-02-16 17:07 +0100 |
| Message-ID | <p66vjn$f1p$1@dont-email.me> |
| In reply to | #126796 |
On 16/02/18 16:50, bartc wrote: > On 16/02/2018 14:50, David Brown wrote: >> On 16/02/18 13:57, bartc wrote: > >>> All developed 100% using my languages and compilers. >> >> And if your customers are left with code that is unmaintainable because >> you have retired and there is no one else who can update or fix the code >> (never mind the tools behind it), then they have bought a cat in a bag. > > I think that happens anyway even when an application uses mainstream > languages. Because it is poorly written. Or the author leaves. Or the > vendor goes out of business. Or just withdraws support. Absolutely true. But when listing reasons for maintenance challenges, using a language known to relatively few people adds another big reason, as does using a language whose tools are from a single small supplier. Using C, or Python is certainly no guarantee for maintainable code - but using something like your scripting language is a guarantee for /unmaintainable/ code. > >> Maybe it was good enough at the time - far from all software projects >> are expected to last forever, or be maintained. But the reality is that >> any use of a single-person or single-company language > > Or single-company product? That depends on the size and style of the company. If it is a small company with a one-man language, then yes, it is a problem. If it is a huge company with lots of people involved, then it is not a problem. The day you are run over by a bus, then /everything/ ever written in your script, and all your tools for it, are suddenly unmaintainable. That is not the case for C#, Java, or whatever other single-company mainstream language you care to think of. > > Because, of course, relying on a monstrously large language, that can > only be built with the help of dozens of complex tools and tens of > thousands of lines of scripts, and that is too big and complex to be > completely understood by any single individual, is /much/ better. > Yes, it is. >> I am sure they have done real work. That does not stop them being >> languages specifically designed to suit /you/, the way /you/ think, and >> the problems /you/ are trying to solve. There is no contradiction there. > > They were designed to solve exactly the same problems that thousands of > other people wanted to solve. But they relied on someone else's slow > cumbersome tools badly ported from bigger computers. > > And I made a living from them which is what counts. > Ah, now that I agree on!
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-02-16 20:44 +0000 |
| Message-ID | <3oHhC.76219$O_7.9713@fx36.am4> |
| In reply to | #126799 |
On 16/02/2018 16:07, David Brown wrote: > On 16/02/18 16:50, bartc wrote: >> On 16/02/2018 14:50, David Brown wrote: >>> On 16/02/18 13:57, bartc wrote: >> >>>> All developed 100% using my languages and compilers. >>> >>> And if your customers are left with code that is unmaintainable because >>> you have retired and there is no one else who can update or fix the code >>> (never mind the tools behind it), then they have bought a cat in a bag. >> >> I think that happens anyway even when an application uses mainstream >> languages. Because it is poorly written. Or the author leaves. Or the >> vendor goes out of business. Or just withdraws support. > > Absolutely true. But when listing reasons for maintenance challenges, > using a language known to relatively few people adds another big reason, > as does using a language whose tools are from a single small supplier. > Using C, or Python is certainly no guarantee for maintainable code - but > using something like your scripting language is a guarantee for > /unmaintainable/ code. Application or implementation? In-house languages were not uncommon (from what I gathered as I never worked in such places). I think you're making too much of it. The advantages of something small and simple can offset some of the disadvantages of not using the same monster language that everyone else does. Like, being able to meet a deadline. And in the case of one of mine, there's a built-in translator to C, so problem solved. >> >>> Maybe it was good enough at the time - far from all software projects >>> are expected to last forever, or be maintained. But the reality is that >>> any use of a single-person or single-company language >> >> Or single-company product? > > That depends on the size and style of the company. If it is a small > company with a one-man language, then yes, it is a problem. If it is a > huge company with lots of people involved, then it is not a problem. > The day you are run over by a bus, then /everything/ ever written in > your script, and all your tools for it, are suddenly unmaintainable. > That is not the case for C#, Java, or whatever other single-company > mainstream language you care to think of. Even if it's open source? Note that I have never actually pushed for the take-up of any language of mine; I'm not interested as it's too much support work. Also current ones are experimental and frequently change. They are sometimes used to back up some argument or to illustrate an alternative way of doing something. Or to show how much a small language can do or how an open source app can be presented. But if no one wants to use one of my languages, I really don't care! It's just amusing how much of a meal something like Python makes of the simplest feature. >> Because, of course, relying on a monstrously large language, that can >> only be built with the help of dozens of complex tools and tens of >> thousands of lines of scripts, and that is too big and complex to be >> completely understood by any single individual, is /much/ better. > > Yes, it is. So if it's big and complex, it /has/ to be good. OK. And people know for sure that every single part of a big app is essential? Nothing is extraneous, nothing is bloat. OK. And that 30,000-line configuration needed to build it can't possibly do the whole job with only 29,000 lines. OK. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-02-17 11:22 +1300 |
| Message-ID | <fep3t0Fhu2iU6@mid.individual.net> |
| In reply to | #126811 |
On 02/17/2018 09:44 AM, bartc wrote: > On 16/02/2018 16:07, David Brown wrote: >> >> Absolutely true. But when listing reasons for maintenance challenges, >> using a language known to relatively few people adds another big reason, >> as does using a language whose tools are from a single small supplier. >> Using C, or Python is certainly no guarantee for maintainable code - but >> using something like your scripting language is a guarantee for >> /unmaintainable/ code. > > Application or implementation? > > In-house languages were not uncommon (from what I gathered as I never > worked in such places). Java started life as an in house language, there are other less well known languages (such as JADE) that also started out that way. As you say, there is nothing wrong with wrong with using in house languages, especially if they are domain specific (such as JADE). -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-02-16 17:48 +0000 |
| Message-ID | <87bmgo3jxk.fsf@bsb.me.uk> |
| In reply to | #126796 |
bartc <bc@freeuk.com> writes:
> On 16/02/2018 14:50, David Brown wrote:
>> On 16/02/18 13:57, bartc wrote:
>
>>> All developed 100% using my languages and compilers.
>>
>> And if your customers are left with code that is unmaintainable because
>> you have retired and there is no one else who can update or fix the code
>> (never mind the tools behind it), then they have bought a cat in a bag.
>
> I think that happens anyway even when an application uses mainstream languages. Because it is poorly written. Or the author leaves. Or the vendor goes out of business. Or just withdraws support.
>
>> Maybe it was good enough at the time - far from all software projects
>> are expected to last forever, or be maintained. But the reality is that
>> any use of a single-person or single-company language
>
> Or single-company product?
>
> Because, of course, relying on a monstrously large language, that can only be built with the help of dozens of complex tools and tens of thousands of lines of scripts, and that is too big and complex to be completely understood by any single individual, is /much/ better.
>
>> I am sure they have done real work. That does not stop them being
>> languages specifically designed to suit /you/, the way /you/ think, and
>> the problems /you/ are trying to solve. There is no contradiction there.
>
> They were designed to solve exactly the same problems that thousands of other people wanted to solve. But they relied on someone else's slow cumbersome tools badly ported from bigger computers.
>
> And I made a living from them which is what counts.
>
> Anyway, in the case of my own tools, then these days the main tools can be expressed in portable C that can work across C compilers, and across OSes, and can be trivially built by anyone on anything. They have been made publicly available from time to time, and include these one-file C source files:
>
> qcc64.c Script language byte-code compiler
> pcc64.c Script language byte-code interpreter
> mxa64.c x64 assembler
> mcc64.c C dialect compiler (which compiles all these)
>
> On the other hand, I haven't yet, myself, been able to build my own version of CPython for Windows.
>
> I've rarely seen any open source programs as simple, self-contained or as easy to build.
>
> As a bonus, qcc works at up to 1M lines per second, mxa at up to 4M, and mcc at over 0.5M, if you're interesting in programs that are nippy.
>
>>> So it is a language design issue: C has decided not to have simple
>>> line-based input built-in, and so has Python. Even though this was
>>> common in languages as far back as Fortran.
>>
>> C's features for text input are very low level, and very limited.
>
> How high level do you think that read statement is? I've already shown that 'read a' maps to:
>
> call _qreadi4
> mov [a],rax
>
> when a is a 32-bit signed int. How much lower can it be?
>
> _qreadi4 (which reads the next item from a line buffer) is little different from atoi().
>
>> Python's are high level and very flexible, but that means it is takes a
>> little more effort for this simple case.
>
> You can have high level, and still be able to read a few numbers from
> a line.
>
> The very first programming exercise I ever did, back in '76, involved
> first reading three numbers from the console. Then deciding if those
> numbers can form the sides of a triangle.
>
> Then, reading the numbers was the easy bit.
>
> These days it would be a more challenging exercise than the main
> problem!
The languages you used are probably still around.
> What's happened?
The main thing that happened (at least with C) is that the focus on
line-oriented input has gone. It was never really very important except
for the first three programs in the book that came with the computer
(those were the days) and for numerical tasks on matrices.
C's view is that if you need three numbers, you need three numbers so
if (scanf("%d%d%d", &a, &b, &c) == 3) {
....
}
is probably what you want. The kind of programs C was designed to write
don't usually say
$ grep
Enter the pattern and a file list all on one line: \w+
No, I need a pattern and a file list: ^C
$
You can do line-oriented input, but the focus was put somewhere else.
It would have been trivial to provide a lnscanf function that never read
past a newline, but for most people,
if (fgets(line, sizeof line, stdin) &&
sscanf(line, "%d%d%d", &a, &b, &c) == 3)
will do.
I've made the point before, but I think it's worth making again, that
there are usually trade-offs in these things. The languages with simple
line-oriented input will often struggle with other things. For example,
I'm not sure how to find out if Pascal's readln procedure actually got
the data it was asked to get.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2018-02-16 17:06 +0100 |
| Message-ID | <20180216170630.ea69ac811c84f94b952cf2bc@gmail.com> |
| In reply to | #126791 |
On Fri, 16 Feb 2018 15:50:29 +0100 David Brown <david.brown@hesbynett.no> wrote: > Real programming languages are made by groups - or at least one or two > language designers that talk to others. When you sit by yourself and > make your own language, you can be sure it is a language primarily for > /you/. No, real programming languages are implemented in conformance to the specification. A programming language doesn't need to be popular to be real, but only used to build a solution. > No, they usually start out as individual efforts or a collaboration of > two or three people. But they need a group effort and group input > before they have a chance of becoming popular - that needs to happen > before the details start getting too fixed. I favour programming > languages that are designed to fit the needs of many people, not just > one or his idea of what other people should be wanting. That does not > mean designed by committee, or maintained by committee, but it means a > collaborative effort. No, the programming language only needs to provide a convenient solution for some users. A collaborative effort is only needed to split the effort to reach the goal rapidly. If the goal is to merge several dialects into one (i.e. building a unique standard), then the working group needs a diversified expertize to find a consensus but it doesn't mean the working group can't be a unique person. > I have experience of using a language designed and implemented by one > person. When that one person's goals diverged from other users, the > language collapsed into oblivion. No, diverging goals won't break the accomplished work. > And if your customers are left with code that is unmaintainable > because you have retired and there is no one else who can update or > fix the code (never mind the tools behind it), then they have bought > a cat in a bag. Maybe it was good enough at the time - far from all > software projects are expected to last forever, or be maintained. > But the reality is that any use of a single-person or single-company > language has a far shorter shelf life than standard languages. It > might still be the right business decision, especially many years ago > when the alternative choices might not have been as good, and code > with source in a weird language is more maintainable than a > binary-only solution. Privative languages can provide a competitive advantage against standard solutions. Guess why people do programs in C# for Windows? It locks your users in your programming environment. AFAIK C# is still alive... > I am sure they have done real work. That does not stop them being > languages specifically designed to suit /you/, the way /you/ think, > and the problems /you/ are trying to solve. There is no > contradiction there. If his way met some user's need then it is his user's way too. You shouldn't be so jealous of his success... -- GOTHIER Nathan
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-02-17 11:10 +1300 |
| Message-ID | <fep36gFhu2iU5@mid.individual.net> |
| In reply to | #126788 |
On 02/17/2018 01:57 AM, bartc wrote: > > I gave an example before of where an older language of mine (one of > those involved above), statically typed like C, could do exactly this: > > int a,b,c,d,e,f > readln #file, a,b,c,d,e,f > > There is no reason why C couldn't do exactly the same. Then it could be > used for quick throwaway programs just as easily as any other language. Ah, so you approve of the way C++ does I/O :) -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-02-16 14:48 -0800 |
| Message-ID | <0c04c390-ed12-4844-95d4-1790cee90c33@googlegroups.com> |
| In reply to | #126788 |
On Friday, February 16, 2018 at 6:57:06 AM UTC-6, Bart wrote:
> I gave an example before of where an older language of mine (one of
> those involved above), statically typed like C, could do exactly this:
>
> int a,b,c,d,e,f
> readln #file, a,b,c,d,e,f
>
> There is no reason why C couldn't do exactly the same. Then it could be
> used for quick throwaway programs just as easily as any other language.
A compiler using a purpose-designed library could probably generate code
to handle variadic arguments that was type-safe while being, in many
typical scenarios, more compact than what a C compiler would generate.
Given something like
WriteLn('The values are x=', x, ' and y=', y, '.);
a compiler could generate code equivalent to:
{
char writeLnSpec8675309[] = {...};
WriteLn(writeLnSpec8675309);
}
where writeLnSpec8675309 would encode information about the types and
addresses of the objects to be printed as well as any format specifiers.
Such information could in many cases be more compact than the instructions
that would be needed to push the values in question onto the stack.
The biggest problem with such an approach would be defining a means of
indicating what things were passed that would promote compatibility among
different tools, and yet lead to efficient code. Having the first thing
in each argument spec be a pointer to a descriptor which contains a
table of functions to examine arguments would be good for compatibility,
but add extra overhead.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-02-16 15:14 -0800 |
| Message-ID | <lnsha0o7bu.fsf@kst-u.example.com> |
| In reply to | #126817 |
supercat@casperkitty.com writes:
> On Friday, February 16, 2018 at 6:57:06 AM UTC-6, Bart wrote:
>> I gave an example before of where an older language of mine (one of
>> those involved above), statically typed like C, could do exactly this:
>>
>> int a,b,c,d,e,f
>> readln #file, a,b,c,d,e,f
>>
>> There is no reason why C couldn't do exactly the same. Then it could be
>> used for quick throwaway programs just as easily as any other language.
>
> A compiler using a purpose-designed library could probably generate code
> to handle variadic arguments that was type-safe while being, in many
> typical scenarios, more compact than what a C compiler would generate.
> Given something like
>
> WriteLn('The values are x=', x, ' and y=', y, '.);
>
> a compiler could generate code equivalent to:
>
> {
> char writeLnSpec8675309[] = {...};
> WriteLn(writeLnSpec8675309);
> }
>
> where writeLnSpec8675309 would encode information about the types and
> addresses of the objects to be printed as well as any format specifiers.
> Such information could in many cases be more compact than the instructions
> that would be needed to push the values in question onto the stack.
Perhaps -- but what if you want more than one way to format a value of a
given type?
C provides multiple ways to format integer values on output. You can
control the base, field width, leading zeros, etc. The cost is a lack
of type safety (though compilers can do some checking *if* the format
string is a literal).
C++ is simpler for simple cases, but the standard way to change how
values are formatted changes the state of the output stream. Print one
integer in hexadecimal, and all following integers are printed in
hexadecimal unless you explicitly reset the state.
I have some vague thoughts about better approaches, but they wouldn't be
topical.
> The biggest problem with such an approach would be defining a means of
> indicating what things were passed that would promote compatibility among
> different tools, and yet lead to efficient code. Having the first thing
> in each argument spec be a pointer to a descriptor which contains a
> table of functions to examine arguments would be good for compatibility,
> but add extra overhead.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-02-16 23:25 +0000 |
| Message-ID | <87eflk1pq7.fsf@bsb.me.uk> |
| In reply to | #126818 |
Keith Thompson <kst-u@mib.org> writes: <snip> > C provides multiple ways to format integer values on output. You can > control the base, field width, leading zeros, etc. The cost is a lack > of type safety (though compilers can do some checking *if* the format > string is a literal). > > C++ is simpler for simple cases, but the standard way to change how > values are formatted changes the state of the output stream. Print one > integer in hexadecimal, and all following integers are printed in > hexadecimal unless you explicitly reset the state. > > I have some vague thoughts about better approaches, but they wouldn't be > topical. There's an interesting book about programming language design that makes the claim that you can evaluate any design by how flexible an input/output mechanism can be written in the language itself. (I forget the details, but if anyone is interested I can probably find it somewhere.) <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-02-16 15:50 -0800 |
| Message-ID | <f0d38dc0-d8b3-441e-ba0e-df4bbdd3d6d1@googlegroups.com> |
| In reply to | #126818 |
On Friday, February 16, 2018 at 5:15:00 PM UTC-6, Keith Thompson wrote:
> supercat@casperkitty.com writes:
> > Given something like
> >
> > WriteLn('The values are x=', x, ' and y=', y, '.);
> >
> > a compiler could generate code equivalent to:
> >
> > {
> > char writeLnSpec8675309[] = {...};
> > WriteLn(writeLnSpec8675309);
> > }
> >
> > where writeLnSpec8675309 would encode information about the types and
> > addresses of the objects to be printed as well as any format specifiers.
> > Such information could in many cases be more compact than the instructions
> > that would be needed to push the values in question onto the stack.
>
> Perhaps -- but what if you want more than one way to format a value of a
> given type?
One could use Pascal-style syntax, which allows sub-arguments to be attached
with colons. Information about passed arguments could then report the
difference between WriteLn(Foo, Bar); and WriteLn(Foo:Bar);. Or one could
use a format string with format specifiers, but use compiler-supplied info
about argument types to ensure any required conversions get performed.
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2018-02-16 07:19 -0800 |
| Message-ID | <2a20e699-4f48-44a6-b19e-d5f3154c1d7b@googlegroups.com> |
| In reply to | #126729 |
On Thursday, February 15, 2018 at 4:58:29 PM UTC+2, David Brown wrote:
> On 15/02/18 15:16, Malcolm McLean wrote:
> > On Thursday, February 15, 2018 at 10:04:15 AM UTC, David Brown wrote:
> >> On 14/02/18 23:51, Ben Bacarisse wrote:
> >>> G B <gb@gb.com> writes:
> >>>
> >>>> If you have a text file of numbers, what is the best way to read
> >>>> numbers line by line and do some tests on numbers for that line before
> >>>> moving to the next line?
> >>>
> >>> You've had some C answers but I'd raise another question -- why C?
> >>
> >> You beat me to it. C is a fine language for some tasks, but certainly
> >> not for everything.
> >>
> > It's often easier to write something in a high level scripting language
> > rather than C. However typically programs are less useful in that form -
> > a file written in a conservative subset of ANSI C89 is usable
> > practically anywhere that native code can be run. A script is not
> > so easy to run on a different platform, or to integrate into a larger
> > system.
> >
>
> Suppose, for example, these numbers are in a file "test.txt" and you
> want to find the sum of the numbers on each line. In Python, this can
> be done as:
>
> for ln in file("test.txt").readlines() :
> nums = [int(x) for x in ln.split()]
> print(sums(nums))
>
Something is missing here.
First, I had to add first line:
#!/usr/bin/python
Otherwise my shell had no idea what to do with it.
But even after that it says:
Traceback (most recent call last):
File "./uu0.py", line 3, in <module>
for ln in file("test.txt").readlines() :
NameError: name 'file' is not defined
So, I changed it into less geeky form:
#!/usr/bin/python
file = open("test.txt");
for ln in file.readlines() :
nums = [int(x) for x in ln.split()]
print(sums(nums))
Now I got:
Traceback (most recent call last):
File "./uu1.py", line 6, in <module>
print(sums(nums))
NameError: name 'sums' is not defined
O.k. Supposedly a spelling mistake. Changed sums to sum.
No it does what it is supposedly supposed to do when the input file is here and consists of decimal numbers and of nothing else.
But when the file is not here or when it contains more than just decimal number
then I got an error message that could be useful for me at time when I an developing the script. Bu it would be incomprehensive for somebody else the want to use my script. Or even for me next week.
So, result is not good enough for shipping.
I am sure that it is possible to make python error reports more friendly for my imaginary user: a person that knows what is a text file and how to edit it with text editor, but has absolutely no desire to become python programmer or even to know what programming language was used to develop the utility.
But the resulting python script will look MUCH more similar to 'C' program that achieves the same objectives than to you python example. In fact, if I want an exact location of the problematic point in input file as a part of error message (and I almost certainly do want such info if the input is expected to be large) then quite possibly a python version would be *harder* to code than C version.
> That is all you need. No faffing about with fgets, or which strtol
> function to use. No worrying about sizes, overflows, or how big your
> buffers should be. No concerns about line endings, or if the file uses
> tabs or spaces. No worries about whether MS in their infinite wisdom
> have decided to deprecate the C standard library functions you want to
> use, so that you have to figure out different compiler switches to use.
When MS deprecate something, the code still compiles and links and runs. It just produces a warning.
>
> It is not going to work in a little embedded system - but you don't do
> this kind of task on a little embedded system. It is not going to work
> on a PC from 1999, before Python 2 came out - but this is 2018, not 1999.
>
One of reasons that perl is widely used in *nix world to do tasks for which python would be better fit from technical perspective, is that until quite recently developers could not rely on ubiquitous presence of python.
> This kind of script /is/ easy to run on almost every platform. The
> exception to ease-of-use is, as always, Windows - but it is still /far/
> easier to run a Python script on Windows than to deal with a C compiler.
You are looking at it from the perspective of developer=user. When user and developer are not the same then [in the Windows world] a self-contained exe have a very significant practical edge. In fact, from that perspective it has a solid edge not only over python scripts but even over powershell script, despite the fact that by now dev *can* rely on the presence of powershell.
>
> Python has not replaced C as the sensible choice of language for
> manipulating text files like this - it replaced Perl, awk and TCL which
> had already replaced C decades ago.
perl -certainly. But not awk or TCL. TCL had and still has different niche as embedded script engine. From technical perspective it should be replaced by Lua in most places, but it's not happening.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-02-16 17:13 +0100 |
| Message-ID | <p67000$hue$1@dont-email.me> |
| In reply to | #126793 |
(If you are going to post in a programming newsgroup, then /please/ get
yourself a proper newsreader, or learn to limit line lengths with google
groups!)
On 16/02/18 16:19, already5chosen@yahoo.com wrote:
> On Thursday, February 15, 2018 at 4:58:29 PM UTC+2, David Brown wrote:
>> On 15/02/18 15:16, Malcolm McLean wrote:
>>> On Thursday, February 15, 2018 at 10:04:15 AM UTC, David Brown wrote:
>>>> On 14/02/18 23:51, Ben Bacarisse wrote:
>>>>> G B <gb@gb.com> writes:
>>>>>
>>>>>> If you have a text file of numbers, what is the best way to read
>>>>>> numbers line by line and do some tests on numbers for that line before
>>>>>> moving to the next line?
>>>>>
>>>>> You've had some C answers but I'd raise another question -- why C?
>>>>
>>>> You beat me to it. C is a fine language for some tasks, but certainly
>>>> not for everything.
>>>>
>>> It's often easier to write something in a high level scripting language
>>> rather than C. However typically programs are less useful in that form -
>>> a file written in a conservative subset of ANSI C89 is usable
>>> practically anywhere that native code can be run. A script is not
>>> so easy to run on a different platform, or to integrate into a larger
>>> system.
>>>
>>
>> Suppose, for example, these numbers are in a file "test.txt" and you
>> want to find the sum of the numbers on each line. In Python, this can
>> be done as:
>>
>> for ln in file("test.txt").readlines() :
>> nums = [int(x) for x in ln.split()]
>> print(sums(nums))
>>
>
> Something is missing here.
> First, I had to add first line:
> #!/usr/bin/python
>
> Otherwise my shell had no idea what to do with it.
I intentionally did not add that, because I was testing with python2.7,
python3.5, and pypy.
> But even after that it says:
> Traceback (most recent call last):
> File "./uu0.py", line 3, in <module>
> for ln in file("test.txt").readlines() :
> NameError: name 'file' is not defined
>
Yes, it turns out that Python 3 does not allow that form - you need
"open" instead of "file". See my other posts.
> So, I changed it into less geeky form:
>
> #!/usr/bin/python
>
> file = open("test.txt");
> for ln in file.readlines() :
> nums = [int(x) for x in ln.split()]
> print(sums(nums))
>
> Now I got:
> Traceback (most recent call last):
> File "./uu1.py", line 6, in <module>
> print(sums(nums))
> NameError: name 'sums' is not defined
And see my other posts for the typo fix.
(Try a real newsreader rather than google groups - it will save you
replying to old posts.)
>
> O.k. Supposedly a spelling mistake. Changed sums to sum.
> No it does what it is supposedly supposed to do when the input file
> is here and consists of decimal numbers and of nothing else.
>
> But when the file is not here or when it contains more than just decimal number
> then I got an error message that could be useful for me at time when
> I an developing the script. Bu it would be incomprehensive for somebody
> else the want to use my script. Or even for me next week.
> So, result is not good enough for shipping.
We have no idea what the actual problem is - so no way of telling how
much error checking or flexibility is needed.
(I've snipped the rest - your overlong lines are too time-consuming to fix.)
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2018-02-19 17:55 +0000 |
| Message-ID | <slrnp8m3t3.eu5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #126801 |
On Fri, 2018-02-16, David Brown wrote:
...
> On 16/02/18 16:19, already5chosen@yahoo.com wrote:
...
>> Something is missing here.
>> First, I had to add first line:
>> #!/usr/bin/python
>>
>> Otherwise my shell had no idea what to do with it.
>
> I intentionally did not add that, because I was testing with python2.7,
> python3.5, and pypy.
>
>> But even after that it says:
>> Traceback (most recent call last):
>> File "./uu0.py", line 3, in <module>
>> for ln in file("test.txt").readlines() :
>> NameError: name 'file' is not defined
>
> Yes, it turns out that Python 3 does not allow that form - you need
> "open" instead of "file". See my other posts.
Something weird is going on if he/she uses /usr/bin/python, and that
means Python 3.x. At least the Linux camp decided some time back that
/usr/bin/python means Python 2.x, forever. Arch Linux gets (or used
to get) this wrong, though.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-02-19 19:14 +0100 |
| Message-ID | <p6f473$1ue$1@dont-email.me> |
| In reply to | #126854 |
On 19/02/18 18:55, Jorgen Grahn wrote:
> On Fri, 2018-02-16, David Brown wrote:
> ...
>> On 16/02/18 16:19, already5chosen@yahoo.com wrote:
> ...
>>> Something is missing here.
>>> First, I had to add first line:
>>> #!/usr/bin/python
>>>
>>> Otherwise my shell had no idea what to do with it.
>>
>> I intentionally did not add that, because I was testing with python2.7,
>> python3.5, and pypy.
>>
>>> But even after that it says:
>>> Traceback (most recent call last):
>>> File "./uu0.py", line 3, in <module>
>>> for ln in file("test.txt").readlines() :
>>> NameError: name 'file' is not defined
>>
>> Yes, it turns out that Python 3 does not allow that form - you need
>> "open" instead of "file". See my other posts.
>
> Something weird is going on if he/she uses /usr/bin/python, and that
> means Python 3.x. At least the Linux camp decided some time back that
> /usr/bin/python means Python 2.x, forever. Arch Linux gets (or used
> to get) this wrong, though.
>
If I run my code with "python2 a.py", it uses Python 2 - if I run it
with "python3 a.py", it uses Python 3. I happen to have Python 2.7 and
Python 3.5 on this system, with 2.7 being the default for plain
"python". But it is all just symbolic links, and I could pick Python
3.5 as the default if I wanted. I think most Linux distros have a
Python 2 version by default for "/usr/bin/python", but distros are free
to make their own decisions, and users are free to override those.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-02-19 11:48 -0800 |
| Message-ID | <lnh8qcoj63.fsf@kst-u.example.com> |
| In reply to | #126854 |
Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
[...]
> Something weird is going on if he/she uses /usr/bin/python, and that
> means Python 3.x. At least the Linux camp decided some time back that
> /usr/bin/python means Python 2.x, forever. Arch Linux gets (or used
> to get) this wrong, though.
Whether /usr/bin/python should be Python 2 or Python 3 is a matter of
some debate -- one that I suggest should not take place here in
comp.lang.c.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
Page 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web