1691: "Optimization"

This forum is for the individual discussion thread that goes with each new comic.

Moderators: Moderators General, Prelates, Magistrates

User avatar
thunk
Posts: 480
Joined: Sat Apr 23, 2016 3:29 am UTC
Location: Arguably Exiled

1691: "Optimization"

Postby thunk » Wed Jun 08, 2016 4:04 am UTC

Image

Alt-text: "Premature optimization is the root of all evil, so to start this project I'd better come up with a system that can determine whether a possible optimization is premature or not."

Come to think of it, most flowcharts that I have seen have been drawn by Randall.
Anyway, what's so bad about premature optimization?
Free markets, free movement, free plops
Blitz on, my friends Quantized, GnomeAnne, and iskinner!
troo dat

User avatar
NeatNit
Posts: 44
Joined: Tue Apr 03, 2012 9:10 pm UTC

Re: 1691: "Optimization"

Postby NeatNit » Wed Jun 08, 2016 4:47 am UTC

thunk wrote:Anyway, what's so bad about premature optimization?

It's the root of all evil, which is pretty meaningless on its own and perfectly harmless. But if you accidentally make a square premature optimization, then you have a problem.

User avatar
ucim
Posts: 6859
Joined: Fri Sep 28, 2012 3:23 pm UTC
Location: The One True Thread

Re: 1691: "Optimization"

Postby ucim » Wed Jun 08, 2016 4:52 am UTC

thunk wrote:Anyway, what's so bad about premature optimization?
She never gets a chance to.... oh... uh... never mind.

Three reasons, really.

1: You spend time writing clever code you won't need, when the easier-to-write straightforward code would do the trick.

2: Since your code is clever, it is less clear. While this makes you seem awesome to anybody who looks at your code (and doesn't have to actually understand it), its disadvantages become clear once anybody (like you!) has to go back and figure out what it is supposed to do. You will have forgotten why you did that dumb oh yeah, it was awesomely clever because it was just a hair more {something}.

3: Debugging is harder than coding. This means that you can write code so cleverly you can't debug it. This usually turns out to be sub-optimal;

4: The requirements will change. This cleverly optimized thing you just did will either not be needed any more, or will need to be rewritten to do something that your optimization is no longer optimal (or even servicable) for.

5: Five is right out!

Jose
Order of the Sillies, Honoris Causam - bestowed by charlie_grumbles on NP 859 * OTTscar winner: Wordsmith - bestowed by yappobiscuts and the OTT on NP 1832 * Ecclesiastical Calendar of the Order of the Holy Contradiction * Heartfelt thanks from addams and from me - you really made a difference.

User avatar
rhomboidal
Posts: 797
Joined: Wed Jun 15, 2011 5:25 pm UTC
Contact:

Re: 1691: "Optimization"

Postby rhomboidal » Wed Jun 08, 2016 5:03 am UTC

You really need to wait at least half an hour before trying again after premature optimization. (I've HEARD.)

User avatar
thunk
Posts: 480
Joined: Sat Apr 23, 2016 3:29 am UTC
Location: Arguably Exiled

Re: 1691: "Optimization"

Postby thunk » Wed Jun 08, 2016 5:10 am UTC

ucim wrote:
thunk wrote:Anyway, what's so bad about premature optimization?
She never gets a chance to.... oh... uh... never mind.

Three reasons, really.

1: You spend time writing clever code you won't need, when the easier-to-write straightforward code would do the trick.

2: Since your code is clever, it is less clear. While this makes you seem awesome to anybody who looks at your code (and doesn't have to actually understand it), its disadvantages become clear once anybody (like you!) has to go back and figure out what it is supposed to do. You will have forgotten why you did that dumb oh yeah, it was awesomely clever because it was just a hair more {something}.

3: Debugging is harder than coding. This means that you can write code so cleverly you can't debug it. This usually turns out to be sub-optimal;

4: The requirements will change. This cleverly optimized thing you just did will either not be needed any more, or will need to be rewritten to do something that your optimization is no longer optimal (or even servicable) for.

5: Five is right out!

Jose


Thanks, Jose. Now I know. It's one of those coding things that I'm still learning, because I'm only dipping my toes into it.
Free markets, free movement, free plops
Blitz on, my friends Quantized, GnomeAnne, and iskinner!
troo dat

ps.02
Posts: 378
Joined: Fri Apr 05, 2013 8:02 pm UTC

Re: 1691: "Optimization"

Postby ps.02 » Wed Jun 08, 2016 6:00 am UTC

ucim wrote:
thunk wrote:Anyway, what's so bad about premature optimization?
Three reasons, really.

These are good reasons, but I think the main thing is that it's really easy to incur the costs Jose describes without actually getting much benefit. Making something faster is only useful if that thing is noticeably slow in the first place. Obvious, yes? But it's not always obvious in practice. It is far too easy to assume, wrongly, that something be slow enough to be worth optimizing. That's the premature aspect.

And even if you know a system as a whole is slow and needs work, you can find yourself spending huge efforts to optimize the wrong thing. Say you're iterating over a million database rows and you need to speed this up. You can say "This loop executes a million times, we need to make the inside of it as fast as possible. Allocating and freeing a buffer each time is ridiculous. Let's just allocate one buffer and reuse it for every iteration." Sensible and effective - maybe. But maybe instead you should have been asking, "Huh, why are we looking at 1 million rows at all? Can we use a smarter query so the database server just gives us the actual answer we wanted in the first place?"

User avatar
Gingercat
Posts: 445
Joined: Thu Nov 07, 2013 4:19 am UTC
Location: Ceiling

Re: 1691: "Optimization"

Postby Gingercat » Wed Jun 08, 2016 6:08 am UTC

There's also the risk that "optimising" one section, say in code, will break another section that relies on how the first section "normally" functions.

Yes, this can indicate a lazy approach having been taken to begin with ("Section X takes exactly 45ms to complete, so I'll code Section Y to wait for 46ms then execute"), but if your "optimisation" results in far more time lost with subsequent twerking than you would have lost by simply leaving it as-is, then you've prematurely optomised. :)
I am Schrödinger's Gingercat.

commodorejohn
Posts: 1180
Joined: Thu Dec 10, 2009 6:21 pm UTC
Location: Placerville, CA
Contact:

Re: 1691: "Optimization"

Postby commodorejohn » Wed Jun 08, 2016 6:33 am UTC

Jose pretty much nailed the disadvantages, so I'll just take this opportunity to stump for taking the time to do things right:
  • You don't waste nearly as much time putting full development effort into bad designs.
  • You'll have to refactor/re-engineer anyway, because you always will, but when you do you'll have a lot of possible bad directions already ruled out by simple thoughtful analysis.
  • For every hour spent on problem analysis, the chances of you creating a list-sorting program that weighs in at 60MB executable size and summons Satan in the error handler decrease by 5%. Science fact!
Remember, kids, it's "premature optimization is the root of all evil," not "optimization is the root of all evil."
"'Legacy code' often differs from its suggested alternative by actually working and scaling."
- Bjarne Stroustrup
www.commodorejohn.com - in case you were wondering, which you probably weren't.

peejunk
Posts: 1
Joined: Thu Feb 03, 2011 11:32 am UTC

Re: 1691: "Optimization"

Postby peejunk » Wed Jun 08, 2016 7:47 am UTC

However, both the image and the caption are not examples of premature optimization but of overengineering, which is related but not the same.

User avatar
orthogon
Posts: 3077
Joined: Thu May 17, 2012 7:52 am UTC
Location: The Airy 1830 ellipsoid

Re: 1691: "Optimization"

Postby orthogon » Wed Jun 08, 2016 8:12 am UTC

rhomboidal wrote:You really need to wait at least half an hour before trying again after premature optimization. (I've HEARD.)

Yeah, there's inevitably going to be downtime before you can get the system up again.
xtifr wrote:... and orthogon merely sounds undecided.

User avatar
sfmans
Posts: 104
Joined: Mon Jun 23, 2014 9:09 am UTC
Location: High Peak, UK

Re: 1691: "Optimization"

Postby sfmans » Wed Jun 08, 2016 11:27 am UTC

If, to follow the recent theme, you replace Prematurely optimizing with DevOps it is also just as true ...

User avatar
cellocgw
Posts: 2053
Joined: Sat Jun 21, 2008 7:40 pm UTC

Re: 1691: "Optimization"

Postby cellocgw » Wed Jun 08, 2016 11:33 am UTC

thunk wrote:
Thanks, Jose. Now I know. It's one of those coding things that I'm still learning, because I'm only dipping my toes into it.


In that case, get out while you still have a chance! RUN AWAAAAAYYYYY
https://app.box.com/witthoftresume
Former OTTer
Vote cellocgw for President 2020. #ScienceintheWhiteHouse http://cellocgw.wordpress.com
"The Planck length is 3.81779e-33 picas." -- keithl
" Earth weighs almost exactly π milliJupiters" -- what-if #146, note 7

User avatar
cellocgw
Posts: 2053
Joined: Sat Jun 21, 2008 7:40 pm UTC

Re: 1691: "Optimization"

Postby cellocgw » Wed Jun 08, 2016 11:34 am UTC

orthogon wrote:
rhomboidal wrote:You really need to wait at least half an hour before trying again after premature optimization. (I've HEARD.)

Yeah, there's inevitably going to be downtime before you can get the system up again.


So he answers a double entendre with a double entendre :oops:
https://app.box.com/witthoftresume
Former OTTer
Vote cellocgw for President 2020. #ScienceintheWhiteHouse http://cellocgw.wordpress.com
"The Planck length is 3.81779e-33 picas." -- keithl
" Earth weighs almost exactly π milliJupiters" -- what-if #146, note 7

User avatar
Eternal Density
Posts: 5579
Joined: Thu Oct 02, 2008 12:37 am UTC
Contact:

Repeating the joke: 1691: "Optimization"

Postby Eternal Density » Wed Jun 08, 2016 11:48 am UTC

Premature optimisation is a real relationship killer.
Play the game of Time! castle.chirpingmustard.com Hotdog Vending Supplier But what is this?
In the Marvel vs. DC film-making war, we're all winners.

User avatar
Whizbang
The Best Reporter
Posts: 2238
Joined: Fri Apr 06, 2012 7:50 pm UTC
Location: New Hampshire, USA

Re: 1691: "Optimization"

Postby Whizbang » Wed Jun 08, 2016 12:14 pm UTC

Postmature ejacoptimization is also less desirable.

User avatar
orthogon
Posts: 3077
Joined: Thu May 17, 2012 7:52 am UTC
Location: The Airy 1830 ellipsoid

Re: 1691: "Optimization"

Postby orthogon » Wed Jun 08, 2016 12:36 pm UTC

cellocgw wrote:
orthogon wrote:
rhomboidal wrote:You really need to wait at least half an hour before trying again after premature optimization. (I've HEARD.)

Yeah, there's inevitably going to be downtime before you can get [it] up again.


So he answers a double entendre with a double entendre :oops:

If not two. I was going to add that it was good practice to have a backup (preferably capable of running on battery power) available to service the client in the meantime.
xtifr wrote:... and orthogon merely sounds undecided.

User avatar
Soupspoon
You have done something you shouldn't. Or are about to.
Posts: 4060
Joined: Thu Jan 28, 2016 7:00 pm UTC
Location: 53-1

Re: 1691: "Optimization"

Postby Soupspoon » Wed Jun 08, 2016 1:35 pm UTC

I was going to say something about hardware and software, but I successfully held myself back.

DanD
Posts: 333
Joined: Tue Oct 05, 2010 12:42 am UTC

Re: 1691: "Optimization"

Postby DanD » Wed Jun 08, 2016 2:08 pm UTC

Premature optimization means you're spending a lot of time making something perfect when there's still a decent chance you're going to throw it out before launch.

Make it work first, then make it perfect.

rmsgrey
Posts: 3631
Joined: Wed Nov 16, 2011 6:35 pm UTC

Re: 1691: "Optimization"

Postby rmsgrey » Wed Jun 08, 2016 3:31 pm UTC

Premature optimisation isn't just a software issue - in any design job it's possible to focus in on some minor element that ends up being irrelevant because it doesn't fit with the major features. For example: writing a story, it's easy to get sucked into editing and rewriting a particular scene, only to find later that the plot goes a different way than you were expecting, and all the foreshadowing, character development, subtle exposition, and whatever else you invested that scene with is no longer relevant (except maybe as a "deleted scene" extra if you do that sort of thing) and you have to either unravel those elements from the scene, or scrap the scene entirely...

Of course, the other side - taking the time to do it right in the first place - also applies broadly - you can throw in a quick place-holder element (a random number routine that always returns '4'; an Ikea chair; a two-line summary of the scene) but you're going to have to come back eventually and come up with a real version - and when you do, you're going to have to remind yourself what it needs to do, so you'll need to spend more time and effort on it than you would if you just did it properly now while you know what's needed. And, of course, if you don't do it now, there's a risk that you'll forget it later, and the placeholder will end up in the final product...

airdrik
Posts: 245
Joined: Wed May 09, 2012 3:08 pm UTC

Re: 1691: "Optimization"

Postby airdrik » Wed Jun 08, 2016 4:04 pm UTC

rmsgrey wrote:... and the placeholder will end up in the final product...

All too true!

How many times does the prototype become the final version "because you've already written it, just ship it as-is" (despite the fact that with software prototypes, the code is intentionally bug-ridden and unmaintainable because you wrote it with the intent to get something out quickly so it can be demoed so you can get feedback about what they really want, and then throw the whole thing away and start from scratch on the real version) "We don't have time for a full rewrite. You have something working, just fix the bugs and ship it!" (as if that is really any faster/cheaper than starting from scratch).

Of course you can't start with the full version because it'll be 6 months before the first demo and they want to see something in 3 weeks so they can approve it, or whatever.

User avatar
PM 2Ring
Posts: 3713
Joined: Mon Jan 26, 2009 3:19 pm UTC
Location: Sydney, Australia

Re: 1691: "Optimization"

Postby PM 2Ring » Thu Jun 09, 2016 9:46 am UTC

According to Wikiquote there are two versions of this remark about premature optimization in Knuth's writings. Knuth calls it "Hoare's Dictum", after fellow computer scientist Tony Hoare (inventor of Quicksort, etc), but that's just Knuth having a bit of fun.

Donald Knuth wrote:The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.

and
Donald Knuth wrote:Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.


Some people repeat this aphorism omitting the "premature" part, which drastically changes its meaning. And a lot of people repeat it without mentioning the 97% / 3%, which is a shame, but I guess that's not quite so bad. Most new programmers have heard some version of this aphorism, and it's fine if it discourages them from wasting time on silly optimizations. Of course, that doesn't mean you should use a hopelessly inefficient algorithm when a more efficient one is well-known and just as easy to code. As for the 3%, newbie programmers simply don't have the requisite skills or experience to do the kind of optimization Knuth is alluding to, so they should be discouraged from attempting it. ;)

User avatar
Soupspoon
You have done something you shouldn't. Or are about to.
Posts: 4060
Joined: Thu Jan 28, 2016 7:00 pm UTC
Location: 53-1

Re: 1691: "Optimization"

Postby Soupspoon » Thu Jun 09, 2016 2:51 pm UTC

There's a peculiar 'institutional pre-optimisation' that seems to result in an engrained trap of disoptimisation for the unwary, at least in my mind.

As an example from libpng, function png_sig_cmp() returns 0/false if the passed filesig matches, and nonzero/true otherwise, a not uncommn system. It ties up with the standard of fail-returns being potentially informative, but success-return has nothing more to say.

And, truly "no difference from expectations", if that's how you read the cmp, probably should return zero. But the universal association of "zero==falseness" is also an engrained property of the whole environment. A trap for the unwary!

And then the documented method for how to use this is:

Code: Select all

is_png = !png_sig_cmp(header, 0, number);
if (!is_png)
{
    return (NOT_PNG);
}


Miss xeither ! and its an instant error. And don't you dare try "if (png_sig_cmp(...)) {...}", straight through, without sufficient commentary for later readers of your code...

(You should probably go off-piste and try "dif_png = png_sig_cmp(...);", if you don't mind sacrificing convention for readability.)

But the compiler will probably optimise it all down, later, anyway... Regardless of human readability, making all valid forms of the code moot and all others just as wrong, but perhaps more quickly so.

xtifr
Posts: 364
Joined: Wed Oct 01, 2008 6:38 pm UTC

Re: 1691: "Optimization"

Postby xtifr » Fri Jun 10, 2016 1:41 am UTC

I tend to think of premature optimization as optimization done before you've profiled the code to identify bottlenecks. Saving fifty ns when your code is about to hang up waiting for a disc read, for example, is silly.

Another overlooked disadvantage these days is that the compiler is frequently much better at it than you are. Compilers are excellent, for example, at hoisting invariant conditions out of a loop. So running around looking for invariant conditions to manually hoist out of loops tends to be a total waste of your time.

Worst case, overoptimization of the source code can actually confuse the compiler, and cause it to overlook potential optimizations it would have applied to the naive, simpler, original code, resulting in <em>poorer</em> performance. Especially since it probably knows more about the underlying CPU architecture than you do.
"[T]he author has followed the usual practice of contemporary books on graph theory, namely to use words that are similar but not identical to the terms used in other books on graph theory."
-- Donald Knuth, The Art of Computer Programming, Vol I, 3rd ed.

commodorejohn
Posts: 1180
Joined: Thu Dec 10, 2009 6:21 pm UTC
Location: Placerville, CA
Contact:

Re: 1691: "Optimization"

Postby commodorejohn » Fri Jun 10, 2016 2:44 am UTC

xtifr wrote:Another overlooked disadvantage these days is that the compiler is frequently much better at it than you are. Compilers are excellent, for example, at hoisting invariant conditions out of a loop. So running around looking for invariant conditions to manually hoist out of loops tends to be a total waste of your time.

Worst case, overoptimization of the source code can actually confuse the compiler, and cause it to overlook potential optimizations it would have applied to the naive, simpler, original code, resulting in <em>poorer</em> performance. Especially since it probably knows more about the underlying CPU architecture than you do.

Some of us would say that's not a problem of over-optimization, but of tools trying to be too smart for their own good and/or insufficient low-level knowledge on the part of the programmer ;)
"'Legacy code' often differs from its suggested alternative by actually working and scaling."
- Bjarne Stroustrup
www.commodorejohn.com - in case you were wondering, which you probably weren't.

Mikeski
Posts: 1099
Joined: Sun Jan 13, 2008 7:24 am UTC
Location: Minnesota, USA

Re: 1691: "Optimization"

Postby Mikeski » Fri Jun 10, 2016 8:53 am UTC

commodorejohn wrote:tools trying to be too smart for their own good and/or insufficient low-level knowledge on the part of the programmer ;)

Easily solved. Programmers with sufficient low-level knowledge should be programming compilers which will be too smart for their own good. Programmers without that knowledge can write the video games and web browsers.

(edit: apparently, I cannot spell at 3AM.)
Last edited by Mikeski on Fri Jun 10, 2016 4:57 pm UTC, edited 1 time in total.

User avatar
Echo244
Posts: 511
Joined: Wed May 20, 2015 9:49 am UTC
Location: Ping! Ping! Ping! Ping!

Re: 1691: "Optimization"

Postby Echo244 » Fri Jun 10, 2016 9:01 am UTC

commodorejohn wrote:Some of us would say that's not a problem of over-optimization, but of tools trying to be too smart for their own good and/or insufficient low-level knowledge on the part of the programmer ;)


The power and speed with which a solution can be created by a lot of modern tools, stacked on top of the low cost of throwing processing power and storage at inefficient solutions, mean quite a lot of things are being built in a way reliant on lower levels being a black box optimised by the compiler that the actual human developer doesn't need to understand the inner workings of.

(Which has been true for a while, but that "lower levels" bar is moving up the stack)

Poking through what the tool is *actually* doing at a lower level seems to be not just a slightly old-fashioned art, but a not-always-necessary one.
Unstoppable force of nature. That means she/her/hers.
Has committed an act of treason.

rmsgrey
Posts: 3631
Joined: Wed Nov 16, 2011 6:35 pm UTC

Re: 1691: "Optimization"

Postby rmsgrey » Fri Jun 10, 2016 1:42 pm UTC

Yeah, for most routine tasks, the automated tools can do it faster than you can, can do it about as well, if not better, aren't constrained by considerations like readability of source code, and their version is based in more development time, and many hours more testing than you have the development budget for on your current project.

xtifr
Posts: 364
Joined: Wed Oct 01, 2008 6:38 pm UTC

Re: 1691: "Optimization"

Postby xtifr » Fri Jun 10, 2016 11:42 pm UTC

commodorejohn wrote:
xtifr wrote:Worst case, overoptimization of the source code can actually confuse the compiler, and cause it to overlook potential optimizations it would have applied to the naive, simpler, original code, resulting in <em>poorer</em> performance. Especially since it probably knows more about the underlying CPU architecture than you do.

Some of us would say that's not a problem of over-optimization, but of tools trying to be too smart for their own good [...]


Hey, the programmers may be misguided in such a case, but I think it's a little extreme to call them tools! :D

(eta: I did say worst case. The standard, and most common case, is that the programmer spends a bunch of time rearranging the code to try to make it more optimal (and harder to read), and the result is no change in performance, since the compiler was already doing those same rearrangements behind the scene.)
"[T]he author has followed the usual practice of contemporary books on graph theory, namely to use words that are similar but not identical to the terms used in other books on graph theory."
-- Donald Knuth, The Art of Computer Programming, Vol I, 3rd ed.

User avatar
ucim
Posts: 6859
Joined: Fri Sep 28, 2012 3:23 pm UTC
Location: The One True Thread

Re: 1691: "Optimization"

Postby ucim » Sat Jun 11, 2016 12:53 am UTC

xtifr wrote:...since the compiler was already doing those same rearrangements behind the scene
N/A for interpreted languages like Python, I presume. And they are getting quite commonplace.

(I'm still not sure what the advantage of interpreted languages are... compiling should be a minor step, and I have to upload to the (web)site before using it anyway.)

Jose
Order of the Sillies, Honoris Causam - bestowed by charlie_grumbles on NP 859 * OTTscar winner: Wordsmith - bestowed by yappobiscuts and the OTT on NP 1832 * Ecclesiastical Calendar of the Order of the Holy Contradiction * Heartfelt thanks from addams and from me - you really made a difference.

User avatar
Soupspoon
You have done something you shouldn't. Or are about to.
Posts: 4060
Joined: Thu Jan 28, 2016 7:00 pm UTC
Location: 53-1

Re: 1691: "Optimization"

Postby Soupspoon » Sat Jun 11, 2016 1:36 am UTC

ucim wrote:(I'm still not sure what the advantage of interpreted languages are... compiling should be a minor step, and I have to upload to the (web)site before using it anyway.)
(Architecture-independance? Yes, there's always some portability problems if you make undue assumptions about the file-system, etc, but well-written scripts work through local interpretation across a wide variety of machines, whilst compiled executables need to be more rigorously matched to the system they're being copied to. Of course, this leaves plenty of chances for non-sequitur 'code' to be included that forces the interpreter to crash out of its task, and all that reading of human-readable (<-theoretically!) ASCII waste-of-space unoptimised junk takes time to parse and translate, each and every pass, into local functionality...

The mid-point is the 'bytecode' solution, you 'half-compile' (weeding out 'interpretation errors' at that point) into a form that architecturely-attuned versions of a program can then quickly run through, in the full knowledge that (logic bombs aside) they quickly know how to present to the processor the appropriate machine-level instructions that will work locally, shorn of much of the overhead already dealt with in de-abstracting the original plaintext 'code', probably encapsulated in OO layers, into something much closer to the actual register pushing/popping behaviour that it all necessarily boils down to.)

rmsgrey
Posts: 3631
Joined: Wed Nov 16, 2011 6:35 pm UTC

Re: 1691: "Optimization"

Postby rmsgrey » Sat Jun 11, 2016 12:14 pm UTC

One of the big advantages of interpreted languages is interactivity - rather than needing to perform an explicit compile step, you can just enter code and get an immediate result. That's also basically how text-driven OS interfaces work, so if you're using a text-based OS interface, extending that to a full interpreted language means only needing to learn a few new things rather than having to learn an entire new language.

User avatar
ucim
Posts: 6859
Joined: Fri Sep 28, 2012 3:23 pm UTC
Location: The One True Thread

Re: 1691: "Optimization"

Postby ucim » Sat Jun 11, 2016 2:57 pm UTC

I can see the advantage of being able to run a few commands on the fly, but in real life, people mainly write programs with languages, no?

Soupspoon wrote:...well-written scripts work through local interpretation across a wide variety of machines, whilst compiled executables need to be more rigorously matched to the system they're being copied to.
I would imagine the interpreter has to be just as well matched as the compiler does, no? The end is still machine language, just a compiler just does it once.

Soupspoon wrote:The mid-point is the 'bytecode' solution, you 'half-compile'
That sounds like a decent halfway point - you obviously can't optimize, but at least you don't have to keep interpreting every statement in a loop.

rmsgrey wrote:...rather than needing to perform an explicit compile step, you can just enter code and get an immediate result.
That's the advantage I don't see the big deal of. Unless you're using the commands interactively, you're still (for example) creating a program, uploading it to a website, and then clicking on a link. So what's the advantage of having an interpreter on your server, rather than a compiler (which can also check for dumb errors before you actually try to run it)? You could even set the compiler to auto-compile anything new. If you reduce the optimization to zero, it seems to me you're pretty close to the bytecode solution anyway.

rmsgrey wrote:only needing to learn a few new things rather than having to learn an entire new language
Only applies if you are just running a few free-form commands for jollies. And that applies to compiled languages too, although presumably if you're using a complied language, you're probably writing a program, which might not be true for an interpreted one.

I guess the real question would be "Why isn't there a real compiler available for Python or PHP, as a natural part of the language?

Jose
Order of the Sillies, Honoris Causam - bestowed by charlie_grumbles on NP 859 * OTTscar winner: Wordsmith - bestowed by yappobiscuts and the OTT on NP 1832 * Ecclesiastical Calendar of the Order of the Holy Contradiction * Heartfelt thanks from addams and from me - you really made a difference.

Kit.
Posts: 1117
Joined: Thu Jun 16, 2011 5:14 pm UTC

Re: 1691: "Optimization"

Postby Kit. » Sat Jun 11, 2016 3:16 pm UTC

ucim wrote:(I'm still not sure what the advantage of interpreted languages are... compiling should be a minor step, and I have to upload to the (web)site before using it anyway.)

O-ok... what would you be compiling, say, HTML ("hypertext markup language") into?

ETA:
ucim wrote:I guess the real question would be "Why isn't there a real compiler available for Python or PHP, as a natural part of the language?

There is Pyston, for example. The problem is that with dynamically-typed languages you are not gaining most of the benefits the compiler could provide for statically-typed languages, such as compile-time type checks and code optimization.

User avatar
Soupspoon
You have done something you shouldn't. Or are about to.
Posts: 4060
Joined: Thu Jan 28, 2016 7:00 pm UTC
Location: 53-1

Re: 1691: "Optimization"

Postby Soupspoon » Sat Jun 11, 2016 3:35 pm UTC

ucim wrote:
Soupspoon wrote:...well-written scripts work through local interpretation across a wide variety of machines, whilst compiled executables need to be more rigorously matched to the system they're being copied to.
I would imagine the interpreter has to be just as well matched as the compiler does, no? The end is still machine language, just a compiler just does it once.
The interpreter has to be written once per platform, give or take its own shortcomings and bugs, no matter the number of scripts, debugged scripts, improved scripts, derivative scripts and downright hacked scripts that are thence run upon it.

Every variation of compiled code needs to be compiled to be tested upon the test machine, may need recompiling to test upon the target machine, recompiled for the upgraded machine... (Scripts can suffer transfer-failure, too, but often can be more easily edited.)

You can compile target-machine executable code by a compiler that itself runs on source-machine architecture, but this is then 'foreign' to the origin machine and you can only (re)test it, VMs aside, on the intended destination, to the same disadvantage as scripts.

And all this means that Bytecode-type halfway houses are either "best of both worlds" or "worst of both worlds", depending on your POV. ;)

commodorejohn
Posts: 1180
Joined: Thu Dec 10, 2009 6:21 pm UTC
Location: Placerville, CA
Contact:

Re: 1691: "Optimization"

Postby commodorejohn » Sat Jun 11, 2016 3:59 pm UTC

ucim wrote:I can see the advantage of being able to run a few commands on the fly, but in real life, people mainly write programs with languages, no?

Primarily, yes, but I can see the appeal in being able to test algorithms on the fly when you're still working out your approach. It certainly beats my usual "write two or three little separate test programs for each significant piece of the whole" approach. The downside is that, uh, you have to do it in Python. (Unfortunately, it seems like most other modern interpreted languages aren't even well-suited for doing that, as they seem to follow the write-mode/run-mode split that the likes of GWBASIC used, so you can't simply declare a function and then test it without writing a test program, even if there's no formal compile step. Forth and Lisp are the only major exceptions I can think of off-hand.)
"'Legacy code' often differs from its suggested alternative by actually working and scaling."
- Bjarne Stroustrup
www.commodorejohn.com - in case you were wondering, which you probably weren't.

User avatar
ucim
Posts: 6859
Joined: Fri Sep 28, 2012 3:23 pm UTC
Location: The One True Thread

Re: 1691: "Optimization"

Postby ucim » Sat Jun 11, 2016 4:22 pm UTC

Kit. wrote:O-ok... what would you be compiling, say, HTML ("hypertext markup language") into?
HTML isn't a programming language. It lacks branching. But, given my druthers, I'd compile it all into whitespace. :)

Kit. wrote:The problem is that with dynamically-typed languages you are not gaining most of the benefits the compiler could provide for statically-typed languages, such as compile-time type checks and code optimization.
Good point. I'd then ask why the web languages are dynamically typed (and then realize that the web IO is all text, so your handed worms every time). Still, I'd wish for a statically typed language with functions that will turn text into the declared type, flagging for errors at runtime. (I suppose if this were corrupt-a-wish, it simply would be granted without any (additional) corruption. Be careful what you wish for!)

But you do gain raw speed, and thus scalability. (I may not care that a web page is computed in .001 sec, or .000001 sec, but with a million visitors, I begin to notice.)

Soupspoon wrote:Every variation of compiled code needs to be compiled to be tested upon the test machine, may need recompiling to test upon the target machine, recompiled for the upgraded machine.
Yes, but that's not what I'm really looking for. Suppose every platform that had an interpreter, had instead a compiler. The resulting code would always be native.

Are (not-very-optimizing) compilers that much harder to write than interpreters?

Soupspoon wrote:And all this means that Bytecode-type halfway houses are either "best of both worlds" or "worst of both worlds", depending on your POV.
I hear you.

Jose
Order of the Sillies, Honoris Causam - bestowed by charlie_grumbles on NP 859 * OTTscar winner: Wordsmith - bestowed by yappobiscuts and the OTT on NP 1832 * Ecclesiastical Calendar of the Order of the Holy Contradiction * Heartfelt thanks from addams and from me - you really made a difference.

User avatar
Soupspoon
You have done something you shouldn't. Or are about to.
Posts: 4060
Joined: Thu Jan 28, 2016 7:00 pm UTC
Location: 53-1

Re: 1691: "Optimization"

Postby Soupspoon » Sat Jun 11, 2016 4:29 pm UTC

commodorejohn wrote: Forth and Lisp are the only major exceptions I can think of off-hand.)
But with these, at least, you can polish your notation both backwards and forwards!

ThemePark
Posts: 450
Joined: Fri Jun 27, 2008 5:42 pm UTC
Location: Århus, Denmark

Re: 1691: "Optimization"

Postby ThemePark » Sat Jun 11, 2016 4:53 pm UTC

Soupspoon wrote:
commodorejohn wrote: Forth and Lisp are the only major exceptions I can think of off-hand.)
But with these, at least, you can polish your notation both backwards and forwards!

Badum-tsch!
I have traveled from 1979 to be a member of the unofficial board Council of Elders. Phear M3

User avatar
ucim
Posts: 6859
Joined: Fri Sep 28, 2012 3:23 pm UTC
Location: The One True Thread

Re: 1691: "Optimization"

Postby ucim » Sat Jun 11, 2016 4:53 pm UTC

I C what you did there.

Jose
Order of the Sillies, Honoris Causam - bestowed by charlie_grumbles on NP 859 * OTTscar winner: Wordsmith - bestowed by yappobiscuts and the OTT on NP 1832 * Ecclesiastical Calendar of the Order of the Holy Contradiction * Heartfelt thanks from addams and from me - you really made a difference.

Kit.
Posts: 1117
Joined: Thu Jun 16, 2011 5:14 pm UTC

Re: 1691: "Optimization"

Postby Kit. » Sat Jun 11, 2016 5:07 pm UTC

ucim wrote:
Kit. wrote:O-ok... what would you be compiling, say, HTML ("hypertext markup language") into?
HTML isn't a programming language. It lacks branching.

HTML has branching on user input, as well as some server-side branching extensions (such as PHP).

ucim wrote:But, given my druthers, I'd compile it all into whitespace. :)

No hyperlinks and no web forms for you then?

ucim wrote:I'd then ask why the web languages are dynamically typed

That allows for faster prototyping by cheaper developers. And most of time the prototypes are "good enough" for production.

ucim wrote:But you do gain raw speed, and thus scalability.

Raw speed has nothing to do with scalability. Actually, interpreted code could be easier to parallelize than pre-compiled one.


Return to “Individual XKCD Comic Threads”

Who is online

Users browsing this forum: orion205, ronaldkr and 102 guests