> The Shinkansen is expensive; with the rise of low-cost carriers, any train trip that takes more than two hours from Tokyo is less cost-effective than flying.
Nonsense. Narita airport is about an hour away from central Tokyo (by one of two express trains, probably longer by car), and Haneda about 30-40 minutes (by monorail, probably longer by car). Then you get to deal with being in an airport. Both run more smoothly than the ones in the US, but still require early arrival for boarding. Flights are _far_ more likely to have delays. Then you get to deal with another airport again after landing, especially if you checked luggage.
Contrast with the shinkansen: trains leave every 10-15 minutes from the center of the city, have better seats (and green or first-class costs a fraction of a first-class plane ticket), and no dealing with airport security or lines at all.
It would take a 4-5 hour trip minimum for me to fly rather than take a train in Japan.
Ah yes, the tragedy of studying computing to the exclusion of everything else. Graduates with computer science degrees have an in-depth understanding of... text editors. And maybe compilers, databases, and operating systems — all items of zero value until they are applied to solving some real problems in some other field. Problems which the computer science graduate knows nothing about.
Then these graduates go into the working world, and they typically can't help solve problems in economics, physics, applied mathematics, or medicine except by coding up some system to someone else's specs. The more dedicated ones make an effort to understand what they're doing. They exceedingly rare, gifted, and motivated ones might learn enough about an industry to make real contributions.
I hope that our field eventually evolves to the point that programming skill becomes an accessory. People will then learn to program just like they learn to write, and use the craft to help them solve their actual problems. The profession of programmers who only know how to program should disappear like the profession of scribes who only know how to write.
In the past, when I worked on a C++98 project, I would have disagreed with you for one simple reason: template debugging sucks. gdb did not provide good template information (but may have improved in the last few years, I have not checked it recently). g++ had horrific template error messages.
Today, I'm looking at C++11 and using Clang, and I like what I see. Vastly improved compiler error messages, lambdas, very decent type inference, standardized smart pointers, good standard library (and Boost is always an option). I haven't tried heavy-duty debugging yet, but I suspect it still sucks. Overall — I'll probably be using C++ quite a bit more in the future. It is no longer the nasty pile of kludges on top of C which it used to be ten years ago.
To Clojure-curious people: please ignore this article. It is misinformed.
Others on this thread have pointed out that the Alioth benchmark takes startup time into account. Yes, this imposes a startup penalty on Clojure.
More importantly, the implementations of each individual benchmark vary significantly in performance quality. High-performance Clojure requires a couple of tricks in type hinting, using unchecked arithmetic, and preferring native Java arrays.
Notice that Java 7 and gcc run at about the same speed, and Clojure is only about 2.2x slower (than C). Scala is about 1.9x slower (than C). gcc is about 1.5x slower than Intel Fortran.
To make the benchmark more fair: (1) all timings should disregard startup time; and (2) all JVM languages should have the opportunity to run the benchmark a few thousand times before timing it. Otherwise, it measures JVM startup time, and then it measures how long it takes the JIT to achieve maximum optimization. By comparison, the C and Fortran code runs at full speed almost out of the gate.
All-in-all, considering that Clojure is an extremely high-level language I consider its performance impressive [1]. Yes, the inner loops need to be coded in a slightly un-idiomatic manner, but you can do all this in the comfort of your REPL, which makes the process of making optimizations reasonably painless.
[1] Don't forget to scroll down the mandelbrot results and look at the stellar performance of other popular high-level languages.
Setting up Linux teaches system administration skills. Useful, but nothing to do with programming. Learning Emacs is fantastic (I'm a huge fan), but again — nothing to do with programming. For that matter, writing a blog engine should not be someone's first exposure to programming. Frameworks and web development should be simply banned for people who haven't yet written a Fibonacci sequence generator. Please don't waste your time learning how to integrate other people's services and APIs. You aren't ready for this yet.
Don't think about tools, think about concepts. Learn about how programs flow. Learn about data structures, the basics of algorithms, and recursion. Understand how and why programs are structured the way they are. This stuff isn't hard, and won't take more than a few weeks to learn. Then you should look around at tools and at the kinds of problems you want to solve. In the meanwhile, you'll only slow yourself down if you try to run (e.g., figure out why web frameworks work the way they work) before you can walk (e.g., understand functions).
Speaking as a New Yorker contemplating a move to California, I'd say the article is somewhat accurate about the prestige of working in finance, but staggeringly wrong on a few other points.
First of all, cafes are plentiful. All he could come up with is the Tea Lounge in Park Slope? There are dozens of small, non-corporate coffee shops in the Village, dozens more in Williamsburg. And that's just the two neighborhoods where I usually spend time.
Second, New Yorkers don't cook? I think the author spent too much time with the wrong crowd. Plenty of people shop at green markets, including the huge one at Union Square precisely because they like local produce and like to use it.
Programming as a profession is only moderately interesting. It can be a good job, but if you want to make about the same money and be happier you could actually just go run a fast food joint. You are much better off using code as your secret weapon in another profession.
I just finished reading the LISP 1.5 Programmer's Manual (still readily available from Amazon), published in 1962. The book is mind-blowing, because it mixes discussions of high-order functions with instructions on how to properly lay out programs on punch cards.
The "high level language" which shipped on every microcomputer platform of the 1970s and 1980s was Basic. I have often wondered why. Compared to Lisp, it is inelegant and inexpressive. Perhaps people who hacked larger computers of the era did not interact with microcomputer hobbyists. Perhaps it was too difficult to get Lisp fast enough to be usable on the old hardware, although if it was possible on big iron in the late 1950s, it should have also been possible on microprocessors in the 1970s.
An entire generation of programmers grew up using GOTO <line number> to call subroutines and execute loops. That same generation could have grown up using lambdas. How sad.
Thanks for posting this. Fossil has many good ideas. Since I rather like learning about source control systems, I took this one for a spin.
It's definitely pretty fast, although I didn't stress-test it. It noticed that I have GPG set up, and prompted me to sign all my commits by default. Very nice. It has no Git-style index, but commits straight to the repository like Mercurial. I did not find anything like "git add --patch" or darcs partial commits, so saving work seem to be all-or-nothing. Like any good modern VCS, Fossil seems to do real branching and merging, although I did not stress-test that, either.
One major downside: if Fossil has file move detection, I didn't find it. So you have to either spend some time informing it that you moved or renamed things (luckily, you can do this after the fact), or you need to use Fossil-aware tools.
The best food for founders is probably rice and beans.
I disagree with this suggestion. One, the human body does not readily digest beans. Two, rice is a pretty heavily refined food, and white rice especially has been stripped of most of its nutritional value (http://en.wikipedia.org/wiki/White_rice).
From the perspective of spending minimal time, I suggest the unintuitive solution of learning to use slow cooking techniques. Most slow-cooked food is fire-and-forget: quickly prepare the ingredients, start the heat source, and get back to your hacking. Three hours later, you have several dinners' worth of excellent food.
Example: A simple beef stew takes about twenty minutes to prepare. Chop up about 1.5 lbs of beef into small pieces, dice one onion, mix with 1.5 lbs of unpeeled (but properly washed and scrubbed) fingerling potatoes cut in halves. Mix with salt and some water in an enameled cast iron 5-quart Dutch oven. Put in a 375-F oven. Return in three hours. You now have about three days worth of dinners. Improvise with spices as you see fit.
Kent Pitman, a member of the X3J13 Common Lisp standards committee, wrote a terrific paper (http://www.nhplace.com/kent/Papers/Condition-Handling-2001.h...) on the subject of various condition handling systems, which includes examples of various error-handling systems.
Exceptions in mainstream languages have a fatal flaw: they unconditionally unwind the stack when thrown. This sacrifices flexibility and makes it unnecessarily difficult to save state or take action at the point of the throw. Of all languages I've ever seen, only Common Lisp really does this right by separating out the concept of signaling a condition and of handling it.
Nice. I guess the author never experienced the joy of having this lovely conversation with his users:
Programmer: That feature you asked for two weeks ago? It's done. Take a look. What do you think?
User: Oh... hmmm... yeah, that's kinda wrong... See, I know I said I wanted X, but I just realized I actually wanted Y. But Y is very similar to X, can't you just tweak it and I'll come back to take a look after lunch?
Programmer: Well, actually, yeah, Y is a lot like X, but I tried to just "start shipping great software," so I didn't take the extra day which will make X->Y only take an hour or two. I'll have to start from scratch. See you in another two weeks.
User (two weeks later): Actually, Y isn't quite right. Can you do Z?
I'll go so far as to claim that code which can't adapt to changing requirements is either (1) pure genius because it just works and does exactly what users want, and therefore rare, or (2) unused, or (3) thrown away. Obviously it shouldn't be overdone, but the ability to balance between flexibility and delivering working applications is precisely what defines people who, as the author puts it, "ship great software."
Nonsense. Narita airport is about an hour away from central Tokyo (by one of two express trains, probably longer by car), and Haneda about 30-40 minutes (by monorail, probably longer by car). Then you get to deal with being in an airport. Both run more smoothly than the ones in the US, but still require early arrival for boarding. Flights are _far_ more likely to have delays. Then you get to deal with another airport again after landing, especially if you checked luggage.
Contrast with the shinkansen: trains leave every 10-15 minutes from the center of the city, have better seats (and green or first-class costs a fraction of a first-class plane ticket), and no dealing with airport security or lines at all.
It would take a 4-5 hour trip minimum for me to fly rather than take a train in Japan.