Why prefer != over <> for Python 3.0?

[kwitters]

I don't know if this is the right place to discuss the death of <in
Python 3.0, or if there have been any meaningful discussions posted
before (hard to search google with '<>' keyword), but why would anyone
prefer the comparison operator != over <>???

I've written an article about it to try and save this nice "is not
equal" operator, located at http://dewitters.koonsolo.com/python_neq.html

Please set it straight in 3.0, and if not, convince me with a good
reason of doing so, so that I can live with it and don't have to spend
the rest of my life in 2.x ;).

[Carl Banks]

On Mar 29, 6:55 am, [e-mail] wrote:

why would anyone

Questions that begin with the words "why would anyone" are almost
always betray an arrogance about their own beliefs and an ignorance
(or feigning ignorance) of human nature.

Wiser folks know better than to phrase this question so judgmentally.

Please set it straight in 3.0, and if not, convince me with a good
reason of doing so, so that I can live with it and don't have to spend
the rest of my life in 2.x ;).

1. It's not going to change in Python 3.0.

2. It's a silly thing to care so much about that you will avoid using
a langauge because of it.
Carl Banks

[Gabriel Genellina]

En Sat, 29 Mar 2008 16:24:01 -0300, Michael Wieher
<mi************@gmail.comescribió:

to me it seems simple.

C uses !=

why does C use != .... because its kind of hard to type the "equal with a
slash"

In C, ! by itself is the logical "not", so !(a==b) is the same as (a!=b)
and that's rather consistent.
Python doesn't use ! for anything else; != is rather arbitrary but
certainly much better than <(for many objects < and are meaningless;
being equal or not equal has nothing to do with being less or greater)

--
Gabriel Genellina

[Aahz]

In article <58**********************************@y21g2000hsf. googlegroups.com>,
<kw******@telenet.bewrote:

>
I don't know if this is the right place to discuss the death of <in
Python 3.0, or if there have been any meaningful discussions posted
before (hard to search google with '<>' keyword), but why would anyone
prefer the comparison operator != over <>???

Are you asking why Python 3.0 gets rid of one of them or are you asking
why != was chosen over <>?
--
Aahz (aa**@pythoncraft.com) <* http://www.pythoncraft.com/

"It is easier to optimize correct code than to correct optimized code."
--Bill Harlan

[hdante]

On Mar 29, 7:55 am, [e-mail] wrote:

I don't know if this is the right place to discuss the death of <in
Python 3.0, or if there have been any meaningful discussions posted
before (hard to search google with '<>' keyword), but why would anyone
prefer the comparison operator != over <>???

I've written an article about it to try and save this nice "is not
equal" operator, located athttp://dewitters.koonsolo.com/python_neq.html

Please set it straight in 3.0, and if not, convince me with a good
reason of doing so, so that I can live with it and don't have to spend
the rest of my life in 2.x ;).

I don't know, but we should have only one operator.

BTW, my opinion is that it's already time that programmer editors
have input methods advanced enough for generating this:

if x ¡Á 0:
¢£y ¡ô s:
if y ¡Ã 0: f1(y)
else: f2(y)

;-)

[Carl Banks]

On Mar 29, 9:23 pm, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com.auwrote:

On Sat, 29 Mar 2008 12:49:05 -0700, Carl Banks wrote:

Please set it straight in 3.0, and if not, convince me with a good
reason of doing so, so that I can live with it and don't have to spend
the rest of my life in 2.x ;).

1. It's not going to change in Python 3.0.

2. It's a silly thing to care so much about that you will avoid using a
langauge because of it.

[snip indignant rant]

>
But it's not silly to care
about the feel of the language.

I'm not exactly sure who you're arguing with, bud. No one around here
that I can tell said anything about what you're railing against.
Carl Banks

[Gabriel Genellina]

En Sun, 30 Mar 2008 02:11:33 -0300, hdante <hd****@gmail.comescribió:

BTW, my opinion is that it's already time that programmer editors
have input methods advanced enough for generating this:

if x â‰* 0:
∀y ∈ s:
if y ≥ 0: f1(y)
else: f2(y)

Fine if you have the right keyboard... Try to write APL with a standard
keyboard :)

--
Gabriel Genellina

[Gabriel Genellina]

En Sun, 30 Mar 2008 05:08:34 -0300, <de*******@gmail.comescribió:

On Mar 29, 12:41 pm, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com.auwrote:

>Since you jump to an invalid conclusion about !=, the rest of your
argument fails.

No, you said <= could be confusing, but we're talking about <here,
and there is no confusion about that :).

Yes, there is: <looks like "less or greater", and being equal or not is
a different thing that being less or greater. Trichotomy law holds for
real numbers (although some people don't even accept that) but not for
floating point (NANs); and Python isn't about numbers only. For a lot of
objects it makes sense to compare them for equality or not, but you can't
say which one is greater than the other (the weather forecast, books in a
bookstore)

--
Gabriel Genellina

[Torsten Bronger]

Hallöchen!

Bjoern Schliessmann writes:

Lie wrote:

>Ah yes, that is also used (I completely forgot about that one, my
math's aren't that sharp anymore) and I think it's used more
frequently than ><.

Where did you read that (I mean, which country)? I've never seen
this sign in any german or english book on
mathematics/physics/engineering I saw.

Maybe he means "≷".

>but my argument was that no math book use != or <(except in
math for programmers).

That's true. Personally, I don't ever use "a!=b" in favor of "not
a==b".

As a side note, I've always found == rather ugly. I'd prefer to
have = for both purposes. The constructs that wouldn't work anymore
are rare as far as I can see (and possibly there are even
workarounds).

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: br*****@jabber.org
(See http://ime.webhop.org for further contact info.)

[Steven D'Aprano]

On Sat, 29 Mar 2008 22:11:33 -0700, hdante wrote:

BTW, my opinion is that it's already time that programmer editors
have input methods advanced enough for generating this:

if x â‰* 0:
∀y ∈ s:
if y ≥ 0: f1(y)
else: f2(y)

;-)

Back in the 1990s, Apple's Hypercard accepted â‰* for "not equal". Of
course, Macs made it easy to type such special characters. By memory you
held down the Option key and typed an equals sign. For ≥ you used Option
and less-than. That worked in *any* Mac application.

Ah, glory days.

But I digress. In Python we can write the above as:
if x != 0:
[f1(y) if y >= 0 else f2(y) for y in s]
which for those not trained in algebra is probably more readable.

--
Steven

[bearophileHUGS]

hdante:

it's already time that programmer editors
have input methods advanced enough for generating this:
if x ¡Á 0:
¢£y ¡ô s:
if y ¡Ã 0: f1(y)
else: f2(y)

Take a look at Fortress language, by Sun. A free (slow) interpreter is
already available.
(Mathematica too allows you to write those symbols, but it costs a
lot, and (despite tons of good things it has) as *programming
language* it's awful, IHMO).
Steven D'Aprano:

In Python we can write the above as:
if x != 0:
[f1(y) if y >= 0 else f2(y) for y in s]

Your code builds an actual array (Python list) of results, while I
think the original code just calls f1/f2.

Bye,
bearophile

[hdante]

On Mar 30, 2:35 am, "Gabriel Genellina" <[e-mail]>
wrote:

En Sun, 30 Mar 2008 02:11:33 -0300, hdante <[e-mail]ó:

BTW, my opinion is that it's already time that programmer editors
have input methods advanced enough for generating this:

if x â‰* 0:
∀y ∈ s:
if y ≥ 0: f1(y)
else: f2(y)

Fine if you have the right keyboard... Try to write APL with a standard
keyboard :)

--
Gabriel Genellina

My sugestion considered using standard keyboards (hint: read again).

[Bjoern Schliessmann]

hdante wrote:

BTW, my opinion is that it's already time that programmer editors
have input methods advanced enough for generating this:

Could you please list some that do, and are also convenient?

Regards,
Björn

--
BOFH excuse #288:

Hard drive sleeping. Let it wake up on it's own...

[Bjoern Schliessmann]

Torsten Bronger wrote:

Maybe he means "?".

Haven't seen this either, nor do I think it's the same than "<>".
From afar, it looks more like "><". But this does more look like
South Park style shut eyes than an operator. :)

Regards,
Björn

--
BOFH excuse #407:

Route flapping at the NAP.

[Torsten Bronger]

Hallöchen!

Bjoern Schliessmann writes:

hdante wrote:

>BTW, my opinion is that it's already time that programmer editors
have input methods advanced enough for generating this:

Could you please list some that do, and are also convenient?

Define "convenient". Emacs is generally not regarded as being
convenient, however, it has very strong input methods. I type
"\gtrless" and get "≷", or "\forall" and get "∀".

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: br*****@jabber.org
(See http://ime.webhop.org for further contact info.)

[Colin J. Williams]

kw******@telenet.be wrote:

I don't know if this is the right place to discuss the death of <in
Python 3.0, or if there have been any meaningful discussions posted
before (hard to search google with '<>' keyword), but why would anyone
prefer the comparison operator != over <>???

I've written an article about it to try and save this nice "is not
equal" operator, located at http://dewitters.koonsolo.com/python_neq.html

Please set it straight in 3.0, and if not, convince me with a good
reason of doing so, so that I can live with it and don't have to spend
the rest of my life in 2.x ;).

Algol 60 had no such operator.
Algol-W had (not)= [(not) was a negative
symbol, not on our current keyboard]
Simula 67 introduced <>
Pascal uses <[Pascal is still
available - http://www.freepascal.org/]
C uses !=
[http://cermics.enpc.fr/~ts/C/CONCEPT...ions.html#rel]

I prefer <but I feel that it's better
not to have two ways of representing
not equal.

The powers that be have chosen !=. I
accept this on the grounds that current
languages seem to have nade that choice.

Colin W.

[MRAB]

On Mar 30, 6:35 am, "Gabriel Genellina" <[e-mail]>
wrote:

En Sun, 30 Mar 2008 02:11:33 -0300, hdante <[e-mail]ó:

BTW, my opinion is that it's already time that programmer editors
have input methods advanced enough for generating this:

if x â‰* 0:
∀y ∈ s:
if y ≥ 0: f1(y)
else: f2(y)

Fine if you have the right keyboard... Try to write APL with a standard
keyboard :)

There was a version of APL for the Sinclair QL which replaced the
standard APL symbols with keywords.

[Dan Bishop]

On Mar 30, 5:40 am, Torsten Bronger <[e-mail]>
wrote:

Hallöchen!

Bjoern Schliessmann writes:

Lie wrote:

Ah yes, that is also used (I completely forgot about that one, my
math's aren't that sharp anymore) and I think it's used more
frequently than ><.

Where did you read that (I mean, which country)? I've never seen
this sign in any german or english book on
mathematics/physics/engineering I saw.

Maybe he means "≷".

but my argument was that no math book use != or <(except in
math for programmers).

That's true. Personally, I don't ever use "a!=b" in favor of "not
a==b".

As a side note, I've always found == rather ugly. I'd prefer to
have = for both purposes.

The earliest versions of Python *did* use = for both purposes.

The constructs that wouldn't work anymore
are rare as far as I can see (and possibly there are even
workarounds).

The construct a = b == c could be rewritten as a = (b = c).

[Lie]

On Mar 30, 7:48 pm, Bjoern Schliessmann <usenet-
[e-mail]:

Torsten Bronger wrote:

Maybe he means "?".

Haven't seen this either, nor do I think it's the same than "<>".
From afar, it looks more like "><".

Actually I meant an X-like symbol that is made not by crossing but by

><. I retracted saying it is the standard, now that I think about it

the last time I saw >< was in elementary school (although it stuck on
my head better than a crossed =, which I first met in high school).

But this does more look like
South Park style shut eyes than an operator. :)

lol, I agree, it looks too much like closed eye smiley. Forums might
automatically convert them to graphic smileys so it is obviously a bad
choice if it is to be used.

[Lie]

On Mar 30, 5:25 pm, Bjoern Schliessmann <usenet-
[e-mail]:

Lie wrote:

Ah yes, that is also used (I completely forgot about that one, my
math's aren't that sharp anymore) and I think it's used more
frequently than ><.

Where did you read that (I mean, which country)? I've never seen
this sign in any german or english book on
mathematics/physics/engineering I saw.

It was in my elementary school at Indonesia (FYI, it is also used as
antonym sign in languages (at least in my country)). And I think I'll
retract that claim, >< wasn't the standard, a crossed = is the
standard (btw, with a little imagination != looks like a crossed =).

[Gabriel Genellina]

En Sun, 30 Mar 2008 11:10:20 -0300, MRAB <go****@mrabarnett.plus.com>
escribió:

On Mar 30, 6:35 am, "Gabriel Genellina" <[e-mail]>
wrote:

>En Sun, 30 Mar 2008 02:11:33 -0300, hdante <[e-mail]ó:

BTW, my opinion is that it's already time that programmer editors
have input methods advanced enough for generating this:

if x â‰* 0:
∀y ∈ s:
if y ≥ 0: f1(y)
else: f2(y)

Fine if you have the right keyboard... Try to write APL with a standard
keyboard :)

There was a version of APL for the Sinclair QL which replaced the
standard APL symbols with keywords.

Wow, APL on 8 bits?
Now there is (or perhaps there was) J, a reincarnation of APL by Iverson
himself that uses ASCII characters only.

--
Gabriel Genellina

[hdante]

On Mar 30, 9:45 am, Bjoern Schliessmann <usenet-
[e-mail]:

hdante wrote:

BTW, my opinion is that it's already time that programmer editors
have input methods advanced enough for generating this:

Could you please list some that do, and are also convenient?

AFAICT there's none. This should be easy to implement on emacs, or in
SCIM.

>
Regards,

Björn

--
BOFH excuse #288:

Hard drive sleeping. Let it wake up on it's own...

[Torsten Bronger]

Hallöchen!

hdante writes:

On Mar 30, 9:45 am, Bjoern Schliessmann <usenet-
[e-mail]:

>hdante wrote:

>>BTW, my opinion is that it's already time that programmer
editors have input methods advanced enough for generating this:

Could you please list some that do, and are also convenient?

AFAICT there's none. This should be easy to implement on emacs,

It *is* implemented in Emacs. You can even choose from many input
methods, optimised for differend areas/languages.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: br*****@jabber.org
(See http://ime.webhop.org for further contact info.)

[hdante]

On Mar 30, 6:08 pm, Torsten Bronger <[e-mail]>
wrote:

Hallöchen!

hdante writes:

On Mar 30, 9:45 am, Bjoern Schliessmann <usenet-
[e-mail]:

hdante wrote:

>BTW, my opinion is that it's already time that programmer
editors have input methods advanced enough for generating this:

Could you please list some that do, and are also convenient?

AFAICT there's none. This should be easy to implement on emacs,

It *is* implemented in Emacs. You can even choose from many input
methods, optimised for differend areas/languages.

I mean creating an input method specific for programming languages,
not using the TeX one.

>
Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: [e-mail]
(Seehttp://ime.webhop.orgfor further contact info.)

[Bjoern Schliessmann]

Torsten Bronger wrote:

Emacs is generally not regarded as being convenient, however, it
has very strong input methods. I type "\gtrless" and get "?",
or "\forall" and get "?".

I wonder where the point of this is. :) Why use fancy unicode chars
if they're not better to read (apart from not being readable with
every font) and require at least the same amount of keypresses?

Regards,
Björn

--
BOFH excuse #123:

user to computer ratio too high.

[Torsten Bronger]

Hallöchen!

Bjoern Schliessmann writes:

Torsten Bronger wrote:

>Emacs is generally not regarded as being convenient, however, it
has very strong input methods. I type "\gtrless" and get "?", or
"\forall" and get "?".

Doesn't KNode support UTF-8?

I wonder where the point of this is. :) Why use fancy unicode
chars if they're not better to read (apart from not being readable
with every font) and require at least the same amount of
keypresses?

Who wants to minimize the number of keypresses? We're not Perl
after all. ;-)

As a general rule of thumb in typography, more glyph forms increase
readability. APL is not readable at all but this is due to its
syntax I suppose. I find hdante's excerpt very readable.

The only reason why we don't use those special characters is that
they aren't ASCII. While ∀ or ∈ are questionable because Python
prefers English words instead of scientific symbols, â‰* or ≤ would be
certainly more legible than != or <=. But they are not ASCII, so
there is no net benefit.

However, I'm quite sure that when Unicode has arrived almost
everywhere, some languages will start considering such characters in
their core syntax. Python 3.0 allows for Unicode letters in
identifiers, and there's still room for improvement.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: br*****@jabber.org
(See http://ime.webhop.org for further contact info.)

[Paul Rubin]

Torsten Bronger <br*****@physik.rwth-aachen.dewrites:

However, I'm quite sure that when Unicode has arrived almost
everywhere, some languages will start considering such characters in
their core syntax. Python 3.0 allows for Unicode letters in
identifiers, and there's still room for improvement.

I agree. What's the codepoint for lower case lambda?

[Bjoern Schliessmann]

Torsten Bronger wrote:

Doesn't KNode support UTF-8?

Well, it should, but automatic encoding detection doesn't always
seem to work (or does it even have one?). I'm looking for a
different (faster) newsreader anyway.

Who wants to minimize the number of keypresses? We're not Perl
after all. ;-)

Sure, but I also don't want to enter fancy unicode operators. I'm
using Python on some computers that even don't support unicode.

However, I'm quite sure that when Unicode has arrived almost
everywhere, some languages will start considering such characters
in their core syntax.

This should be the time when there are widespread quasi-standardised
input methods for those characters.

Regards,
Björn

--
BOFH excuse #154:

You can tune a file system, but you can't tune a fish (from most
tunefs man pages)

[Terry Reedy]

"Bjoern Schliessmann" <us**************************@spamgourmet.comwro te
in message news:65*************@mid.individual.net...
| However, I'm quite sure that when Unicode has arrived almost
| everywhere, some languages will start considering such characters
| in their core syntax.
|
| This should be the time when there are widespread quasi-standardised
| input methods for those characters.

C has triglyphs for keyboards missing some ASCII chars. != and <= could
easily be treated as diglyphs for the corresponding chars. In a sense they
are already, it is just that the real things are not allowed ;=).

[Gabriel Genellina]

En Mon, 31 Mar 2008 16:17:39 -0300, Terry Reedy <tj*****@udel.edu>
escribió:

"Bjoern Schliessmann" <us**************************@spamgourmet.com>
wrote
in message news:65*************@mid.individual.net...
| However, I'm quite sure that when Unicode has arrived almost
| everywhere, some languages will start considering such characters
| in their core syntax.
|
| This should be the time when there are widespread quasi-standardised
| input methods for those characters.

C has triglyphs for keyboards missing some ASCII chars. != and <= could
easily be treated as diglyphs for the corresponding chars. In a sense
they
are already, it is just that the real things are not allowed ;=).

I think it should be easy to add support for â‰*≤≥ and even λ, only the
tokenizer has to be changed.

--
Gabriel Genellina

[Torsten Bronger]

Hallöchen!

Jorge Vargas writes:

On Tue, Apr 1, 2008 at 6:03 AM, Gabriel Genellina
<ga*******@yahoo.com.arwrote:

>[...]

I think it should be easy to add support for â‰*≤≥ and even λ,
only the tokenizer has to be changed.

show me a keyboard that has those symbols and I'm all up for it.

For <= I have to press three buttons, for ≤ I have to press four
buttons. Not much of a difference. ;-)

However, I'm slightly disappointed with the UTF-8 support in some
mail clients involved in this thread, so Unicode surely has not
arrived yet.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: br*****@jabber.org
(See http://ime.webhop.org for further contact info.)

[Ben Finney]

Torsten Bronger <br*****@physik.rwth-aachen.dewrites:

However, I'm slightly disappointed with the UTF-8 support in some
mail clients involved in this thread, so Unicode surely has not
arrived yet.

Want <URL:http://www.cafepress.com/nucleartacos.26721820>.

--
\ "bash awk grep perl sed, df du, du-du du-du, vi troff su fsck |
`\ rm * halt LART LART LART!" -- The Swedish BOFH, |
_o__) alt.sysadmin.recovery |
Ben Finney

[Gabriel Genellina]

En Tue, 01 Apr 2008 04:15:57 -0300, Jorge Vargas <jo**********@gmail.com>
escribió:

as for the original question, the point of going unicode is not to
make code unicode, but to make code's output unicode. thin of print
calls and templates and comments the world's complexity in languages.
sadly most english speaking people think unicode is irrelevant because
ASCII has everything, but their narrow world is what's wrong.

Python 3 is a good step in that direction. Strings are unicode,
identifiers are not restricted to ASCII, and the default source encoding
is not ASCII anymore (but I don't remember which one).
So this is now possible with 3.0:

>>año = 2008
print("halagüeño")

halagüeño

>>print("halagüeño".encode("latin1"))

b'halag\xfce\xf1o'

--
Gabriel Genellina

[Steve Holden]

Torsten Bronger wrote:

Hallöchen!

Jorge Vargas writes:

>On Tue, Apr 1, 2008 at 6:03 AM, Gabriel Genellina
<ga*******@yahoo.com.arwrote:

>>[...]

I think it should be easy to add support for â‰*≤≥ and even λ,
only the tokenizer has to be changed.

show me a keyboard that has those symbols and I'm all up for it.

For <= I have to press three buttons, for ≤ I have to press four
buttons. Not much of a difference. ;-)

However, I'm slightly disappointed with the UTF-8 support in some
mail clients involved in this thread, so Unicode surely has not
arrived yet.

I'd settle for a program listing utility that made the replacements.

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC http://www.holdenweb.com/

[Steve Holden]

Torsten Bronger wrote:

Hallöchen!

Jorge Vargas writes:

>On Tue, Apr 1, 2008 at 6:03 AM, Gabriel Genellina
<ga*******@yahoo.com.arwrote:

>>[...]

I think it should be easy to add support for â‰*≤≥ and even λ,
only the tokenizer has to be changed.

show me a keyboard that has those symbols and I'm all up for it.

For <= I have to press three buttons, for ≤ I have to press four
buttons. Not much of a difference. ;-)

However, I'm slightly disappointed with the UTF-8 support in some
mail clients involved in this thread, so Unicode surely has not
arrived yet.

I'd settle for a program listing utility that made the replacements.

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC http://www.holdenweb.com/

[John J. Lee]

"Gabriel Genellina" <ga*******@yahoo.com.arwrites:
[...]

>There was a version of APL for the Sinclair QL which replaced the
standard APL symbols with keywords.

Wow, APL on 8 bits?
Now there is (or perhaps there was) J, a reincarnation of APL by
Iverson himself that uses ASCII characters only.

The BBC Model B ran I-APL, too.

Sitting on my desk is a copy of "I-APL Instruction Manual for PC
Clones, RML Nimbus, BBC Master & B, and Archimedes", along with a few
other APL books and a pile of newsletters, waiting to be thrown away
:-( I got a copy because they were giving it away free to schools.
Poisoning young minds ;-)

How did programmers manage back then in 32k? Less software
development, more jigsaw puzzle.
John

[MRAB]

On Mar 30, 7:59 pm, "Gabriel Genellina" <[e-mail]>
wrote:

En Sun, 30 Mar 2008 11:10:20 -0300, MRAB <[e-mail]>
escribió:

On Mar 30, 6:35 am, "Gabriel Genellina" <[e-mail]>
wrote:

En Sun, 30 Mar 2008 02:11:33 -0300, hdante <[e-mail]ó:

BTW, my opinion is that it's already time that programmer editors
have input methods advanced enough for generating this:

if x â‰* 0:
∀y ∈ s:
if y ≥ 0: f1(y)
else: f2(y)

Fine if you have the right keyboard... Try to write APL with a standard
keyboard :)

There was a version of APL for the Sinclair QL which replaced the
standard APL symbols with keywords.

Wow, APL on 8 bits?
Now there is (or perhaps there was) J, a reincarnation of APL by Iverson
himself that uses ASCII characters only.

The Sinclair QL used the Motorola 68008, which was like the 68000 (a
32-bit processor) but with an 8-bit external data bus instead of a 16-
bit one; that made the system cheaper to build, but as the
instructions were multiples of 16 bits long every instruction required
at least 2 memory accesses, which made it slower. Nice clean processor
though, unlike the 8086... :-)