It's okay to call it a 'British accent'. Surely you realize that many Scottish and Welsh people speak with this accent too; and many English people do not.
To me as a Perl programmer, the most attractive aspect of Python is the well-managed way they evolve the language, with __future__ and deprecation warnings, and a clear choice of whether to upgrade to 3.0 or stick with 2.6, both of which are maintained. Contrast that with the haphazard approach taken in perl 5, where things can be vaguely 'deprecated' for years but never removed, and any major language changes are constipated waiting for perl 6 any decade now. (Interestingly, one original reason for $ prefixes on variable names in Perl was that it allows new keywords to be added to the language without breaking existing programs, but in perl 5.10 the developers didn't want to add any new keywords such as 'say' unless you add a 'use 5.010' boilerplate line to your program.)
What parts of Python's semantics are undefined or just defined by its implementation? I agree, Python is not a standardized language like C, C++, Java or C#, but stood side-by-side with Perl it looks like a model of academic rigour.
Or finally admit that maybe there are more shades of grey than "secure" and "insecure" when it comes to send and fetching data over the Internet?
Or realize that if you do have a black and white division into 'secure' and 'woo woo insecure danger Will Robinson', then unencrypted http traffic falls into the latter category and deserves a scary warning at least as much as a self-signed certificate.
The biggest reason is that Python is a fairly small language with a well-defined spec. It already had at least two independent implementations (in C and Java) and between them they had ironed out areas of ambiguity in the language. If you write a Python program you are programming for the defined language and usually not for the quirks of any one implementation.
Perl 5, on the other hand, is very much defined by its single implementation, full of odd quirks and things that don't really make any sense but have to be kept for compatibility. To implement a fully compatible Perl 5 you would essentially need to reproduce the guts of the existing perl source code, which is why nobody has really bothered.
It is also very difficult, if not improssible, to track VM incompatibilities when main developer (MS) is not interested in 100% compatibility at all.
If this is concern, just write your code for Mono, and the Mono project becomes your main vendor. You realize that Mono also runs on Windows? So just develop and deploy entirely with Mono and if that alternative implementation of.NET from a certain other vendor is slightly incompatible, that need not concern you at all.
I think it's unwise to start out with what any company's marketing department says and then argue against that, because marketing always exaggerates. Nobody with any clue has ever said that you can't make security holes in Java, or that C's low-level machine access is a 'flaw'. Just that certain very common kinds of security hole don't happen, and that C is a sharp tool that needs a lot of care to use correctly.
I'm sorry that apparently you have only discussed this with marketers and overenthusiastic weenies, but please don't feel you have to repeat the obviously bogus arguments they trot out.
I completely agree that not trampling memory on buffer overruns is not enough for airtight security. But it is a necessary bare minimum! To make a secure app you at least need to get the basic stuff right, and any help the computer can give you for that is welcome. If you look at the typical security holes _still_ being discovered in software (in 2008, for goodness' sake) you will see that buffer overruns and bad pointer accesses represent a good chunk. If you're a perfect programmer you don't need any assistance from the compiler or runtime and C is just fine for you. Sadly, most programmers are all too fallible. I know I am, and I would never trust myself to get details like buffer length checking correct when I can get the computer to do that for me.
Can Java or C# eliminate all security holes? Of course not! Are they suitable languages for 100% of programs? Nope. Can they often help you automatically take care of the low-level stuff, so you can spend your precious and limited brainpower on something else? Damn right they can!
Please don't argue against a straw man. Nobody tries to make a programming language eliminate all bugs. Just all occurrences of a certain class of bug. For example, if the language has checked array access, then that eliminates array overrun memory trampling bugs, or mitigates them to safely thrown errors. A real integer type, or a bounded numeric type with checking, eliminates bugs caused by silent integer overflow in C-like languages. Of course you can't deal with all errors. That is not to say you should therefore not try to do anything.
How much bovine stupidity can be attributed to human preferences? Have we bred cattle to make them more stupid? I'm sure wild bison and buffaloes are a lot sharper. I expect it's our fault; when did you last send back a steak in a restaurant because it wasn't intelligent enough?
GIMP isn't a RAW conversion tool, surely your curves are applied before you're anywhere near it?
Exactly, I can't really use the GIMP for this task. If it had high bit depth support then it would be suitable, but currently it's not. Even though the final output might use only 8 bits per channel.
In the meantime the choice seems to be Cinepaint (which does the right thing but is very old and Spartan) or Krita, or messing around with pnmtools on the command line.
I'm motivated exactly by getting DSLR pictures with 12 bits per channel. Sometimes a picture is a bit underexposed or overexposed and you need to adjust the levels. If you chop to 8 bits first then a lot of detail in the sky or in shadows, which would be salvageable with a high-colour-depth processing tool, is lost.
By all means convert to 8 bits per channel and JPEG format *after* you've finished processing.
Re:when GEGL Integration is complete.
on
GIMP 2.6 Released
·
· Score: 1
By convention when you say '8-bit' these days you mean eight bits per channel. Nobody would interpret it as meaning the GIMP has a 256 colour palette.
GEGL is great news but I still think it's a shame that Cinepaint had to fork all those years ago. They did all the hard work of cleaning up the legacy 8-bit code, although there was a lot less of it back then.
Re:Foctothorpe FTW
on
C# In-Depth
·
· Score: 2, Insightful
On a piano keyboard to play E# you press the same key as for F, so it gives the same sound. But I *think* this is not true for every instrument. Some instruments can produce different sounds for E# and F. Then there are the considerations of music theory and notation which others have pointed out.
Re:Foctothorpe FTW
on
C# In-Depth
·
· Score: 0, Redundant
How do you know that the C-sharp programming language does not use U+266F (MUSIC SHARP SIGN) rather than U+0023 (NUMBER SIGN)?
Still no high colour depth?
on
GIMP 2.6 Released
·
· Score: 4, Interesting
It's not completely clear from the release notes: does this mean that the GIMP can now load and save images with 16 or 32 bits per colour channel, or is it still limited to 8-bit RGB despite the new GEGL engine under the hood?
Yeah why not? As long as they release all their code under the MIT licence (which they've said they will do), there is no reason not to embrace and extend. The parent project can choose to incorporate Microsoft's code, or not.
From the article, Microsoft have said they will contribute patches upstream rather than forking their own version. But as long as you're sure everybody is releasing their code under the same free licence, 'embrace and extend' is not a problem in the free software world. In many cases it can be beneficial.
'Super unleaded' in Britain at least meant an unleaded fuel designed for older engines (that previously ran on leaded petrol and were converted). IIRC It had benzene and other peculiar stuff in it and was phased out (or replaced with a benzene-free version). The fuel for modern cars is simply 'unleaded'. Perhaps this is equivalent to 'super unleaded' in the US, I don't know. But you have to be careful with terminology.
(for example, Texas voted for Bush; switch 24.999% of the votes Texas cast to Bush to Gore, and the result does not change)
On second thoughts this is not quite true; the number of votes you can switch obviously depends on the number of votes for each candidate in Texas. But it remains true you could switch millions of votes, but still not enough to affect the result.
Yes, 289 is the _smallest_ number of voters that could be switched to change the result of the election. But that gives a misleading picture of how close it was. You should also consider the largest number of voters that could switch without changing the result: that is several million votes (for example, Texas voted for Bush; switch 24.999% of the votes Texas cast to Bush to Gore, and the result does not change). In other words huge numbers of people (outside Florida and other swing states) could have decided to vote for Gore (or Nader) instead of Bush and it wouldn't have made the slightest difference.
Perhaps the fairest measure of the closeness of an election is: what is the smallest number N of votes such that if you picked N individual votes at random across the whole country and flipped them, there is more than a 50% probability that the result would change?
I'm curious, what are these 'glitches' and 'rendering issues' you talk of? I've used Chrome for a while and not noticed it misrendering anything (while I am affected by a rendering bug in Firefox). Nor any glitches or crashes.
The current model of Wikipedia is a simple monotonically increasing version. You can commit changes, diff between versions and even revert changes, but you can't make separate branches or merge changes from one branch to another.
I've been suggesting for some time that Wikipedia, or some fork of Wikipedia, should allow users to "sign off" on a version of an article, and then lock that article against future edits until the signer had approved them. The signing off would allow people to cite a Wikipedia article as a source that had been vetted by at least one person (with confidence in the source depending on that person's credentials). The signer's identity (and sometimes, their credentials) could be confirmed using several methods, such as verifying an.edu e-mail address. Users could still submit edits, but they would have to be approved by the article verifier. Different users could sign off on different versions of the same article,
Isn't this the same as the distributed version control model used by the Linux kernel and many other software projects? Put all of Wikipedia into a DVCS, and anyone can clone it and publish their own changes; someone who maintains a 'signed-off' copy of an article can choose whether or not to pull changes from someone else's repository.
Slashdot Mirror
It's okay to call it a 'British accent'. Surely you realize that many Scottish and Welsh people speak with this accent too; and many English people do not.
To me as a Perl programmer, the most attractive aspect of Python is the well-managed way they evolve the language, with __future__ and deprecation warnings, and a clear choice of whether to upgrade to 3.0 or stick with 2.6, both of which are maintained. Contrast that with the haphazard approach taken in perl 5, where things can be vaguely 'deprecated' for years but never removed, and any major language changes are constipated waiting for perl 6 any decade now. (Interestingly, one original reason for $ prefixes on variable names in Perl was that it allows new keywords to be added to the language without breaking existing programs, but in perl 5.10 the developers didn't want to add any new keywords such as 'say' unless you add a 'use 5.010' boilerplate line to your program.)
What parts of Python's semantics are undefined or just defined by its implementation? I agree, Python is not a standardized language like C, C++, Java or C#, but stood side-by-side with Perl it looks like a model of academic rigour.
Or realize that if you do have a black and white division into 'secure' and 'woo woo insecure danger Will Robinson', then unencrypted http traffic falls into the latter category and deserves a scary warning at least as much as a self-signed certificate.
So they took advantage of an idiotic system. Good for them.
The biggest reason is that Python is a fairly small language with a well-defined spec. It already had at least two independent implementations (in C and Java) and between them they had ironed out areas of ambiguity in the language. If you write a Python program you are programming for the defined language and usually not for the quirks of any one implementation.
Perl 5, on the other hand, is very much defined by its single implementation, full of odd quirks and things that don't really make any sense but have to be kept for compatibility. To implement a fully compatible Perl 5 you would essentially need to reproduce the guts of the existing perl source code, which is why nobody has really bothered.
How does that handle LINQ-to-SQL and other query backends? Do you get the same performance?
If this is concern, just write your code for Mono, and the Mono project becomes your main vendor. You realize that Mono also runs on Windows? So just develop and deploy entirely with Mono and if that alternative implementation of .NET from a certain other vendor is slightly incompatible, that need not concern you at all.
I think it's unwise to start out with what any company's marketing department says and then argue against that, because marketing always exaggerates. Nobody with any clue has ever said that you can't make security holes in Java, or that C's low-level machine access is a 'flaw'. Just that certain very common kinds of security hole don't happen, and that C is a sharp tool that needs a lot of care to use correctly.
I'm sorry that apparently you have only discussed this with marketers and overenthusiastic weenies, but please don't feel you have to repeat the obviously bogus arguments they trot out.
I completely agree that not trampling memory on buffer overruns is not enough for airtight security. But it is a necessary bare minimum! To make a secure app you at least need to get the basic stuff right, and any help the computer can give you for that is welcome. If you look at the typical security holes _still_ being discovered in software (in 2008, for goodness' sake) you will see that buffer overruns and bad pointer accesses represent a good chunk. If you're a perfect programmer you don't need any assistance from the compiler or runtime and C is just fine for you. Sadly, most programmers are all too fallible. I know I am, and I would never trust myself to get details like buffer length checking correct when I can get the computer to do that for me.
Can Java or C# eliminate all security holes? Of course not! Are they suitable languages for 100% of programs? Nope. Can they often help you automatically take care of the low-level stuff, so you can spend your precious and limited brainpower on something else? Damn right they can!
Please don't argue against a straw man. Nobody tries to make a programming language eliminate all bugs. Just all occurrences of a certain class of bug. For example, if the language has checked array access, then that eliminates array overrun memory trampling bugs, or mitigates them to safely thrown errors. A real integer type, or a bounded numeric type with checking, eliminates bugs caused by silent integer overflow in C-like languages. Of course you can't deal with all errors. That is not to say you should therefore not try to do anything.
How much bovine stupidity can be attributed to human preferences? Have we bred cattle to make them more stupid? I'm sure wild bison and buffaloes are a lot sharper. I expect it's our fault; when did you last send back a steak in a restaurant because it wasn't intelligent enough?
Thanks for the suggestion, I will try UFRAW.
Exactly, I can't really use the GIMP for this task. If it had high bit depth support then it would be suitable, but currently it's not. Even though the final output might use only 8 bits per channel.
In the meantime the choice seems to be Cinepaint (which does the right thing but is very old and Spartan) or Krita, or messing around with pnmtools on the command line.
I'm motivated exactly by getting DSLR pictures with 12 bits per channel. Sometimes a picture is a bit underexposed or overexposed and you need to adjust the levels. If you chop to 8 bits first then a lot of detail in the sky or in shadows, which would be salvageable with a high-colour-depth processing tool, is lost.
By all means convert to 8 bits per channel and JPEG format *after* you've finished processing.
By convention when you say '8-bit' these days you mean eight bits per channel. Nobody would interpret it as meaning the GIMP has a 256 colour palette.
GEGL is great news but I still think it's a shame that Cinepaint had to fork all those years ago. They did all the hard work of cleaning up the legacy 8-bit code, although there was a lot less of it back then.
On a piano keyboard to play E# you press the same key as for F, so it gives the same sound. But I *think* this is not true for every instrument. Some instruments can produce different sounds for E# and F. Then there are the considerations of music theory and notation which others have pointed out.
How do you know that the C-sharp programming language does not use U+266F (MUSIC SHARP SIGN) rather than U+0023 (NUMBER SIGN)?
It's not completely clear from the release notes: does this mean that the GIMP can now load and save images with 16 or 32 bits per colour channel, or is it still limited to 8-bit RGB despite the new GEGL engine under the hood?
Yeah why not? As long as they release all their code under the MIT licence (which they've said they will do), there is no reason not to embrace and extend. The parent project can choose to incorporate Microsoft's code, or not.
From the article, Microsoft have said they will contribute patches upstream rather than forking their own version. But as long as you're sure everybody is releasing their code under the same free licence, 'embrace and extend' is not a problem in the free software world. In many cases it can be beneficial.
'Super unleaded' in Britain at least meant an unleaded fuel designed for older engines (that previously ran on leaded petrol and were converted). IIRC It had benzene and other peculiar stuff in it and was phased out (or replaced with a benzene-free version). The fuel for modern cars is simply 'unleaded'. Perhaps this is equivalent to 'super unleaded' in the US, I don't know. But you have to be careful with terminology.
On second thoughts this is not quite true; the number of votes you can switch obviously depends on the number of votes for each candidate in Texas. But it remains true you could switch millions of votes, but still not enough to affect the result.
Yes, 289 is the _smallest_ number of voters that could be switched to change the result of the election. But that gives a misleading picture of how close it was. You should also consider the largest number of voters that could switch without changing the result: that is several million votes (for example, Texas voted for Bush; switch 24.999% of the votes Texas cast to Bush to Gore, and the result does not change). In other words huge numbers of people (outside Florida and other swing states) could have decided to vote for Gore (or Nader) instead of Bush and it wouldn't have made the slightest difference.
Perhaps the fairest measure of the closeness of an election is: what is the smallest number N of votes such that if you picked N individual votes at random across the whole country and flipped them, there is more than a 50% probability that the result would change?
I'm curious, what are these 'glitches' and 'rendering issues' you talk of? I've used Chrome for a while and not noticed it misrendering anything (while I am affected by a rendering bug in Firefox). Nor any glitches or crashes.
1st-party applications? You mean you have to program it yourself?
If you want to say that the seller of the phone provides apps, you mean second-party.
The current model of Wikipedia is a simple monotonically increasing version. You can commit changes, diff between versions and even revert changes, but you can't make separate branches or merge changes from one branch to another.
Isn't this the same as the distributed version control model used by the Linux kernel and many other software projects? Put all of Wikipedia into a DVCS, and anyone can clone it and publish their own changes; someone who maintains a 'signed-off' copy of an article can choose whether or not to pull changes from someone else's repository.