Talk:1319: Automation - Revision history

Kevrotti: Reference joke that a parser developer made about automation.

2020-11-10T20:06:04Z

Reference joke that a parser developer made about automation.

108.162.212.5 at 21:38, 28 July 2015

2015-07-28T21:38:19Z

Jevicci at 23:05, 23 January 2014

2014-01-23T23:05:09Z

Jevicci at 23:04, 23 January 2014

2014-01-23T23:04:11Z

Jevicci at 23:03, 23 January 2014

2014-01-23T23:03:14Z

Davidy22: Reverted edits by 199.27.128.88 (talk) to last revision by 141.101.99.248

2014-01-23T00:40:54Z

Reverted edits by 199.27.128.88 (talk) to last revision by 141.101.99.248

199.27.128.88: How?

2014-01-22T22:41:44Z

How?

141.101.99.248 at 19:22, 22 January 2014

2014-01-22T19:22:49Z

Hkmaly at 10:17, 22 January 2014

2014-01-22T10:17:54Z

Greyson at 00:21, 22 January 2014

2014-01-22T00:21:54Z

← Older revision		Revision as of 20:06, 10 November 2020
Line 35:		Line 35:
	sub - under		sub - under
	marine - from "mare" meaning "lava field on the moon" or "female horse" [[Special:Contributions/108.162.212.5\|108.162.212.5]] 21:38, 28 July 2015 (UTC)		marine - from "mare" meaning "lava field on the moon" or "female horse" [[Special:Contributions/108.162.212.5\|108.162.212.5]] 21:38, 28 July 2015 (UTC)
		+
		+	See also the motto of [http://parrt.cs.usfca.edu\| Terence Parr] (the "maniac behind [http://www.antlr.org\| ANTLR]"): ''“Why program by hand in five days what you can spend five years of your life automating?”''

← Older revision		Revision as of 21:38, 28 July 2015
Line 31:		Line 31:

	:And if you really must rethink, at least deploy the program first. -- [[User:Hkmaly\|Hkmaly]] ([[User talk:Hkmaly\|talk]]) 10:17, 22 January 2014 (UTC)		:And if you really must rethink, at least deploy the program first. -- [[User:Hkmaly\|Hkmaly]] ([[User talk:Hkmaly\|talk]]) 10:17, 22 January 2014 (UTC)
		+
		+	Today's [http://what-if.xkcd.com/138/ what if?] makes a false-etymology joke similar to the auto+mating one here:
		+	sub - under
		+	marine - from "mare" meaning "lava field on the moon" or "female horse" [[Special:Contributions/108.162.212.5\|108.162.212.5]] 21:38, 28 July 2015 (UTC)

@@ Line 18: / Line 18: @@
 ::Yes, but I agree with Jevicci's comment and that's what I was going to post. The point of the automation is (in theory) to save effort. After an initial input of lots of work coding, the "automation" line drops to near-zero. That makes sense, but the "regular way" line should continue horizontal like it does in the 2nd graph because if you don't automate, it should continue to take effort. The first chart suggests that even in theory, automation takes more work and the same amount of time as the old fashioned way.
-::I think what Randall is trying to say is EITHER that a) programmers will automate for the sake of the challenge or it being less tedious than the basic way even if it doesn't save time. b) programmers will automate even if it doesn't save time because they can use the code next time the problem arises. But I agree, I think the first graph's "regular way" line should have either continued horizontal, or tappered off somewhere after the "automation" line does. [[User:TheHYPO|TheHYPO]] ([[User talk:TheHYPO|talk]]) 14:56, 21 January 2014 (UTC)
+:::I think what Randall is trying to say is EITHER that a) programmers will automate for the sake of the challenge or it being less tedious than the basic way even if it doesn't save time. b) programmers will automate even if it doesn't save time because they can use the code next time the problem arises. But I agree, I think the first graph's "regular way" line should have either continued horizontal, or tappered off somewhere after the "automation" line does. [[User:TheHYPO|TheHYPO]] ([[User talk:TheHYPO|talk]]) 14:56, 21 January 2014 (UTC)
-:::As far as I can tell, the line labelled "work on original task" is not meant to represent the amount of work you'd be doing without any automation (which would indeed remain a straight horizontal line), as the "theory" graph doesn't compare two separate scenarios. Rather, it's just there to be a baseline amount of work (programming work being done on top), which diminishes to near-zero as soon as automation takes over. [[Special:Contributions/108.162.231.221|108.162.231.221]] 18:28, 21 January 2014 (UTC)
+::::As far as I can tell, the line labelled "work on original task" is not meant to represent the amount of work you'd be doing without any automation (which would indeed remain a straight horizontal line), as the "theory" graph doesn't compare two separate scenarios. Rather, it's just there to be a baseline amount of work (programming work being done on top), which diminishes to near-zero as soon as automation takes over. [[Special:Contributions/108.162.231.221|108.162.231.221]] 18:28, 21 January 2014 (UTC)
-::::Yea, in the theory you would continue performing the task while also coding the automation. Once the automation is done, you work on neither the original nor the coding so both drop to zero. In practice, you keep doing the work and never finish the automation, so the coding goes up and the original stays the same. --[[Special:Contributions/173.245.48.29|173.245.48.29]] 22:20, 21 January 2014 (UTC)
+:::::Yea, in the theory you would continue performing the task while also coding the automation. Once the automation is done, you work on neither the original nor the coding so both drop to zero. In practice, you keep doing the work and never finish the automation, so the coding goes up and the original stays the same. --[[Special:Contributions/173.245.48.29|173.245.48.29]] 22:20, 21 January 2014 (UTC)
-:::::It makes more sense if you see the lines as' amount of work existing for a task'. The two lines are the given work and work given to self. Top graph: The amount of work for the given task remains constant until you solve the automation (work you gave yourself) at which point both drop as given work is now done and you won't carry on working on the automation anymore, free time. The graph doesn't reach zero as there will always be more you could do (like Richardson's Theory). On the second graph, you never work on the original task, get consumed by automation and end up with far more work than was ever presented (as pointed out, after the rethink) and there is a total increase in the amount of work which exists for you, without actually touching the given work... whether it actually gets done in the end or not doesn't matter as you could stop and the graphs would stay like they are. [[Special:Contributions/141.101.99.248|141.101.99.248]] 19:22, 22 January 2014 (UTC) thesuperkev
+::::::It makes more sense if you see the lines as' amount of work existing for a task'. The two lines are the given work and work given to self. Top graph: The amount of work for the given task remains constant until you solve the automation (work you gave yourself) at which point both drop as given work is now done and you won't carry on working on the automation anymore, free time. The graph doesn't reach zero as there will always be more you could do (like Richardson's Theory). On the second graph, you never work on the original task, get consumed by automation and end up with far more work than was ever presented (as pointed out, after the rethink) and there is a total increase in the amount of work which exists for you, without actually touching the given work... whether it actually gets done in the end or not doesn't matter as you could stop and the graphs would stay like they are. [[Special:Contributions/141.101.99.248|141.101.99.248]] 19:22, 22 January 2014 (UTC) thesuperkev
-::::::Ah, I see now.  Didn't realize the two lines represented simultaneous work as opposed to two separate scenarios.  Makes sense now.  Thanks for the explanation. [[User:Jevicci|Jevicci]] ([[User talk:Jevicci|talk]]) 23:03, 23 January 2014 (UTC)
+:::::::Ah, I see now.  Didn't realize the two lines represented simultaneous work as opposed to two separate scenarios.  Makes sense now.  Thanks for the explanation. [[User:Jevicci|Jevicci]] ([[User talk:Jevicci|talk]]) 23:03, 23 January 2014 (UTC)
 In other words, when automating, NEVER rethink. [[User:Greyson|Greyson]] ([[User talk:Greyson|talk]]) 00:21, 22 January 2014 (UTC)
 :And if you really must rethink, at least deploy the program first. -- [[User:Hkmaly|Hkmaly]] ([[User talk:Hkmaly|talk]]) 10:17, 22 January 2014 (UTC)

@@ Line 12: / Line 12: @@
 "dead parrot" [[Special:Contributions/141.101.99.236|141.101.99.236]] 09:55, 21 January 2014 (UTC)
-Why do the lines on the "Theory" graph converge shortly after automation takes over?  Surely, the idea behind writing a code in this example is to save time.  Therefore, the original task line should remain relatively constant and the coding line should plunge below it, no? [[User:Jevicci|Jevicci]] ([[User talk:Jevicci|talk]]) 23:03, 23 January 2014 (UTC)
+Why do the lines on the "Theory" graph converge shortly after automation takes over?  Surely, the idea behind writing a code in this example is to save time.  Therefore, the original task line should remain relatively constant and the automation line should plunge below it, no? [[User:Jevicci|Jevicci]] ([[User talk:Jevicci|talk]]) 23:03, 23 January 2014 (UTC)
 : Once the automation takes over, the programmer will no longer have to do anything, the program will take care of it [[User:Raestloz|Raestloz]] ([[User talk:Raestloz|talk]]) 00:22, 21 January 2014 (UTC)

@@ Line 12: / Line 12: @@
 "dead parrot" [[Special:Contributions/141.101.99.236|141.101.99.236]] 09:55, 21 January 2014 (UTC)
-Why do the lines on the "Theory" graph converge shortly after automation takes over?  Surely, the idea behind writing a code in this example is to save time.  Therefore, the original task line should remain relatively constant and the coding line should plunge below it, no? {{unsigned|Jevicci}}
+Why do the lines on the "Theory" graph converge shortly after automation takes over?  Surely, the idea behind writing a code in this example is to save time.  Therefore, the original task line should remain relatively constant and the coding line should plunge below it, no? [[User:Jevicci|Jevicci]] ([[User talk:Jevicci|talk]]) 23:03, 23 January 2014 (UTC)
 : Once the automation takes over, the programmer will no longer have to do anything, the program will take care of it [[User:Raestloz|Raestloz]] ([[User talk:Raestloz|talk]]) 00:22, 21 January 2014 (UTC)
@@ Line 24: / Line 23: @@
 ::::Yea, in the theory you would continue performing the task while also coding the automation. Once the automation is done, you work on neither the original nor the coding so both drop to zero. In practice, you keep doing the work and never finish the automation, so the coding goes up and the original stays the same. --[[Special:Contributions/173.245.48.29|173.245.48.29]] 22:20, 21 January 2014 (UTC)
-:::: It makes more sense if you see the lines as' amount of work existing for a task'. The two lines are the given work and work given to self. Top graph: The amount of work for the given task remains constant until you solve the automation (work you gave yourself) at which point both drop as given work is now done and you won't carry on working on the automation anymore, free time. The graph doesn't reach zero as there will always be more you could do (like Richardson's Theory). On the second graph, you never work on the original task, get consumed by automation and end up with far more work than was ever presented (as pointed out, after the rethink) and there is a total increase in the amount of work which exists for you, without actually touching the given work... whether it actually gets done in the end or not doesn't matter as you could stop and the graphs would stay like they are. [[Special:Contributions/141.101.99.248|141.101.99.248]] 19:22, 22 January 2014 (UTC) thesuperkev
+:::::It makes more sense if you see the lines as' amount of work existing for a task'. The two lines are the given work and work given to self. Top graph: The amount of work for the given task remains constant until you solve the automation (work you gave yourself) at which point both drop as given work is now done and you won't carry on working on the automation anymore, free time. The graph doesn't reach zero as there will always be more you could do (like Richardson's Theory). On the second graph, you never work on the original task, get consumed by automation and end up with far more work than was ever presented (as pointed out, after the rethink) and there is a total increase in the amount of work which exists for you, without actually touching the given work... whether it actually gets done in the end or not doesn't matter as you could stop and the graphs would stay like they are. [[Special:Contributions/141.101.99.248|141.101.99.248]] 19:22, 22 January 2014 (UTC) thesuperkev
 In other words, when automating, NEVER rethink. [[User:Greyson|Greyson]] ([[User talk:Greyson|talk]]) 00:21, 22 January 2014 (UTC)
 :And if you really must rethink, at least deploy the program first. -- [[User:Hkmaly|Hkmaly]] ([[User talk:Hkmaly|talk]]) 10:17, 22 January 2014 (UTC)

← Older revision		Revision as of 00:40, 23 January 2014
Line 1:		Line 1:
−	~~How~~ do you ~~make~~ a ~~comment?~~	+	Why is this administrator protected? Did an admin lock it just to make sure they'd be the first person to explain it? --[[User:Mynotoar\|Mynotoar]] ([[User talk:Mynotoar\|talk]]) 07:12, 20 January 2014 (UTC)
		+
		+	It is not protected. Check the logs. [[Special:Contributions/108.162.246.117\|108.162.246.117]] 07:39, 20 January 2014 (UTC)
		+
		+	Alright, done the preliminary explanation. I think I got the joke right, and I'm a programmer myself so I can relate to the graphs. However, laymen may not understand the circumstances of programming world, so maybe simpler words could be used, or a real-life example given. That and I'm not a native English speaker, so someone else should do some grammar check. Also, I posted that from my mobile, it's not really convenient (editing the post itself is already a bit hard) so I'll do some fact checking and citation-linking once I got home. I did check on the screwing definition with TheFreeDictionary, don't have time to do better search now. [[User:Raestloz\|Raestloz]] ([[User talk:Raestloz\|talk]]) 08:55, 20 January 2014 (UTC)
		+
		+	Note that in reality, many tasks can be automated successfully: while the programming takes longer that expected, may not simplify the task as much as expected and the program feels unfinished, outside circumstances can force the programmer to abandon ongoing development and use the program for partial automation instead. -- [[User:Hkmaly\|Hkmaly]] ([[User talk:Hkmaly\|talk]]) 09:54, 20 January 2014 (UTC)
		+
		+	The title text reminds me of the old joke about the definition of politics -- "poli-" meaning "many" and "tics" meaning "blood sucking creatures". --[[Special:Contributions/108.162.219.202\|108.162.219.202]] 12:31, 20 January 2014 (UTC)
		+
		+	Or the definition of polygon; "poly" = parrot and "gon" = gone (i.e., deceased). Therefore,
		+	"dead parrot" [[Special:Contributions/141.101.99.236\|141.101.99.236]] 09:55, 21 January 2014 (UTC)
		+
		+	Why do the lines on the "Theory" graph converge shortly after automation takes over? Surely, the idea behind writing a code in this example is to save time. Therefore, the original task line should remain relatively constant and the coding line should plunge below it, no? {{unsigned\|Jevicci}}
		+
		+	: Once the automation takes over, the programmer will no longer have to do anything, the program will take care of it [[User:Raestloz\|Raestloz]] ([[User talk:Raestloz\|talk]]) 00:22, 21 January 2014 (UTC)
		+
		+	::Yes, but I agree with Jevicci's comment and that's what I was going to post. The point of the automation is (in theory) to save effort. After an initial input of lots of work coding, the "automation" line drops to near-zero. That makes sense, but the "regular way" line should continue horizontal like it does in the 2nd graph because if you don't automate, it should continue to take effort. The first chart suggests that even in theory, automation takes more work and the same amount of time as the old fashioned way.
		+
		+	::I think what Randall is trying to say is EITHER that a) programmers will automate for the sake of the challenge or it being less tedious than the basic way even if it doesn't save time. b) programmers will automate even if it doesn't save time because they can use the code next time the problem arises. But I agree, I think the first graph's "regular way" line should have either continued horizontal, or tappered off somewhere after the "automation" line does. [[User:TheHYPO\|TheHYPO]] ([[User talk:TheHYPO\|talk]]) 14:56, 21 January 2014 (UTC)
		+
		+	:::As far as I can tell, the line labelled "work on original task" is not meant to represent the amount of work you'd be doing without any automation (which would indeed remain a straight horizontal line), as the "theory" graph doesn't compare two separate scenarios. Rather, it's just there to be a baseline amount of work (programming work being done on top), which diminishes to near-zero as soon as automation takes over. [[Special:Contributions/108.162.231.221\|108.162.231.221]] 18:28, 21 January 2014 (UTC)
		+
		+	::::Yea, in the theory you would continue performing the task while also coding the automation. Once the automation is done, you work on neither the original nor the coding so both drop to zero. In practice, you keep doing the work and never finish the automation, so the coding goes up and the original stays the same. --[[Special:Contributions/173.245.48.29\|173.245.48.29]] 22:20, 21 January 2014 (UTC)
		+
		+	:::: It makes more sense if you see the lines as' amount of work existing for a task'. The two lines are the given work and work given to self. Top graph: The amount of work for the given task remains constant until you solve the automation (work you gave yourself) at which point both drop as given work is now done and you won't carry on working on the automation anymore, free time. The graph doesn't reach zero as there will always be more you could do (like Richardson's Theory). On the second graph, you never work on the original task, get consumed by automation and end up with far more work than was ever presented (as pointed out, after the rethink) and there is a total increase in the amount of work which exists for you, without actually touching the given work... whether it actually gets done in the end or not doesn't matter as you could stop and the graphs would stay like they are. [[Special:Contributions/141.101.99.248\|141.101.99.248]] 19:22, 22 January 2014 (UTC) thesuperkev
		+
		+	In other words, when automating, NEVER rethink. [[User:Greyson\|Greyson]] ([[User talk:Greyson\|talk]]) 00:21, 22 January 2014 (UTC)
		+
		+	:And if you really must rethink, at least deploy the program first. -- [[User:Hkmaly\|Hkmaly]] ([[User talk:Hkmaly\|talk]]) 10:17, 22 January 2014 (UTC)

← Older revision		Revision as of 22:41, 22 January 2014
Line 1:		Line 1:
−	~~Why is this administrator protected? Did an admin lock it just to~~ make ~~sure they'd be the first person to explain it? --[[User:Mynotoar\|Mynotoar]] ([[User talk:Mynotoar\|talk]]) 07:12, 20 January 2014 (UTC)~~	+	How do you make a comment?
−
−	~~It is not protected. Check the logs. [[Special:Contributions/108.162.246.117\|108.162.246.117]] 07:39, 20 January 2014 (UTC)~~
−
−	~~Alright, done the preliminary explanation. I think I got the joke right, and I'm~~ a programmer myself so I can relate to the graphs. However, laymen may not understand the circumstances of programming world, so maybe simpler words could be used, or a real-life example given. That and I'm not a native English speaker, so someone else should do some grammar check. Also, I posted that from my mobile, it's not really convenient (editing the post itself is already a bit hard) so I'll do some fact checking and citation-linking once I got home. I did check on the screwing definition with TheFreeDictionary, don't have time to do better search now. [[User:Raestloz\|Raestloz]] ([[User talk:Raestloz\|talk]]) 08:55, 20 January 2014 (UTC)
−
−	Note that in reality, many tasks can be automated successfully: while the programming takes longer that expected, may not simplify the task as much as expected and the program feels unfinished, outside circumstances can force the programmer to abandon ongoing development and use the program for partial automation instead. -- [[User:Hkmaly\|Hkmaly]] ([[User talk:Hkmaly\|talk]]) 09:54, 20 January 2014 (UTC)
−
−	The title text reminds me of the old joke about the definition of politics -- "poli-" meaning "many" and "tics" meaning "blood sucking creatures". --[[Special:Contributions/108.162.219.202\|108.162.219.202]] 12:31, 20 January 2014 (UTC)
−
−	~~Or the definition of polygon; "poly" = parrot and "gon" = gone (i.e., deceased). Therefore,~~
−	~~"dead parrot" [[Special:Contributions/141.101.99.236\|141.101.99.236]] 09:55, 21 January 2014 (UTC)~~
−
−	~~Why do the lines on the "Theory" graph converge shortly after automation takes over~~? Surely, the idea behind writing a code in this example is to save time. Therefore, the original task line should remain relatively constant and the coding line should plunge below it, no? {{unsigned\|Jevicci}}
−
−	: Once the automation takes over, the programmer will no longer have to do anything, the program will take care of it [[User:Raestloz\|Raestloz]] ([[User talk:Raestloz\|talk]]) 00:22, 21 January 2014 (UTC)
−
−	::Yes, but I agree with Jevicci's comment and that's what I was going to post. The point of the automation is (in theory) to save effort. After an initial input of lots of work coding, the "automation" line drops to near-zero. That makes sense, but the "regular way" line should continue horizontal like it does in the 2nd graph because if you don't automate, it should continue to take effort. The first chart suggests that even in theory, automation takes more work and the same amount of time as the old fashioned way.
−
−	::I think what Randall is trying to say is EITHER that a) programmers will automate for the sake of the challenge or it being less tedious than the basic way even if it doesn't save time. b) programmers will automate even if it doesn't save time because they can use the code next time the problem arises. But I agree, I think the first graph's "regular way" line should have either continued horizontal, or tappered off somewhere after the "automation" line does. [[User:TheHYPO\|TheHYPO]] ([[User talk:TheHYPO\|talk]]) 14:56, 21 January 2014 (UTC)
−
−	:::As far as I can tell, the line labelled "work on original task" is not meant to represent the amount of work you'd be doing without any automation (which would indeed remain a straight horizontal line), as the "theory" graph doesn't compare two separate scenarios. Rather, it's just there to be a baseline amount of work (programming work being done on top), which diminishes to near-zero as soon as automation takes over. [[Special:Contributions/108.162.231.221\|108.162.231.221]] 18:28, 21 January 2014 (UTC)
−
−	::::Yea, in the theory you would continue performing the task while also coding the automation. Once the automation is done, you work on neither the original nor the coding so both drop to zero. In practice, you keep doing the work and never finish the automation, so the coding goes up and the original stays the same. --[[Special:Contributions/173.245.48.29\|173.245.48.29]] 22:20, 21 January 2014 (UTC)
−
−	:::: It makes more sense if you see the lines as' amount of work existing for a task'. The two lines are the given work and work given to self. Top graph: The amount of work for the given task remains constant until you solve the automation (work you gave yourself) at which point both drop as given work is now done and you won't carry on working on the automation anymore, free time. The graph doesn't reach zero as there will always be more you could do (like Richardson's Theory). On the second graph, you never work on the original task, get consumed by automation and end up with far more work than was ever presented (as pointed out, after the rethink) and there is a total increase in the amount of work which exists for you, without actually touching the given work... whether it actually gets done in the end or not doesn't matter as you could stop and the graphs would stay like they are. [[Special:Contributions/141.101.99.248\|141.101.99.248]] 19:22, 22 January 2014 (UTC) thesuperkev
−
−	~~In other words, when automating, NEVER rethink. [[User:Greyson\|Greyson]] ([[User talk:Greyson\|talk]]) 00:21, 22 January 2014 (UTC)~~
−
−	~~:And if you really must rethink, at least deploy the program first. -- [[User:Hkmaly\|Hkmaly]] ([[User talk:Hkmaly\|talk]]) 10:17, 22 January 2014 (UTC)~~

← Older revision		Revision as of 10:17, 22 January 2014
Line 25:		Line 25:

	In other words, when automating, NEVER rethink. [[User:Greyson\|Greyson]] ([[User talk:Greyson\|talk]]) 00:21, 22 January 2014 (UTC)		In other words, when automating, NEVER rethink. [[User:Greyson\|Greyson]] ([[User talk:Greyson\|talk]]) 00:21, 22 January 2014 (UTC)
		+
		+	:And if you really must rethink, at least deploy the program first. -- [[User:Hkmaly\|Hkmaly]] ([[User talk:Hkmaly\|talk]]) 10:17, 22 January 2014 (UTC)

← Older revision		Revision as of 00:21, 22 January 2014
Line 23:		Line 23:

	::::Yea, in the theory you would continue performing the task while also coding the automation. Once the automation is done, you work on neither the original nor the coding so both drop to zero. In practice, you keep doing the work and never finish the automation, so the coding goes up and the original stays the same. --[[Special:Contributions/173.245.48.29\|173.245.48.29]] 22:20, 21 January 2014 (UTC)		::::Yea, in the theory you would continue performing the task while also coding the automation. Once the automation is done, you work on neither the original nor the coding so both drop to zero. In practice, you keep doing the work and never finish the automation, so the coding goes up and the original stays the same. --[[Special:Contributions/173.245.48.29\|173.245.48.29]] 22:20, 21 January 2014 (UTC)
		+
		+	In other words, when automating, NEVER rethink. [[User:Greyson\|Greyson]] ([[User talk:Greyson\|talk]]) 00:21, 22 January 2014 (UTC)