OT: This Swift thing

[Alain Ketterlin]

Cython compiles Python with optional extensions that allow additional
speed ups over compiling Python as is. In other word, the Cython
language is a Python superset.

You're right. What I question is the fact that anybody uses Cython
without the additional syntax. There is little chance that a "pure"
Python program will see any significant speedup when compiled with
Cython (or, if it does, it means that the "canonical" Python interpreter
has some sub-optimal behavior that will, eventually, be corrected).

The nice thing with optional type annotations and an hypothetical Python
compiler would be that you could, e.g., continue using the interpreter
during development and then compile for production use. Or whatever mix
you need.

-- Alain.

 

[Alain Ketterlin]

I don't understand that comment, please explain.

"Type safety" means many different things to different people. What
Python has is untyped variables, and hierarchically typed objects.
It's impossible to accidentally treat an integer as a float, and have
junk data [1].

It's impossible in Swift as well.

It's impossible to accidentally call a base class's method when you
ought to have called the overriding method in the subclass, which is a
risk in C++ [2].

I don't how this can happen in C++, unless you actually have an instance
of the base class. Anyway, I didn't mention C++.

[I agree with the rest of your explanation.]

-- Alain.

 

[Alain Ketterlin]

And it was almost always the wrong decision...

I think they know better than you and me.

-- Alain.

 

[Alain Ketterlin]

I have seen dozens of projects where Python was dismissed because of the
lack of static typing, and the lack of static analysis tools.

[...]
When is static analysis actually needed and for what purpose?

For example WCET analysis (where predictability is more important than
performance). Or code with strong security constraint. Or overflow
detection tools. Or race condition analyzers. And there are many others.
And I don't even mention engineering tools for dependence analysis,
packaging, etc. (or even IDEs).

[...] But still they avoid Ada [...]

Sorry, I forgot Ada in my list.

-- Alain.

 

[Chris Angelico]

It's impossible to accidentally call a base class's method when you
ought to have called the overriding method in the subclass, which is a
risk in C++ [2].

I don't how this can happen in C++, unless you actually have an instance
of the base class. Anyway, I didn't mention C++.

Mostly if you forget to declare the method 'virtual'; there are other
ways to muck things up, but that's the main one.

ChrisA

 

[Terry Reedy]

I am assuming here that the claim to have reached this goal is correct.

You're right. What I question is the fact that anybody uses Cython
without the additional syntax. There is little chance that a "pure"
Python program will see any significant speedup when compiled with

I believe the Cython author has claimed a 2x-5x speedup for stdlib
modules when compiled 'as is'.

Cython (or, if it does, it means that the "canonical" Python interpreter
has some sub-optimal behavior that will, eventually, be corrected).

I believe that there is some inherent overhead that Cython bypasses.

 

[Sturla Molden]

For example WCET analysis (where predictability is more important than
performance). Or code with strong security constraint. Or overflow
detection tools. Or race condition analyzers. And there are many others.
And I don't even mention engineering tools for dependence analysis,
packaging, etc. (or even IDEs).

You don't have to answer a rhetorical question.


Sturla

 

[Sturla Molden]

I think they know better than you and me.

Now it's my turn to say "oh, come on". Those who make these decisions have
likely never written a line of code in their life.

Sturla

 

[Michael Torrie]

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.

 

[Steven D'Aprano]

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.)

 

[Alain Ketterlin]

Now it's my turn to say "oh, come on". Those who make these decisions have
likely never written a line of code in their life.

This totally contradicst my experience. I've heard horror stories like
everybody else, but I just have been lucky enough to work with people
that very seriously evaluate their engineering decisions.

-- Alain.

 

[Mark Lawrence]

This totally contradicst my experience. I've heard horror stories like
everybody else, but I just have been lucky enough to work with people
that very seriously evaluate their engineering decisions.

-- Alain.

Clearly manpower isn't an issue.

 

[Alain Ketterlin]

Clearly manpower isn't an issue.

No. Cost is the issue (development, maintenance, operation,
liability...). Want an example? Here is one:

http://tech.slashdot.org/story/14/0...-engineers-involved-in-faulty-ignition-switch

-- Alain.

 

[Roy Smith]

This totally contradicst my experience. I've heard horror stories like
everybody else, but I just have been lucky enough to work with people
that very seriously evaluate their engineering decisions.

You are lucky indeed. Trust me, in big companies, technical decisions
are often made by people who are not using the technology.

 

[Dennis Lee Bieber]

You are lucky indeed. Trust me, in big companies, technical decisions
are often made by people who are not using the technology.

Or influenced by someone familiar with some tech and having a big
ego...

Many years ago, in a company to remain nameless, I was in a department
with ~130 programmers distributed among 3-4 main subsystems (batch analysis
[aka, post-processing of the daily tapes], planning [generating the
schedule for the next day], and real-time [operations using the schedule]).
The real-time group was 15-30 people using Macro-11 (PDP-11s if that dates
things). The rest of the department was pretty much all skilled VAX
FORTRAN-77.

The time came to port real-time from PDP-11 to a VAX system. A small
study was performed to determine what language would be used. Very small
study -- I think it was restricted to the 30 RT folks; I only learned of
the result after a choice had been made.

The candidates: VAX-11 Assembly, F77, C, Pascal.

Assembly was rejected since this was seen as a chance to modernize the
RT system, and few were familiar with it.

C was rejected as being unsafe, and too close to assembly.

F77 -- even with an overwhelming majority of skilled programmers
available to support development -- was rejected as being "old school"

The ego had familiarity with Pascal, and argued that Pascal was being
taught to students in college. Manager succumbed and declared VAX Pascal
would be the new RT system language.

That's when I saw the email summarizing the findings. My response was:
1) They were ignoring the massive experience in F77 available;
2) Pascal as being taught to students was probably TurboPascal (at least
this was late enough to not be UCSD P-System, which is what I'd learned it
on), with no support for real-time or really modularized development
(later, when I ended up having to fix a bug, I found I had to import the
F77 math library just to get sufficient math functions into Pascal);
3) As long as you went the whole mile to go from Macro-11 to Pascal, why
not fall the extra 6-feet to pick up VAX Ada -- which fixed all the flaws
in Pascal syntax AND was designed for real-time work.

About a decade later, said manager retired and confessed that the
choice of Pascal was a mistake (hearsay is that "ego" had given an
ultimatum -- Pascal, or /I/ leave the department). By the time of the
retirement, RT had moved again to HPUX boxes with x-windows using C...
While I was still plugging along on the F77 applications...

 

[Dennis Lee Bieber]

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...

 

[Roy Smith]

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.

 

[Roy Smith]

You are lucky indeed. Trust me, in big companies, technical decisions
are often made by people who are not using the technology.

Or influenced by someone familiar with some tech and having a big
ego...

Many years ago, in a company to remain nameless, I was in a department
with ~130 programmers distributed among 3-4 main subsystems (batch analysis
[aka, post-processing of the daily tapes], planning [generating the
schedule for the next day], and real-time [operations using the schedule]).
The real-time group was 15-30 people using Macro-11 (PDP-11s if that dates
things). The rest of the department was pretty much all skilled VAX
FORTRAN-77.

The time came to port real-time from PDP-11 to a VAX system. A small
study was performed to determine what language would be used. Very small
study -- I think it was restricted to the 30 RT folks; I only learned of
the result after a choice had been made.

The candidates: VAX-11 Assembly, F77, C, Pascal.

What was wrong with just running the original pdp-11 binaries on the VAX
in compatibility mode?

 

[Marko Rauhamaa]

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

 

[Michael Torrie]

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.