Robert Morris Sr. gave a talk long ago about the two major rules of crypto. First, never underestimate how far someone will go to read your data (for example, hiring Alan Turing and inventing digital computers). Second, look for plaintext, which will pop up in unexpected places while you perfect the algorithm that create the ciphertext. I'd imagine that Morris' first point can be best addressed by using a well tested encryption algorithm, and a mature, open source encryption application. This minimises the chance that your data can be brute-forced.
The second point can be circumvented by simply not storing any plaintext. Remove any harddrives from your machine, and use a specialist LiveCD with an encrypted USB stick to store any data you wish to keep between sessions.
Granted, these techniques are not foolproof. You could be unknowingly under surveillance when you enter your password in, for instance. However, one can reduce the risk by a considerable margin, making it increasingly harder, and increasingly expensive, for you data to be accessed without your consent.
Of course. Although functional languages are great at specifying and evaluating algorithms which are at the heart of a program, these algorithms usually take up a small percentage of the total work on the program. The rest is business logic, a GUI, database connectivity, etc., which are most easily tackled by a procedural, object-oriented language. But you haven't explained why business logic, GUIs, etc. are more suited to imperative OO languages. Could you provide a pseudo-code example which you think would be difficult to emulate in a functional language?
Every time you create something, destroy it afterwards.
Assume every action will fail and handle it appropriately. Your advice applies well to C, but since the parent poster was talking about Python, your advice is not actually that good. It's bad practise to explicitly delete objects in Python, and typically you'll want to hang off on handling exceptions until you get to a suitably high level. But I'll grant that's it's a good idea to make liberal use of the finally keyword when dealing with I/O:)
Maybe it's just a little bit of the functional-programming mentality getting absorbed into the mainstream (OO/imperative), but the goal of reducing side-effects is increasingly common with modern software engineering methodologies More than just a little; the defining feature of a functional language is a language that attempts to avoid mutable state. If the goal of reducing side-effects is becoming increasingly more common, then I'd say languages are becoming more functional in nature.
Haskell is used by many as a springboard through which to research programming language design and computer science, so it should come as little surprise that there are many different experimental extensions to the language.
It is a language not without its disadvantages, but every language has its weaknesses, and that should not blind you to their strengths.
But although functional languages are good at representing algorithms and reasoning about them, they are horribly unproductive when it comes to most real-world applications (the ones with a GUI, for instance). Care to justify that statement?
Because functional programming makes it extremely difficult to do things that OOP and procedural can do very simply. A minor nitpick; a language can be functional and object orientated, such as Scala or OCaml.
Stateless isn't a benefit, its a defect. Real life has state. Most workflows you use a computer for require state. Even a simple event like posting this answer requires state- state to store my session info (on both ends). Functional programming languages do not forbid the use of state; they merely require that the programmer pass state around explicitly, rather than it being an implicit part of the environment. State is often a necessary evil, but it causes a lot of problems. Stateful functions are harder to make concurrent, harder to test, and harder to rigorously type. Functional programming discourages the use of states use whenever possible, and attempts to separate it out in the cases when it is required.
I myself think that atheism requires just as much faith as a person who believes in god. Who are you to know for a fact that something intelligent didn't create everything, something had to come from somewhere no one knows so why it is that it has to be nothing. It depends on whether you're talking about weak atheism, which is the absence of a belief in god, or strong atheism, which is the belief that god does not exist.
All the general sources of IT news have already been mentioned in other comments, but I tend to visit programming.reddit.com when I want news and articles on computer science and software development.
Anyone who makes an such a user-friendly, anonymous, encrypted software will be charged with facilitating the distribution of child pornography. 1. Such a charge would be hard to make stick, especially if the author resided outside the US. 2. There already exist anonymising networks (admittedly not that user friendly), that could be used to distribute the software, such as Tor or Freenet. 3. The software could be also posted anonymously from an internet cafe, or an open wireless link. 4. Once enough people are using the software, updates could be performed anonymously through the system, like the Japanese P2P system Share does. 5. If it was released as open source, then arresting the original author wouldn't stop it's spread.
Trying to prevent a piece of software from spreading has never been successful in the past. Why assume it'll be successful in the future, when copying and anonymity will be much easier?
And legislators will make transrouting encrypted data illegalt out of concern for the children. Please, please, think of the children. Twisting the voter's morality to one's own ends can be a very successful ploy, but give that such a law would mean the end of all electronic financial transactions (which is the majority, these days), I suspect that even the most zealous politicians would think twice. Stopping the economy dead in it's tracks ain't going to be much of a vote-winner.
You cannot explain to Joe User why he should use encryption. He doesn't have anything to hide! Only criminals need encryption! I think I could have a go at it. How about this:
Do you like credit cards? Online banking? Shopping on the web? Do you not want criminals taking all your money? Encryption stops criminals stealing your cash online.
There. Simple, to the point - what's not to understand?
By raising the cost (i.e. the hassle, the legil peril, the hardware requirements, the software expertise, etc.) of copying, and of receiving copies, above the price of retail media, they'll solve the problem enough. The problem with this strategy is that it's effectiveness is inversely proportionate to the amount of bandwidth and harddrive space available on the open market. The RIAA and the MPAA are betting their strategy on the assumption that bandwidth and diskspace won't significantly increase any further than it has done already. This does not strike me as an assumption I'd wish to put money on.
For instance, it's pretty easy to tell who is downloading a particular bittorrent. But if bandwidth is not an issue, we can route the request through several intermediaries, such that it is not possible to tell whether an particular IP initiated a request, or is merely relaying it. We can further eliminate the intermediaries liability by encrypting the request, so that the intermediary can legitimately claim he didn't know that the encrypted bytestream he received was anything illegal.
So the RIAA and the MPAA have three choices:
1. Hope that bandwidth plateaus before it becomes easy to anonymously share media. 2. Hope that no-one develops an user-friendly application to do anonymously share media. 3. Try to convince legislators to make people liable for any encrypted data routed through their systems.
Interesting, but can I ask what use base64 has? I read about it on wikipedia but it left me a little confused - how can it provide any useful encryption if you can just run it through a program which is freely available to gain the plaintext? It's not a way of encrypting information; it's a way of representing binary data as alphanumeric characters (along with '+' and '/'). You could also represent binary as a stream of 1s and 0s, or as hexadecimal characters, but because base64 uses more symbols (64 instead of 2 or 16), there's much less redundancy.
Base64 is useful for sending binary data across communication channels that do not normally support it. SMTP is the most common user of base64. It would also be useful if I wanted to post some binary data, such as a long encryption key, as a comment in a/. post.
I don't know enough about 19th century copyright law, but frankly, 20th century copyright law based on the Berne Convention is quite good at what it does, and doesn't really need to be fixed. At best, it needs minor modifications. What do you mean by "minor modifications"? Copyright is a legal incentive to encourage authors to produce more creative works, by allowing the author a temporary monopoly over the work. But whilst this monopoly might encourage new works, it also restricts people's access to existing ones. In the end it it is a balancing act between providing a reasonable incentive, and allowing people access to existing works.
The Berne convention protects an author's work for 50 years after his or her death. Now, somehow this period seems rather excessive. How many writers would say, "I would not write this book if I did not have a guarantee that 50 years after I die, I would still have the copyright." Most people do not plan that far past their own death, and whilst most people want to provide for their children, I don't think many people plan three or four generations down the line.
If copyright were reduced to a fixed period of 50 years from creation date, or even 40 or 30 or even 20 years, would we see a significant drop in creative works? And would that drop be greater than or less than all of the new content produced from adapting older works?
Would you consider an 80% reduction in the length of copyright as being a "minor modification"?
It does not follow. The choice you have is to buy something ang agree to their restrictions, Or dont buy it at all. You just cant assume yourself rights not granted to you. Companies can only enforce restrictions within the bounds of the law; they can't arbitrarily take away any right they choose. This is partially why the DMCA in the US is so heavily criticised, as it provides a loophole in the law for companies to get around restrictions that would otherwise be unlawful.
Unless MS rewrites all of their other commands to accept STDIN/OUT, Monad will never surpass the shells. The power of the shells isnt' their programming flexibility, it's their ability to incorporate all the other UNIX tools and commands via pipes to do what you want. Powershell doesn't use pipes in the same way shells do in unix. Powershell communicates via remote methods and objects, and a lot of the Windows API has been exposed to it, so there's quite a lot of things you can do with it, and a few things that would be a lot more difficult to do with text streams and pipes. It's also quite logically put together, much more so than the standard unix set of command tools. There's not as many third party apps, but most of the basics are there.
It really fails in two places. Firstly, it's slow. You wouldn't have thought it possible for a command shell to be that slow, but it is. It's so slow it was actually quicker for me to use explorer. It is god-awfully, mind-bogglingly slow.
The second problem is that it had no easy way of being accessed over a network link, last time I looked at it. So there's no chance of SSHing into a Windows box and administrating it from there, at least not without fiddling with a lot of hacks and workarounds I couldn't get to work.
The other place where unix shells have an advantage over Powershell is in there interface, as Powershell is currently quite basic in that department. There's limited tab completion and a prompt that can be altered (like PS1 under sh derivitives), but not much over that. Certainly nowhere near my personal favourite, Fish.
Another reason it will never surpass the shells. They're lightweight, and flexible, and I don't need a Garbage Collector running in the back end to clean up my object allocation. Why so closed-minded? Powershell has a lot of interesting ideas, and an architecture that's structurally very well organised. Don't dismiss it just because it was made by Microsoft, especially since it sounds as if you haven't even tried it out.
Re:This is (now) a famous number-theory integer!
on
Censoring a Number
·
· Score: 1, Flamebait
blah blah blah. How is he supposed to know that's what you meant? Because if he didn't, then he isn't very good at math, and if that's the case, why would he be criticising someone's else's calculations?
Me, I'm stupidest one where I work. And I still don't know how 2^6 is a prime. unless there is a special 64 in your imagination. Okay, I'll assume this is a genuine query, rather than a further attempt to be pedantic. Here's a question: what prime numbers multiple together to form 1458?
Answer: 2 * 3 * 3 * 3 * 3 * 3 * 3
If I wanted to be brief, I could write 2 * 3 ^ 6. Or, more informally, I could say that the prime factors are 2 and 3 ^ 6. The latter way of saying it is technically incorrect, but anyone who is even vaguely familiar with factors and prime would instantly understand what I, or the original poster, meant to say. The fact the first AC did not implies that the AC knew very little, and if so, why was he writing such scathing criticism? Anyone with any sense knows that it's a bad idea to voice loud opinions about subjects you know little about, as there's a good chance you'll wind up looking foolish.
Re:When you step back and consider history
on
Beginning Ruby
·
· Score: 1
I know what pure functional approach means; but it's just not practical for the vast majority of applications - we can't optimize it nearly as well as the more conventional imperative style. That's why you see more programs written in O'Caml than Haskell, for example. Haskell is great as a language to learn what FP is about, but pure functional programming certainly won't be the next big thing, not in the next few years at least. Pure functional programming eliminates all side effects. More pragmatic forms of functional programming only attempt to minimise it. This is why I don't consider C# to be a very functional language, because it doesn't really attempt to minimise side effects. C#'s style is still very imperative.
Regarding optimization, I think you'd be surprised at how much pure functional languages can be optimized. If you compare the benchmarks of pure languages like Haskell or Clean again impure languages like OCaml, you'll get comparable performance. Clean even manages to outperform OCaml on average, according to the Computer Language Shootout.
However, I agree that pure functional languages are unlikely to gain much ground for a few years at least. But hopefully we'll see side-effect functions slowly, slowly falling out of fashion the next decade or so, or at least have some way of partitioning them from stateless functions. C# is a long way off from doing anything of the sort.
Re:When you step back and consider history
on
Beginning Ruby
·
· Score: 1
No idea in either case. C++ standard certainly doesn't guarantee it, but IIRC, most optimizing compilers (and GCC in particular) try to perform it already. Java, I don't know. More likely for C#, since CIL already has a special bytecode for optimized tail calls. I didn't know GCC optimised that, though it would appear you're certainly right! I don't think tail call elimination is planned for Java (from what I've heard), and I haven't heard it being introduced into C#. I guess it's possible though, since as you say it's supported by CIL, although so far as I know only functional languages like F# etc. use it.
Technically, first-class functions are all that is needed to consider the language functional. Pragmatically, it's more like "convenient first-class functions". There are a few other things traditionally associated with functional languages, true - type inference and pattern matching, in particular. Functional programming is a programming style that attempts to minimise side effects, and whilst first-class functions et all are steps to ensuring that goal, C# still encourages an imperative style, and many common classes and methods in the.NET libraries produce a lot of side effects when called.
For instance, if I call the Add method on the array ArrayList in C#, it updates the data in the ArrayList with a new value. If I were to add an element to a list in Haskell, a new list would be returned; the original list would not be altered (indeed, in languages like Haskell, it literally cannot be altered).
I favour the functional approach, since it makes programs easier to test and verify. In a pure functional programming language, I know that for any arguments I pass into the function, I'll always get the same return value. Perfect for unit testing, and other verification methods.
This is a pure hypothetical. What I am trying to illicit from the/. folks is an alternative or modification to the current system.
In principle I agree that most every software patent issued in the last 20 years is more then likely just trash. So the question is, How or What is a more appropriate method, device etc. to protect truly novel and unique work? I'd gathered that it was hypothetical;)
My point was that your example of a pure algorithm could still make considerable money even in absence of a patent system, so perhaps patents aren't necessary at all.
If you had such an algorithm, I'd suggest starting a remote storage business, as such a reduction in space could save an awful lot of money.
Or sell it to a company like Google under some agreement where they are the sole recipients of the algorithm. You'd probably make more money that way than you ever could on your own.
That's a lawyerly-phrased question. I still indent code. I don't like my indentation preferences determining the logic of the code. Under what circumstances would you indent something in a different fashion to Python? I can't think of any instance, myself, but perhaps you can?
Re:When you step back and consider history
on
Beginning Ruby
·
· Score: 1
C# has first-class functions and lambdas already, and will get neat syntax for them in v3.0. Java is going to get lambdas in the next version. Even C++0x is going to get something similar, though not with true closure semantics. Does that include tail call elimination?
You don't have to wait for the Next Big Thing for functional stuff - it's already here, in the mainstream languages. It just doesn't look as neat as Haskell does, but you shouldn't care all that much about the looks. Sure, this is all a step in the functional direction, but I was rather hoping for a more than just a single step. Since you mention Haskell, you'll probably be aware it contains a lot of functionality that is difficult or impossible to reproduce in a language like C# or Java.
Not to doubt Twitter, but this would have it as the second most popular website on the net, behind Google: http://www.alexa.com/site/ds/top_500?&qterm=&p=Dev Corner, as MSN currently averages 9,700 page views per second (I should know). I did some checking and you're probably right; according to this page the oft-quoted 11000 figure is a misquote, and apparently the true figure is closer to 600 requests per second.
Oops! That's what happens when you don't check your sources, folks - my bad!
Still, 600 requests per second is still a fairly heavy traffic throughput for Rails to scale to.
Such as...what? The two main complaints I've seen about Ruby features are (1) lack of good Unicode support, which is certainly can be a real problem with I18n, but isn't a barrier to its utility in learning to program, for sure; and (2) its "too slow", which, again, isn't a barrier to its utility in learning to program in it Well, I was talking generally, rather than just from a beginners point of view. However, from a learning perspective, personally I found Ruby's class model to be more difficult to grasp than Python's, and it still has some odd bits to it. It's more elegant, however, I'll admit.
Ruby's syntax itself is also not as suited for a beginner, in my opinion, as there a lot of different ways to do the same thing. If you're learning by example, and each example employs a different technique, you have more to learn. Some other things that come to mind are the "and" and "or" boolean operators, which don't behave as one might expect they would; blocks have some scope issues that aren't immediately obvious; and leaving a method call unbracketed, whilst sometimes more aesthetically pleasing, can produce odd syntax errors.
I'm sure there's a few more oddities in the language I've forgotten about.
I'm not saying Ruby is a bad language, merely that it has its share of flaws, the same as everything else.
Slashdot Mirror
The second point can be circumvented by simply not storing any plaintext. Remove any harddrives from your machine, and use a specialist LiveCD with an encrypted USB stick to store any data you wish to keep between sessions.
Granted, these techniques are not foolproof. You could be unknowingly under surveillance when you enter your password in, for instance. However, one can reduce the risk by a considerable margin, making it increasingly harder, and increasingly expensive, for you data to be accessed without your consent.
Haskell is used by many as a springboard through which to research programming language design and computer science, so it should come as little surprise that there are many different experimental extensions to the language.
It is a language not without its disadvantages, but every language has its weaknesses, and that should not blind you to their strengths.
Frankly, this seems a rather sensible idea to me.
All the general sources of IT news have already been mentioned in other comments, but I tend to visit programming.reddit.com when I want news and articles on computer science and software development.
2. There already exist anonymising networks (admittedly not that user friendly), that could be used to distribute the software, such as Tor or Freenet.
3. The software could be also posted anonymously from an internet cafe, or an open wireless link.
4. Once enough people are using the software, updates could be performed anonymously through the system, like the Japanese P2P system Share does.
5. If it was released as open source, then arresting the original author wouldn't stop it's spread.
Trying to prevent a piece of software from spreading has never been successful in the past. Why assume it'll be successful in the future, when copying and anonymity will be much easier? And legislators will make transrouting encrypted data illegalt out of concern for the children. Please, please, think of the children. Twisting the voter's morality to one's own ends can be a very successful ploy, but give that such a law would mean the end of all electronic financial transactions (which is the majority, these days), I suspect that even the most zealous politicians would think twice. Stopping the economy dead in it's tracks ain't going to be much of a vote-winner. You cannot explain to Joe User why he should use encryption. He doesn't have anything to hide! Only criminals need encryption! I think I could have a go at it. How about this:
Do you like credit cards? Online banking? Shopping on the web?
Do you not want criminals taking all your money?
Encryption stops criminals stealing your cash online.
There. Simple, to the point - what's not to understand?
For instance, it's pretty easy to tell who is downloading a particular bittorrent. But if bandwidth is not an issue, we can route the request through several intermediaries, such that it is not possible to tell whether an particular IP initiated a request, or is merely relaying it. We can further eliminate the intermediaries liability by encrypting the request, so that the intermediary can legitimately claim he didn't know that the encrypted bytestream he received was anything illegal.
So the RIAA and the MPAA have three choices:
1. Hope that bandwidth plateaus before it becomes easy to anonymously share media.
2. Hope that no-one develops an user-friendly application to do anonymously share media.
3. Try to convince legislators to make people liable for any encrypted data routed through their systems.
Base64 is useful for sending binary data across communication channels that do not normally support it. SMTP is the most common user of base64. It would also be useful if I wanted to post some binary data, such as a long encryption key, as a comment in a
The Berne convention protects an author's work for 50 years after his or her death. Now, somehow this period seems rather excessive. How many writers would say, "I would not write this book if I did not have a guarantee that 50 years after I die, I would still have the copyright." Most people do not plan that far past their own death, and whilst most people want to provide for their children, I don't think many people plan three or four generations down the line.
If copyright were reduced to a fixed period of 50 years from creation date, or even 40 or 30 or even 20 years, would we see a significant drop in creative works? And would that drop be greater than or less than all of the new content produced from adapting older works?
Would you consider an 80% reduction in the length of copyright as being a "minor modification"?
It really fails in two places. Firstly, it's slow. You wouldn't have thought it possible for a command shell to be that slow, but it is. It's so slow it was actually quicker for me to use explorer. It is god-awfully, mind-bogglingly slow.
The second problem is that it had no easy way of being accessed over a network link, last time I looked at it. So there's no chance of SSHing into a Windows box and administrating it from there, at least not without fiddling with a lot of hacks and workarounds I couldn't get to work.
The other place where unix shells have an advantage over Powershell is in there interface, as Powershell is currently quite basic in that department. There's limited tab completion and a prompt that can be altered (like PS1 under sh derivitives), but not much over that. Certainly nowhere near my personal favourite, Fish. Another reason it will never surpass the shells. They're lightweight, and flexible, and I don't need a Garbage Collector running in the back end to clean up my object allocation. Why so closed-minded? Powershell has a lot of interesting ideas, and an architecture that's structurally very well organised. Don't dismiss it just because it was made by Microsoft, especially since it sounds as if you haven't even tried it out.
unless there is a special 64 in your imagination. Okay, I'll assume this is a genuine query, rather than a further attempt to be pedantic. Here's a question: what prime numbers multiple together to form 1458?
Answer: 2 * 3 * 3 * 3 * 3 * 3 * 3
If I wanted to be brief, I could write 2 * 3 ^ 6. Or, more informally, I could say that the prime factors are 2 and 3 ^ 6. The latter way of saying it is technically incorrect, but anyone who is even vaguely familiar with factors and prime would instantly understand what I, or the original poster, meant to say. The fact the first AC did not implies that the AC knew very little, and if so, why was he writing such scathing criticism? Anyone with any sense knows that it's a bad idea to voice loud opinions about subjects you know little about, as there's a good chance you'll wind up looking foolish.
Regarding optimization, I think you'd be surprised at how much pure functional languages can be optimized. If you compare the benchmarks of pure languages like Haskell or Clean again impure languages like OCaml, you'll get comparable performance. Clean even manages to outperform OCaml on average, according to the Computer Language Shootout.
However, I agree that pure functional languages are unlikely to gain much ground for a few years at least. But hopefully we'll see side-effect functions slowly, slowly falling out of fashion the next decade or so, or at least have some way of partitioning them from stateless functions. C# is a long way off from doing anything of the sort.
For instance, if I call the Add method on the array ArrayList in C#, it updates the data in the ArrayList with a new value. If I were to add an element to a list in Haskell, a new list would be returned; the original list would not be altered (indeed, in languages like Haskell, it literally cannot be altered).
I favour the functional approach, since it makes programs easier to test and verify. In a pure functional programming language, I know that for any arguments I pass into the function, I'll always get the same return value. Perfect for unit testing, and other verification methods.
In principle I agree that most every software patent issued in the last 20 years is more then likely just trash. So the question is, How or What is a more appropriate method, device etc. to protect truly novel and unique work? I'd gathered that it was hypothetical
My point was that your example of a pure algorithm could still make considerable money even in absence of a patent system, so perhaps patents aren't necessary at all.
If you had such an algorithm, I'd suggest starting a remote storage business, as such a reduction in space could save an awful lot of money.
Or sell it to a company like Google under some agreement where they are the sole recipients of the algorithm. You'd probably make more money that way than you ever could on your own.
Oops! That's what happens when you don't check your sources, folks - my bad!
Still, 600 requests per second is still a fairly heavy traffic throughput for Rails to scale to.
Ruby's syntax itself is also not as suited for a beginner, in my opinion, as there a lot of different ways to do the same thing. If you're learning by example, and each example employs a different technique, you have more to learn. Some other things that come to mind are the "and" and "or" boolean operators, which don't behave as one might expect they would; blocks have some scope issues that aren't immediately obvious; and leaving a method call unbracketed, whilst sometimes more aesthetically pleasing, can produce odd syntax errors.
I'm sure there's a few more oddities in the language I've forgotten about.
I'm not saying Ruby is a bad language, merely that it has its share of flaws, the same as everything else.