While I appreciate your intent, what actual practical difference is there for the end user between those two disclaimers? One creates a far better impression, of course, and suggests better quality in the rest of the project; but as disclaimers, don't they they both boil down to exactly the same thing?
Software developers should take pride in their work...
Absolutely. But how can you enforce that? We could just as well have a law stating that "Everyone must be excellent to one another"...
...and shouldn't release things that they aren't proud to claim.
Claim as what precisely? In particular, how do open source projects get started? With a fully working product? Of course not. They start with an idea, and some code that goes only part (in many cases, a very small part) of the way to fulfilling that idea. If software had to be guaranteed to work, then most open source projects wouldn't even get started...
Small projects, particularly. I'm an open source developer, and I've written something small to solve a problem of my own. Do I release it? At present, the cost-benefit is fairly straightforward: some time to write a bit of doc, rework the ugliest bits of code, and think a bit about how other folks might use it. Easy enough. And the benefits: I get to use the better code, other people get to use it too, maybe my name gets known a bit, and maybe I get input from other people too.
But under your proposed legislation, the balance is very different. Benefits: as above. Costs: much, much, much more effort in making damn sure it works. And the risk of getting sued to smithereens if I miss anything. Hmmm... do I share, or do I not bother? Difficult one...
Not to mention that one of the other major benefits to open source software -- that all bugs are shallow to enough eyes -- is meaningless if nothing's released until it has no bugs!
Yes, of course all software should do what it says, and of course developers should take pride in it, but you don't show any understanding of how software gets written in the first place.
But that's the point. The Ring didn't appear particularly evil when first used; that's why it's such a shock to Frodo in LOTR to find out its origin.
(Of course, there were suspicious circumstances attached to it: Gollum's extreme possessiveness; its magical nature; Bilbo hiding it and then lying about its origin. Gandalf was suspicious of it from the first; in the film, maybe a few telling glances from him could speak volumes.)
That's often the nature of evil; it's deceptive and can appear perfectly innocent at first. (I know Tolkien didn't intend any direct allegories in his work, but occasional resonances like that do happen.)
Yes, McKellen and Weaving will be fine, but I doubt Ian Holm would be a good choice for Bilbo. Bilbo is about 51 in The Hobbit, but hobbits are longer-lived than we are, and that's probably equivalent to thirty or so in human terms. There's no way Holm can pass for that sort of age any more!
Nor do I think that continuity with LOTR is a good argument here. Yes, there he's 'well-preserved' for 111, but there are still some changes, and in the flashback to the finding of the ring, he's made to look younger. I doubt that, several years since that was filmed, they'd be able to keep that up for an entire movie.
No, I think we'll have to get used to the idea of someone else playing Bilbo. If they choose well, that someone will bring a liveliness and sense of humour to the story which will probably turn out for the best.
IKWYM, but I think it's wrong to judge the films on the theatrical versions alone.
I know that traditionally, the theatrical version has been the 'definitive' one, and that DVD extras have been add-ons thrown in quickly to make up the weight. However, despite PJ's comments a few months ago, IMO the definitive versions of LOTR are really the extended DVD editions. They have better pacing, a more coherent plotline, lots of telling details -- in short, the story is given more room to breathe, and works all the better for it.
So please don't judge ROTK until you've seen the EE. If the first two are anything to go by, I suspect we'll see a lot more character development (hopefully involving Denethor's corruption, and Faramir's and Eowyn's recoveries, and maybe more of Aragorn, as well as Saruman's closure), better explanation and progression of the plot, better pacing, and more balance in the grand themes and symbolism. Calling the theatrical versions 'edited highlights' would be unfair, but perhaps it wouldn't be that far from the truth. It's amazing what PJ managed to pack into each 3-hour slot; but the EEs are more amazing still.
Of course, even the EE won't be perfect. There are still flaws, awkward issues and disappointments. But despite those, I think LOTR is a magnificent achievement, wonderful to watch and better than we had any right to hope for.
BTW, I wonder if his may be the start of a deep change in the industry, where what you see in the cinema is no longer seen as the most important part of moviemaking, and where DVD &c editions may come to take on equal or greater importance overall.
Mac OS X Mail lets you run an AppleScript as a result of any of the mail rules you can set. For example, I've got a little one which announces new mail -- it speaks "Mail from <sender>", which is rather handy.
AppleScripts can run Unix-level commands, as well as accessing apps at an excitingly deep level, so you could probably do all you wanted with it, and more.
Why not use the comparison with Peter and the Wolf?
Because Wagner did most to promote letimotif as a powerful and complex tool, and is most associated with it. Yes, Weber used it first, as did Prokofiev many years later; but in Peter and the Wolf it's used in an obvious, childish manner (not that there's anything wrong with that in a piece aimed at children!), quite unlike the depth and richness that Wagner's more abstract and imaginative use brought to his operas.
The association of music with character is as strong
Oh yes; but that's not exactly what I'm talking about. Wagner uses motifs for abstractions, not just for particular people. They bring new ideas, resonances, and connections, adding to the meaning of the story as well as its emotion.
And this is what I think Shore does in LOTR. One of the more obvious examples I noticed is the well-known 'fellowship' theme, which is used throughout all three films to emphasise the support and comfort people can give each other, and how they can do more together than separately.
Perhaps you actually like Wagner
Er, no, actually. I like a few of the obvious bits, and I can take more in smallish doses... But I can still appreciate what he did, and how he developed the musical form.
Maybe the word is a little pretentious, but it's not that uncommon, and there's nothing simpler that describes it well. Terms like 'thematic development' and 'recurring ideas' don't do justice to the deep connection between music and story. And 'that bit, you know, the one that goes der-ner-ner DAH du-dum pom pom whenever the baddie turns up' is a bit long-winded.
But a movie score is about more than just good tunes. A movie score isn't (or at least, shouldn't be) a piece of music on its own, but a part of the movie. And Howard Shore's three scores are that, to a depth and degree that most other scores don't reach.
He uses styles and references to mediaeval, folk, and other music suited to the setting; he writes highly appropriate music for some of the many songs that feature in the book; he evokes the magical, the mystical, the transcendent, the strange, the ugly, the fearsome, the heroic, while only rarely dropping into cliche or banality.
But more than this, his use of leitmotif is almost Wagnerian. His themes, far more than just attaching to particular people or emotions (as in most films), are connected with abstractions like fellowship, the power of evil, hope, inheritance, and destiny. If you listen closely, his music doesn't just underscore the emotion of a scene, but comments on its deeper meaning, and makes allusions which can be surprising in their insight.
Yes, it's good that some people came out of theatres humming a couple of the tunes, but that's not why Howard Shore won.
This will only happen (in a bad way) if Sun are neglecting Java development and not doing things people want.
And what if what certain people want is a version of Java which ties people into a certain OS? More generally, what if people want different things?
Any fork is bad for the consistency of the platform -- and good for people who don't want it to succeed (maybe because they have their own platform to push instead).
Java is not like other forms of software, and open-sourcing it is a very different proposition. Maybe a better analogy would be 'open-sourcing' the x86 instruction set -- how would you like it if every brand of PC had a slightly different instruction set, and you couldn't expect software to run?
Cached code sounds like a good idea, provided that the original bytecode is always available as the 'definitive' version. It's worth being aware of the issue, though.
...the java native interface. It is really ugly and very cumbersome...
Some might think that's a Good Thing as it helps discourage native code unless it's absolutely vital:)
Re: One Rule For 90% of Bugs
on
Debugging
·
· Score: 1
Oh yes! I'm so glad it's not just me. People are always trying to get me to use their special-purpose methods: debuggers, and the like. But putting in display statements is by far the most universal, most flexible, most available, and most useful technique I've ever seen. It's available on everything from shell and scripting languages to assembly, from COBOL to C++ and Java, from character-based terminals to GUI workstations, on all OSs, from PDAs to mainframes, from one-file programs to multi-million-line systems.
I find the exercise of working out exactly what displays to put in, and where, helps to narrow down the cause quicker than any debugger, and often gives you more insight into what the app is doing generally. Of course, it depends how easy it is to edit/recompile/re-run, but if that's not too slow, then it's a very productive method.
Some of my most useful bits of general-purpose coding have been display-based debugging aids: code to display the important features of an object or network of objects tersely but exactly; code to display certain types of asynchronous event; code to highlight and display the objects involved in a GUI; code to dump state or whatever. That sort of thing comes in useful at all sorts of odd moments.
It works! And not just for debugging, too -- I find a similar technique works well for design decisions and other knotty problems.
I tend to explain things in an email (it helps if it's to a real person, though you don't need to send it when you're done). Sometimes I'll end up rewriting the entire mail in the process, so that all that's left is the solution; but even if not, it usually clarifies and limits the problem.
My other debugging technique, when I'm really stumped, is to pace up and down the office muttering to myself. Really! I get strange looks, but there's nothing like leg movement and a steady rhythm (careful, now!) for getting you thinking, and each time you turn around it helps you look at the problem slightly differently.
they would have to release the changes to the community which would keep it from being Windows only
Doesn't follow. Open source or not, it would be trivial for them to use some feature which is only available on Windows. Sun can have all the source code they want, but if it can't run on other platforms (without effectively porting chunks of Windows too), then they're stuffed.
Open Source is wonderful for apps with a known interface. But Java isn't an app; it's a platform. One of its greatest advantages is its platform neutrality. While having a single company like Sun in charge of it may prevent Joe Bloggs from adding his whizzy new feature, it also prevents M$ from doing the same, which IMO is far more important. I think Sun have steered a fine line between locking Java up so tightly that no-one feels safe using, and opening it up so much that no-one can choose which of the multiple subtly-incompatible versions to use.
perhaps the language could be forced to match the nice features of C#, like unsafe constructs and precompilation
Either would remove some of what makes Java great.
Unsafe constructs would risk punching huge holes through Java's nice safe sandbox.
And precompilation would probably mean that compiled code gets distributed rather than bytecode; 'Write Once, Run Anywhere' doesn't mean much if you can't get hold of anything you can run!
You might just be shocked that enough people will pay for your content!
Now, come on... Yes, some people are downloading files illegally out of principle, in protest against record-company practices, or whatever, but the vast majority download files for the Sir Edmund Hillary reason: simply because they're there. (However they rationalise it...)
This is the implication every time stories like this get posted: that if record companies 'behaved themselves' (though what qualifies as 'good behaviour' is never specified), pass reasonable percentages on to the artists (though 'reasonable percentages' are never specified), then people would pay for their CDs; and that if they were then to produce completely unrestricted downloadable formats, people would all pay for those too.
Yeah, really? Right.
It's a big bluff. Oh yes, people would say great things, but most would carry on downloading illegally. Some would stop, and some would cut down, but most would carry straight on - maybe covering it by moving their goalposts or some other dodgy rationalisation.
What happens if they call our bluff? What happens if they can turn around and say "We need to restrict our formats, because we've proved no-one pays for them otherwise!" Perhaps, in the long run, we're actually better off if they don't take your word for things...
Don't worry, it never seems to bother anyone else here... [fx: mutter mutter mutter]
Re: Heisenbugs...
on
Debugging
·
· Score: 3, Insightful
Well, yes, but that determinism can be arbitrarily complex; causes may be very far removed from their effects. A GUI app can have a *lot* of past input to affect things, for example, especially if it runs for days or weeks. Exactly when asynchronous events happen can be extremely difficult to predict, detect, handle, or test; livelocks and race conditions are notoriously hard to track down. Even exact patterns of memory layout and allocation, file organisation or access, &c can affect subtle bugs. So while strictly true, determinism isn't a lot of help in some cases.
Re: Heisenbugs...
on
Debugging
·
· Score: 3, Interesting
You're describing bugs which are reproducible, but only on the unchanged code.
Worse even that those are bugs which aren't reproducible at all, where there's no way to determine the conditions that caused them, or be sure you've fixed them. The only way to handle them is to fill the code with assertions and defensive code, and hope that at some point it'll catch something for you...
The scope tag is probably more useful than the data type.
Very true. I've used a few different conventions, and IMO including the type in the variable name is both pointless and painful. In most cases, the type is fairly clear from the usage anyway, and often doesn't matter exactly. Indicating it exactly can take many characters, making code far less readable; and using just one or two isn't precise enough to be useful anyway. Plus type also gets changed quite often, with all the potential for error that gives.
However, scope is another thing; I've found a single character scope prefix to be very useful. It tells you where to find the variable's definition, so you know where to look for anything else about it. Changing scope is extremely rare, and since similarly-scoped variables are declared together, mistakes should be obvious.
It depends on the language, of course. In C, it might be useful to distinguish some or all of: formal parameters, automatic variables, local statics, module (file) level variables, global ones, preprocessor constants, enumeration constants, and structure members. But in Java, things tend to be more obvious; functions tend to be small enough that their parameters don't get lost, local variables get declared close to where they're used, and it's usually clear what other names refer to. The only prefix I've found useful is an underscore before instance variables. (And arguably, using this. is clearer anyway.)
And it also depends on the size and organisation of a project. Small apps might find little benefit from a convention, whereas huge projects can be made much more manageable by indicating where to look for things.
Code readability is an art, really, and you can't force people to write good code with simple rules. Just as using single-character names for all variables obscures their meaning and makes code incomprehensible, so does using excessively long variable names obscure the meaning of the code they're in, and makes it incomprehensible. The ideal lies somewhere in between.
In olden times, we spent quite a bit of time foraging around for nuts, scavenging meat when we could find it, and eating a hell of a lot of fruits and vegetables...
...when they were in season. Fruits in particular are only available at certain times of the year; for the rest of the time, we did without. Vegetables last longer, of course.
But although low-carb diets in general and Atkins in particular are often portrayed as a meat feast, most vegetables figure largely. Other than the plain starchy ones like potatoes, rice, and wheat, most vegetables are fairly or very low-carb; I had far more fresh veg when low-carbing than before. Maybe low-carb isn't as unhealthy, or as far from our ancestors' diet, as some people think?
Slashdot Mirror
That's rediculous. I'm running slackware with everything I need to rule the world
While I appreciate your intent, what actual practical difference is there for the end user between those two disclaimers? One creates a far better impression, of course, and suggests better quality in the rest of the project; but as disclaimers, don't they they both boil down to exactly the same thing?
Absolutely. But how can you enforce that? We could just as well have a law stating that "Everyone must be excellent to one another"...
Claim as what precisely? In particular, how do open source projects get started? With a fully working product? Of course not. They start with an idea, and some code that goes only part (in many cases, a very small part) of the way to fulfilling that idea. If software had to be guaranteed to work, then most open source projects wouldn't even get started...
Small projects, particularly. I'm an open source developer, and I've written something small to solve a problem of my own. Do I release it? At present, the cost-benefit is fairly straightforward: some time to write a bit of doc, rework the ugliest bits of code, and think a bit about how other folks might use it. Easy enough. And the benefits: I get to use the better code, other people get to use it too, maybe my name gets known a bit, and maybe I get input from other people too.
But under your proposed legislation, the balance is very different. Benefits: as above. Costs: much, much, much more effort in making damn sure it works. And the risk of getting sued to smithereens if I miss anything. Hmmm... do I share, or do I not bother? Difficult one...
Not to mention that one of the other major benefits to open source software -- that all bugs are shallow to enough eyes -- is meaningless if nothing's released until it has no bugs!
Yes, of course all software should do what it says, and of course developers should take pride in it, but you don't show any understanding of how software gets written in the first place.
(Of course, there were suspicious circumstances attached to it: Gollum's extreme possessiveness; its magical nature; Bilbo hiding it and then lying about its origin. Gandalf was suspicious of it from the first; in the film, maybe a few telling glances from him could speak volumes.)
That's often the nature of evil; it's deceptive and can appear perfectly innocent at first. (I know Tolkien didn't intend any direct allegories in his work, but occasional resonances like that do happen.)
Nor do I think that continuity with LOTR is a good argument here. Yes, there he's 'well-preserved' for 111, but there are still some changes, and in the flashback to the finding of the ring, he's made to look younger. I doubt that, several years since that was filmed, they'd be able to keep that up for an entire movie.
No, I think we'll have to get used to the idea of someone else playing Bilbo. If they choose well, that someone will bring a liveliness and sense of humour to the story which will probably turn out for the best.
I know that traditionally, the theatrical version has been the 'definitive' one, and that DVD extras have been add-ons thrown in quickly to make up the weight. However, despite PJ's comments a few months ago, IMO the definitive versions of LOTR are really the extended DVD editions. They have better pacing, a more coherent plotline, lots of telling details -- in short, the story is given more room to breathe, and works all the better for it.
So please don't judge ROTK until you've seen the EE. If the first two are anything to go by, I suspect we'll see a lot more character development (hopefully involving Denethor's corruption, and Faramir's and Eowyn's recoveries, and maybe more of Aragorn, as well as Saruman's closure), better explanation and progression of the plot, better pacing, and more balance in the grand themes and symbolism. Calling the theatrical versions 'edited highlights' would be unfair, but perhaps it wouldn't be that far from the truth. It's amazing what PJ managed to pack into each 3-hour slot; but the EEs are more amazing still.
Of course, even the EE won't be perfect. There are still flaws, awkward issues and disappointments. But despite those, I think LOTR is a magnificent achievement, wonderful to watch and better than we had any right to hope for.
BTW, I wonder if his may be the start of a deep change in the industry, where what you see in the cinema is no longer seen as the most important part of moviemaking, and where DVD &c editions may come to take on equal or greater importance overall.
AppleScripts can run Unix-level commands, as well as accessing apps at an excitingly deep level, so you could probably do all you wanted with it, and more.
No, but if I wanted to, I could already, thanks.
So are you going to give me the 100 needed*? And find a version of Cubase SX that works with it?
(* Equivalent to US$186.)
Because Wagner did most to promote letimotif as a powerful and complex tool, and is most associated with it. Yes, Weber used it first, as did Prokofiev many years later; but in Peter and the Wolf it's used in an obvious, childish manner (not that there's anything wrong with that in a piece aimed at children!), quite unlike the depth and richness that Wagner's more abstract and imaginative use brought to his operas.
The association of music with character is as strong
Oh yes; but that's not exactly what I'm talking about. Wagner uses motifs for abstractions, not just for particular people. They bring new ideas, resonances, and connections, adding to the meaning of the story as well as its emotion.
And this is what I think Shore does in LOTR. One of the more obvious examples I noticed is the well-known 'fellowship' theme, which is used throughout all three films to emphasise the support and comfort people can give each other, and how they can do more together than separately.
Perhaps you actually like Wagner
Er, no, actually. I like a few of the obvious bits, and I can take more in smallish doses... But I can still appreciate what he did, and how he developed the musical form.
Maybe the word is a little pretentious, but it's not that uncommon, and there's nothing simpler that describes it well. Terms like 'thematic development' and 'recurring ideas' don't do justice to the deep connection between music and story. And 'that bit, you know, the one that goes der-ner-ner DAH du-dum pom pom whenever the baddie turns up' is a bit long-winded.
Go and look up what that means, and then make a sensible comment. Meanwhile, I'll try not to be so irritable on Mondays.
He uses styles and references to mediaeval, folk, and other music suited to the setting; he writes highly appropriate music for some of the many songs that feature in the book; he evokes the magical, the mystical, the transcendent, the strange, the ugly, the fearsome, the heroic, while only rarely dropping into cliche or banality.
But more than this, his use of leitmotif is almost Wagnerian. His themes, far more than just attaching to particular people or emotions (as in most films), are connected with abstractions like fellowship, the power of evil, hope, inheritance, and destiny. If you listen closely, his music doesn't just underscore the emotion of a scene, but comments on its deeper meaning, and makes allusions which can be surprising in their insight.
Yes, it's good that some people came out of theatres humming a couple of the tunes, but that's not why Howard Shore won.
And what if what certain people want is a version of Java which ties people into a certain OS? More generally, what if people want different things?
Any fork is bad for the consistency of the platform -- and good for people who don't want it to succeed (maybe because they have their own platform to push instead).
Java is not like other forms of software, and open-sourcing it is a very different proposition. Maybe a better analogy would be 'open-sourcing' the x86 instruction set -- how would you like it if every brand of PC had a slightly different instruction set, and you couldn't expect software to run?
Some might think that's a Good Thing as it helps discourage native code unless it's absolutely vital :)
I find the exercise of working out exactly what displays to put in, and where, helps to narrow down the cause quicker than any debugger, and often gives you more insight into what the app is doing generally. Of course, it depends how easy it is to edit/recompile/re-run, but if that's not too slow, then it's a very productive method.
Some of my most useful bits of general-purpose coding have been display-based debugging aids: code to display the important features of an object or network of objects tersely but exactly; code to display certain types of asynchronous event; code to highlight and display the objects involved in a GUI; code to dump state or whatever. That sort of thing comes in useful at all sorts of odd moments.
I tend to explain things in an email (it helps if it's to a real person, though you don't need to send it when you're done). Sometimes I'll end up rewriting the entire mail in the process, so that all that's left is the solution; but even if not, it usually clarifies and limits the problem.
My other debugging technique, when I'm really stumped, is to pace up and down the office muttering to myself. Really! I get strange looks, but there's nothing like leg movement and a steady rhythm (careful, now!) for getting you thinking, and each time you turn around it helps you look at the problem slightly differently.
Doesn't follow. Open source or not, it would be trivial for them to use some feature which is only available on Windows. Sun can have all the source code they want, but if it can't run on other platforms (without effectively porting chunks of Windows too), then they're stuffed.
Open Source is wonderful for apps with a known interface. But Java isn't an app; it's a platform. One of its greatest advantages is its platform neutrality. While having a single company like Sun in charge of it may prevent Joe Bloggs from adding his whizzy new feature, it also prevents M$ from doing the same, which IMO is far more important. I think Sun have steered a fine line between locking Java up so tightly that no-one feels safe using, and opening it up so much that no-one can choose which of the multiple subtly-incompatible versions to use.
Either would remove some of what makes Java great.
Unsafe constructs would risk punching huge holes through Java's nice safe sandbox.
And precompilation would probably mean that compiled code gets distributed rather than bytecode; 'Write Once, Run Anywhere' doesn't mean much if you can't get hold of anything you can run!
Now, come on... Yes, some people are downloading files illegally out of principle, in protest against record-company practices, or whatever, but the vast majority download files for the Sir Edmund Hillary reason: simply because they're there. (However they rationalise it...)
This is the implication every time stories like this get posted: that if record companies 'behaved themselves' (though what qualifies as 'good behaviour' is never specified), pass reasonable percentages on to the artists (though 'reasonable percentages' are never specified), then people would pay for their CDs; and that if they were then to produce completely unrestricted downloadable formats, people would all pay for those too.
Yeah, really? Right.
It's a big bluff. Oh yes, people would say great things, but most would carry on downloading illegally. Some would stop, and some would cut down, but most would carry straight on - maybe covering it by moving their goalposts or some other dodgy rationalisation.
What happens if they call our bluff? What happens if they can turn around and say "We need to restrict our formats, because we've proved no-one pays for them otherwise!" Perhaps, in the long run, we're actually better off if they don't take your word for things...
Don't worry, it never seems to bother anyone else here... [fx: mutter mutter mutter]
Well, yes, but that determinism can be arbitrarily complex; causes may be very far removed from their effects. A GUI app can have a *lot* of past input to affect things, for example, especially if it runs for days or weeks. Exactly when asynchronous events happen can be extremely difficult to predict, detect, handle, or test; livelocks and race conditions are notoriously hard to track down. Even exact patterns of memory layout and allocation, file organisation or access, &c can affect subtle bugs. So while strictly true, determinism isn't a lot of help in some cases.
Worse even that those are bugs which aren't reproducible at all, where there's no way to determine the conditions that caused them, or be sure you've fixed them. The only way to handle them is to fill the code with assertions and defensive code, and hope that at some point it'll catch something for you...
You're thinking too small. Depending what counts as 'similar to' Unix, even my toaster might need a licence!
Very true. I've used a few different conventions, and IMO including the type in the variable name is both pointless and painful. In most cases, the type is fairly clear from the usage anyway, and often doesn't matter exactly. Indicating it exactly can take many characters, making code far less readable; and using just one or two isn't precise enough to be useful anyway. Plus type also gets changed quite often, with all the potential for error that gives.
However, scope is another thing; I've found a single character scope prefix to be very useful. It tells you where to find the variable's definition, so you know where to look for anything else about it. Changing scope is extremely rare, and since similarly-scoped variables are declared together, mistakes should be obvious.
It depends on the language, of course. In C, it might be useful to distinguish some or all of: formal parameters, automatic variables, local statics, module (file) level variables, global ones, preprocessor constants, enumeration constants, and structure members. But in Java, things tend to be more obvious; functions tend to be small enough that their parameters don't get lost, local variables get declared close to where they're used, and it's usually clear what other names refer to. The only prefix I've found useful is an underscore before instance variables. (And arguably, using this. is clearer anyway.)
And it also depends on the size and organisation of a project. Small apps might find little benefit from a convention, whereas huge projects can be made much more manageable by indicating where to look for things.
Code readability is an art, really, and you can't force people to write good code with simple rules. Just as using single-character names for all variables obscures their meaning and makes code incomprehensible, so does using excessively long variable names obscure the meaning of the code they're in, and makes it incomprehensible. The ideal lies somewhere in between.
But although low-carb diets in general and Atkins in particular are often portrayed as a meat feast, most vegetables figure largely. Other than the plain starchy ones like potatoes, rice, and wheat, most vegetables are fairly or very low-carb; I had far more fresh veg when low-carbing than before. Maybe low-carb isn't as unhealthy, or as far from our ancestors' diet, as some people think?