Slide 38
Slide 38 text
Distributed Execution
through
on while
-specific
ake hun-
ritten in
ormance
time en-
res:
complex
impera-
hreading
runtime,
cked by
tely.
m’s exe-
iples be-
er-Client
syntax,
se appli-
ime and
entation,
nt
c across
specify
ncoming
h a URL
th while
ncluding
ed rout-
r object.
tric pro-
(c) Workflow-Centric Code (Dog)
17
18 if session["login_tries"] >= 3 then
19 redirect_to("/forgot_password")
20 else
21 flash["message"] = "Wrong password. Please try again."
22 render "login_form.html"
23 end
24 end
25 end
26
1 listen to everyone for logins
2
3 on each login do
4 user = person from login
5 repeat 3 times
6 if user: login.user has_password: login.pass then
7 signin: login.user
8 show_dashboard_for: user
9 else
10 message = "Wrong password. Try again."
11 show message to user
12 listen to user for logins
13 on login do
14 user = person from login
15 end
16 end
17 end
18 reset_password_for:user
19 end
Figure 2. Server-side code to implement login logic. Workflow-centric
programming allows for code to be written as a straightforward imper-
ative control flow. State is manage implicitly by the program’s execution
using familiar techniques like control structures and local variables. In
resource-centric programming, state between individual server requests
is manually preserved by storing data in the session.
This style of server-side programming plays a specific and
limited role: it inspects incoming HTTP requests and pro-
duces an HTTP response. Multistep logic that spans multiple
requests needs to manually store state so that the relevant in-
formation is available during a future request-response cycle
(Figure 2b shows an example using sessions). This manual
bookkeeping complicates many development tasks, for ex-
ample, ensuring confirmation before changing a user’s email
address, choosing a different billing method before making
an online purchase, or viewing the next page from paginated
results.
Dog: Automatic State Management
Instead of writing code as a series of URL endpoints, Dog ap-
plications are written as imperative control flows that directly
allowing
s through
ion while
m-specific
ake hun-
written in
formance
ntime en-
ures:
complex
d impera-
threading
runtime,
acked by
itely.
am’s exe-
ciples be-
ver-Client
s syntax,
rse appli-
ntime and
mentation,
ent
ic across
s specify
incoming
th a URL
ath while
including
ated rout-
er object.
ntric pro-
(c) Workflow-Centric Code (Dog)
16 session["login_tries"] += 1
17
18 if session["login_tries"] >= 3 then
19 redirect_to("/forgot_password")
20 else
21 flash["message"] = "Wrong password. Please try again."
22 render "login_form.html"
23 end
24 end
25 end
26
1 listen to everyone for logins
2
3 on each login do
4 user = person from login
5 repeat 3 times
6 if user: login.user has_password: login.pass then
7 signin: login.user
8 show_dashboard_for: user
9 else
10 message = "Wrong password. Try again."
11 show message to user
12 listen to user for logins
13 on login do
14 user = person from login
15 end
16 end
17 end
18 reset_password_for:user
19 end
Figure 2. Server-side code to implement login logic. Workflow-centric
programming allows for code to be written as a straightforward imper-
ative control flow. State is manage implicitly by the program’s execution
using familiar techniques like control structures and local variables. In
resource-centric programming, state between individual server requests
is manually preserved by storing data in the session.
This style of server-side programming plays a specific and
limited role: it inspects incoming HTTP requests and pro-
duces an HTTP response. Multistep logic that spans multiple
requests needs to manually store state so that the relevant in-
formation is available during a future request-response cycle
(Figure 2b shows an example using sessions). This manual
bookkeeping complicates many development tasks, for ex-
ample, ensuring confirmation before changing a user’s email
address, choosing a different billing method before making
an online purchase, or viewing the next page from paginated
results.
Dog: Automatic State Management
Instead of writing code as a series of URL endpoints, Dog ap-
plications are written as imperative control flows that directly
allowing
ns through
tion while
m-specific
take hun-
written in
rformance
untime en-
ures:
s complex
nd impera-
threading
e runtime,
backed by
nitely.
ram’s exe-
nciples be-
ver-Client
’s syntax,
erse appli-
ntime and
mentation,
ment
gic across
rs specify
incoming
ith a URL
path while
(including
cated rout-
ler object.
entric pro-
(c) Workflow-Centric Code (Dog)
16 session["login_tries"] += 1
17
18 if session["login_tries"] >= 3 then
19 redirect_to("/forgot_password")
20 else
21 flash["message"] = "Wrong password. Please try again."
22 render "login_form.html"
23 end
24 end
25 end
26
1 listen to everyone for logins
2
3 on each login do
4 user = person from login
5 repeat 3 times
6 if user: login.user has_password: login.pass then
7 signin: login.user
8 show_dashboard_for: user
9 else
10 message = "Wrong password. Try again."
11 show message to user
12 listen to user for logins
13 on login do
14 user = person from login
15 end
16 end
17 end
18 reset_password_for:user
19 end
Figure 2. Server-side code to implement login logic. Workflow-centric
programming allows for code to be written as a straightforward imper-
ative control flow. State is manage implicitly by the program’s execution
using familiar techniques like control structures and local variables. In
resource-centric programming, state between individual server requests
is manually preserved by storing data in the session.
This style of server-side programming plays a specific and
limited role: it inspects incoming HTTP requests and pro-
duces an HTTP response. Multistep logic that spans multiple
requests needs to manually store state so that the relevant in-
formation is available during a future request-response cycle
(Figure 2b shows an example using sessions). This manual
bookkeeping complicates many development tasks, for ex-
ample, ensuring confirmation before changing a user’s email
address, choosing a different billing method before making
an online purchase, or viewing the next page from paginated
results.
Dog: Automatic State Management
Instead of writing code as a series of URL endpoints, Dog ap-
plications are written as imperative control flows that directly
y allowing
ons through
ation while
rm-specific
t take hun-
e written in
erformance
untime en-
atures:
ws complex
nd impera-
t threading
he runtime,
backed by
finitely.
gram’s exe-
nciples be-
rver-Client
g’s syntax,
verse appli-
untime and
ementation,
ment
ogic across
ers specify
n incoming
with a URL
path while
(including
cated rout-
dler object.
centric pro-
(c) Workflow-Centric Code (Dog)
15 end
16 session["login_tries"] += 1
17
18 if session["login_tries"] >= 3 then
19 redirect_to("/forgot_password")
20 else
21 flash["message"] = "Wrong password. Please try again."
22 render "login_form.html"
23 end
24 end
25 end
26
1 listen to everyone for logins
2
3 on each login do
4 user = person from login
5 repeat 3 times
6 if user: login.user has_password: login.pass then
7 signin: login.user
8 show_dashboard_for: user
9 else
10 message = "Wrong password. Try again."
11 show message to user
12 listen to user for logins
13 on login do
14 user = person from login
15 end
16 end
17 end
18 reset_password_for:user
19 end
Figure 2. Server-side code to implement login logic. Workflow-centric
programming allows for code to be written as a straightforward imper-
ative control flow. State is manage implicitly by the program’s execution
using familiar techniques like control structures and local variables. In
resource-centric programming, state between individual server requests
is manually preserved by storing data in the session.
This style of server-side programming plays a specific and
limited role: it inspects incoming HTTP requests and pro-
duces an HTTP response. Multistep logic that spans multiple
requests needs to manually store state so that the relevant in-
formation is available during a future request-response cycle
(Figure 2b shows an example using sessions). This manual
bookkeeping complicates many development tasks, for ex-
ample, ensuring confirmation before changing a user’s email
address, choosing a different billing method before making
an online purchase, or viewing the next page from paginated
results.
Dog: Automatic State Management
Instead of writing code as a series of URL endpoints, Dog ap-
plications are written as imperative control flows that directly
by allowing
ons through
cation while
orm-specific
at take hun-
e written in
performance
runtime en-
eatures:
ws complex
and impera-
ht threading
the runtime,
e backed by
efinitely.
gram’s exe-
rinciples be-
erver-Client
og’s syntax,
verse appli-
runtime and
lementation,
ement
logic across
pers specify
an incoming
with a URL
m path while
s (including
ticated rout-
ndler object.
-centric pro-
(c) Workflow-Centric Code (Dog)
15 end
16 session["login_tries"] += 1
17
18 if session["login_tries"] >= 3 then
19 redirect_to("/forgot_password")
20 else
21 flash["message"] = "Wrong password. Please try again."
22 render "login_form.html"
23 end
24 end
25 end
26
1 listen to everyone for logins
2
3 on each login do
4 user = person from login
5 repeat 3 times
6 if user: login.user has_password: login.pass then
7 signin: login.user
8 show_dashboard_for: user
9 else
10 message = "Wrong password. Try again."
11 show message to user
12 listen to user for logins
13 on login do
14 user = person from login
15 end
16 end
17 end
18 reset_password_for:user
19 end
Figure 2. Server-side code to implement login logic. Workflow-centric
programming allows for code to be written as a straightforward imper-
ative control flow. State is manage implicitly by the program’s execution
using familiar techniques like control structures and local variables. In
resource-centric programming, state between individual server requests
is manually preserved by storing data in the session.
This style of server-side programming plays a specific and
limited role: it inspects incoming HTTP requests and pro-
duces an HTTP response. Multistep logic that spans multiple
requests needs to manually store state so that the relevant in-
formation is available during a future request-response cycle
(Figure 2b shows an example using sessions). This manual
bookkeeping complicates many development tasks, for ex-
ample, ensuring confirmation before changing a user’s email
address, choosing a different billing method before making
an online purchase, or viewing the next page from paginated
results.
Dog: Automatic State Management
Instead of writing code as a series of URL endpoints, Dog ap-
by allowing
tions through
ication while
form-specific
hat take hun-
be written in
performance
e runtime en-
eatures:
ows complex
d and impera-
ght threading
y the runtime,
re backed by
definitely.
ogram’s exe-
principles be-
Server-Client
Dog’s syntax,
diverse appli-
g runtime and
plementation,
gement
logic across
opers specify
an incoming
c with a URL
m path while
ns (including
sticated rout-
andler object.
e-centric pro-
(c) Workflow-Centric Code (Dog)
14 session["login_tries"] = 0
15 end
16 session["login_tries"] += 1
17
18 if session["login_tries"] >= 3 then
19 redirect_to("/forgot_password")
20 else
21 flash["message"] = "Wrong password. Please try again."
22 render "login_form.html"
23 end
24 end
25 end
26
1 listen to everyone for logins
2
3 on each login do
4 user = person from login
5 repeat 3 times
6 if user: login.user has_password: login.pass then
7 signin: login.user
8 show_dashboard_for: user
9 else
10 message = "Wrong password. Try again."
11 show message to user
12 listen to user for logins
13 on login do
14 user = person from login
15 end
16 end
17 end
18 reset_password_for:user
19 end
Figure 2. Server-side code to implement login logic. Workflow-centric
programming allows for code to be written as a straightforward imper-
ative control flow. State is manage implicitly by the program’s execution
using familiar techniques like control structures and local variables. In
resource-centric programming, state between individual server requests
is manually preserved by storing data in the session.
This style of server-side programming plays a specific and
limited role: it inspects incoming HTTP requests and pro-
duces an HTTP response. Multistep logic that spans multiple
requests needs to manually store state so that the relevant in-
formation is available during a future request-response cycle
(Figure 2b shows an example using sessions). This manual
bookkeeping complicates many development tasks, for ex-
ample, ensuring confirmation before changing a user’s email
address, choosing a different billing method before making
an online purchase, or viewing the next page from paginated
results.
Dog: Automatic State Management
Instead of writing code as a series of URL endpoints, Dog ap-
by allowing
ctions through
plication while
tform-specific
that take hun-
be written in
g performance
ue runtime en-
features:
lows complex
d and impera-
ight threading
y the runtime,
are backed by
definitely.
rogram’s exe-
principles be-
Server-Client
Dog’s syntax,
diverse appli-
g runtime and
mplementation,
gement
p logic across
lopers specify
o an incoming
ic with a URL
em path while
ons (including
isticated rout-
handler object.
ce-centric pro-
(c) Workflow-Centric Code (Dog)
14 session["login_tries"] = 0
15 end
16 session["login_tries"] += 1
17
18 if session["login_tries"] >= 3 then
19 redirect_to("/forgot_password")
20 else
21 flash["message"] = "Wrong password. Please try again."
22 render "login_form.html"
23 end
24 end
25 end
26
1 listen to everyone for logins
2
3 on each login do
4 user = person from login
5 repeat 3 times
6 if user: login.user has_password: login.pass then
7 signin: login.user
8 show_dashboard_for: user
9 else
10 message = "Wrong password. Try again."
11 show message to user
12 listen to user for logins
13 on login do
14 user = person from login
15 end
16 end
17 end
18 reset_password_for:user
19 end
Figure 2. Server-side code to implement login logic. Workflow-centric
programming allows for code to be written as a straightforward imper-
ative control flow. State is manage implicitly by the program’s execution
using familiar techniques like control structures and local variables. In
resource-centric programming, state between individual server requests
is manually preserved by storing data in the session.
This style of server-side programming plays a specific and
limited role: it inspects incoming HTTP requests and pro-
duces an HTTP response. Multistep logic that spans multiple
requests needs to manually store state so that the relevant in-
formation is available during a future request-response cycle
(Figure 2b shows an example using sessions). This manual
bookkeeping complicates many development tasks, for ex-
ample, ensuring confirmation before changing a user’s email
address, choosing a different billing method before making
an online purchase, or viewing the next page from paginated
results.
Dog: Automatic State Management
Instead of writing code as a series of URL endpoints, Dog ap-
by allowing
actions through
plication while
atform-specific
that take hun-
o be written in
ng performance
ue runtime en-
e features:
llows complex
ed and impera-
eight threading
by the runtime,
are backed by
ndefinitely.
program’s exe-
e principles be-
d Server-Client
Dog’s syntax,
l diverse appli-
og runtime and
mplementation,
agement
up logic across
elopers specify
to an incoming
gic with a URL
tem path while
ions (including
histicated rout-
handler object.
(c) Workflow-Centric Code (Dog)
13 if session["login_tries"] == nil then
14 session["login_tries"] = 0
15 end
16 session["login_tries"] += 1
17
18 if session["login_tries"] >= 3 then
19 redirect_to("/forgot_password")
20 else
21 flash["message"] = "Wrong password. Please try again."
22 render "login_form.html"
23 end
24 end
25 end
26
1 listen to everyone for logins
2
3 on each login do
4 user = person from login
5 repeat 3 times
6 if user: login.user has_password: login.pass then
7 signin: login.user
8 show_dashboard_for: user
9 else
10 message = "Wrong password. Try again."
11 show message to user
12 listen to user for logins
13 on login do
14 user = person from login
15 end
16 end
17 end
18 reset_password_for:user
19 end
Figure 2. Server-side code to implement login logic. Workflow-centric
programming allows for code to be written as a straightforward imper-
ative control flow. State is manage implicitly by the program’s execution
using familiar techniques like control structures and local variables. In
resource-centric programming, state between individual server requests
is manually preserved by storing data in the session.
This style of server-side programming plays a specific and
limited role: it inspects incoming HTTP requests and pro-
duces an HTTP response. Multistep logic that spans multiple
requests needs to manually store state so that the relevant in-
formation is available during a future request-response cycle
(Figure 2b shows an example using sessions). This manual
bookkeeping complicates many development tasks, for ex-
ample, ensuring confirmation before changing a user’s email
address, choosing a different billing method before making
an online purchase, or viewing the next page from paginated
results.
Dog: Automatic State Management
nt by allowing
ractions through
uplication while
latform-specific
s that take hun-
to be written in
ng performance
que runtime en-
re features:
allows complex
red and impera-
weight threading
by the runtime,
d are backed by
indefinitely.
program’s exe-
re principles be-
nd Server-Client
f Dog’s syntax,
al diverse appli-
Dog runtime and
implementation,
nagement
up logic across
velopers specify
to an incoming
ogic with a URL
stem path while
tions (including
phisticated rout-
a handler object.
(c) Workflow-Centric Code (Dog)
13 if session["login_tries"] == nil then
14 session["login_tries"] = 0
15 end
16 session["login_tries"] += 1
17
18 if session["login_tries"] >= 3 then
19 redirect_to("/forgot_password")
20 else
21 flash["message"] = "Wrong password. Please try again."
22 render "login_form.html"
23 end
24 end
25 end
26
1 listen to everyone for logins
2
3 on each login do
4 user = person from login
5 repeat 3 times
6 if user: login.user has_password: login.pass then
7 signin: login.user
8 show_dashboard_for: user
9 else
10 message = "Wrong password. Try again."
11 show message to user
12 listen to user for logins
13 on login do
14 user = person from login
15 end
16 end
17 end
18 reset_password_for:user
19 end
Figure 2. Server-side code to implement login logic. Workflow-centric
programming allows for code to be written as a straightforward imper-
ative control flow. State is manage implicitly by the program’s execution
using familiar techniques like control structures and local variables. In
resource-centric programming, state between individual server requests
is manually preserved by storing data in the session.
This style of server-side programming plays a specific and
limited role: it inspects incoming HTTP requests and pro-
duces an HTTP response. Multistep logic that spans multiple
requests needs to manually store state so that the relevant in-
formation is available during a future request-response cycle
(Figure 2b shows an example using sessions). This manual
bookkeeping complicates many development tasks, for ex-
ample, ensuring confirmation before changing a user’s email
address, choosing a different billing method before making
an online purchase, or viewing the next page from paginated
results.
Dog: Automatic State Management
nt by allowing
eractions through
duplication while
platform-specific
ms that take hun-
to be written in
cing performance
ique runtime en-
ore features:
allows complex
ured and impera-
weight threading
d by the runtime,
nd are backed by
e indefinitely.
a program’s exe-
.
ore principles be-
and Server-Client
of Dog’s syntax,
ral diverse appli-
Dog runtime and
implementation,
anagement
k up logic across
evelopers specify
e to an incoming
logic with a URL
ystem path while
ations (including
ophisticated rout-
a handler object.
(c) Workflow-Centric Code (Dog)
12 else
13 if session["login_tries"] == nil then
14 session["login_tries"] = 0
15 end
16 session["login_tries"] += 1
17
18 if session["login_tries"] >= 3 then
19 redirect_to("/forgot_password")
20 else
21 flash["message"] = "Wrong password. Please try again."
22 render "login_form.html"
23 end
24 end
25 end
26
1 listen to everyone for logins
2
3 on each login do
4 user = person from login
5 repeat 3 times
6 if user: login.user has_password: login.pass then
7 signin: login.user
8 show_dashboard_for: user
9 else
10 message = "Wrong password. Try again."
11 show message to user
12 listen to user for logins
13 on login do
14 user = person from login
15 end
16 end
17 end
18 reset_password_for:user
19 end
Figure 2. Server-side code to implement login logic. Workflow-centric
programming allows for code to be written as a straightforward imper-
ative control flow. State is manage implicitly by the program’s execution
using familiar techniques like control structures and local variables. In
resource-centric programming, state between individual server requests
is manually preserved by storing data in the session.
This style of server-side programming plays a specific and
limited role: it inspects incoming HTTP requests and pro-
duces an HTTP response. Multistep logic that spans multiple
requests needs to manually store state so that the relevant in-
formation is available during a future request-response cycle
(Figure 2b shows an example using sessions). This manual
bookkeeping complicates many development tasks, for ex-
ample, ensuring confirmation before changing a user’s email
address, choosing a different billing method before making
an online purchase, or viewing the next page from paginated
results.
Dog: Automatic State Management
ile not sacrificing
ent by allowing
teractions through
duplication while
platform-specific
ms that take hun-
s to be written in
ficing performance
nique runtime en-
core features:
t allows complex
tured and impera-
tweight threading
ed by the runtime,
and are backed by
se indefinitely.
a program’s exe-
s.
core principles be-
and Server-Client
of Dog’s syntax,
eral diverse appli-
e Dog runtime and
e implementation,
anagement
ak up logic across
evelopers specify
se to an incoming
logic with a URL
system path while
cations (including
ophisticated rout-
(c) Workflow-Centric Code (Dog)
11 redirect_to("/dashboard")
12 else
13 if session["login_tries"] == nil then
14 session["login_tries"] = 0
15 end
16 session["login_tries"] += 1
17
18 if session["login_tries"] >= 3 then
19 redirect_to("/forgot_password")
20 else
21 flash["message"] = "Wrong password. Please try again."
22 render "login_form.html"
23 end
24 end
25 end
26
1 listen to everyone for logins
2
3 on each login do
4 user = person from login
5 repeat 3 times
6 if user: login.user has_password: login.pass then
7 signin: login.user
8 show_dashboard_for: user
9 else
10 message = "Wrong password. Try again."
11 show message to user
12 listen to user for logins
13 on login do
14 user = person from login
15 end
16 end
17 end
18 reset_password_for:user
19 end
Figure 2. Server-side code to implement login logic. Workflow-centric
programming allows for code to be written as a straightforward imper-
ative control flow. State is manage implicitly by the program’s execution
using familiar techniques like control structures and local variables. In
resource-centric programming, state between individual server requests
is manually preserved by storing data in the session.
This style of server-side programming plays a specific and
limited role: it inspects incoming HTTP requests and pro-
duces an HTTP response. Multistep logic that spans multiple
requests needs to manually store state so that the relevant in-
formation is available during a future request-response cycle
(Figure 2b shows an example using sessions). This manual
bookkeeping complicates many development tasks, for ex-
ample, ensuring confirmation before changing a user’s email
address, choosing a different billing method before making
an online purchase, or viewing the next page from paginated
results.
hile not sacrificing
ment by allowing
nteractions through
e duplication while
of platform-specific
ams that take hun-
es to be written in
ficing performance
unique runtime en-
core features:
at allows complex
ctured and impera-
htweight threading
ged by the runtime,
and are backed by
use indefinitely.
s a program’s exe-
es.
core principles be-
g and Server-Client
w of Dog’s syntax,
veral diverse appli-
he Dog runtime and
ce implementation,
G
Management
ak up logic across
Developers specify
nse to an incoming
s logic with a URL
system path while
ications (including
sophisticated rout-
(c) Workflow-Centric Code (Dog)
11 redirect_to("/dashboard")
12 else
13 if session["login_tries"] == nil then
14 session["login_tries"] = 0
15 end
16 session["login_tries"] += 1
17
18 if session["login_tries"] >= 3 then
19 redirect_to("/forgot_password")
20 else
21 flash["message"] = "Wrong password. Please try again."
22 render "login_form.html"
23 end
24 end
25 end
26
1 listen to everyone for logins
2
3 on each login do
4 user = person from login
5 repeat 3 times
6 if user: login.user has_password: login.pass then
7 signin: login.user
8 show_dashboard_for: user
9 else
10 message = "Wrong password. Try again."
11 show message to user
12 listen to user for logins
13 on login do
14 user = person from login
15 end
16 end
17 end
18 reset_password_for:user
19 end
Figure 2. Server-side code to implement login logic. Workflow-centric
programming allows for code to be written as a straightforward imper-
ative control flow. State is manage implicitly by the program’s execution
using familiar techniques like control structures and local variables. In
resource-centric programming, state between individual server requests
is manually preserved by storing data in the session.
This style of server-side programming plays a specific and
limited role: it inspects incoming HTTP requests and pro-
duces an HTTP response. Multistep logic that spans multiple
requests needs to manually store state so that the relevant in-
formation is available during a future request-response cycle
(Figure 2b shows an example using sessions). This manual
bookkeeping complicates many development tasks, for ex-
ample, ensuring confirmation before changing a user’s email
address, choosing a different billing method before making
an online purchase, or viewing the next page from paginated
results.
13年12⽉月29⽇日星期⽇日