It would be very easy for an ISP to perform man-in-the-middle attacks on supposedly secure sites which use self-signed certificates.
Not necessarily. There's a Firefox plugin called Perspectives that prevents MITM attacks that are confined to a limited IP block, such as one initiated by an ISP.
It works by getting several remote servers to query the site and send the certificate back to the browser. If the certificate the remote sites see is the same as the certificate your browser sees, then you can bee certain your ISP isn't performing a MITM attack.
The U.S. average speed = 4.8 Mbit/s. EU = 5.3. Australia = 1.7. We Americans are no worse-off than our European colleagues, and vastly superior than the Aussies.
Citation?
The EU is also comprised of a lot of different countries, some of which have better infrastructure than others. I'd be interested in comparing the average speed of, say Sweden with California.
Yes, a good programmer can pick up the syntax of any language. But syntax hasn't been the key to a language since K&R's White Book. The main issues is the API that goes with it.
And if you had bothered to read the article, you'd have learned that out of the 6 languages, 3 use the Java API, 2 use the.NET API, and the remaining one is designed to integrate very well with C.
In a very limited, specialized sort of way... maybe.
But I would consider "good at their craft" to be along the lines of handling someone coming by your desk unexpected, dropping a listing (or the equivalent) on it and saying "fix this" and being able to do so.
It seems unlikely that you'd be asked to fix a bug in some 68008 assembly if you worked in a company that writes web applications. The programming field is wide enough that certain fields have little bearing on one another. I've written a few things in assembly, but I can't think of a single time that's been useful when working in Ruby on Rails.
And whilst I know it's just a hypothetical example, people shouldn't be coming to a programmer's desk and telling him or her to fix X or Y; that's just too distracting. Put the problem in an issue tracker instead:)
Sure a good programmer will learn any programming language very fast. The thing that takes time to learn is the compiler, and the standard libraries available with that language and compiler.
Uh, the compiler? Seriously? Could you explain what you mean by that?
I'd consider the minimum for a really good programmer to include at least a project or two's worth of exposure to...
I'm familiar with languages in all those categories, but I wouldn't consider them all essential. It's important to have a wide range of experience outside the norm, if only because it demonstrates an enjoyment of learning new things. But I don't necessarily think that a programmer's experience needs to be comprehensive for them to be good at their craft.
Boo is 0.8.2 - If you wish your boss would let you use this, you're fired.
I once created an in-house fork of Boo for file processing. It worked reasonably well as a stopgap solution, and I wasn't fired at the end of it.
I could understand a more generic Functional Lang like Hask,OCaml,Erlang but F#?
Haskell, OCaml and Erlang don't have access to the.NET libraries. F# does, so you get the benefits of a statically typed functional language with the extensive.NET APIs.
Groovy - JVM Java scripting for when Java is too hard for you? Wow. You're fired.
Groovy is a superset of Java functionality, not a subset. You can do everything in Groovy that you can in Java, but there are a lot of things in Groovy that Java lacks, most notably closures.
So if anything, I'd contend that Groovy is harder to learn than Java.
Clojure - Functional syntax on the JVM. Why would I use this and for what when there's no support?
The mailing list is quite active, so I assume you're talking about a paid support contract or something? Can you even get that kind of support with, say, Scala or Ruby? Would you even want to?
Lua... Chances your developer wants to use it inappropriately = 99%
Uh, hire better developers?
I mean, really, if you're working with morons, then sure, you might not want them to use a language they can screw things up too badly in. But it's probably better to just hire competent programmers in the first place.
Despite the inflamatory tone of the parent article, Ruby is pretty immature and rough around the edges in many ways, so I feel your pain. However, since Rails will run under JRuby, you can always use that to avoid buffer overflows.
Perhaps my Calc professor was a moron, but if you are suggesting that the entirety of calculus can boiled down to y/x and one simple variation of it...
Exactly so. My previous post demonstrated how to work out the derivitive of a function from first principles, which is essentially all there is to calculus. Where it gets difficult is figuring out how to write f(x + d) in terms of x and f(x), but that's just algebra. The essense of calculus is very simple; it's just that the problems posed to the student can become quite complex.
I think maybe you've just had a bad teacher, because calculus is little more than basic algebra. I'm not exaggerating here.
When someone says "find the gradient of y", all they mean is "divide y by x". So the gradient of 2x is 2.
When someone says "find the gradient between y1 at x1, and y2 at x2", all they mean is:
y2 - y1 ------- x2 - x1
All calculus does is say "imagine the difference between y2 and y1 is a really small number, which we'll call 'd'".
And that's it. There's really nothing more to it than that. Compared to actually programming a website, calculus is really basic. But people teach it like it's some amazingly complex mathematical technique, when all boils down to is "How much does y change over a very small period".
If someone says to you "differentiate x^2", all they mean is to simplify:
(x + d)^2 - x^2 --------------
(x + d) - x
There's nothing more to it. Loops, if statements, recursion... all so much more difficult.
.
x^2 + 2dx + d^2 - x^2 = --------------------
d
2dx + d^2 = --------
d
= 2x + d
If you can work out that "(x + d - x)" is "d", then calculus isn't much of a leap beyond that. Sure, there are complex calculus equations, and there are some which require real imagination to solve. But the actual core of calculus is really simple.
Right now the ONLY logical reasons to move to a Linux based PC is 1) cost and 2) boot time when run in minimalist mode. Otherwise an XP machine is far better for the availability of apps and consistency of experience.
Presumably you're talking about this from the point of view of a manufacturer. From the user's perspective, there's plenty of other logical reasons to switch.
Note how clearly it states exactly what it does and how obvious it is what the resultant tree structure looks like.
The original problem called for a tree of depth 8, which from your VB example would result in a large amount of nested code.
I'm also interested whether the inner loop generates a new SQL query for each item. Is LINQ clever enough to optimise that inner query into a join? I'd be impressed if it did.
If not, then you're performing N queries as opposed to just one. Applying this technique to a tree of depth 8 would result in even more distinct queries. This would start to get very slow, as I've had experience maintaining code that use nested SQL statements to pull out hierarchical data. It takes about a day to do something that should have taken under a minute.
So the VB code is considerably longer than the Haskell code, and possibly much, much slower, depending on how clever LINQ is.
I did say I wouldn't return to this thread, but it occurred to me that having asked for evidence, I had provided little of my own.
So lets try to remove some of this hand-waving with a set of facts.
If you want to apply any kind of exhaustive approach you will have to deal with the same nearly infinite number of states I have mentioned
Let's deal with this assertion, which seems to be the core of your argument; there are just too many states to be tested for unit testing to be useful.
I disagree, because you don't have to test all cases in order to have a high degree of confidence the system works. This seems obvious to me, but let's test it.
Consider a standard stack-based language with seven operations: add, sub, mul, inc, dec, dup, swp. What operations would be needed to calculate, say, f(x) = (x + 1)(x - 1)?
For feasibility's sake, lets limit the size of the program to a maximum of 8 operations. Given this restriction, there are 6,725,600 possible programs that could be written.
So lets introduce a unit test to validate the output: f(5) == 24. How many possible programs can fulfil that criteria? Only 1,104. So what about two tests? Adding f(9) == 80, the number of programs falls to 721. Add a third test, f(43) == 1848, it's still 721. A fourth, f(26) == 675, and it's still 721. Tests five and six, f(0) = -1 and f(255) == 65024, yield the same: 721.
In this example, with one single unit test we were able to eliminate 99.99% of all possible bugs. With only two unit tests, 100% of bugs were eliminated.
There's no need to test every possible combination of code and state in order to be reasonably confident that your program works, because a program isn't a random collection of symbols that just happen to produce the right result. Rather, the symbols represent connected rules, and that vastly reduces the problem space.
There, I've satisfied my own criteria for basing arguments on evidence and examples. That gets my nagging sense of hypocrisy out of the way.
A neat approach to the problem, though your code loads the entire result tree into memory, which could be rather large if you're trying to export information from a large database. Conversely, the Haskell code builds up the tree lazily, so it can handle a result set of arbitrary size with relatively little memory overhead.
Slashdot Mirror
It would be very easy for an ISP to perform man-in-the-middle attacks on supposedly secure sites which use self-signed certificates.
Not necessarily. There's a Firefox plugin called Perspectives that prevents MITM attacks that are confined to a limited IP block, such as one initiated by an ISP.
It works by getting several remote servers to query the site and send the certificate back to the browser. If the certificate the remote sites see is the same as the certificate your browser sees, then you can bee certain your ISP isn't performing a MITM attack.
Never has the world had more need for a B-Ark.
Just so you know, I've already reserved a place for all the British MPs that think a surveillance state is a good idea.
His answer? "To stop terrorists killing people in our society quite a long way, actually." Which sent a chill down my spine.
The war in Iraq has made Britain a tempting target for Islamic extremism, but funnily enough Geoff Hoon strongly supports the Iraq War.
When it comes to preventing terrorism, it seems Mr. Hoon rates bombing Iraqis more important than maintaining British civil liberties.
Never. Never ever. Not until there is one cohesive Linux distribution to rule them all.
Or until they standardise on a package format, at least for closed binaries.
Although, I'd imagine there's a lot of people who'd be happy with just an Office + Browser combination.
The U.S. average speed = 4.8 Mbit/s. EU = 5.3. Australia = 1.7. We Americans are no worse-off than our European colleagues, and vastly superior than the Aussies.
Citation?
The EU is also comprised of a lot of different countries, some of which have better infrastructure than others. I'd be interested in comparing the average speed of, say Sweden with California.
If suddenly all messages sent are garbled groups of characters, the government will think something's up and may outlaw private encryption
Over 100 billion pounds worth of revenue generated per year from ecommerce in the UK says they won't.
Yes, a good programmer can pick up the syntax of any language. But syntax hasn't been the key to a language since K&R's White Book. The main issues is the API that goes with it.
And if you had bothered to read the article, you'd have learned that out of the 6 languages, 3 use the Java API, 2 use the .NET API, and the remaining one is designed to integrate very well with C.
In a very limited, specialized sort of way ... maybe.
But I would consider "good at their craft" to be along the lines of handling someone coming by your desk unexpected, dropping a listing (or the equivalent) on it and saying "fix this" and being able to do so.
It seems unlikely that you'd be asked to fix a bug in some 68008 assembly if you worked in a company that writes web applications. The programming field is wide enough that certain fields have little bearing on one another. I've written a few things in assembly, but I can't think of a single time that's been useful when working in Ruby on Rails.
And whilst I know it's just a hypothetical example, people shouldn't be coming to a programmer's desk and telling him or her to fix X or Y; that's just too distracting. Put the problem in an issue tracker instead :)
Sure a good programmer will learn any programming language very fast. The thing that takes time to learn is the compiler, and the standard libraries available with that language and compiler.
Uh, the compiler? Seriously? Could you explain what you mean by that?
I'd consider the minimum for a really good programmer to include at least a project or two's worth of exposure to...
I'm familiar with languages in all those categories, but I wouldn't consider them all essential. It's important to have a wide range of experience outside the norm, if only because it demonstrates an enjoyment of learning new things. But I don't necessarily think that a programmer's experience needs to be comprehensive for them to be good at their craft.
Boo is 0.8.2 - If you wish your boss would let you use this, you're fired.
I once created an in-house fork of Boo for file processing. It worked reasonably well as a stopgap solution, and I wasn't fired at the end of it.
I could understand a more generic Functional Lang like Hask,OCaml,Erlang but F#?
Haskell, OCaml and Erlang don't have access to the .NET libraries. F# does, so you get the benefits of a statically typed functional language with the extensive .NET APIs.
Groovy - JVM Java scripting for when Java is too hard for you? Wow. You're fired.
Groovy is a superset of Java functionality, not a subset. You can do everything in Groovy that you can in Java, but there are a lot of things in Groovy that Java lacks, most notably closures.
So if anything, I'd contend that Groovy is harder to learn than Java.
Clojure - Functional syntax on the JVM. Why would I use this and for what when there's no support?
The mailing list is quite active, so I assume you're talking about a paid support contract or something? Can you even get that kind of support with, say, Scala or Ruby? Would you even want to?
Lua... Chances your developer wants to use it inappropriately = 99%
Uh, hire better developers?
I mean, really, if you're working with morons, then sure, you might not want them to use a language they can screw things up too badly in. But it's probably better to just hire competent programmers in the first place.
Is that it's not like other languages, you still write Java with dynamic typing.
Clojure is also dynamically typed, and it's a lot faster than Groovy.
Your programming skills should not be tied to the language you use.
Sure, and good driving skills should not be tied to the car you drive, but I suspect you'd probably prefer driving a Porsche over a Reliant Robin.
Right on! A good programmer will learn any programming language in a fortnight.
Try learning Haskell in a fortnight, if you have no experience of statically typed functional languages.
Of course, you could be arguing that a programmer isn't very good if he doesn't already have a few functional languages under his or her belt :)
Despite the inflamatory tone of the parent article, Ruby is pretty immature and rough around the edges in many ways, so I feel your pain. However, since Rails will run under JRuby, you can always use that to avoid buffer overflows.
Perhaps my Calc professor was a moron, but if you are suggesting that the entirety of calculus can boiled down to y/x and one simple variation of it...
Exactly so. My previous post demonstrated how to work out the derivitive of a function from first principles, which is essentially all there is to calculus. Where it gets difficult is figuring out how to write f(x + d) in terms of x and f(x), but that's just algebra. The essense of calculus is very simple; it's just that the problems posed to the student can become quite complex.
I think maybe you've just had a bad teacher, because calculus is little more than basic algebra. I'm not exaggerating here.
When someone says "find the gradient of y", all they mean is "divide y by x". So the gradient of 2x is 2.
When someone says "find the gradient between y1 at x1, and y2 at x2", all they mean is:
All calculus does is say "imagine the difference between y2 and y1 is a really small number, which we'll call 'd'".
And that's it. There's really nothing more to it than that. Compared to actually programming a website, calculus is really basic. But people teach it like it's some amazingly complex mathematical technique, when all boils down to is "How much does y change over a very small period".
If someone says to you "differentiate x^2", all they mean is to simplify:
There's nothing more to it. Loops, if statements, recursion... all so much more difficult.
If you can work out that "(x + d - x)" is "d", then calculus isn't much of a leap beyond that. Sure, there are complex calculus equations, and there are some which require real imagination to solve. But the actual core of calculus is really simple.
Of course, I'm sure you meant that as an insult, something like, "oh a web developer! They're so stupid! No wonder they don't know math! Ha ha ha!!!"
Given that you seem to take pride in your ignorance of basic math, you're not doing a lot to dispel that myth.
Right now the ONLY logical reasons to move to a Linux based PC is 1) cost and 2) boot time when run in minimalist mode. Otherwise an XP machine is far better for the availability of apps and consistency of experience.
Presumably you're talking about this from the point of view of a manufacturer. From the user's perspective, there's plenty of other logical reasons to switch.
And if it's like some other languages you might have a long time to wait before 3.0.
Given that the first release candidate of Python 3.0 is already out, I doubt we'll be in for a very long wait.
See here. Hope that's clear enough!
Note how clearly it states exactly what it does and how obvious it is what the resultant tree structure looks like.
The original problem called for a tree of depth 8, which from your VB example would result in a large amount of nested code.
I'm also interested whether the inner loop generates a new SQL query for each item. Is LINQ clever enough to optimise that inner query into a join? I'd be impressed if it did.
If not, then you're performing N queries as opposed to just one. Applying this technique to a tree of depth 8 would result in even more distinct queries. This would start to get very slow, as I've had experience maintaining code that use nested SQL statements to pull out hierarchical data. It takes about a day to do something that should have taken under a minute.
So the VB code is considerably longer than the Haskell code, and possibly much, much slower, depending on how clever LINQ is.
If you want to convert SQL results to XML, you can't do better than VB9.
That's just a linear list of items tags. The Haskell code was creating a tree of depth N from a result set of N columns.
I did say I wouldn't return to this thread, but it occurred to me that having asked for evidence, I had provided little of my own.
So lets try to remove some of this hand-waving with a set of facts.
If you want to apply any kind of exhaustive approach you will have to deal with the same nearly infinite number of states I have mentioned
Let's deal with this assertion, which seems to be the core of your argument; there are just too many states to be tested for unit testing to be useful.
I disagree, because you don't have to test all cases in order to have a high degree of confidence the system works. This seems obvious to me, but let's test it.
Consider a standard stack-based language with seven operations: add, sub, mul, inc, dec, dup, swp. What operations would be needed to calculate, say, f(x) = (x + 1)(x - 1)?
For feasibility's sake, lets limit the size of the program to a maximum of 8 operations. Given this restriction, there are 6,725,600 possible programs that could be written.
So lets introduce a unit test to validate the output: f(5) == 24. How many possible programs can fulfil that criteria? Only 1,104. So what about two tests? Adding f(9) == 80, the number of programs falls to 721. Add a third test, f(43) == 1848, it's still 721. A fourth, f(26) == 675, and it's still 721. Tests five and six, f(0) = -1 and f(255) == 65024, yield the same: 721.
In this example, with one single unit test we were able to eliminate 99.99% of all possible bugs. With only two unit tests, 100% of bugs were eliminated.
There's no need to test every possible combination of code and state in order to be reasonably confident that your program works, because a program isn't a random collection of symbols that just happen to produce the right result. Rather, the symbols represent connected rules, and that vastly reduces the problem space.
There, I've satisfied my own criteria for basing arguments on evidence and examples. That gets my nagging sense of hypocrisy out of the way.
Java version might look something like this
A neat approach to the problem, though your code loads the entire result tree into memory, which could be rather large if you're trying to export information from a large database. Conversely, the Haskell code builds up the tree lazily, so it can handle a result set of arbitrary size with relatively little memory overhead.