Screen also has a handy copy/paste/scrollback feature (C-a ESC by default). I have to admit I normally use the X selection, but being able to copy text on a text console can save a lot of time.
Isn't part of the bloat that Windows is so often (and appropriately) accused of directly attributable to having to support a nearly infinite number of hardware / software configurations?
No.
The bloat is attributable to trying to support a lot of hardware combinations in a poorly-designed way. For example, having an installable executable driver for a mouse (sheesh) or printer, when a description file would be enough.
Supporting a lot of applications would be easier if they put more thought into versioning and didn't make application writers feel they must use undocumented interfaces.
I think the grandparent is not trying to say "2.99999..." repeating unto infinity, but rather e.g. 2.9999999999999999999981823, the kind of quantity that tends to pop up in FP arithmetic. As another poster noted, 3 can be represented exactly in FP, so it's a bad example. 3.3 would be better, which is 3.2999999999999998223643160599749535322189 as a double.
It's also wrong to say it's not deterministic. Of course it is; converting an integer to a float is a pure algorithm. I think what he meant is "I can't tell off the top of my head".:-)
On a related note, it looks like Python is about to get some Cowlishaw-style Decimal number types, which should help with some of these problems.
I think this is how I would put it (as a humble engineer, not a maths postgrad): generally of course we can say that 2.9999.. = 3. Sometimes we want to make the distinction, even if Cantor disapproves. Even if the limit = 3, the *concepts* of "3, exactly" and "the limit of 2.99999..." can be distinguished.
I would be interested to hear whether your prof says "2.9999 is *exactly* equivalent to 3." I don't know for sure, though it seems like you can make a distinction between them.
I think part of the definition of the real number field is that for any x < y there is a value z s.t. x < z < y
29.999... - 2.99... = 10x - x
I don't think you can just sling around decimal fractions like that without treading close to a division-by-zero fallacy. It's been too long since I did serious math for me to be able to prove it.
I think all you have proved is that the limit of 2.9999... is 3, which is obvious.
If you think you have done otherwise, please write it without relying on decimals.
IIRC there is also a relatively simple proof involving Cauchy sequences.
No, if that were true what is the number between 3 and 2.999...?
I think part of the definition of the real number field is that for any x, y there is a value z s.t. x 29.999... - 2.99... = 10x - x
I don't think you can just sling around infinitessimals like that without treading close to a division-by-zero fallacy. It's been too long since I did serious math for me to be able to prove it.
I think all you have proved is that the limit of 2.9999... is 3, which is obvious.
IIRC there is also a relatively simple proof involving Cauchy sequences.
There is one other point that I forgot to mention but that I think tips the balance: if you use tab characters, the indentation will be screwed up in a diff because of "+ " being inserted on the left hand side. No problem with spaces. Using tabs also makes it marginally more likely your patches will not apply, though you can kludge it with patch options.
Similarly, if you copy code using tabs into email, a web page, or a document then it is likely to look messed up. There is no problem with spaces.
As you say, code with vertical alignment anywhere but the start of the line is always going to get screwed up with tabs.
I think at the start of the project the people involved should pick a width (2, 4, 8, whatever) and use that many spaces, and just stick to it. You need to make these decisions about lots of other stylistic questions, so I don't see why picking a single indent depth should be hard.
Tabs make the alignment of code flap around as it moves between programs. I hate that. It ought to stay the way it was written.
I find the best fix is to just ban tab characters from files. That way there is no argument or confusion about how many spaces they are supposed to represent. N spaces is always N spaces.
Using only tabs and not spaces also kind-of works, but I think it is not such a good solution. Not everyone's favourite editor can be configured to treat tabs the right way. Spaces tend to creep in -- you can hardly avoid spaces altogether -- and so entropy increases. Code that makes sense indented with tabs shown as 2 spaces might look bad or wrong when someone changes it. I guess it does let you avoid agreeing on what size of indent to use but I am not sure that is a good thing.
None of this to say Python's usage is bad. I love Python. I love that there is no possibility of getting mislead by incorrectly-indented code, as happens sometimes in C.
The syntax is no more complex than C and totally acceptable for any programmer -- but that's still a lot more complex than Lisp, the language with almost no syntax. Naively moving indent syntax into Lisp would give you the worst bits of Lisp (prefix algebra) and Python (non-trivial syntax).
That's exactly my point: it is standardized, but not to a sufficient extend to be able to write a spectrum of useful applications that are portable.
What good in 2004 is a programming language that can't work with sockets? Sure, sometimes I write purely algorithmic, simple file IO programs, but I don't think many programmers *never* write GUIs or need to call OS functions or do networking.
I might be wrong here, but last time I looked at the state of Scheme on Unix, there were common specifications (SRFIs) for some useful libraries. But the syntax to load them differs between implementations! So again, you cannot write a program portable across different implementations can call useful libraries.
If there were a single strong free implementation of either CL or Scheme then it might be OK; the standard would be defined by the implementation, as it is with Perl. But that doesn't seem to be the case at the moment. Ask N lisp programmers and you will hear about >=N implementations.
I count 4 freeish CLs in Debian, and a larger number of Schemes. How am I to know which one supports the libraries I want and will be well supported in the future? If there were 4 C compilers then I would still have a choice, but at least I ought to be able to call the same libraries from intel cc as from gcc.
Therefore, I repeat my point: the reason why even programmers who like Scheme often end up using Python (or whatever) has nothing to do with syntax or any aspect of the language itself. It's the libraries, stupid. Doing useful work in a high-level language is, for many applications, mostly about having useful libraries. Perhaps for big applications the relative importance of the library decreases. But if people can't easily write small programs, they are less likely to get around to writing big ones.
If you filled a desert with a solar farm that absorbed 30% of the solar energy, I wouldn't be at all surprised if it stopped being a desert.
Could you extract enough energy as electricity to make the ambient temperature fall? I would be surprised. I just don't think any solar cells would be that efficient.
Worse, when it starts raining there, whose rain did it used to be?
Not necessarily anyone's rain. This kind of interaction could cause rainfall that simply did not happen before.
This has been proposed and implemented several times as an alternative syntax. I think Arc is meant to have this, but it's hardly the first. I don't think it's ever really caught on.
Why?
- Sometimes it's nice to put code into things that don't reliable preserve whitespace, such as, say, comment fields on web sites.
- Parens are well-established in lisp. If you change it you give an additional barrier to people coming from other lisp dialects, without particularly helping people coming from elsewhere.
- Whitespace by itself is not enough. Do you want to write (+ 3 (* 4 5)) across 3-5 lines? Python ends up with fairly complex rules about backslashes, open parens, etc.
- One advantage of lisp is that it's easy to write out from a program. This is really not true of Python.
- If you accept that we need paren syntax, then you can wonder whether indentation should be supported as an alternative. But having two different syntaxes for one language, though an interesting idea, is likely to cause a lot of practical confusion.
So I think all you really want is an editor that ensures the indentation is always valid, and that can highlight parens and do other things. emacs goes a long way, but it could be better -- for example by making outer parens larger, as in TeX-printed or handwritten mathematics.
In my humble opinion what Lisp needs to take from Python is not semantic indentation, but rather a single standard dialect with good OS bindings. The last thing we need is yet another slightly incompatible dialect that can't bind to existing code. Sheesh; I love lisp but lisp implementers really exasperate me.
Uh, no. The point which you seem to have missed is that steam engines use *steam*, not air. Steam is the gas phase of water. Air is a mix of nitrogen, oxygen, other gases and only a small amount of water.
On purely practical narrow grounds, open standards are more important. It holds for any business, in fact: they ought to prefer not to be captured by any single vendor. Of course for complex situations, having the source may be the only reasonable guarantee that the format really is open.
But there is more to good government than just circulating memos at minimum cost. Governments ought to consider all the additional benefits of investing in open source rather than proprietary software. It contributes to what Moglen calls "the world's greatest technical library", to the benefit of students. It creates opportunities for local businesses, whereas most proprietary software is developed in the US. Free software can be used by every citizen, so they all get value from their taxes, and so that people unable to drop $700 on an office suite are not excluded.
Perhaps none of these matter to corporations, who don't need to care about whether their purchases help the public good or not. But they ought to at least be considered by governments.
Reducing CPU consumption down to 5W is not a great win when you still have backlit screens and hard disks chewing up power. It's a simple application of Amdahl's law.
Intel CPUs use a lot of power at full load, but rather less when sleeping. The typical client machine spends a lot of time idle. Probably the heaviest loaded laptops are those running Gentoo, and even those are not building absolutely all the time. As I write this now, my machine's CPU is probably asleep except for a couple of ms after I hit a key.
On the other hand the screen and backlight stay on all the time, and the disk stays spun up most of the time.
This is one reason why Crusoe was less successful than people hoped. For laptops, CPU power consumption is just not the dominant factor.
If passive screens and solid-state storage became popular for laptops then CPU consumption would matter again. In devices like PDAs where there is no hard disk and the screen is not always backlit, then low-power CPUs are more popular.
Even then, power usage in flat-out benchmarks doesn't matter. The most important thing is that the CPU and memory should use little power when idle. If you run a CPU benchmark on your laptop or PDA it is expected that the battery will go flat quickly. So, don't do that when you're disconnected.
I've read Ken Brown's essay, and I debunk it here. Here is the executive summary:
The paper is poorly written, full of contradictions and gramatical
errors. If their essay were a program, it would not even compile, let
alone work.
Nearly every paragraph makes an unsubstantiated assertion. Brown
seems to feel that just inserting "it is clear that", "ironically",
"clearly", or "it is widely known" is an adequate substitute for
cited evidence. Ironically, it clearly is not.
Brown clearly does not understand the terms he uses, such as
"copyright", "public domain" or "open source". He does not seem to
understand that copyright protects representations, not ideas. In
several places he seems to think that open source is in the public domain.
Quotes such as "sometimes theft is necessary" as are attributed to
the open source community without any evidence they were ever uttered
by anyone.
Experts are asked misleading or hypothetical questions to elicit
quotes that are used out of context. I think AdTI is not honest
enough to ask straight questions because the answers would not suit
them.
Brown says he can't believe that Linus wrote Linux,
because... welll, he just can't believe it. Nothing more. He does
not cite even a single line of Linux source that was copied from any
other system, despite that all the data needed to check this is
available to him. If he found even one line, his paper might be
credible. But he does not.
When sources are cited, Brown grossly misinterprets the data:
diagrams that do not show code descent are interpreted as showing code
descent.
If Microsoft paid AdTI to write this, they didn't get much for
their money.
AdTI would like universities to release their work under something
like the MIT licence, rather than the GPL or proprietary licences. At
least this is not obviously silly, though as usual they just state it
without making a meaningful case.
Right, you are not required to permit anonymous access. You are not required to release your source at all. In fact, you are not required to develop software at all. Why don't you go and play outside?
But many open source projects want to do it. Making development source publicly available is a pretty important, though not absolutely necessary, condition for effective open development. (See Cathedral vs Bazaar, etc etc.) Closed projects have a completely different situation for source control security.
My point, which I would have thought has already been thrashed out sufficiently, is that Arch and Darcs allow you to publish source without requiring any anonymous access beyond a read-only web server.
(And before you say it: no project is required to have a web site, but how many don't?)
Slashdot Mirror
"I'd like to thank my parents, Ayn Rand and God."
It's "deprecated", dammit. Not "depricated", not "depreciated."
Real men don't need to use images.
Because they're really getting laid?
Screen also has a handy copy/paste/scrollback feature (C-a ESC by default). I have to admit I normally use the X selection, but being able to copy text on a text console can save a lot of time.
screen -h 100000 works fine. How much scrollback do you need?
You can also assign single-key shortcuts. Look at the documentation for bindkey in the manual.
Isn't part of the bloat that Windows is so often (and appropriately) accused of directly attributable to having to support a nearly infinite number of hardware / software configurations?
No.
The bloat is attributable to trying to support a lot of hardware combinations in a poorly-designed way. For example, having an installable executable driver for a mouse (sheesh) or printer, when a description file would be enough.
Supporting a lot of applications would be easier if they put more thought into versioning and didn't make application writers feel they must use undocumented interfaces.
I think he must have been talking about javascript.
I think the grandparent is not trying to say "2.99999..." repeating unto infinity, but rather e.g. 2.9999999999999999999981823, the kind of quantity that tends to pop up in FP arithmetic. As another poster noted, 3 can be represented exactly in FP, so it's a bad example. 3.3 would be better, which is 3.2999999999999998223643160599749535322189 as a double.
:-)
It's also wrong to say it's not deterministic. Of course it is; converting an integer to a float is a pure algorithm. I think what he meant is "I can't tell off the top of my head".
On a related note, it looks like Python is about to get some Cowlishaw-style Decimal number types, which should help with some of these problems.
I think this is how I would put it (as a humble engineer, not a maths postgrad): generally of course we can say that 2.9999.. = 3. Sometimes we want to make the distinction, even if Cantor disapproves. Even if the limit = 3, the *concepts* of "3, exactly" and "the limit of 2.99999..." can be distinguished.
Thanks for the information!
I would be interested to hear whether your prof says "2.9999 is *exactly* equivalent to 3." I don't know for sure, though it seems like you can make a distinction between them.
Should have been:
:)
I think part of the definition of the real number field is that for any x < y there is a value z s.t. x < z < y
29.999... - 2.99... = 10x - x
I don't think you can just sling around decimal fractions like that without treading close to a division-by-zero fallacy. It's been too long since I did serious math for me to be able to prove it.
I think all you have proved is that the limit of 2.9999... is 3, which is obvious.
If you think you have done otherwise, please write it without relying on decimals.
IIRC there is also a relatively simple proof involving Cauchy sequences.
But it won't fit in this margin?
No, if that were true what is the number between 3 and 2.999...?
:)
I think part of the definition of the real number field is that for any x, y there is a value z s.t. x 29.999... - 2.99... = 10x - x
I don't think you can just sling around infinitessimals like that without treading close to a division-by-zero fallacy. It's been too long since I did serious math for me to be able to prove it.
I think all you have proved is that the limit of 2.9999... is 3, which is obvious.
IIRC there is also a relatively simple proof involving Cauchy sequences.
But it won't fit in this margin?
Glad you liked the JWZ article.
There is one other point that I forgot to mention but that I think tips the balance: if you use tab characters, the indentation will be screwed up in a diff because of "+ " being inserted on the left hand side. No problem with spaces. Using tabs also makes it marginally more likely your patches will not apply, though you can kludge it with patch options.
Similarly, if you copy code using tabs into email, a web page, or a document then it is likely to look messed up. There is no problem with spaces.
As you say, code with vertical alignment anywhere but the start of the line is always going to get screwed up with tabs.
I think at the start of the project the people involved should pick a width (2, 4, 8, whatever) and use that many spaces, and just stick to it. You need to make these decisions about lots of other stylistic questions, so I don't see why picking a single indent depth should be hard.
Tabs make the alignment of code flap around as it moves between programs. I hate that. It ought to stay the way it was written.
In Python you can use tabnanny to avoid this.
I find the best fix is to just ban tab characters from files. That way there is no argument or confusion about how many spaces they are supposed to represent. N spaces is always N spaces.
Using only tabs and not spaces also kind-of works, but I think it is not such a good solution. Not everyone's favourite editor can be configured to treat tabs the right way. Spaces tend to creep in -- you can hardly avoid spaces altogether -- and so entropy increases. Code that makes sense indented with tabs shown as 2 spaces might look bad or wrong when someone changes it. I guess it does let you avoid agreeing on what size of indent to use but I am not sure that is a good thing.
None of this to say Python's usage is bad. I love Python. I love that there is no possibility of getting mislead by incorrectly-indented code, as happens sometimes in C.
The syntax is no more complex than C and totally acceptable for any programmer -- but that's still a lot more complex than Lisp, the language with almost no syntax. Naively moving indent syntax into Lisp would give you the worst bits of Lisp (prefix algebra) and Python (non-trivial syntax).
That's exactly my point: it is standardized, but not to a sufficient extend to be able to write a spectrum of useful applications that are portable.
What good in 2004 is a programming language that can't work with sockets? Sure, sometimes I write purely algorithmic, simple file IO programs, but I don't think many programmers *never* write GUIs or need to call OS functions or do networking.
I might be wrong here, but last time I looked at the state of Scheme on Unix, there were common specifications (SRFIs) for some useful libraries. But the syntax to load them differs between implementations! So again, you cannot write a program portable across different implementations can call useful libraries.
If there were a single strong free implementation of either CL or Scheme then it might be OK; the standard would be defined by the implementation, as it is with Perl. But that doesn't seem to be the case at the moment. Ask N lisp programmers and you will hear about >=N implementations.
I count 4 freeish CLs in Debian, and a larger number of Schemes. How am I to know which one supports the libraries I want and will be well supported in the future? If there were 4 C compilers then I would still have a choice, but at least I ought to be able to call the same libraries from intel cc as from gcc.
Therefore, I repeat my point: the reason why even programmers who like Scheme often end up using Python (or whatever) has nothing to do with syntax or any aspect of the language itself. It's the libraries, stupid. Doing useful work in a high-level language is, for many applications, mostly about having useful libraries. Perhaps for big applications the relative importance of the library decreases. But if people can't easily write small programs, they are less likely to get around to writing big ones.
If you filled a desert with a solar farm that absorbed 30% of the solar energy, I wouldn't be at all surprised if it stopped being a desert.
Could you extract enough energy as electricity to make the ambient temperature fall? I would be surprised. I just don't think any solar cells would be that efficient.
Worse, when it starts raining there, whose rain did it used to be?
Not necessarily anyone's rain. This kind of interaction could cause rainfall that simply did not happen before.
This has been proposed and implemented several times as an alternative syntax. I think Arc is meant to have this, but it's hardly the first. I don't think it's ever really caught on.
Why?
- Sometimes it's nice to put code into things that don't reliable preserve whitespace, such as, say, comment fields on web sites.
- Parens are well-established in lisp. If you change it you give an additional barrier to people coming from other lisp dialects, without particularly helping people coming from elsewhere.
- Whitespace by itself is not enough. Do you want to write (+ 3 (* 4 5)) across 3-5 lines? Python ends up with fairly complex rules about backslashes, open parens, etc.
- One advantage of lisp is that it's easy to write out from a program. This is really not true of Python.
- If you accept that we need paren syntax, then you can wonder whether indentation should be supported as an alternative. But having two different syntaxes for one language, though an interesting idea, is likely to cause a lot of practical confusion.
So I think all you really want is an editor that ensures the indentation is always valid, and that can highlight parens and do other things. emacs goes a long way, but it could be better -- for example by making outer parens larger, as in TeX-printed or handwritten mathematics.
In my humble opinion what Lisp needs to take from Python is not semantic indentation, but rather a single standard dialect with good OS bindings. The last thing we need is yet another slightly incompatible dialect that can't bind to existing code. Sheesh; I love lisp but lisp implementers really exasperate me.
Uh, no. The point which you seem to have missed is that steam engines use *steam*, not air. Steam is the gas phase of water. Air is a mix of nitrogen, oxygen, other gases and only a small amount of water.
On purely practical narrow grounds, open standards are more important. It holds for any business, in fact: they ought to prefer not to be captured by any single vendor. Of course for complex situations, having the source may be the only reasonable guarantee that the format really is open.
But there is more to good government than just circulating memos at minimum cost. Governments ought to consider all the additional benefits of investing in open source rather than proprietary software. It contributes to what Moglen calls "the world's greatest technical library", to the benefit of students. It creates opportunities for local businesses, whereas most proprietary software is developed in the US. Free software can be used by every citizen, so they all get value from their taxes, and so that people unable to drop $700 on an office suite are not excluded.
Perhaps none of these matter to corporations, who don't need to care about whether their purchases help the public good or not. But they ought to at least be considered by governments.
Reducing CPU consumption down to 5W is not a great win when you still have backlit screens and hard disks chewing up power. It's a simple application of Amdahl's law.
Intel CPUs use a lot of power at full load, but rather less when sleeping. The typical client machine spends a lot of time idle. Probably the heaviest loaded laptops are those running Gentoo, and even those are not building absolutely all the time. As I write this now, my machine's CPU is probably asleep except for a couple of ms after I hit a key.
On the other hand the screen and backlight stay on all the time, and the disk stays spun up most of the time.
This is one reason why Crusoe was less successful than people hoped. For laptops, CPU power consumption is just not the dominant factor.
If passive screens and solid-state storage became popular for laptops then CPU consumption would matter again. In devices like PDAs where there is no hard disk and the screen is not always backlit, then low-power CPUs are more popular.
Even then, power usage in flat-out benchmarks doesn't matter. The most important thing is that the CPU and memory should use little power when idle. If you run a CPU benchmark on your laptop or PDA it is expected that the battery will go flat quickly. So, don't do that when you're disconnected.
Right, you are not required to permit anonymous access. You are not required to release your source at all. In fact, you are not required to develop software at all. Why don't you go and play outside?
But many open source projects want to do it. Making development source publicly available is a pretty important, though not absolutely necessary, condition for effective open development. (See Cathedral vs Bazaar, etc etc.) Closed projects have a completely different situation for source control security.
My point, which I would have thought has already been thrashed out sufficiently, is that Arch and Darcs allow you to publish source without requiring any anonymous access beyond a read-only web server.
(And before you say it: no project is required to have a web site, but how many don't?)
What current systems don't have an 8-bit byte? /curious
I guess they were using that Arial cable to transfer fonts?