It didn't force recursion, and the most sensible, understandable, fastest, *easiest* way to solve the stated goals is to just hardcode the solution. Recursion, for this problem, is way overkill.
I notice that you didn't write out the whole hardcoded solution. Perhaps writing out an entire recursive solution would be easier?
DVDs are not without their own problems though. I find the unskippable commercials at the beginning of many DVDs (Shrek 2 for example) to be offensive. Sort of like commercials on cable TV.
Lua is an interpreted language. A Lua program can never be as fast as a properly-written C program. If you can prove differently, there's a big future for you in Computer Science.
Let me clarify my point. We need a language that is easy on the programmer, but can also be used to write fast code and operating systems.
Compiling to native code is essential for a truly general-purpose language because there are some things which an interpreter cannot do. Full hardware speed and bare metal execution are two of them.
If all the C programmers vanish, what are we going to write the next generation of high-level languages in?
That's a very good question. However, just because programming in C is difficult doesn't mean that it's the best language to write high-level languages in. C has many design flaws that people have gotten so used to, they assume there's no other way of doing things.
If you like programming in C because it's a challenge, then by all means do so. However, I would classify that hobby with people who program in Intercal and similar. Those languages are challenging too.
I see a real need for a language that is as easy to program in as Python, yet as potentially fast as C. As far as I know such a language doesn't exist yet, but I see no fundamental obstacles preventing us from creating one. It's just a matter of time.
Do you really want a future where not a single person actually knows what is happening inside that CPU, just because "it's hard?"
Yes, an essential part of a programmer's training is learning exactly what is happening inside the machine. However, a human being cannot keep track of everything at once. That's why we use abstraction. A high-level language (not C) abstracts away the details the computer is smart enough to handle, and leaves the material which the computer is not smart enough to handle.
Programming is fundamentally hard. Making the job harder than it needs to be can be fun, but for day-to-day work, it just doesn't make sense.
I'd more likely point to our superb visual acuity, and our unparalleled dexterity and communication skills. It was these qualities, coupled to our endurance, that I would argue made our species successful enough to be able to afford to develop large brains.
In discussions like these I never see anyone mention human throwing ability. No other animal can throw as hard or as accurately as humans can. I would not be surprised if a large part of early human hunting consisted of throwing rocks at small animals.
That's backwards. Recursive decent with backtracking can parse all LL(k) grammars for arbitrary k. OTOH, yacc/bison can only parse LR(1) which, although sufficient for most realistic grammars, definitely is not as general as a full LL(k) method.
A few reminders:
Recursive descent with backtracking has exponential time complexity.
The set of LL(n) languages is a subset of the LL(n+1) languages.
The set of LR(n) languages is identical to the set of LR(n+1) languages which is identical to the set of deterministic context-free languages.
Left-recursive grammars are a red herring -- you can always eliminate the recursion, and with backtracking you can deal with arbitrary lookahead requirements.
Yes, but you have to alter the grammar and deal with nonlinear time complexity. Which is the reason LR(1) parsing is so common.
Meaning that it is not backward compatible without modifying your source code.
Thus spake Larry Wall in Apocalypse 5:
...we took several large steps in Perl 5 to enhance regex capabilities. We took one large step forwards with the/x option, which allowed whitespace between regex tokens. But we also took several large steps sideways with the (?...) extension syntax. I call them steps sideways, but they were simultaneously steps forward in terms of functionality and steps backwards in terms of readability. At the time, I rationalized it all in the name of backward compatibility, and perhaps that approach was correct for that time and place. It's not correct now, since the Perl 6 approach is to break everything that needs breaking all at once.
And unfortunately, there's a lot of regex culture that needs breaking.
And from Apocalypse 1:
It would be rather bad to suddenly give working code a brand new set of semantics. The answer, I believe, is that it has to be impossible by definition to accidentally feed Perl 5 code to Perl 6. That is, Perl 6 must assume it is being fed Perl 5 code until it knows otherwise.
In other words, it is backwards compatible, it isn't backwards compatible, and when you install Perl 6, you are installing both.
I tried learning Python as my first language because Eric Raymond recommended it to newbies, and it didn't work out so well for me.
I'm sorry to hear that. It's true that some of the Python books out there are deficient. This book is good for teaching programming, but it's only been available for a couple years.
yeah but everyone should at least understand the concept of "type" a strong typed language should be used
Python is a strongly typed language. More strongly typed than C in fact. People often think that Python is weakly typed because variables do not have a particular type associated with them. However, in Python it is the values that have types. Python variables are just names that make it convenient to manipulate those values.
Python is strongly dynamically typed, like Lisp and Smalltalk. Other combinations of strong vs weak and static vs dynamic are shown here.
Go is about constant evaluation, pattern recognition, and balance and computers can't touch it.
That's how people play Go. That's also how people play Chess. That's not how computers play either one.
A computer that can analyze Go can analyze life. There are too many factors interacting simultaneously to brute-force so you must actually move forward with AI.
People used to think that making chess-playing computers would help us understand intelligence. Turns out it just helped us understand Chess (and a few other things).
The only real difference between Chess and Go as far as computers are concerned is that Go is many orders of magnitude more complex. It's only a matter of time before computer power and search techniques reach a level that can challenge humans at playing Go. Whether that leads to a computer that can analyze life remains to be seen.
see, for example, the modifications to SHA-1(?) that defeated differential cryptanalysis but were utterly inexplicable at the time they proposed them
It may not be the instance you're thinking of, but I know that the NSA was involved in the design of DES. It's resistant against differential cryptanalysis (which was not discovered publically until 15 years after DES was published). DES is not resistant against linear cryptanalysis however, which may indicate that the NSA was not aware of the technique at that time.
Never messed with Python, but I agree that it would probably be better to throw students right in the deep end and get them coding in C.
The trouble with teaching C first is that there are many things about C which are not good for newbies. For example, how long would it take for you to explain the following C program to a person who knew nothing about programming?
Now, how long would it take to explain the following Python program to the same person?
print "Hello, World!"
Granted, the C example could be made simpler, but only at the expense of leaving out things which really belong there in a real program. The Python example is complete as is.
There are some domains where C is still the correct choice, but teaching programming is not one of them. C does not reward as many bad habits as BASIC, but it does make the programmer worry about things that beginning programmers shouldn't have to think about. There are many other reasons Python is a better language for teaching programming, but I'll leave it at that for now. I recommend you look into it. Most people who do are glad they did.:)
The biggest reason being to teach them structure. BASIC breeds spaghetti coders.
Are you saying that the universe will honor the rule only if no one is sending the signal?
Well, what I meant to say is that the inflation process does not cause information to go from one part of the universe to another faster than light can, so it does not violate causality.
Pardon me but if the universe expanded in such a manner wouldn't that be against the theory of relativity. What about breaking causality?
Well IANAP, but I'll explain what I understand of it.
Relativity requires that no signal can travel faster than the speed of light. During inflation, nearby parts of the universe move away from each other faster than the speed of light. However, because there is no signal traveling FTL, causality is not violated.
...the universe would have to have expanded at several times the speed of light in those first 400,000 years...
Yes. During inflation the universe expanded not at several times the speed of light, but rather doubled its size every 10^-34 of a second. After about a hundred doublings the inflationary period ended and expansion slowed to (locally) sub-light speeds.
The microwave background didn't come from the big bang though. It was actually emitted from the surface of last scattering when the universe became transparent for the first time--around 300k years after the big bang.
...we'd have to be sitting at pretty close to the center of the universe...
The "center of the universe" is not well-defined. If the universe is topologically closed, then it has neither center nor boundary, like the surface of the earth. If the universe is topologically open, then it is infinite in size and similarly has neither center nor boundary.
Still, this whole getting into "space" thing is kinda silly, apart from a 3 minute free-fall and a good view. It's an adrenaline kick, but it's so far from what is needed for orbital, it's not even funny.
The X-15 was very far from orbital as well. However, do you think that Mercury, Gemini, and Apollo would have been possible without the technology and data from X-15? Perhaps, but it would have been like trying to run before you know how to stand. Learning things a few at a time is better.
Probably not. The sound of an impact is very localized in time, so it is spread out in the frequency domain. A musical sound is spread out in time, so it can be very localized in frequency.
I believe that most helium found on earth is a product of nuclear decay. Helium is very stable, so many decay reactions release helium nuclei (alpha particles). It tends to collect in the same places as natural gas.
Personally I miss the days of 3-5watt analog cell phones.
But weren't those the bag phones where you carried around a big backpack full of battery to use them?
I'll take a handset that fits in my pocket, thanks. Though the option to plug in the phone and boost the signal strength would be nice for driving out in the sticks...
Slashdot Mirror
It didn't force recursion, and the most sensible, understandable, fastest, *easiest* way to solve the stated goals is to just hardcode the solution. Recursion, for this problem, is way overkill.
I notice that you didn't write out the whole hardcoded solution. Perhaps writing out an entire recursive solution would be easier?
I agree though. It is a very artificial problem.
TTFN
No Arc?! Paul Graham; paging Paul Graham!
As much as I enjoy reading his essays, I would like to see him write less English and more code.
Or at least a status update now and then.
But I suppose you have different priorities when you're designing something to last rather than something to be useful right now.
TTFN
Again I am reminded of why I prefer DVDs.
DVDs are not without their own problems though. I find the unskippable commercials at the beginning of many DVDs (Shrek 2 for example) to be offensive. Sort of like commercials on cable TV.
TTFN
It's called Lua.
Lua is an interpreted language. A Lua program can never be as fast as a properly-written C program. If you can prove differently, there's a big future for you in Computer Science.
Let me clarify my point. We need a language that is easy on the programmer, but can also be used to write fast code and operating systems.
Compiling to native code is essential for a truly general-purpose language because there are some things which an interpreter cannot do. Full hardware speed and bare metal execution are two of them.
TTFN
If all the C programmers vanish, what are we going to write the next generation of high-level languages in?
That's a very good question. However, just because programming in C is difficult doesn't mean that it's the best language to write high-level languages in. C has many design flaws that people have gotten so used to, they assume there's no other way of doing things.
If you like programming in C because it's a challenge, then by all means do so. However, I would classify that hobby with people who program in Intercal and similar. Those languages are challenging too.
I see a real need for a language that is as easy to program in as Python, yet as potentially fast as C. As far as I know such a language doesn't exist yet, but I see no fundamental obstacles preventing us from creating one. It's just a matter of time.
Do you really want a future where not a single person actually knows what is happening inside that CPU, just because "it's hard?"
Yes, an essential part of a programmer's training is learning exactly what is happening inside the machine. However, a human being cannot keep track of everything at once. That's why we use abstraction. A high-level language (not C) abstracts away the details the computer is smart enough to handle, and leaves the material which the computer is not smart enough to handle.
Programming is fundamentally hard. Making the job harder than it needs to be can be fun, but for day-to-day work, it just doesn't make sense.
TTFN
Because they are twelve years old.
Just FYI, when I was nine I designed a one bit full adder after learning about basic logic gates from my dad.
TTFN
I'd more likely point to our superb visual acuity, and our unparalleled dexterity and communication skills. It was these qualities, coupled to our endurance, that I would argue made our species successful enough to be able to afford to develop large brains.
In discussions like these I never see anyone mention human throwing ability. No other animal can throw as hard or as accurately as humans can. I would not be surprised if a large part of early human hunting consisted of throwing rocks at small animals.
TTFN
That's backwards. Recursive decent with backtracking can parse all LL(k) grammars for arbitrary k. OTOH, yacc/bison can only parse LR(1) which, although sufficient for most realistic grammars, definitely is not as general as a full LL(k) method.
A few reminders:
Recursive descent with backtracking has exponential time complexity.
The set of LL(n) languages is a subset of the LL(n+1) languages.
The set of LR(n) languages is identical to the set of LR(n+1) languages which is identical to the set of deterministic context-free languages.
Left-recursive grammars are a red herring -- you can always eliminate the recursion, and with backtracking you can deal with arbitrary lookahead requirements.
Yes, but you have to alter the grammar and deal with nonlinear time complexity. Which is the reason LR(1) parsing is so common.
TTFN
Thus spake Larry Wall in Apocalypse 5:
And from Apocalypse 1:
In other words, it is backwards compatible, it isn't backwards compatible, and when you install Perl 6, you are installing both.
TTFN
I tried learning Python as my first language because Eric Raymond recommended it to newbies, and it didn't work out so well for me.
I'm sorry to hear that. It's true that some of the Python books out there are deficient. This book is good for teaching programming, but it's only been available for a couple years.
TTFN
yeah but everyone should at least understand the concept of "type" a strong typed language should be used
Python is a strongly typed language. More strongly typed than C in fact. People often think that Python is weakly typed because variables do not have a particular type associated with them. However, in Python it is the values that have types. Python variables are just names that make it convenient to manipulate those values.
Python is strongly dynamically typed, like Lisp and Smalltalk. Other combinations of strong vs weak and static vs dynamic are shown here.
TTFN
Go is about constant evaluation, pattern recognition, and balance and computers can't touch it.
That's how people play Go. That's also how people play Chess. That's not how computers play either one.
A computer that can analyze Go can analyze life. There are too many factors interacting simultaneously to brute-force so you must actually move forward with AI.
People used to think that making chess-playing computers would help us understand intelligence. Turns out it just helped us understand Chess (and a few other things).
The only real difference between Chess and Go as far as computers are concerned is that Go is many orders of magnitude more complex. It's only a matter of time before computer power and search techniques reach a level that can challenge humans at playing Go. Whether that leads to a computer that can analyze life remains to be seen.
TTFN
see, for example, the modifications to SHA-1(?) that defeated differential cryptanalysis but were utterly inexplicable at the time they proposed them
It may not be the instance you're thinking of, but I know that the NSA was involved in the design of DES. It's resistant against differential cryptanalysis (which was not discovered publically until 15 years after DES was published). DES is not resistant against linear cryptanalysis however, which may indicate that the NSA was not aware of the technique at that time.
TTFN
The trouble with teaching C first is that there are many things about C which are not good for newbies. For example, how long would it take for you to explain the following C program to a person who knew nothing about programming?Now, how long would it take to explain the following Python program to the same person?Granted, the C example could be made simpler, but only at the expense of leaving out things which really belong there in a real program. The Python example is complete as is.
There are some domains where C is still the correct choice, but teaching programming is not one of them. C does not reward as many bad habits as BASIC, but it does make the programmer worry about things that beginning programmers shouldn't have to think about. There are many other reasons Python is a better language for teaching programming, but I'll leave it at that for now. I recommend you look into it. Most people who do are glad they did.
The biggest reason being to teach them structure. BASIC breeds spaghetti coders.
Amen to that.
TTFN
Sorry to be pedantic, but why did you lowercase "basic", but capitalize "PERL, PYTHON, LOGO"? It's supposed to be the other way around.
That aside, I agree with you. Especially about Python (it's my favorite).
TTFN
Are you saying that the universe will honor the rule only if no one is sending the signal?
Well, what I meant to say is that the inflation process does not cause information to go from one part of the universe to another faster than light can, so it does not violate causality.
TTFN
Pardon me but if the universe expanded in such a manner wouldn't that be against the theory of relativity. What about breaking causality?
Well IANAP, but I'll explain what I understand of it.
Relativity requires that no signal can travel faster than the speed of light. During inflation, nearby parts of the universe move away from each other faster than the speed of light. However, because there is no signal traveling FTL, causality is not violated.
TTFN
Yes. During inflation the universe expanded not at several times the speed of light, but rather doubled its size every 10^-34 of a second. After about a hundred doublings the inflationary period ended and expansion slowed to (locally) sub-light speeds.
The microwave background didn't come from the big bang though. It was actually emitted from the surface of last scattering when the universe became transparent for the first time--around 300k years after the big bang.
The "center of the universe" is not well-defined. If the universe is topologically closed, then it has neither center nor boundary, like the surface of the earth. If the universe is topologically open, then it is infinite in size and similarly has neither center nor boundary.
TTFN
Still, this whole getting into "space" thing is kinda silly, apart from a 3 minute free-fall and a good view. It's an adrenaline kick, but it's so far from what is needed for orbital, it's not even funny.
The X-15 was very far from orbital as well. However, do you think that Mercury, Gemini, and Apollo would have been possible without the technology and data from X-15? Perhaps, but it would have been like trying to run before you know how to stand. Learning things a few at a time is better.
TTFN
...you can just get the solutions by using Google to search for the answers.
But, could you use Google to search for the answers before anyone else solved the problems?
In other words, only the first few applicants using this process are worth anything.
TTFN
Pnumatic drills / hammers also do this?
Probably not. The sound of an impact is very localized in time, so it is spread out in the frequency domain. A musical sound is spread out in time, so it can be very localized in frequency.
TTFN
Where does helium come from?
I believe that most helium found on earth is a product of nuclear decay. Helium is very stable, so many decay reactions release helium nuclei (alpha particles). It tends to collect in the same places as natural gas.
TTFN
...the ceramic tiles on the shuttle glow red from the friction of the atmosphere.
Just a small pedanticism: The shuttle tiles are heated by air compression, not friction.
TTFN
Personally I miss the days of 3-5watt analog cell phones.
But weren't those the bag phones where you carried around a big backpack full of battery to use them?
I'll take a handset that fits in my pocket, thanks. Though the option to plug in the phone and boost the signal strength would be nice for driving out in the sticks...
TTFN
I have yet to find a library that works with postgres under windows for python.
psycopg
TTFN