Congrats for Guido and Python.. the point I wanted to make is: Oh how much I miss this place!!It's a techie's-over-40-dream-place. So many memories when you walk around there, all the hardward and floppy disks.. such a beauty!!
If you miss it because you're now in the UK, there's a museum with an impressive collection (especially of the very first machines; EDSAC, WITCH, and Colossus) just outside of London.
I highly recommend a visit! I went a few years ago and had a great time. It's right at the top of Bletchley Park and only costs a few pounds. It's a bit of a shame that it feels neglected by the main museum (it's a separate area/exhibit/entrance to the main Bletchley Park museum). Easy to get to from London, regular trains run from Euston all day.
I took a bunch of photos when I visited [1], I could've easily spent days there. It's unlike any museum I've been to before, towards the "end" there are lots of rooms with just piles of books and computers you can sit down with for however long you wanted - lots of tactile interaction! It was also wonderful to see machines like Colossus running as well as all manner of oddities like early UNIX systems, air traffic computers and calculators.
I loved the games room at the end of the museum. Great way to transition from all the interesting history, from all the invoked thoughts of how high the stakes were for cracking Enigma, to seeing how technology and computers can improve our lives and make us happy.
Hey now, I'm under 40 and I still get lost in that place for hours. I ended up there at a friend's recommendation the first time I was in San Francisco, and was blown away. Even though we were there for a few hours, it wasn't enough, and I've made it out there every time I'm on the west coast. What a wonderful place.
Guido is a great example of the right leader for a software project. Always kind, knowing how to delegate, knowing which are his limitations and encouraging other people to step up.
I have to say though, and this probably is me because I'm not that deeply invested into the Python community, but I don't really know anyone else in the Python community who represents the core language. In most other programming language projects of this size there are a multiple people who are public faces of the language itself, beyond the first people who designed it.
The last few years we’ve seen a few others help carry the torch (from active discussion on the python-ideas mailing list, core contributions, and major library compliments driving the ecosystem forward):
* David Beasley
* Raymond Hettinger
* Yuri Selivanov
I’m sure there are more but those are the first few that come to mind.
I'm not sure I agree; for example, I associate Perl very strongly with Larry Wall, Clojure with Rich Hickey, and Erlang with Joe Armstrong (and nobody else).
Correct me if I am wrong, but I believe that interpreted vs compiled has far more to do with python's speed then abstraction in this case. Also the post you linked literally states that abstraction doesn't necessarily mean slow.
If making a language compiled is a magic bullet for speed, why isn't every language compiled? Because they have different levels of abstraction that lend their implementation to compilation or interpretation. You're just citing a specific example of one of the tradeoffs made in the language design that falls along those three axes.
Glad to hear! As I was typing away at python the other day, the thought occurred to me that Guido (and every python contributor) have had an eerily strong impact on my day-to-day life.
I'm not sure closeness to natural language is necessarily something you would want. I remember some super painful experiments with AppleScript (https://en.wikipedia.org/wiki/AppleScript) 10 years ago, which really pushed me away from that ideal. The languageification of a programming language creates a lot of cruft.
if the text returned of (display dialog "Username" default answer "") is userAns
Similar issues can be seen in some of the monstrosities created as ruby DSLs, for example in rspec
expect(true).to eq true
where it becomes hard to understand what's actually going on.
Once you've accepted the need for precision in computer code, it becomes apparent that the correct standard is "as understandable as legal English". I don't think we're doing too bad on that metric.
I hereby declare, proclaim, and certify that I consider the Python programming language no less than 100 times as understandable, clear, and readable than English written for a legal, formal, or legislative context.
The 'equivalent' for that sort of thing in Python these days is comprehensions. The other stuff is pretty subjective. There is a blurb in the FAQ about things like 'len' and it makes the argument it's more readable.
I don't think that's true. Both Python and Ruby are readable enough. Both languages encourage good practices in different ways. I'm a 100% Python developer, but I like many ideas of Ruby; for example, the convention of using question marks to indicate that a method returns a boolean.
When you're working in a large project with +10K LOC, the project structure and the quality of the code you write is much more important than the language itself.
If we’re talking about Rails, even there Ruby is possibly better. Rails has been around for a long time and its community is very clear on readability and maintenance.
for _ in range(10):
something
for i in range(10):
something_with(i)
Can you explain why the Ruby reads more naturally?
The major differences, as I see them are that ruby requires end blocks, and uses methods instead of global functions for things.
In my opinion, python takes great pains to make things consistent, which is valuable. There's one function, range, instead of two methods, times and each. The syntax is unified: `for N in range`, which `_` being a convention if `N` is unused, as opposed to Ruby where you can define the looping variable, or not, depending on the method that was called (I guess?).
Ruby does appear to read more like something you might say, although still with weirdish grammar, but on the other hand, replace ":" with "repeat" and be explicit about the elided 0 in range, and you get "for i in the range 0 to 10, repeat something with i" which is english, as opposed to Ruby which is "take the range 1-10 and for each do unto i something with i", which imo appears significantly less natural.
This actually extend's to the stuff about "len" vs ".length", where you're asking which is more natural, to "do something to the length of X" or "do something to X's length". And that's very much a subjective question, but Python's answer establishes stronger consistency.
IMHO (1..10) is much more explicit than range(10). No questions about what it is. Where does range(10) starts from? -infinity, 0, 1? Or where does it ends at? Is 10 the starting point? Probably not but who knows. One should read the manual for that. BTW I hate Ruby's three dots (1...10) because it's (1..9) and I never remember which one is what when I find it in somebody's else code. Languages should not trick developers into mistakes. I only write the two dots.
However:
1) if one comes from Ruby, then Python is a Ruby designed by someone with a weird mind
2) if one comes from Python, then Ruby is a Python designed by someone with a weird mind
I'm coming from Ruby, a historical accident I can't change. No hard feelings.
Quite readable and fun.
I've never loved a language like I do Ruby. Everytime I am stuck, and find a simple, fun and elegant solution I like it even more.
> Is Python the language that comes closest to this goal? And if not, which is?
In the end, it's subjective. And "understandable" and "plain English" may not sit together well, as it can lead to overly verbose code.
But, here's a few examples for you to judge between. (Examples lifted from RosettaCode, which is well worth the look.)
All these languages have claimed, at some time or another, to be easy to read, and close to "plain English". Obviously, this is just a taste.
Python
def fib(n,x=[0,1]):
for i in range(abs(n)-1): x=[x[1],sum(x)]
return x[1]*pow(-1,abs(n)-1) if n<0 else x[1] if n else 0
for i in range(-30,31): print fib(i),
Ada (A safety-oriented language)
with Ada.Text_IO, Ada.Command_Line;
procedure Fib is
X: Positive := Positive'Value(Ada.Command_Line.Argument(1));
function Fib(P: Positive) return Positive is
begin
if P <= 2 then
return 1;
else
return Fib(P-1) + Fib(P-2);
end if;
end Fib;
begin
Ada.Text_IO.Put("Fibonacci(" & Integer'Image(X) & " ) = ");
Ada.Text_IO.Put_Line(Integer'Image(Fib(X)));
end Fib;
AppleScript (Seeing less support from Apple these days, but part of macOS)
on fib(n)
if n < 1 then
0
else if n < 3 then
1
else
fib(n - 2) + fib(n - 1)
end if
end fib
BASIC (Easy to read, easy to use, easy to get lost.)
FUNCTION itFib (n)
n1 = 0
n2 = 1
FOR k = 1 TO ABS(n)
sum = n1 + n2
n1 = n2
n2 = sum
NEXT k
IF n < 0 THEN
itFib = n1 * ((-1) ^ ((-n) + 1))
ELSE
itFib = n1
END IF
END FUNCTION
Clojure (A modern Lisp, bits of Scheme, Common Lisp and Java)
(defn fibs []
(map first (iterate (fn [[a b]] [b (+ a b)]) [0 1])))
CoffeeScript (Billed as a better JavaScript, it was popular until ES2016)
fib_rec = (n) ->
if n < 2 then n else fib_rec(n-1) + fib_rec(n-2)
Delphi (One of my first programming languages. Probably the least verbose staticly typed language without inference I've seen.)
function FibonacciI(N: Word): UInt64;
var
Last, New: UInt64;
I: Word;
begin
if N < 2 then
Result := N
else begin
Last := 0;
Result := 1;
for I := 2 to N do
begin
New := Last + Result;
Last := Result;
Result := New;
end;
end;
end;
Elixir (Kinda like Ruby, but running atop Erlang's massively-concurrent VM.)
defmodule Fibonacci do
def fib(0), do: 0
def fib(1), do: 1
def fib(n), do: fib(0, 1, n-2)
def fib(_, prv, -1), do: prv
def fib(prvprv, prv, n) do
next = prv + prvprv
fib(prv, next, n-1)
end
end
IO.inspect Enum.map(0..10, fn i-> Fibonacci.fib(i) end)
Elm (A new language for the web. More a framework that replaces HTML, CSS and JS than just JS.)
fibonacci : Int -> Int
fibonacci n = if n < 2 then
n
else
fibonacci(n - 2) + fibonacci(n - 1)
FORTRAN (I've done too much professional work with FORTRAN to like it. It looks straight-forward, but you can do pretty much whatever you feel like with memory, and it'll let you.)
FUNCTION IFIB(N)
IF (N.EQ.0) THEN
ITEMP0=0
ELSE IF (N.EQ.1) THEN
ITEMP0=1
ELSE IF (N.GT.1) THEN
ITEMP1=0
ITEMP0=1
DO 1 I=2,N
ITEMP2=ITEMP1
ITEMP1=ITEMP0
ITEMP0=ITEMP1+ITEMP2
1 CONTINUE
ELSE
ITEMP1=1
ITEMP0=0
DO 2 I=-1,N,-1
ITEMP2=ITEMP1
ITEMP1=ITEMP0
ITEMP0=ITEMP2-ITEMP1
2 CONTINUE
END IF
IFIB=ITEMP0
END
Go (Google's somewhat naive language, can be odd to set up, but is fast, static and fairly readable. Lots of people switch from Python to Go.)
func fib(a int) int {
if a < 2 {
return a
}
return fib(a - 1) + fib(a - 2)
}
Julia (It's a language aimed at scientific application. That means a great number system, a really good compiler, and access to things you usually need FORTRAN for.)
fib(n) = n < 2 ? n : fib(n-1) + fib(n-2)
Lua (Fast but small. Standard library isn't much bigger than C, but has LuaRocks, a decent package manager, with an active community. Some think of it as a better JavaScript, though it was designed for embedding and has a fantastic C-interop story.)
function fibs(n)
return n < 2 and n or fibs(n - 1) + fibs(n - 2)
end
Nim (Think Python, but staticly typed, and much faster.)
proc Fibonacci(n: int): auto =
var fn = float64(n)
var p: float64 = (1.0 + sqrt(5.0)) / 2.0
var q: float64 = 1.0 / p
return int64((pow(p, fn) + pow(q, fn)) / sqrt(5.0))
What's totally missing from this comparison is that languages allow multiple styles. E.g. the Python variant is for some reason not recursive, and you could write a Python version that looks a lot more like the Go or Lua versions than this Python version. (Which also can be seen as a weakness of Python from a readability point of view: freedom to choose a style also means you can pick the wrong one or a reader can be surprised by more uncommon one)
For the most part, I tried to choose styles that match the language, but yes, just a taste of the languages.
> E.g. the Python variant is for some reason not recursive
Because of the recursion limit in Python, really, as Python doesn't do tail-call elimination. That limit can make recursive code a real pain point, so iterative styles tend to work better.
Many of these programs do not get tail-call elimination (e.g. I think most languages can not automatically optimize the equivalent of "return f(n-1) + f(n-2)", if they do tail-call elimination at all). The nicest ones do not bother with negative n, some others don't. IMHO not a very useful set of comparisons.
As I mentioned elsewhere, in python the correct way would be to add the @functools.lru_cache decorator. That way you get the caching behavior of the tricky to write methods, with the clarity of the obvious recursive solution.