741 karma · joined October 30, 2009
I get lonely though! I miss the technical and social conversations we used to have in the kitchen or round the coffee machine.
What would be ideal is if I were to rent an office inside the company I'm working for. I would actually be quite happy to pay my client to rent a bit of their space if it's ever a possibility. After all rental costs are chickenfeed compared to developer compensation.
So is there any way to do this automatically whenever websites do this sort of thing?
As far as I can tell after trying it out on various friends it seems to be a mathematician / programmer detector.
If people would like to leave comments about their backgrounds that would really help! (What was your last year of formal schooling, do you have an IQ test result, formal exam results, etc)
Full procedure if anyone's interested is:
sudo apt-get install sbcl sbcl-asdf
$ rlwrap sbcl This is SBCL 1.0.29.11.debian, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. * (require 'asdf)
NIL * (require 'asdf-install)
; loading system definition from ; /usr/lib/sbcl/sb-bsd-sockets/sb-bsd-sockets.asd into #<PACKAGE "ASDF0"> ; registering #<SYSTEM SB-BSD-SOCKETS {AD248A1}> as SB-BSD-SOCKETS ; registering #<SYSTEM SB-BSD-SOCKETS-TESTS {AE975D9}> as SB-BSD-SOCKETS-TESTS ("SB-BSD-SOCKETS" "ASDF-INSTALL") * (asdf-install:install :cells) Install where? 1) System-wide install: System in /usr/lib/sbcl/site-systems/ Files in /usr/lib/sbcl/site/ 2) Personal installation: System in /home/john/.sbcl/systems/ Files in /home/john/.sbcl/site/ --> 2
debugger invoked on a SIMPLE-ERROR in thread #<THREAD "initial thread" RUNNING {AA5E589}>: The assertion (STRING-EQUAL ASDF-INSTALL::URL "http:// :END1 7) failed.
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
And no-one is claiming that you can't do closures in C, but I am claiming that C-only programmers don't usually think in those terms, because the language makes them more complicated than they need to be.
In the same way, if you want to learn OO, learn Java rather than C++, where the same concepts seem very much more complex. And that's probably true even if you want to program in C++ eventually!
Probably better to use python than either, because that's got the least accidental complexity of anything and can express a wide range of ideas, as far as I can tell.
My favourite language at the moment is clojure, but actually some of its nice features like pervasive immutability would make things hard for a beginner. Better to learn how to do everything and then decide which powers you want to not use.
So I guess my ideal beginner's computer today would be a modern ZX Spectrum running a version of python with a lisp syntax (for macros). pg's original vision for arc sounds like a good spec.
And of course an essential requirement would be a printed user manual as friendly and straightforward as the ZX BASIC manual or the TRS80 one.
I would have thought they would be more useful for the sorts of things that programmers are bad at, like dealing with, or in, lies and half-truths. And not be so good for the 'long chains of precise reasoning' type problems.
Of course, you might equally say that being able to handle the political side of life 'makes you a better programmer', but I don't think you'd mean it in the same way.
Ideally you'd want both.
Clojure doesn't compile to Java, it compiles to JVM bytecode, and I think (although I don't know) that that's supposed to be very fast.
In this post:
http://www.learningclojure.com/2010/09/clojure-faster-than-m...
I compiled a (lookup into a map (potentially constructed at run time)) into a series of nested if statements, which then ran very fast indeed.
I shouldn't think I've achieved anything like the holy grail here, it all goes wrong at the end anyway, and I think that clojure 1.3 might actually have broken the optimization techniques I used.
But I think there's a case for saying that an immutable lisp on the JVM might one day be the fastest language in the world, because you can do those sorts of tricks in lisp in a way that you can't feasibly do in assembler, and the JVM does optimization dependent on run-time behaviour, as well as on static analysis.
I don't have the data. I'm not asserting this.
But I am asserting that Java speed is not a strict upper bound on JVM language speed, (unless every JVM bytecode program is also a Java program, which I can't imagine is the case!).
Anyway, pretty fractal tree program in lisp!