Maximum PC

It's kind of a chicken and egg thing...

No, no it isn't. Shift + 9 and Shift + 0. Looks like two to me

I am sure it does. I just don't know how our experience can be compared, since it is obviously very different (and likely why we are such a differing opinion!)

Part of me feels stupid and weak, but I had decided long ago that I wanted to make money. Which meant I likely wouldn't do anything super interesting. I KNOW my skills have dulled since college, and they weren't razor sharp to begin with. I could figure things out and understand them, it just took a lot longer than it did for most of my peers. I went to school with some pretty fucking smart people.

It was interesting, because one of our professors pointed it out to us. He said that was why we often argued over things. Because we were all smart people, and we knew it. It was some what intimidating at times to be on the lower end (ok, really more about the dead middle of the pack) of that group (thankfully not the bottom!).

I think most programmers feel this way until we surround ourselves with smart and interesting people. The two days I spent in Berlin with a bunch of Ruby guys (met up for a Ruby conference), I ended up hanging out (and drinking a lot of beer) with some of the smartest people in the world. I met Matz (creator of Ruby), met the creator of MagLev (distributed Ruby) and a bunch of other folks who come from very diverse computing backgrounds. It's both intimidating and awesome when you speak of something and it gets validated by the smartest in that field.
Funny enough, they thought my experience as a C# guy seeing Ruby for the first time was interesting. I talked about how Ruby's meta-programming was clearly a magnitudes over C#'s (define_method and method_missing are really powerful), and it was great to hear smart people validating your train of thought.

This is why I'm going open source; the projects are there and the movement in F/OSS is fast. They innovate fast, they're always looking for the next big thing. I found that sticking with the MSFT tech stack has left me bored and I know my skills has dulled as well.

Is it necessary? It would probably be more constructive for both of us to argue objectively about the merits of different IDEs, languages, computing paradigms, etc. And others would certainly benefit more from those conversations as well. =)

Regarding your background, trust me, everyone feels this way at some point in their education/careers. After all, you can't be the smartest person in the room at everything. I scored closed to the 100th percentile on the math section of the GRE, and believe me when I tell you that I have felt extremely anxious during weekly meetings with professors. The real trick is to benefit as much as possible from all the hard-work other smart people have put into developing different aspects of the field whether it be research or business app related.


Oh, I don't know about that one. Pursuing 'interesting' projects or work doesn't mean forgoing money. Hell, most interesting tech companies were started by people during their PhD and/or subsequent research (Google, Yahoo, Akamai, iRobot, RSA, etc). I suspect that you're just more comfortable working in a large company environment than a small company or research lab. Also, it can take quite a bit of time and effort to find a problem(s) that make you want to spend time away from the family, regular hobbies or the security of a salaried job. In many respects, it is much more difficult than finding a first job.

BTW, this is turning into an interesting tangent.

In general, I wouldn't say that F/OSS is faster. If anything, it tends to be a slower and broader front than most proprietary corporate projects (stealing a line from Eric Raymond here). It is a great way for companies or researchers to appeal to a larger developer audience (Google APIs and the Plan9 OS come to mind) and offset maintenance costs (bug hunters, porting code, maintaining code that is no longer economical to maintain, etc). You rarely see a companies 'secret sauce' being released into the wild. Given the breadth of F/OSS, we could be thinking of different things though.

We may as well be.

I meant stuff like nginx, jQuery, Rails, node.js...all are F/OSS projects that are backed by a large community base. Rails moves fast: this year at RailsConf, DHH (the creator of Rails) already announced 3.1 when it feels like 3.0 was just released. Five years ago, if you had told me that we would be able to write a web server that uses javascript, I would have laughed at your face and took back that beer I just bought you. Now, node.js makes it possible. I guess it depends on the project, but F/OSS now has movements that are going faster than the commercial ones.

I really can't say that there would be much that could do this to be honest.

Interesting article: http://shootout.alioth.debian.org/u64q/ruby.php

Stirring the pot a bit there, huh? =)

For shigs and gittles, I went ahead and put the information on what I believe is all languages on all machines into a spreadsheet to do a little more analysis (I don't like their box plots... data is from here). I then added some extra dimensions to the data and started playing around a bit.

The categories that I added were "performance fade", which is just the ratio of the worst time divided by the best time for a given language (if I had been awake this morning I would have (hopefully) done variance or std dev... oh well). I also added categories for language type ([functional, procedural, concurrent, etc]) and object file type ([native, either, virtual, interpreted]). Since I haven't looked at the actual code for any language, I've basically guessed the likely paradigm for some of the multi-paradigm languages and object file types (eg functional for lisp). I later decided to remove some of the languages which I'm not familiar (ie ATS, Go, Scala, OCaml). This is obviously a bit of a wonky guessing game, but at least I'm not blindly guessing in the dark with languages like ATS.

Here is the raw data so far...


Some initial observations:

1. How on earth does Intel's Fortran compiler produce a 1 in the best case, a 3 at the median, and a worst-case of 22? Given the quality of this compiler and the high-performance nature of this language, I find that rather perplexing. I'm going to look into this at some point -- Something smells here.

2. I would have expected a higher variation for C# than F# (due to functional programming vs procedural) but the data says otherwise.

3. I also wouldn't have expected the variance in C++ to be lower than C. Based on other similar benchmarks of this type, I would have never expected Java to have a low variance. This is one of the things that Lisp programmers killed Java programmers with here.

4. What the hell is going on with Erlang? I expected it to perform in the C / C++ neighborhood. Maybe it is just the type of benchmarks being tested.

I'll post some numbers on the paradigm and object file types after I can verify some things about the benchmarks. Also, this probably should be the start of a new thread. I'll let the rest of you decide.

Nothing at all. Erlang's not designed for speed. However, it is designed for stability, scalability and robustness. Erlang was never really designed to perform like you would in C/C++ apps but goodness, what it lacks in speed it more than makes up for in stability.

This thread is fine. I mean, it is about comparing languages yes?

Btw, me, stir the pot? NEVER! I would NEVER! How dare you accuse me

I just finished reading the Wikipedia article on Erlang and must say that I'm a bit surprised with the language. Erlang was originally implemented in Prolog. Not only does Erlang retain a strong syntatic similarity to Prolog, but it is clearly meant to be a type of logic language (I'm not sure to what degree though). What you lose in performance, you probably more than make up for in usability and robustness as you stated. Interesting language.

This is a good read about Erlang's robustness.

http://www.erlang-factory.com/upload/pr ... ooters.pdf

In essence, Erlang was written to support an online multiplayer environment. They have around 100+ Dell RC610's running in a clustered setting and with Erlang, they can support up to 10 million users? This is why XMPP (the open source messaging protocol) is written in Erlang, so is CouchDB and the backend of Github.

You're right about robustness; but honestly is speed so important that you trade it in for robustness? In my line of work, I'll take robust over fast. Also, Erlang throws in a LOT of neat stuff like distribution that you would have to think about when writing a similar type of system in C. Erlang had it figured out, so why reinvent the wheel?

I think you hit the nail on the head with 'in my line of work'. Priorities really depends on the project, and I think many projects are not using languages that best meet the projects requirements. I'd love to see more positions that involve languages besides Java, C# and C++.

I have friends who worked in algorithmic trading and they require speed, so they wrote majority of their software in C/C++. I honestly never really understood the logic behind it, Erlang can do the job better since the distributive nature and multi-processor/core requirements come for free. I guess they required speed and kept their data sets simple to improve robustness.

Since I work in healthcare, I would love to see more projects built on robust frameworks. We're not really building software in healthcare to meet project requirements, I find that we often just build software on tools that MSFT tells us that we need to build our stuff off of.

Depends. If they're focusing on high-frequency trading, which often involves quickly responding to news events, relative changes in price or incorrect pricing between different financial instruments (ie arbitrage), they need to minimize latency which doesn't seem like a good match for Erlang. If they're attempting to do something more complicated in terms of computation like finding patterns, they might be hooking their code into existing mathematical software like Matlab which has good support for C/C++ integration. I suspect they're doing the former, but in either case, Erlang probably isn't the best fit. Also, unless they're a giant hedge fund, they're probably only trading during 'business hours'. They don't need extremely high reliability or hot-swappable code.

Now if they were going to open their own exchange.... Erlang sounds like a really good match!


LOL... I actually haven't seen or heard of that happening before. Were you working with MS consultants or what?

Actually, now that I think about it...yeah, they relied on getting prices quickly. They traded mostly commodities and they were looking for low latency to trade as quickly as possible since they were trading sometimes in the pennies (or even fractions of pennies). You're right though, Erlang wouldn't be a good fit.



Yes and no. We work with MSFT consultants when there's a product we need but we don't know what it is. I work in the administrative side of the hospital, so I never touch the clinical side. Healthcare has an interesting curse to it; the software written in healthcare is generally written by a bunch of obtuse morons who never bothered learning anything above VBA. I kid you not, I know of cancer registry software that uses an Access Database in the backend. I was miffed, then I realized to complicate things more, they actually went one step further and used Access to write to a SQL Server database. They have no plans to upgrade the software to .NET and 64-bit, Windows XP is the best they'll do.

When I said that we build stuff according to what MSFT tells us, well, in reality we build stuff according to the tools they give us. MSFT doesn't support Erlang or Ruby or Python, let alone finding ways to make it talk to Microsoft apps. So whenever I need to build something, I'm stuck with the tools MSFT has in their toolbox. We're a pretty MSFT driven shop and going open source is barely an option.

http://blog.rubybestpractices.com/posts ... dogma.html

This guy has some good points, some which I failed to be able to articulate:

He has good points but I still digress.



I fail to see how. Tools like RSpec, Steak (I met the creators of Steak.fm, actually, nice guys), and Cucumber is to make testing more logical and read like a requirements document. While there is a certain of level of testing that is unacceptable - like testing database connectivity or the creation of cookies - tests should focus on the important parts of the logic. The problem with the argument we're having is that tests is left to the developer. We can all agree on testing, it's the methodology and even the granularity of our tests that we can't seem to agree on. But hey, it's the differences in opinion that make this country great.



So does the inverse of it. When I explore new things, I don't really write tests for it. I begin to write tests when I want to understand it. It also depends on what kind of thing I'm working on. If it's a new product or something for fun, I generally skip tests. If it's algorithmic in nature, I write tests. If I'm serious into putting together a real project, then I implement tests. His argument of a local maximum is kind of off, IMO and it contradicts his first statement. The problem is what kind of development are you doing? If your goal is to putz around and try new things, sure, go right ahead and skip tests...but if I'm evaluating a library, you better bet your bottom dollar that I will test it.



Honestly, he may not need to rethink his tests, he may need to rethink his architecture. Judging based on what he's talking about, complex interactions should have been abstracted as messages. The problem I had with this statement is that he retailors his tests when he should have looked at the architecture. When you get into complex object interactions, sometimes, message passing is easier because it decouples objects from one another. Your integration tests are simple: test the message pass and the behavior, rather than testing the interaction itself. Those false negatives stem from the fact that his objects are tightly coupled - and false negatives are awful because they're misleading to the developer. It's almost a trade-off; testing is a kind of development effort, so you might as well architect well.



The one part I definitely agree on! However, writing tests creates a contract. I argued this with another guy from twitter who didn't agree with the open/closed principle. The problem is that objects, invariably, have a contract. Their signatures are their method behaviors, and the contract is that the object will behave as expected. Tests enforce this behavior, so it solidifies the contract between developer and object.

When I read the article, I came away with the impression that he favors the type of testing that DJ Spin and I have been articulating. I agree with the sentiment that automated unit testing isn't a magic bullet, but it sure beats the hell out of the alternative... "Yeah, I've been too lazy to retest this sloppy piece of code. I think it has been three years now."


Yes, and unfortunately, you do see this crap occasionally. They're usually the guys who can't solve an easy top coder problem within an hour, but will gladly take an hour to explain why the 13 design patterns they used to parse a simple test file are necessary. They're obsessed with decoupling everything, design patterning everything, middleware everything, documenting everything. All this guy is really saying is that unit testing isn't idiot proof.

In his latern vs laser analogy all he is really doing is advocating an informal type of prototyping. It is also subjective. Personally, I wish more people spent ANY amount of time using a whiteboard to think about a problem before writing their crappy code (and subsequently discovering the problems in their crappy code), but it doesn't really matter as long as you're willing to refactor the code (and in some cases completely rewrite). What I hate is when people realize that their crappy code is solving a problem inefficiently, say O(n^2) vs O(n), but they're dead set against rewriting the code because they've already spent three hours writing their crap code. Writing a few unit tests after doing some prototyping to flesh out the API is almost certainly helpful.