Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #72539 > unrolled thread
| Started by | Sturla Molden <sturla.molden@gmail.com> |
|---|---|
| First post | 2014-06-03 17:28 +0000 |
| Last post | 2014-06-08 13:09 +1200 |
| Articles | 20 on this page of 132 — 27 participants |
Back to article view | Back to comp.lang.python
OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-03 17:28 +0000
Re: OT: This Swift thing Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-06-05 10:14 +0200
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-05 18:38 +1000
Re: OT: This Swift thing Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-06-05 11:42 +0200
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-05 22:48 +1000
Re: OT: This Swift thing Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-06-05 22:27 +0200
Re: OT: This Swift thing Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-06-05 22:28 +0100
Re: OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-05 23:03 +0000
Re: OT: This Swift thing Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-06-06 13:21 +0200
Re: OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-07 01:54 +0000
Re: OT: This Swift thing Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-06-07 10:20 +0200
Re: OT: This Swift thing Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-06-07 09:32 +0100
Re: OT: This Swift thing Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-06-07 11:54 +0200
Re: OT: This Swift thing Johannes Bauer <dfnsonfsduifb@gmx.de> - 2014-06-15 10:55 +0200
Re: OT: This Swift thing Roy Smith <roy@panix.com> - 2014-06-07 08:52 -0400
Re: OT: This Swift thing Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-06-07 11:13 -0400
Re: OT: This Swift thing Roy Smith <roy@panix.com> - 2014-06-07 11:54 -0400
Re: OT: This Swift thing Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-06-07 17:10 -0400
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-07 23:32 +0000
Re: OT: This Swift thing Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-06-06 00:41 +0100
Re: OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-06 01:54 +0200
Re: OT: This Swift thing Roy Smith <roy@panix.com> - 2014-06-05 20:13 -0400
Re: OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-06 02:35 +0200
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-06 05:45 +0000
Re: OT: This Swift thing Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-06-06 13:39 +0200
Re: OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-07 01:54 +0000
Re: OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-06 02:03 +0200
Re: OT: This Swift thing wxjmfauth@gmail.com - 2014-06-05 02:09 -0700
Re: OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-05 16:10 +0200
Re: OT: This Swift thing Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-06-05 22:07 +0200
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-06 06:18 +1000
Re: OT: This Swift thing Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-06-05 23:12 +0200
Re: OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-05 23:02 +0000
Re: OT: This Swift thing Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-06-05 22:23 +0100
Re: OT: This Swift thing Marko Rauhamaa <marko@pacujo.net> - 2014-06-06 00:53 +0300
Re: OT: This Swift thing Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-06-05 23:13 +0100
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-06 02:52 +0000
Re: OT: This Swift thing Johannes Bauer <dfnsonfsduifb@gmx.de> - 2014-06-15 11:33 +0200
Re: OT: This Swift thing Marko Rauhamaa <marko@pacujo.net> - 2014-06-15 16:10 +0300
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-06 07:36 +1000
Re: OT: This Swift thing Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-06-06 13:20 +0200
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-06 22:23 +1000
Re: OT: This Swift thing Christian Gollwitzer <auriocus@gmx.de> - 2014-06-07 09:30 +0200
Re: OT: This Swift thing Terry Reedy <tjreedy@udel.edu> - 2014-06-05 18:18 -0400
Re: OT: This Swift thing Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-06-06 13:11 +0200
Re: OT: This Swift thing Terry Reedy <tjreedy@udel.edu> - 2014-06-06 13:06 -0400
Re: OT: This Swift thing alex23 <wuwei23@gmail.com> - 2014-06-10 15:32 +1000
Re: OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-05 23:02 +0000
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-05 23:08 +0000
Re: OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-05 23:08 +0000
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-06 09:21 +1000
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-06 03:16 +0000
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-06 13:27 +1000
Re: OT: This Swift thing Michael Torrie <torriem@gmail.com> - 2014-06-05 08:33 -0600
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-06 01:44 +1000
Re: OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-05 18:09 +0200
Re: OT: This Swift thing Michael Torrie <torriem@gmail.com> - 2014-06-05 11:18 -0600
Re: OT: This Swift thing Mark H Harris <harrismh777@gmail.com> - 2014-06-05 13:49 -0500
Re: OT: This Swift thing Travis Griggs <travisgriggs@gmail.com> - 2014-06-05 23:28 -0700
Re: OT: This Swift thing Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-06-06 10:25 +0200
Re: OT: This Swift thing Michael Torrie <torriem@gmail.com> - 2014-06-06 20:41 -0600
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-07 04:57 +0000
Re: OT: This Swift thing Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-06-07 11:23 -0400
Re: OT: This Swift thing Roy Smith <roy@panix.com> - 2014-06-07 11:51 -0400
Re: OT: This Swift thing Marko Rauhamaa <marko@pacujo.net> - 2014-06-07 19:18 +0300
Re: OT: This Swift thing MRAB <python@mrabarnett.plus.com> - 2014-06-08 15:10 +0100
Re: OT: This Swift thing Michael Torrie <torriem@gmail.com> - 2014-06-07 11:37 -0600
Re: OT: This Swift thing Roy Smith <roy@panix.com> - 2014-06-07 14:11 -0400
Re: OT: This Swift thing Michael Torrie <torriem@gmail.com> - 2014-06-07 13:00 -0600
Re: OT: This Swift thing Roy Smith <roy@panix.com> - 2014-06-07 15:11 -0400
Re: OT: This Swift thing Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-06-07 17:59 -0400
Re: OT: This Swift thing Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-06-08 13:25 +1200
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-07 23:38 +0000
Re: OT: This Swift thing Roy Smith <roy@panix.com> - 2014-06-07 20:09 -0400
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-08 10:37 +1000
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-08 03:50 +0000
Re: OT: This Swift thing Roy Smith <roy@panix.com> - 2014-06-08 10:51 -0400
Re: OT: This Swift thing Gene Heskett <gheskett@wdtv.com> - 2014-06-08 11:21 -0400
Re: OT: This Swift thing Roy Smith <roy@panix.com> - 2014-06-08 12:09 -0400
Re: OT: This Swift thing Gene Heskett <gheskett@wdtv.com> - 2014-06-08 13:14 -0400
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-09 03:25 +1000
Re: OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-08 18:09 +0000
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-09 04:16 +1000
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-09 01:44 +0000
Re: OT: This Swift thing Rustom Mody <rustompmody@gmail.com> - 2014-06-08 19:24 -0700
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-09 04:20 +0000
Re: OT: This Swift thing Rustom Mody <rustompmody@gmail.com> - 2014-06-08 23:32 -0700
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-09 09:27 +0000
Re: OT: This Swift thing Rustom Mody <rustompmody@gmail.com> - 2014-06-09 04:51 -0700
Re: OT: This Swift thing Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-06-11 19:41 +1200
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-11 13:44 +0000
Re: OT: This Swift thing Rustom Mody <rustompmody@gmail.com> - 2014-06-11 08:28 -0700
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-12 02:08 +0000
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-12 12:16 +1000
Re: OT: This Swift thing Steven D'Aprano <steve@pearwood.info> - 2014-06-12 09:06 +0000
Re: OT: This Swift thing alister <alister.nospam.ware@ntlworld.com> - 2014-06-12 09:34 +0000
Re: OT: This Swift thing Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-06-12 23:32 +1200
Re: OT: This Swift thing Anssi Saari <as@sci.fi> - 2014-06-16 13:57 +0300
Re: OT: This Swift thing Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-06-17 10:12 +1200
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-17 08:34 +1000
Re: OT: This Swift thing alister <alister.nospam.ware@ntlworld.com> - 2014-06-17 11:16 +0000
Re: OT: This Swift thing Bob Martin <bob.martin@excite.com> - 2014-06-18 07:41 +0100
Re: OT: This Swift thing Rustom Mody <rustompmody@gmail.com> - 2014-06-12 05:54 -0700
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-12 17:04 +0000
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-13 03:18 +1000
Re: OT: This Swift thing Rustom Mody <rustompmody@gmail.com> - 2014-06-12 18:59 -0700
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-13 03:26 +0000
Re: OT: This Swift thing Gene Heskett <gheskett@wdtv.com> - 2014-06-12 14:43 -0400
Re: OT: This Swift thing albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-27 23:21 +0000
Re: OT: This Swift thing Joshua Landau <joshua@landau.ws> - 2014-06-15 02:51 +0100
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-15 03:33 +0000
Re: OT: This Swift thing Gene Heskett <gheskett@wdtv.com> - 2014-06-09 10:11 -0400
Re: OT: This Swift thing Marko Rauhamaa <marko@pacujo.net> - 2014-06-09 17:27 +0300
Re: OT: This Swift thing Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-06-11 18:56 +1200
Re: OT: This Swift thing Roy Smith <roy@panix.com> - 2014-06-09 09:14 -0400
Re: OT: This Swift thing Michael Torrie <torriem@gmail.com> - 2014-06-09 07:56 -0600
Re: OT: This Swift thing Marko Rauhamaa <marko@pacujo.net> - 2014-06-09 17:30 +0300
Re: OT: This Swift thing Rustom Mody <rustompmody@gmail.com> - 2014-06-08 19:35 -0700
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-09 12:23 +1000
Re: OT: This Swift thing Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-06-11 19:50 +1200
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-11 12:34 +0000
Re: OT: This Swift thing Roy Smith <roy@panix.com> - 2014-06-11 08:48 -0400
Re: OT: This Swift thing Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-06-11 20:17 -0400
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-12 01:25 +0000
Re: OT: This Swift thing Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-06-12 14:11 +1200
Re: OT: This Swift thing Gene Heskett <gheskett@wdtv.com> - 2014-06-11 23:06 -0400
Re: OT: This Swift thing Roy Smith <roy@panix.com> - 2014-06-13 08:55 -0400
Re: OT: This Swift thing Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-06-09 21:51 -0400
Re: OT: This Swift thing Carlos Anselmo Dias <carlos@premium-sponsor.com> - 2014-06-08 18:56 +0100
Re: OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-08 23:34 +0000
Re: OT: This Swift thing Rustom Mody <rustompmody@gmail.com> - 2014-06-08 19:32 -0700
Re: OT: This Swift thing Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-06-08 13:09 +1200
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
| From | Michael Torrie <torriem@gmail.com> |
|---|---|
| Date | 2014-06-06 20:41 -0600 |
| Message-ID | <mailman.10844.1402108877.18130.python-list@python.org> |
| In reply to | #72690 |
On 06/06/2014 12:28 AM, Travis Griggs wrote: > > >> On Jun 5, 2014, at 1:14, Alain Ketterlin >> <alain@dpt-info.u-strasbg.fr> wrote: >> >> Swift's memory management is similar to python's (ref. counting). >> Which makes me think that a subset of python with the same type >> safety would be an instant success. > > Except that while you don't need to regularly worry about cycles in > python, you do in swift. Which means you get to think constantly > about direct and indirect cycles, figure out where to put weak stuff, > when to use a local to keep a weak property alive until it finds it's > strong home, etc. Swift's reference counting seems to be fairly close to Objective C's, which makes sense since the classes can be used directly in Swift. Seems to me that Swift is just Objective C with some syntactic sugar and a nicer syntax. That's why I said it was a little odd to be comparing Swift to Python, or at least to be claiming Apple should have made Python it's core language.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-06-07 04:57 +0000 |
| Message-ID | <53929baf$0$29988$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #72898 |
On Fri, 06 Jun 2014 20:41:09 -0600, Michael Torrie wrote: > On 06/06/2014 12:28 AM, Travis Griggs wrote: >> >> >>> On Jun 5, 2014, at 1:14, Alain Ketterlin <alain@dpt-info.u-strasbg.fr> >>> wrote: >>> >>> Swift's memory management is similar to python's (ref. counting). >>> Which makes me think that a subset of python with the same type safety >>> would be an instant success. >> >> Except that while you don't need to regularly worry about cycles in >> python, you do in swift. Which means you get to think constantly about >> direct and indirect cycles, figure out where to put weak stuff, when to >> use a local to keep a weak property alive until it finds it's strong >> home, etc. > > Swift's reference counting seems to be fairly close to Objective C's, > which makes sense since the classes can be used directly in Swift. Seems > to me that Swift is just Objective C with some syntactic sugar and a > nicer syntax. That's why I said it was a little odd to be comparing > Swift to Python, or at least to be claiming Apple should have made > Python it's core language. A "little" odd? It's utterly astonishing! Swift is not in the same family of languages as Python, Perl, Javascript, Ruby, Applescript, etc. I'll call them "scripting languages", but I don't mean that as a put-down. I just mean that they are intended for rapid development, they are dynamically typed, lightweight, and typically aren't expected to compile directly to machine code. Swift is intended as a new generation *systems language*. The old generation of systems languages are things like C, Objective-C, C#, C++, Java, Pascal, Algol, and so forth. The new generation are intended to fulfil the same niches, but to have syntax and usability closer to that of scripting languages. Languages like Go, Rust, Ceylon, and now Swift. We're starting to see the distinction between systems and scripting languages blurred even more than it used to be. These smart, lightweight but powerful systems languages are likely to be a big challenge to scripting languages like Python and Ruby in the coming decades. If you had a language as easy to use and as safe as Python, but as efficient as C, why wouldn't you use it? It is naive to expect Apple to have made Python it's core language. Apple's core language is Objective-C, and if they were going to pick a core scripting language (other than Applescript, which exists in a different ecological niche) it would have been Ruby, not Python. Ruby's fundamental model is very similar to Objective-C, Python's is not. Apple already developed a version of Ruby, "MacRuby", which was designed to call directly into the Objective-C APIs without an intermediate interface layer, but they have abandoned that to focus on Swift. (Besides, Apple is unlikely to commit to a core language being something they don't control.) -- Steven D'Aprano http://import-that.dreamwidth.org/
[toc] | [prev] | [next] | [standalone]
| From | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Date | 2014-06-07 11:23 -0400 |
| Message-ID | <mailman.10852.1402154644.18130.python-list@python.org> |
| In reply to | #72901 |
On 07 Jun 2014 04:57:19 GMT, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> declaimed the following:
>
>Swift is intended as a new generation *systems language*. The old
>generation of systems languages are things like C, Objective-C, C#, C++,
>Java, Pascal, Algol, and so forth. The new generation are intended to
>fulfil the same niches, but to have syntax and usability closer to that
>of scripting languages. Languages like Go, Rust, Ceylon, and now Swift.
>
Pascal as a systems language? We must have major differences what
constitutes a systems language then...
Native Pascal had no features to support hitting the hardware or
arbitrary memory addresses/registers. It was a candidate for an
applications language (though even that always felt a stretch to me; as a
teaching language for structured programming it was ideal, though). Try
writing a serial port driver for a memory mapped I/O system using pure
Pascal.
I'll even put Java and C# into that category, though they may have
escape routes to hardware -- I don't have that exposure.
Ada, OTOH, was built for such...
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
[toc] | [prev] | [next] | [standalone]
| From | Roy Smith <roy@panix.com> |
|---|---|
| Date | 2014-06-07 11:51 -0400 |
| Message-ID | <roy-1E6B93.11513507062014@news.panix.com> |
| In reply to | #72915 |
In article <mailman.10852.1402154644.18130.python-list@python.org>, Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote: > On 07 Jun 2014 04:57:19 GMT, Steven D'Aprano > <steve+comp.lang.python@pearwood.info> declaimed the following: > > > > >Swift is intended as a new generation *systems language*. The old > >generation of systems languages are things like C, Objective-C, C#, C++, > >Java, Pascal, Algol, and so forth. The new generation are intended to > >fulfil the same niches, but to have syntax and usability closer to that > >of scripting languages. Languages like Go, Rust, Ceylon, and now Swift. > > > Pascal as a systems language? We must have major differences what > constitutes a systems language then... The original MacOS was written in Pascal (both applications and kernel). Being able to touch memory locations or registers requires no more than a few short glue routines written in assembler.
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2014-06-07 19:18 +0300 |
| Message-ID | <87egz04rrs.fsf@elektro.pacujo.net> |
| In reply to | #72916 |
Roy Smith <roy@panix.com>: > The original MacOS was written in Pascal (both applications and > kernel). Being able to touch memory locations or registers requires no > more than a few short glue routines written in assembler. Pascal is essentially equivalent to C, except Pascal has a cleaner syntax. I like the fact that the semicolon is a separator. Also, the variable declaration syntax is done more smartly in Pascal. And the pointer/array confusion in C is silly. Marko
[toc] | [prev] | [next] | [standalone]
| From | MRAB <python@mrabarnett.plus.com> |
|---|---|
| Date | 2014-06-08 15:10 +0100 |
| Message-ID | <mailman.10877.1402236658.18130.python-list@python.org> |
| In reply to | #72954 |
On 2014-06-07 17:18, Marko Rauhamaa wrote: > Roy Smith <roy@panix.com>: > >> The original MacOS was written in Pascal (both applications and >> kernel). Being able to touch memory locations or registers requires no >> more than a few short glue routines written in assembler. > > Pascal is essentially equivalent to C, except Pascal has a cleaner > syntax. I like the fact that the semicolon is a separator. Also, the > variable declaration syntax is done more smartly in Pascal. And the > pointer/array confusion in C is silly. > I also like the fact that the semicolon is a separator, but, in practice, misplaced semicolons can cause problems, so languages descended of Pascal prefer to have explicit terminators.
[toc] | [prev] | [next] | [standalone]
| From | Michael Torrie <torriem@gmail.com> |
|---|---|
| Date | 2014-06-07 11:37 -0600 |
| Message-ID | <mailman.10853.1402162690.18130.python-list@python.org> |
| In reply to | #72901 |
On 06/07/2014 09:23 AM, Dennis Lee Bieber wrote: > On 07 Jun 2014 04:57:19 GMT, Steven D'Aprano > <steve+comp.lang.python@pearwood.info> declaimed the following: > >> >> Swift is intended as a new generation *systems language*. The old >> generation of systems languages are things like C, Objective-C, C#, C++, >> Java, Pascal, Algol, and so forth. The new generation are intended to >> fulfil the same niches, but to have syntax and usability closer to that >> of scripting languages. Languages like Go, Rust, Ceylon, and now Swift. >> > Pascal as a systems language? We must have major differences what > constitutes a systems language then... > > Native Pascal had no features to support hitting the hardware or > arbitrary memory addresses/registers. It was a candidate for an > applications language (though even that always felt a stretch to me; as a > teaching language for structured programming it was ideal, though). Try > writing a serial port driver for a memory mapped I/O system using pure > Pascal. Technically C doesn't either, except via subroutines in libc, though C does have pointers which would be used to access memory. In the old MS DOS days, C would embed assembly to call interrupts and set up interrupt tables, etc. As someone else mentioned recently, Pascal was used as the system language on Mac computers for many years.
[toc] | [prev] | [next] | [standalone]
| From | Roy Smith <roy@panix.com> |
|---|---|
| Date | 2014-06-07 14:11 -0400 |
| Message-ID | <roy-5B56FD.14112707062014@news.panix.com> |
| In reply to | #72919 |
In article <mailman.10853.1402162690.18130.python-list@python.org>, Michael Torrie <torriem@gmail.com> wrote: > Technically C doesn't [have features to support hitting the hardware] > either, except via subroutines in libc, though C does have pointers > which would be used to access memory. Several language constructs in C are there specifically to diddle bits in hardware. Bit fields were in the earliest implementations of the language to allow you to address individual bit control and status bits in memory-mapped device controllers. The volatile keyword is there to deal with bits which change value on their own (as hardware status registers do). And, why do you need a library routine to touch a memory location, when you can just dereference an integer? :-)
[toc] | [prev] | [next] | [standalone]
| From | Michael Torrie <torriem@gmail.com> |
|---|---|
| Date | 2014-06-07 13:00 -0600 |
| Message-ID | <mailman.10857.1402167635.18130.python-list@python.org> |
| In reply to | #72923 |
On 06/07/2014 12:11 PM, Roy Smith wrote: > Several language constructs in C are there specifically to diddle bits > in hardware. Bit fields were in the earliest implementations of the > language to allow you to address individual bit control and status bits > in memory-mapped device controllers. The volatile keyword is there to > deal with bits which change value on their own (as hardware status > registers do). > > And, why do you need a library routine to touch a memory location, when > you can just dereference an integer? :-) Which of course, technically, Pascal has too. But memory addressing is only half the story. You still need interrupts and ioctl access, both of which happen via assembly instructions that libc exposes via a standard C subroutine interface. Really any language can access hardware this way. Whether it's MicroPython on an embedded system, or BASIC on a pic. The lines are being blurred.
[toc] | [prev] | [next] | [standalone]
| From | Roy Smith <roy@panix.com> |
|---|---|
| Date | 2014-06-07 15:11 -0400 |
| Message-ID | <roy-81C7BE.15113007062014@news.panix.com> |
| In reply to | #72925 |
In article <mailman.10857.1402167635.18130.python-list@python.org>, Michael Torrie <torriem@gmail.com> wrote: > On 06/07/2014 12:11 PM, Roy Smith wrote: > > Several language constructs in C are there specifically to diddle bits > > in hardware. Bit fields were in the earliest implementations of the > > language to allow you to address individual bit control and status bits > > in memory-mapped device controllers. The volatile keyword is there to > > deal with bits which change value on their own (as hardware status > > registers do). > > > > And, why do you need a library routine to touch a memory location, when > > you can just dereference an integer? :-) > > Which of course, technically, Pascal has too. > > But memory addressing is only half the story. You still need interrupts > and ioctl access, both of which happen via assembly instructions that > libc exposes via a standard C subroutine interface. Well, on a machine where all I/O is memory mapped, it's really 3/4 of the story, but I get your point.
[toc] | [prev] | [next] | [standalone]
| From | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Date | 2014-06-07 17:59 -0400 |
| Message-ID | <mailman.10863.1402178382.18130.python-list@python.org> |
| In reply to | #72923 |
On Sat, 07 Jun 2014 13:00:24 -0600, Michael Torrie <torriem@gmail.com>
declaimed the following:
>
>Which of course, technically, Pascal has too.
>
Not "standard" Pascal... It had pointer types, but no means to "stuff"
an integer into the pointer variable in order to dereference it as a memory
address...
>But memory addressing is only half the story. You still need interrupts
>and ioctl access, both of which happen via assembly instructions that
>libc exposes via a standard C subroutine interface.
>
I/O interrupts is a level above the "driver" example I spoke of... I'm
talking a true low-level "test status register, if data ready, copy data
register, clear status register, return data to caller"...
ioctl() is an OS abstraction mechanism to provide a standardized means
for applications to provide uncommon parameters to an I/O driver... Heck,
/libc/ is above the level of code I'm defining. What is an interrupt --
typically a handler (function) address stored in a fixed location used by
the CPU when an external hardware signal goes high... Nothing prevents one
from writing that handler in C and using C's various casting operations to
stuff it into the vector memory.
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2014-06-08 13:25 +1200 |
| Message-ID | <bvhsbjF2on9U1@mid.individual.net> |
| In reply to | #72932 |
Dennis Lee Bieber wrote: > Not "standard" Pascal... It had pointer types, but no means to "stuff" > an integer into the pointer variable in order to dereference it as a memory > address... Although most implementations would let you get the same effect by abusing variant records (the equivalent of a C union). > What is an interrupt -- > typically a handler (function) address stored in a fixed location used by > the CPU when an external hardware signal goes high... Nothing prevents one > from writing that handler in C and using C's various casting operations to > stuff it into the vector memory. Most CPU architectures require you to use a special "return from interrupt" instruction to return from a hardware interrupt handler. So you need at least a small assembly language stub to call a handler written in C, or a C compiler with a non-standard extension to generate that instruction. -- Greg
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-06-07 23:38 +0000 |
| Message-ID | <5393a264$0$29988$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #72923 |
On Sat, 07 Jun 2014 14:11:27 -0400, Roy Smith wrote: > And, why do you need a library routine to touch a memory location, when > you can just dereference an integer? :-) And in one sentence we have an explanation for 90% of security vulnerabilities before PHP and SQL injection attacks... C is not a safe language, and code written in C is not safe. Using C for application development is like shaving with a cavalry sabre -- harder than it need be, and you're likely to remove your head by accident. -- Steven D'Aprano http://import-that.dreamwidth.org/
[toc] | [prev] | [next] | [standalone]
| From | Roy Smith <roy@panix.com> |
|---|---|
| Date | 2014-06-07 20:09 -0400 |
| Message-ID | <roy-259D4C.20093607062014@news.panix.com> |
| In reply to | #72937 |
In article <5393a264$0$29988$c3e8da3$5496439d@news.astraweb.com>, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > On Sat, 07 Jun 2014 14:11:27 -0400, Roy Smith wrote: > > > And, why do you need a library routine to touch a memory location, when > > you can just dereference an integer? :-) > > And in one sentence we have an explanation for 90% of security > vulnerabilities before PHP and SQL injection attacks... > > C is not a safe language, and code written in C is not safe. Using C for > application development is like shaving with a cavalry sabre -- harder > than it need be, and you're likely to remove your head by accident. I never claimed C was a safe language. I assume you've seen the classic essay, http://www-users.cs.york.ac.uk/susan/joke/foot.htm ? And, no, I don't think C is a good application language (any more). When it first came out, it was revolutionary. A lot of really amazing application software was written in it, partly because the people writing in it were some of the smartest guys around. But, that was 40 years ago. We've learned a lot about software engineering since then. We've also got machines that are so fast, it's not longer critical that we squeeze out every last iota of performance. Oh, but wait, now we're trying to do absurd things like play full-motion video games on phones, where efficiency equates to battery life. Sigh.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-06-08 10:37 +1000 |
| Message-ID | <mailman.10869.1402187824.18130.python-list@python.org> |
| In reply to | #72939 |
On Sun, Jun 8, 2014 at 10:09 AM, Roy Smith <roy@panix.com> wrote: > We've also got machines that are so fast, it's not longer critical that > we squeeze out every last iota of performance. Oh, but wait, now we're > trying to do absurd things like play full-motion video games on phones, > where efficiency equates to battery life. Sigh. Efficiency will never stop being important. Efficiency will also never be the one most important thing. No matter how much computing power changes, those statements are unlikely to be falsified... ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-06-08 03:50 +0000 |
| Message-ID | <5393dd6a$0$29988$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #72939 |
On Sat, 07 Jun 2014 20:09:37 -0400, Roy Smith wrote: > We've also got machines that are so fast, it's not longer critical that > we squeeze out every last iota of performance. Oh, but wait, now we're > trying to do absurd things like play full-motion video games on phones, > where efficiency equates to battery life. Sigh. That's where there needs to be a concerted push to develop more efficient CPUs and memory, in the engineering sense of efficiency (i.e. better power consumption, not speed). In desktop and server class machines, increasing speed has generated more and more waste heat, to the point where Google likes to build its server farms next to rivers to reduce their air conditioning costs. You can't afford to do that on a battery. Even for desktops and servers, I'd prefer to give up, say, 80% of future speed gains for a 50% reduction in my electricity bill. -- Steven D'Aprano http://import-that.dreamwidth.org/
[toc] | [prev] | [next] | [standalone]
| From | Roy Smith <roy@panix.com> |
|---|---|
| Date | 2014-06-08 10:51 -0400 |
| Message-ID | <roy-665AFD.10512408062014@news.panix.com> |
| In reply to | #72951 |
In article <5393dd6a$0$29988$c3e8da3$5496439d@news.astraweb.com>, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > On Sat, 07 Jun 2014 20:09:37 -0400, Roy Smith wrote: > > > We've also got machines that are so fast, it's not longer critical that > > we squeeze out every last iota of performance. Oh, but wait, now we're > > trying to do absurd things like play full-motion video games on phones, > > where efficiency equates to battery life. Sigh. > > That's where there needs to be a concerted push to develop more efficient > CPUs and memory, in the engineering sense of efficiency (i.e. better > power consumption, not speed). In desktop and server class machines, > increasing speed has generated more and more waste heat, to the point > where Google likes to build its server farms next to rivers to reduce > their air conditioning costs. You can't afford to do that on a battery. > > Even for desktops and servers, I'd prefer to give up, say, 80% of future > speed gains for a 50% reduction in my electricity bill. For desktops, I'm more concerned about physical size. On my desk at work, I have a Mac Mini. It's about 8 inches square, by an inch and a half high. It sits in a corner of my desk and doesn't take up much room. The guy that sits next to me has a Dell running Linux. It's about 8 inches wide, 15 inches deep, and 24 inches high. In terms of CPU, memory, disk, video, networking, etc, they have virtually identical specs. I've never compared the power consumption, but I assume his eats many time the electricity mine does (not to mention makes more noise).
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@wdtv.com> |
|---|---|
| Date | 2014-06-08 11:21 -0400 |
| Message-ID | <mailman.10878.1402242019.18130.python-list@python.org> |
| In reply to | #72963 |
On Sunday 08 June 2014 10:51:24 Roy Smith did opine And Gene did reply: > In article <5393dd6a$0$29988$c3e8da3$5496439d@news.astraweb.com>, > > Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > > On Sat, 07 Jun 2014 20:09:37 -0400, Roy Smith wrote: > > > We've also got machines that are so fast, it's not longer critical > > > that we squeeze out every last iota of performance. Oh, but wait, > > > now we're trying to do absurd things like play full-motion video > > > games on phones, where efficiency equates to battery life. Sigh. > > > > That's where there needs to be a concerted push to develop more > > efficient CPUs and memory, in the engineering sense of efficiency > > (i.e. better power consumption, not speed). In desktop and server > > class machines, increasing speed has generated more and more waste > > heat, to the point where Google likes to build its server farms next > > to rivers to reduce their air conditioning costs. You can't afford > > to do that on a battery. > > > > Even for desktops and servers, I'd prefer to give up, say, 80% of > > future speed gains for a 50% reduction in my electricity bill. > > For desktops, I'm more concerned about physical size. On my desk at > work, I have a Mac Mini. It's about 8 inches square, by an inch and a > half high. It sits in a corner of my desk and doesn't take up much > room. The guy that sits next to me has a Dell running Linux. It's > about 8 inches wide, 15 inches deep, and 24 inches high. In terms of > CPU, memory, disk, video, networking, etc, they have virtually > identical specs. > > I've never compared the power consumption, but I assume his eats many > time the electricity mine does (not to mention makes more noise). You may want to reconsider that statement after the first fan failure in your mini. We've had quite a few Mac's in the tv station, as video servers, graphics composers, etc. The airflow for cooling in them is controlled by baffles to get the maximum air flow past the hot spots, but a fan failure usually cooks the whole thing. And at that time, Macs warranty did not cover collateral damage from a fan failure. Cooked cpu? Too bad, so sad. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS
[toc] | [prev] | [next] | [standalone]
| From | Roy Smith <roy@panix.com> |
|---|---|
| Date | 2014-06-08 12:09 -0400 |
| Message-ID | <roy-54DF0A.12094008062014@news.panix.com> |
| In reply to | #72966 |
In article <mailman.10878.1402242019.18130.python-list@python.org>, Gene Heskett <gheskett@wdtv.com> wrote: > You may want to reconsider that statement after the first fan failure in > your mini. We've had quite a few Mac's in the tv station, as video > servers, graphics composers, etc. The airflow for cooling in them is > controlled by baffles to get the maximum air flow past the hot spots, but > a fan failure usually cooks the whole thing. And at that time, Macs > warranty did not cover collateral damage from a fan failure. Cooked cpu? > Too bad, so sad. The CPU (or maybe I'm thinking of the video card?) in the Dell has some huge heat sink, a bunch of funky ductwork, and a dedicated fan. I suspect if that fan were to fail, the chip it's cooling would fry itself pretty quickly too.
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@wdtv.com> |
|---|---|
| Date | 2014-06-08 13:14 -0400 |
| Message-ID | <mailman.10888.1402248064.18130.python-list@python.org> |
| In reply to | #72968 |
On Sunday 08 June 2014 12:09:41 Roy Smith did opine And Gene did reply: > In article <mailman.10878.1402242019.18130.python-list@python.org>, > > Gene Heskett <gheskett@wdtv.com> wrote: > > You may want to reconsider that statement after the first fan failure > > in your mini. We've had quite a few Mac's in the tv station, as > > video servers, graphics composers, etc. The airflow for cooling in > > them is controlled by baffles to get the maximum air flow past the > > hot spots, but a fan failure usually cooks the whole thing. And at > > that time, Macs warranty did not cover collateral damage from a fan > > failure. Cooked cpu? Too bad, so sad. > > The CPU (or maybe I'm thinking of the video card?) in the Dell has some > huge heat sink, a bunch of funky ductwork, and a dedicated fan. I > suspect if that fan were to fail, the chip it's cooling would fry > itself pretty quickly too. Probably. I have lost several nvidia video cards over the years from fan failures. My phenom in this box has a 75C shutdown that has not been tested. Best fan & sink assembly I could buy at the time. And I have gotten into the habit of replacing the 45 cent fans on the video card with bigger, ball bearing fans at the first hint of a squall. A lot of this stuff has more engineering time in assuring it will die 2 weeks out of warranty, than in giving top performance. And that goes double for stuff wearing an Antec label. I'm on the 4th psu in this box, its a $12.65 in 10 packs 350 watter, Chinese of course, running 4 terrabyte drives and a USB tree that looks like a weeping willow plus the original 2.1Mhz Phenom. 165 watts IIRC. I run gkrellm and watch its voltages. Now about 3 years old, the 5 volt line is still 5.08 volts. Whats not to like? The 2 Antecs I was dumb enough to try, had 5 volt lines down to 4.75 volts and doing random resets at the end of the 1 year warranty. Thats not an excusable failure in my book. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS
[toc] | [prev] | [next] | [standalone]
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
Back to top | Article view | comp.lang.python
csiph-web