I wrote the same program in Clojure somewhat recently. Boggle seems to be a popular problem. https://github.com/dmansen/boggle
Nice. Implementing the same problem in Clojure has been on my todo list. Now I've seen yours though so I guess I'll have to think up another problem :)
A Boggling Return to C
81–88 of 88 posts
Re: A Boggling Return to C
#82Earlier quoted context omitted.
The one thing that I have trouble with in Python projects is that it can be very difficult to figure out where the actual object is from that is being imported. from somedir.somefile import objectX Then when you go to somedir.somefile you find out objectX is nowhere to be found only to figure out later that it is dynamically created and added to that namespace and it can be imported in the file you've been reading be…
I have come to the exact same conclusion about Ruby. Finding the source of given behavior is where I tend to get the most annoyed. This is doubly so for any library which uses method_missing? or other bits of Ruby-dynamism. Yes, it can (and does) lead to terser, elegant code. But it also makes it challenging to analyze root causes, and I have become less enamored of this style as I have had to deal with it over the p…
> method(:gem).source_location
=> ["/Users/wycats/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/site_ruby/1.9.1/rubygems.rb", 1228]Re: A Boggling Return to C
#83The author implements an inneficient algorithm using python and then a better one using C. He seems to feel python is for dirty brute force and C is for "real" programming...
Yes and no. I wrote the Python version in probably under an hour. My girlfriend had gotten into playing some stupid Facebook version of Boggle and I just wanted to see her face when I came out of nowhere with implausibly high scores. I didn't think hard about the problem, just reached for the tool I know best and implemented the first obvious approach that came to mind. It worked as needed and I moved on. You make it…
Re: A Boggling Return to C
#84Earlier quoted context omitted.
Not being a experienced C programmer by any measure, but this doesn't look right to me: https://github.com/thraxil/boggle/blob/master/boggle.c#L92 struct foo f() { struct foo f; return f; } isn't returning a stack-allocated struct a bad idea?
It returns a copy of it. Example: #include struct foo { char space[1024]; }; struct foo f() { struct foo f; printf("address of f is %p\n",&f); return f; } int main() { struct foo g; g = f(); printf("address of g is %p\n",&g); return 0; } produces this output: address of f is 0x7fbfffec30 address of g is 0x7fbffff050
Re: A Boggling Return to C
#85"By way of comparison, the Python program takes 1.5 seconds to run, so that's about a 10X speedup." Only tenfold? Interesting. While Python is surely not the slowest interpreted language around, a result like that borders on the performance of Java. That seems unlikely, especially given the fact that Python version uses worse algorithm. I would think about how big is the portion of time eaten by I/O - that is, actual…
> a result like that borders on the performance of Java I haven't seen the "Java is slow" chestnut in years.
The point is, if you assign nearly mystical properties to writing in C, but when you rewrite a brute force approach Python program with a much fancier algorithm in C and you "only" get 10x speedup then something is amiss.
Re: A Boggling Return to C
#86Earlier quoted context omitted.
> The code relies heavily on preprocessor macros and some weird gcc-only syntax that made my head hurt. The preprocessor is generally recognized as one of C's biggest flaws, is not for nothing that Ken Thompson, the first C programmer and the greatest influence on the language other than DMR himself, cut down most of the preprocessor when he wrote his own set of C compilers for Plan 9: http://doc.cat-v.org/plan_9/4th…
It keeps all the simplicity of C, without actually being able to write a kernel or device driver!
You cannot easily write device drivers for existing operating systems in Go because the existing operating systems provide a particular environment unsuited for Go and expect certain constraints from the device drivers themselves, constraints which Go breaks. In principle, it could be made to work.
Re: A Boggling Return to C
#87Earlier quoted context omitted.
> a result like that borders on the performance of Java I haven't seen the "Java is slow" chestnut in years.
I think he's saying Java is fast (compared with Python at least). The point is, if you assign nearly mystical properties to writing in C, but when you rewrite a brute force approach Python program with a much fancier algorithm in C and you "only" get 10x speedup then something is amiss.
Re: A Boggling Return to C
#88I'm a student who learns C#, Java, Php, javascript... at school. I bought "C: A Refence Manual" to learn this summer... Hope it will make me a better programmer.
If you want to learn C, K&R is the right way to do it. C: A Reference Manual is excellent and is probably the only other C book you need, but only if you are already a C programmer, and only for what the title implies: reference.