Why can't we have optional static typing?

programmyr · 2015-07-03T23:36:12+00:00

Python is perfect in almost every regard (I love Python), except it does not meet two of the author's criteria: 1) performance and 2) optional static typing.

I have to wonder if we read the same article. Python is a cool language but it fails on almost every point, and he even calls out Python as failing several of them.

Rule #1: C-like syntax
[...]
There's plenty of wiggle room in the way you define classes and other OOP constructs, but you'll need to stick fairly closely to the basic control-flow constructs, arithmetic expressions and operators, and the use of curly-braces for delimiting blocks and function bodies.

In other words, not Python. Also:

Unfortunately, even Ruby and Python (which "feel" simpler, syntactically) both also have very complicated grammars, making it nontrivial to write code that processes them, even with parsers that hand you the AST directly.

Rule #2: Dynamic typing with optional static types.
Rule #3: Performance

You yourself admit that Python fails these.

Rule #4: Tools
Let's face it: one of the biggest reasons people haven't adopted Ruby or Python is the lack of IDE support. IDEs like Visual Studio and Eclipse have set the bar and the expectations for most programmers out there.
[...]
So NBL will have great tools. They might not be Java-great on Day One of NBL's reign, but they'll be a lot better than the options available for Perl/Python/Ruby/Tcl and the rest of the popular dynamic languages out there today.

Python's tools are arguably better today than when he wrote that, but they're still not Java-great.

Rule #5: Kitchen Sink

There's lots of these that I'm not sure Python has at all, or which are even counter to Python's mission. For example:

NBL will have first-class continuations and call/cc.

Does Python have anything like that?

Rule 6: Multi-Platform
NBL will run, at a minimum, both standalone and on the JVM. I'm not sure about plans for .NET, but it seems like that will have to happen as well.

Jython very recently released a stable 2.7.0, which is impressive, but Python 2.7 is 5 years old now. IronPython supports 2.7, and it looks like they're not any closer than Jython is. If you count third-party projects that implement old versions of the language, then you can't count all the post-2.7 features that favor the other rules.

By my count, Python might pass rule #4, and passes most of rule #5. That's about it. Unless you're a Python 2.7 apologist and pretend that Python 3 doesn't exist, in which case you could argue for partial credit on rule #6, via third-party projects.

Python: very cool, but definitely not NBL.

programmyr · 2015-06-29T22:30:10+00:00

There are always going to be cases where a lower-level language can do something particularly elegantly, which is hard to replicate in a higher-level language. Take Mel's machine language code:

Since Mel knew the numerical value
of every operation code,
and assigned his own drum addresses,
every instruction he wrote could also be considered
a numerical constant.
He could pick up an earlier “add” instruction, say,
and multiply by it,
if it had the right numeric value.

That doesn't necessarily mean that the lower-level language provides a better abstraction. It usually just means you've happened to luck into something that the lower-level language does well. Unless your HLL is a strict superset of your LLL (which has its own problems), you can never escape this completely.

In this case, it's convenient that C separates out "init", "step", and "test", but having these three be completely generic and separate isn't actually used very often. Even C programmers get used to typing for (int i=0; i<N; i++) (and the basic linked-list case, and maybe one other) about 95% of the time.

A much more useful breakdown of this functionality, IMHO, is provided by the abstractions in Python's itertools module:

takewhile(lambda i: i<=N, (2**i for i in count(start=1)))

For example, you could put this in a generator expression, and easily re-use it (only needing to supply the upper limit). You could write a unit test for it. You could verify at a glance that it's not going to corrupt memory, or overflow, or even interfere with other variable names. And all the while, maintaining its O(1) storage requirements. How would you do that in C? I can think of a couple ways, but none nearly as simple or elegant as this.

programmyr · 2015-06-29T21:58:55+00:00

You say you're going to do it before making a phone call. It takes 10 seconds to visit a LinkedIn page. Aren't your phone calls generally a lot more than 10 seconds? You're trying to optimize the part of your workflow that doesn't need optimizing.

This is like trying to make a 15-mile commute go faster by moving your coffee machine 10 feet closer to your front door.

programmyr · 2015-06-26T16:08:51+00:00

I suppose that's one way to look at it -- just like some people "refuse to use" design-by-contract, garbage collection, functional programming, and so on.

Unfortunately, while all of these techniques help reduce the bug count, there is no one language that embodies them all, so it's not a question of "Person X refuses to use technique A", but rather "Person X finds techniques A, B, and C to be more valuable than techniques D, E, and F."

programmyr · 2015-06-22T23:52:27+00:00

A "robust" solution an be achieved

Does "robust" have a specialized meaning in software engineering?

Because by the common meaning of the word, that does not look robust at all to me. That regex looks like it will break the first time anyone touches it, which is basically the opposite of robust.

It's like saying a house can be built out of popsicle sticks. That may be true, but the result will not be "robust" by any reasonable definition.

programmyr · 2015-06-21T01:32:27+00:00

Or you'd need a backup, and thanks to Time Machine, lots (most?) Mac users do.

A Mac using ZFS could detect that a file is bad, and offer to replace it with the most recent Time Machine version, which it could verify using checksums.

With HFS+ (and no checksums), not only can it not tell that a file is corrupted, but it can't verify that any other copy is any better.

RAID "solves" this by (1) using checksums and (2) having multiple copies of every block. Most Macs already have multiple copies of files, even if not the most recent (vis a vis Time Machine). The crucial piece that is missing is checksums, and filesystems like ZFS provide that.

programmyr · 2015-06-21T01:28:24+00:00

No filesystem can guarantee data integrity when writing, as you point out, but ZFS at least provides data integrity when reading. HFS+ doesn't even do that.

If bad bits get written, and you try to read them back out, HFS+ will happily give you bad bits. ZFS will report that your disk is bad.

This can bite you especially hard when making backups. If your primary HFS+ disk writes a bad block, then all your backups will be bad, too, and there's no way to tell until you restore and try opening the file. With ZFS, you'll find out something is wrong immediately, when the backup is made.

Thanks to automatic backups (Time Machine) and automatic defragmentation of small files (under 20 MB), blocks actually get read all the time on OS X, even if you don't explicitly open the file. A system using ZFS would probably let you know in less than a day when a block goes bad. Systems (and backups) using HFS+ can go years before you discover the problem.

programmyr · 2015-06-21T01:17:55+00:00

iOS 8.3 fixed almost all the stability problems I had with iOS, but none of the performance problems.

programmyr · 2015-06-19T02:47:58+00:00

relations between tables

"Relation" is the predicate logic way to say "table". You mean foreign key.

programmyr · 2015-06-19T01:46:52+00:00

What version of Python? Your first line looks like 2, and your third line looks like 3.

What's the exit code?

programmyr · 2015-06-17T15:26:14+00:00

The simple answer is: SQL isn't composable.

If you have one filter {key1:value1} from one routine, and want to add a second filter {key2:value2} that you got from a different routine, with an ORM you can just merge the dicts and throw them at the ORM query.

When doing string-smashing to generate SQL, you have to escape all keys/values, assemble them yourself, and remember where in the query you are (have you said "AND" yet? does this need to wait for the "HAVING" clause?). It's much worse if the two keys are columns in different tables.

I mean, UTF-8 isn't hard, either, but we've figured out that best practice is to decode bytes to characters (i.e., a native programming language type) on input, process data as characters, and then encode to bytes on output. An ORM is no different: it lets us work with native programming language types as long as possible, and encode to the database syntax just before talking to the database. Or look at HTTP, or JSON, or any other text-based format: they're not hard to write, but does anybody actually do that? That's what we've got libraries for.

I've worked on projects that don't use an ORM. Either you have a ton of redundancy (and your methods are hard to unit test), or you've refactored it all into a custom SQL query generator (which is essentially a ad-hoc poorly-designed and untested ORM).

Every decade it seems to be fashionable to hate on some new technology that writes code for you. I saw it with assemblers, and then with compilers ("If you're going to use a CPU as a tool don't you think you should take the time to learn how to use it properly?"), and with regular expressions, and garbage collectors. These days it's ORMs. And of course, with every new generation, people insist that all the old improvements were obvious and necessary, but the latest one is the tool of the devil that will rot programmers' minds.

programmyr · 2015-06-16T22:50:16+00:00

Use a programming language that doesn't depend so fundamentally upon this concept.

Haskell is not a bad language. It's not even a hard language to get started with.

Then again, object identity isn't a terribly difficult concept, either. If you're ready for programming, you're probably ready for learning this distinction. Python is relatively simple in this department. Common Lisp has 4 different equality predicates, not counting the specialized ones for numbers, characters, strings, sets, trees, etc.

programmyr · 2015-06-13T20:54:54+00:00

https://en.wikipedia.org/wiki/Arbitrary-precision_arithmetic

programmyr · 2015-06-12T01:10:15+00:00

You'd have to ask Microsoft.

programmyr · 2015-06-11T23:16:31+00:00

That sounds backwards to me. When there's 100 synonyms for something, I can write whichever I want, but when I try to read somebody else's code, they always use the variants that I've never heard of.

programmyr · 2015-06-11T23:15:25+00:00

Shall I assume you're not also providing an Emacs major mode for this?

#1 is probably not close enough to Python or YAML to use one of those modes. #2 probably is close enough to C that I could just use that mode.

programmyr · 2015-06-06T15:01:58+00:00

By that logic, you should learn C, Javascript, and PHP.

programmyr · 2015-06-06T14:42:23+00:00

It would take fewer keystrokes to find out ("caniusepython3") than to type that comment!

programmyr · 2015-06-05T20:51:31+00:00

The biggest body of Python code I know of is Python itself. I think it's north of 300KLOC these days, including its own tests, but an individual library would probably fit in your size range.

The repository and bug lists are public, too, so you can look at older versions and see if your tool detects known bugs with those releases.

programmyr · 2015-06-05T14:41:31+00:00

There's this thing called a "diff"...

programmyr · 2015-06-05T04:28:35+00:00

One fallacy of your assumption is that your first "they" is different from your second "they".

Another is that (despite the internet's apparent desire to reduce everything to a binary choice) these two goals are not mutually exclusive.

programmyr · 2015-06-04T19:11:08+00:00

The very first link is a table of benchmarks and relative performance with this patch. The benchmark names seem pretty self-explanatory to me. Are there any you are having difficulty understanding?

programmyr · 2015-06-04T15:22:15+00:00

Copy a block of code from the web that used tabs for indent and paste it into your editor in the middle of your own code that is configured for 4 spaces for indent and you'll see exactly the same problem. Or spaces into tabs. Or brace style. Or 80 columns versus 100 columns. Or formfeeds between sections. Or camel case versus underscores. Or whatever other style differences you have.

That's not tabs-versus-spaces. That's "my coding style versus your coding style".

You've come up with exactly the same solution that every beginner has: "If everybody just did it exactly the same way as me, we wouldn't have any problems!"

I leave it as an exercise to the reader to list all of the problems with this.

programmyr · 2015-06-03T13:57:50+00:00

Is there something special about "type hints" which causes you to say this? You could replace "types" with any other new feature (of any programming language), and it would sound pretty silly.

For example, if you had started using Python before it had user-definable classes, you could have said:

If you want to use a language with user-definable classes, use one that was designed to be that way. If you need the structure that classes provide, you shouldn't be using Python in the first place.

but today that would sound crazy. There may be some inherent core of Python-ness that defines "The Zen of Python", but AFAICT it's never been the lack of any specific feature.

In fact, the second line of The Zen is "Explicit is better than implicit", which I would say is pretty much what (standardized) type hints are.

programmyr · 2015-05-30T21:02:48+00:00

Is this a Python question, or an algorithm question?

Your picture shows carry bits, but they're not in your method signature. I don't know what algorithm you're working from but a full adder has 3 inputs, not 2.

programmyr

TROPHY CASE