►
From YouTube: SES-mtg: sep 9 real title coming soon
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right
this
week,
we'll
start
up
with.
Let's
see
we
just
briefly
recap
the
progress
on
the
tax
group
and
what
needs
to
be
done
next,
let's
talk
about
records
and
tuples,
and
then
I
brian
and
I
will
reprise
our
presentation
that
we
may
do
about
the
progress
and
test
sound
good
sounds
good,
yeah,
all
right
the
just
to
recap
what
was
said
off
the
call
regarding
the
task
group,
michael
takara
would
like
to
figure
out
the
scoping
organization
and
scheduled
calls
before
organizing
a
tax
group
and
daniel.
A
You
mentioned
one
thing
I'll,
let
you
let
you
speak
for
yourself
about
organization
and
the
exact
columns.
Oh.
B
Just
I
think
now
I
would
now
be
the
time
to
get
this
chartering
done.
Ideally,
we
could
have
something
on
the
agenda
for
this
upcoming
tc39
meeting
and
then
the
results
of
that
could
go
to
to
add
an
agenda
item
for
the
exec
comm
meeting.
That's
on
october
1st,
because,
ideally,
the
chartering
of
these
tgs
should
be
reviewed
by
the
exit
com
and
then
it
would
be
referred
to
the
ga.
But
in
practice
you
could
start
whenever
it's
just
nice
to
get
the
ball
rolling.
A
Would
someone
from
this
group
like
to
get
in
touch
with
michael
and
and
see
if
we
can
get
that
ball
rolling?
It
sounds
like
he
needs
help.
B
Well,
maybe
maybe
the
next
step
could
be
just
sort
of
write,
a
potential
charter
and
email
it
to
various
people
in
today.
Does
anybody
have
any
concerns?
Otherwise,
I'll
put
this
on
the
agenda.
C
Yeah
in
the
chat
here
I've
I
made
a
slide
deck
for
proposed
scoping.
I
don't
have
any
preferences
on
organizational
structure
and
it
seems
michael,
has
a
desire
for
a
more
rigid
organizational
structure
than
I
would
produce.
So
if
somebody
wants
to
take
over
that
part
propose
something
that'll
be
good.
A
All
right,
let's,
let's
keep
that
on
the
back
of
their
minds.
If,
by
the
end
of
the
meeting,
we
have
somebody
who's
interested
in
volunteering
to
produce
a
charter,
we'll
make
a
note
of
it.
Okay,
let's
move
on
to
records
and
tuples
update
daniel.
You
wanted
to
restate
and
clarify
your
understanding
of
the
changes
that
we've
previously
discussed.
B
Deck,
it's
great
that
you
wrote
that,
but
I
think
I
hope
the
the
the
group,
the
security
gg,
can
feel
comfortable
for
people
to
sign
on
for
without
feeling
like
they're
signing
on
to
like
the
validity
of
the
frame,
because
that
will
probably
be
a
big
topic
of
the
discussion
in
the
group.
A
B
Okay,
I'll
have
to
think
more
about
this
anyway
for
records
and
temples.
The
big
thing
is
based
on
past
discussions
that
we've
had
in
this
group.
Nikola
has
prepared
a
specif
specification
change
to
add
box
to
the
record
and
double
proposal,
so
the
idea
is
to
add
it.
First.
D
Then
sorry
to
interrupt,
I
just
wanted
to
to
put
a
clarification
from
last
time.
First
about
a
suggestion
that
was
made,
notably
by
mark
about
making
the
pro
the
records
and
tuple
structures
shallow.
Do
you
mind
if
we
do
that
quickly?
Now,.
D
Yeah
so
after
discussing
last
time,
I
am
under
the
understanding
that
it
has
been
proposed
that
we
could
change
the
proposal
to
make
it
shallow
and
make
bugs
that
we're
going
to
talk
about
just
after
not
useful
and
or
at
least
not
needed
right,
which
so
at
the
moment,
the
the
champion
group
wants
to
reiterate
the
fact
that
we
really
want
the
proposal
to
be
deeply
mutable
in
not
theoretically,
because
we
know
that
if
you
have
a
box
inside
of
a
recorded
tuple
structure,
it's
effectively
not
an
fully
deeply
mutable
data
structures.
D
But
at
the
same
time
we
want
that
to
be
reflected
as
part
of
the
developer
experience.
And
the
advantage
is
that
if
you
can
reflect
about
the
fight,
whether
you
have
a
box
inside
of
a
recorded
tuple
data
structure,
you
if
you
know
that
there
is
no
box
in
there.
You
know
that
the
record
and
tuple
structure
is
json
round
triple
as
well.
So
that
is
a
nice
property,
and
this
is
property
that
we
would
like
to
to
keep.
If
that's
possible.
D
E
So
because
that's
does
that
still
have
the
notion
that
there
would
be
a
predicate
so
that
you
could
ask
if
a
particular
node
really
is
deeply
immutable.
D
E
Okay,
so,
okay,
so
is
there
the
ra
since
we've
gone
back
and
forth
on
this?
Is
there
sometimes
for
the
rationale
in
favor
of
the
box
being
a
you
know,
being
present
not
just
syntactically,
but
in
the
api
and
semantically?
Is
there
sometimes
where
the
rationale
for
that
is
written
down?
This.
B
I
mean
yeah,
you
kind
of
already
gave
away
the
story,
so
I
mean,
I
think,
writing
up.
The
rationale
formally
is
to
item
for
us.
I
mean
nicole.
If
you
want
to
present
the
patch
that
you
wrote,
you
can
do.
B
That
or
okay,
if
either
way
the
I
the
idea
would
be
that
you
know
we're
still
we're
still
thinking
about
whether
or
not
records
in
tuples
should
be
in
objects
or
primitives.
But
the
conclusion
that
we
came
to
in
this
group
seemed
to
be
that
shallowly
immutable.
B
In
practice
I
mean
in
theory,
but
in
practice,
with
this
extra
sort
of
ergonomic
thing
of
requiring
that
you
make
an
explicit
box,
it
seemed
like
that
would
be
compatible
with
membranes.
That
was
our
analysis
and
it
seems
like
there's
sufficient
use
cases,
so
we
are
thinking
of
including
this
in
the
record
and
trouble
mvp
and
that's
something
that
we
were
thinking
of
presenting
at
the
next
tc39
meeting
based
on
nicolo
spec
work.
Do
people
here
have
any
concerns
with
that
or
are
there
any
details
to
to
go
into.
E
So
my
concern
is
not
driven
by
membranes,
the
idea
that
there
would
be
a
membrane
issue
either
way
hadn't
actually
occurred
to
me.
It
probably
should
be
examined.
I
mean
it
also
hasn't
been
examined
and
I
always
haven't
thought
about
it
much.
But
from
our
previous
conversation
I
could
see
the
rationale
for
you
know
something
syntactically
distinct
for
the
literal
form,
but
I
thought
we
were
kind
of
talking
ourselves
out
of
there
being
a
api
or
semantic
distinction.
B
E
If
we
generalize
the
read
only
collections
proposal
so
that
it
plays
nicely
with
the
records
and
tuples
proposal
and
in
particular
introduce
a
a
a
a
array.
That's
that's
in
the
typed
array
family,
but
can
hold
arbitrary
values,
but
in
which
the
array
itself
is
is
a
is
a
normal
mutable
array
in
the
type
3
family
that
differs
only
that
it
can
hold
arbitrary
values
and
then
to
have
the
same
snapshot,
diverge,
read-only
view
available
on
arrays
and
on
as
we
would
on
maps
and
sets,
and
then
the
idea.
E
B
F
I'm
sorry
good,
I
was
gonna
say
we
finished
that
conversation
by
saying
that
the
prop
the
requirement
for
a
box
is
more
of
a
function
of
the
record
in
tuple
itself
and
not
of
like
some
identities
object
or
like
structural,
primitive,
like
the
the
syntactic
requirement
for
record
and
tuple
could
also
just
be
a
requirement
to
use
the
box
primitive
or
box
object
or
whatever
and
then
record
read-only
collections.
Just
don't
have
to
do
that
that
I
think
that
was
ultimate
conclusion
we
came
to,
but
but.
E
If
the,
if
a
disciplined
array
hold
can
holds
an
arbitrary
object
and
the
snapshot
of
the
disciplined
array
is,
is
a
tuple
that
holds
the
same
object,
the
snapshot
would
have
to
wrap
the
object
in
a
box
in
order
to
be
a
proper
tuple.
According
to
the
semantics
that
I
think
you
guys
are
proposing
and
then
the
diverge,
putting
it
back
into
a
disciplined
array
would
automatically
unwrap
all
the
boxes.
E
B
B
B
E
Yeah,
I
really
don't
want
the
language
to
have
both
tuples
and
identity-less
arrays,
because
that
is
identityless,
arrays
and
tuples
are
are
concepts
that
are
so
close
to
each
other,
and
I
think
this
is
the
only
thing
that
stands
in
the
way
of
you
know
bringing
these
two
ideas
together.
F
I
think
the
conflict
then
here
is
the
desire
for
this
kind
of
like
immutability
integrity
across
all
instances
of
all
tuples,
and
not
necessarily
maybe
tuples
constructed
by
the
user
manually,
using
the
literal
syntax
or
like
tuple.map
or
something.
So
we
have.
F
B
B
Is
that
at
the
frontier
between
the
deeply
immutable
data
and
the
normal
and
the
object's
mutable
data,
there's
an
explicit
operation
that
you
use
to
cross
from
one
world
to
the
other
and
the
rationale
for
that
is
because
you,
you
conceptualize
those
two
worlds
differently,
you
treat
them.
You
treat
them
differently,
and
so
this
would
hopefully
avoid
avoid
bugs
that
happen
by
you
think
you're
in
one
world,
but
you're
actually
in
the
other
world,.
E
Okay,
that
that's
that's
that's
well
stated.
I
I
understand
that
I
don't
have
it's
it's
the
kind
of
rationale
I
respect
and
whether
how
this
one
would
play
out,
I
don't
yet
have
an
intuition
for,
as
we
went
over
last
time.
My
experience
with
similar
concepts
in
similar
languages
was
enough
different
that
that
we
should
be
suspicious
that
it
generalizes.
E
But
but
that
is
why
I'm
very
skeptical
that
the
that
the
introduction
of
the
box
on
the
front
here
without
a
without
a
rights,
amplification
step,
is
actually
doing
anything
for
you
with
the.
When
I
say.
C
E
Okay,
so
in
the
version
of
all
this,
where
we
had
symbols
as
weak
map
keys,
the
the
the
box
equivalent
and
you
you
can
just
say
box
rather
than
symbol,
but
the
idea
would
be
that
the
if
the
box
itself
was
not
adequate
to
get
to
the
mutable
value,
if
it
was
the
box
plus
something
that
gave
you
that
you
know
that
gave
you
the
the
corresponding
mutable
values
that
were
registered
with
it.
And
if
you
didn't
have
that
amplifier,
you
couldn't
see
past
the
boxes.
B
Right,
but
I
think
this
property
is
just
it's
not
a
capabilities
argument.
It's
it's
more
about
developer,
developer.
Awareness
of
these.
You
know
which
context.
E
I
got
that
I
got
that
and
and
and
that's
that's
I
got
that
when
I
said
that
it's
the
kind
of
rationale
that
I
respect
and
it
might
be
right.
E
If
you
do
a
a
deep
navigation,
that's
cros,
that's
that's!
That's
crossing
the
mutability
boundary
when
you
didn't
expect
it,
whereas
forcing
you
to
do
a
draft
would
be
you
know
that
would
be
saving
you
from
those
bugs.
I
just
I
just
don't,
have
a
good
intuition
for
whether
there's
actually
a
plausible
bug
scenario
that
this
is
addressing
in.
B
Practice
so
I
think
that's
a
good
action
item
for
us
to
document
such
a
use
case,
and
so
we
can
make
the
discussion
more
concrete
because
we
don't
currently
have
something
written
up
about
that.
C
E
They're
completely
that
that
completely
destroys
the
usability
of
snapshot
and
the
way
the
way
in
which
you
know,
one
would
generalize
it
to
maps
and
sets
the
the
the.
The
idea
is
that
you
know
you're
talking
about
a
a
category
of
collection
that
can
contain
arbitrary
values
and
that
you're
and
that
the
the
snapshotted
form
is
shallowly
immutable
but
but
contains
the
same.
E
You
know
contains
the
a
snapshot
of
what
the
what
the
collection
was,
that
you
did
the
snapshot
operation
on
okay,
it's
a
you
know.
It
contains
the
same
contents
that
the
original
collection
had
at
the
moment
of
snapshot.
F
Yeah,
I
think
this
is
just
gonna
require
some
more
thinking
I
didn't
consider.
I
didn't
fully
understand
this
problem
space
until
just
now.
Okay,
I
think
I
think
we're
gonna
have
to
think
about
it.
B
E
E
Tuples
now
the
other
thing,
the
other
thing
about
the
about
the
you
know
the
where
I
want
to
go
with
read-only
collections
and
reconciling
it
is
that
I
would
like
the
snapshotted
map
and
the
snapshot
set
to
themselves
be
similarly
immutable,
so
that
if
a
tuple
contains
them
and
they
and
they
only
contain
you-
know,
records
and
tuples-
and
you
know
snapshotted
maps
and
sets
that
that
you
can
still
have
a
deeply
immutable
structure.
That
includes
the
immutable
maps
and
sets.
B
E
A
B
Wanted
to
mention
about
the
same
key
idea:
I've
already
gotten
some
amount
of
pushback
from
implementers
about
the
negative,
zero
versus
euro,
identifying
those
two
with
each
other,
and
I
imagine
that
same
key.
For
example,
if
we
allow
symbols
and
records
unsorted
or
this,
this
map
concept
in
more
generality
could
encounter
more
pushback
from
the
from
the
angle
of
will
it
be
optimizable
to
to
do.
B
E
E
Important,
I
think,
that's
an
important
investigation.
Obviously,
if
there
is
a
a
real
problem
there,
that's
that's
a
serious
issue,
but
simply
anticipating
possible
problems
and
encountering
unease
is
is,
you
know,
is
not
a
reason
to
stop.
Okay
yeah
there
was
this.
E
This
huge
design
issue
back
when
we
first
introduced
maps
and
sets
about
iteration
order
and
everybody
who
had
who
had
implemented
you
know
using
hash
tables,
was
just
used
to
the
idea
that
identity,
hash
tables
enumerate
their
elements
in
a
in
an
arbitrary
order.
According
to
the
happenstance
of
the
identity,
hashing
and.
E
That
one
didn't
get
settled
until
I
forget
who
it
was
at
mozilla,
implemented
tyler
close's
implementation
scheme,
but
did
it
in
a
way
that
was
comparable
with
the
tuned
maps
and
sets
that
mozilla
already
had
working
internally
and
found
that
that,
even
without
a
similar
level
of
tuning
that
the
ones
using
tyler's
technique
took,
I
think
it
was
one
third
more
space
but
actually
performed
faster,
which
surprised
everybody,
including
tyler
tyler's
analysis-
was
that
they
should
be
performed
the
same.
We
think
they're
performing
actually
better
because
of
cache
effects.
E
But
as
far
as
I
know,
nobody
really
knows
why
they're
performing
better.
But
you
know
it
was
it.
E
One
you
know
we
until
that
experiment
happened.
We
had
months
of
really
strong
developer
objections,
meeting
the
really
strong
need
for
to
not
introduce
new
sources.
Non-Determinism.
B
Yeah,
I
mean
I've
heard
different
versions
of
the
story
from
other
implementers.
I
don't
want
to
get
into
it,
but
I
actually
want
to
not
just
find
one
not
just
find
one
implementation
where
you
know.
There's
some
space
overhead
and
you
know
people
say
maybe
it's
okay
and
say
that
that's
enough,
I
actually
want
to
talk
to
all
the
implementers
and
make
sure
that
everybody's
good
with
it
before
we
go
ahead.
B
Well,
you
know
because
this
proposal,
because
this
proposal
is
really
big-
I
kind
of
want
to
hold
us
to
a
high
standard
of
having
consulted
everybody
and
making
sure
that
everybody's
okay
with
it
so
there's
kind
of
resentment
here
so
that
it
actually
gets
shipped
once
it
gets
to
stage
three
and
four.
E
And
clearly,
if
the
other
implementers
had
run
into
a
roadblock,
that
would
have
stopped
that
proposal
as
well.
B
Well,
implementers
in
es6
implementers
saying
that
something
was
going
to
be
slow,
didn't
stop
things
like
I
did
to
various
things
because
they
would
be
slow
and
they
said
no,
you
can't
do
that
so
and
then
they
were
slow
and
now
people
are
talking
later
about
reverting
right.
B
In
mind
you
know,
I
don't
I
it's,
I
think
it's
well.
I
mean
one
is
classified
in
the
things
like
regex,
subclassing
and
and
another
was
array
return.
I
mean
iterator
return
and
yeah,
and
the
committee
just
didn't
accept
the
performance
arguments
or
the
arguments
about
lack
of
use
case.
So
I'm
really
trying
to
make
sure
the
committee's
a
place
where
those
arguments
are
respected,
even
if
I'm
not
the
one
making
them.
Even
if
it's
my
proposal,
they
would
be
going
against.
B
E
Yeah,
the
the
iterators
returning
a
fresh
object,
each
time
that
one
really
surprised
me-
and
I
remember
discussing
in
a
committee
and
being
surprised,
my
memory
of
it-
is
that
the
implementers
in
the
room
at
the
time-
I
don't
remember
who
they
were.
It
was
certainly
multiple
browsers.
E
B
What
would
be
extremely
unfortunate
is
if
there's
like
an
unlikely
edge
case,
that
requires
a
lot
of
optimization
work
for
it
and
that's
the
case
with
like
regex
subclassing,
and
it
might
be
the
case
with
you
know:
symbols
in
records
requiring
this
order,
independent
comparison,
if
that
ends
up
being
a
big
source
of
complexity,
that's
kind
of
my
fear:
if,
if
there
aren't,
you
know,
use
cases
to
justify
it.
E
Yeah,
so
so
the
if
we
do
an
order,
independent
comparison,
what
I've,
what
what
what
I
would
like
to
advocate
is
something
that
we
did
not.
I.
E
Last
time
we
talked
is
that
the
order
of
records
be
treated
the
way
we
treat
the
orders
of
properties
in
an
object,
so
they
can
be
arbitrarily
different,
but
you
still
have
for
records
the
order
independent
comparison.
So
it's
not
just
that
that
the
symbols
are
being
compared
order
independently.
It's
that
all
the
properties
are
being
compared
over
like.
B
I
thought
you
were
proposing
and
that's
kind
of
what
I'm
responding
to,
because
the
you
know
I
feel
like
we,
we
kind
of
thought
that
if
it's
just
string
keys,
then
it's
probably
doesn't
cause
a
serious
problem
to
sort
the
geeks
and
introducing
basically
requiring
a
sort.
Each
time
you
compare
two
records
unless
it
gets
interned,
but
every
time
you
intern
it
you
also
have
to
you
know,
provide
a
sorted
exemplar
to
compare
against
the
other
ones.
B
B
B
B
A
I
think
that
I
heard
a
concern
about
the
optimizability
of
of
comparing
equivalent
objects
with
equivalent
properties,
but
in
different
orders.
Is
that
correct.
B
A
My
I
think
I
feel
like
it's
a
good
time
to
to
say
again
that
I
think
that
there
is
an
obvious
high
performance
way
to
do
that.
That
is
not
complicated.
A
That
being
that,
I
usually
identity,
full
objects
are
compared,
are
are
hatched
based
off
of
the
underlying
memory
address
and
that's
just
not
revealed
to
the
user
because
of
insertion
order
iteration
for
identity-less
objects.
I
would
propose
that
the
the
hash
key
for
such
an
object
be
an
aggregate
of
the
hash
keys
of
its
of
the
objects
or
values
it's
comprised
of,
like.
Obviously,
a
number
would
correspond
its
hash
key
would
be.
A
The
number
itself
strings
would
be
effectively
a
hash
of
the
string,
the
for
a
composite
object.
I
would
suggest
that
the
that
the
aggregate
hash
key
of
such
an
object,
like
a
record,
would
be
the
the
sore
sum
of
the
the
composite
keys
and
values,
because
that
has
the
nice
fret
and
this
would
apply
for
records
as
and
tuples
and
for
maps
and
sets
for
immutable
maps
and
such
that
is
in
the
same
way.
A
Because
it
has
this
nice
property
that,
if
you
were
to
create
it,
that
it's
fast
to
insert
and
remove
and
recompute
that
that
hash
index
on
both
both
for
values
entering
and
exiting
the
collection.
And
it's
symmetric.
Regardless
of
order.
B
So
I
I
agree
that
that's
the
you
know:
if
we
want
to
optimize
this,
then
that's
part
of
it
so
basically
for
records
and
doubles.
We
need
a
two
level
intern
table.
We
need
one.
We
need
a
hash
code
which
is
independent,
which
is
like
a
same
key
hash
code,
so
just
for
negative
zero.
We
need
a
hash
algorithm
that
will
hash
zero
and
negative
zero
to
the
same
thing
and
the
the
algorithm
that
you're
explaining
for
for
keys,
makes
sense.
B
So
probably
we
would
also
want
the
values
to
be
part
of
the
hash
code.
Somehow
yes
yeah,
so
the
so
then,
within
a
hash
bucket.
We're
still
going
to
have
to
do
comparisons
between
you
know
the
one
one
way
to
do.
It
is
kind
of
a
linear
scan.
B
You
probably
want
to
store
also
like
a
pointer
to
an
exemplar
and
a
hash
set
in
a
hash
bucket
that
everything
is
you
know
same
key
to,
but
when
you're,
when
you're
finding.
That
example,
are
you
doing
repeated
comparisons
over
everything
in
the
hash
bucket?
So
you're
able
to
cache
this,
but
those
comparisons
will
be
slower
because
you'll
have
to
start
by
sorting
the
you'll
have
to
start
by
sorting
the
keys
and
doing
these
different
kind
of.
B
A
A
I
see
I
see
that
so
so,
if
I
restate
your,
your
point
is
that
while
it
is
trivial
to
solve
the
problem
of
a
composite
hashkey,
it
is
not
trivial
to
come
up
with
a
trip,
a
fast
equivalence
operation.
In
the
cases
where
there
are
hash
collisions.
A
B
Don't
have
an
idea
for
how
I
mean
I
think
we
could.
We
could
cache
the
results
by
having
each
thing
have
a
pointer
to
its
exemplar
in
the
in
the
hash
set.
But
when
you
allocate
a
new
object
and
compare
it
for
the
first
time,
then
you'll,
then
you
have
to
do
a
linear
scan
over
things
and
it's
in
its
hash
market.
Yes,.
A
A
Well,
you
can
basically,
I
think
what
you're
saying
is
that
it
is
possible
to
make
the
common
case
fast,
but
there
will
always
be
a
degenerate
case
which
is
slow,
which
is
par
for
the
course
with
hash
maps
in
general,
yeah,
okay,.
E
Well,
I
think
I
think
this
is.
I
mean
this
again
reminds
me
of
the
kinds
of
conversations
that
we
had
about:
deterministic
versus
arbitrary
enumeration
order
of
maps
and
sets
which
is
first,
we
argued
about
complexity,
measure
and
sort
of
the
normal
kind
of
paper,
algorithm
analysis,
and
only
when
it
you
know
it.
It
held
up
to
all
of
the
arguments
there.
E
It
still
wasn't
moving
forward
until
a
actual
experiment
was
tried
to
where
you
could
see
what
it
did
in
an
actual
implementation,
and
I
expect
that
you
know
this.
This
discussion
was
sort
of
a
start
on
the
algorithmic
comparison
and,
if
the
end
of
the
the
the
best
algorithm
for
doing
the
the
hash
consing
for
the
for
just
same
value,
zero
is,
is
a
algorithmic
complexity
that
we
can't
get
get
to
or
get
a
hair's
breath
away
from.
E
B
Yeah,
it's
an
it's
an
interesting
thing
to
look
into,
so
I
guess,
since
we
only
have
five
minutes
left,
I
wanted
to
ask
for
for
the
next
tc39
meeting
when
we're
talking
about
records
and
doubles.
Would
everybody
feel
comfortable
with
the
framing?
Were
you
know?
We've
talked
about
this
in
detail
with
the
with
the
ses
group,
who
we
previously
thought
would
be
the
ones
very
concerned
about
having
references
to
objects.
E
I
would
I
would
emphasize
since
you're
since
you're,
I
would
emphasize
that
the
choice
that
we're
going
back
and
forth
over
is
not
a
security
concern
with
regard
to
ses
security
concerns.
Whether
box
is
there
or
not,
I
don't
think
really
affects
any
ses
relevant
security
concern,
so
it's
it's
it's
more.
Just
on
all
the
other
software
engineering
concerns.