Is it bad if I don't want to work at a C++/Java startup?
I have an opportunity to work at a company coming in as employee# < 10. They are doing so well that they are already profitable after a year and trying to keep up with the demand. I think I would really like working there, except that they use C++/Java. I want to accomplish as much as possible in my life, and coding memory management in C++ or otherwise being limited to unexpressive languages just seems to prevent that goal.
86 comments
[ 6.0 ms ] story [ 284 ms ] threadI don't suppose you think there are situations where you want to be slower or spend more effort just for the sake of it?
As for the "tradeoff" I mean that high-level languages are particularly useful if one is primarily interested in minimizing development time possibly at the expense of other variables. Examples of "other variables" include processing time, memory usage, ease of hiring cog-like but adequate developers to maintain the system, company politics, etc. Such other factors are used everyday to justify the higher-effort solutions.
Does that make more sense? Sorry for any confusion.
Processing time is a real tradeoff, but you can go a long way if you get good at identifying the bottlenecks and translating the critical code to a faster language. I work in a massively multiplayer online game, which is a very performance sensitive application both client and server side, and most of our code is Python (and I think a good part of our C/C++ code could be ported to Python without significantly hurting performance).
Theoretically, high level languages should eventually perform better, not worse, than low level languages, as compiler technology improves, because the compiler has more information and freedom to perform optimizations. OCaml is a high level language which claims performance on the order of C.
Re: memory usage, I'm not convinced the overhead of higher level languages is a big deal, except for apps in very restricted hardware. Unless you mean cache coherency, which goes back to speed.
Re: easy of hiring, in my company we had some graphics guys picking up Python and contributing useful code in a very short time. We also had C++ programmers picking up Python easily, although I must admit C++ habits and idioms die hard.
That said, ease of hiring cog-like developers and company politics is not what I'd look for in a startup.
I admit I cheated by mentioning Lisp, OCaml, and Python to reply different points. Lisp and OCaml are less mainstream and not as trivial to pick as Python, which in turn is not as powerful or as efficient as these.
So yes, there are tradeoffs, but I wouldn't pick C++ as the pragmatic compromise, not even for big business. IMHO, Python + C (via ctypes) for close to the metal stuff would be it. For personal/startup work, I'd go for Scheme, and be happy to limit my hiring choices to people willing to learn that.
As for the Sapir-Whorf argument the relevant case is not what the Lisp programmer thinks while programming C++ but what the only-C++ programmer thinks while programming C++. Are there thoughts he is not capable of thinking because he has not been exposed to Lisp (or any other non-C++ language)? I do not believe this is the case. How would Lisp have been invented if only Lisp programmers are capable of thinking at that level of abstraction?
With the Lisper-coding-C++ example I was trying to convey that even if you could think such thoughts, it wouldn't help you much for practical purposes unless you can express them in a convenient way. So, even if we discard the Sapir-Whorf argument in the literal sense, for practical purposes you may just as well pretend it's applicable.
That said, I find different languages do shape how you think about programming.
The people that invented Lisp were mathematicians, which of course were used to thinking at a pretty high level of abstraction. It's not strictly impossible to come upon the same ideas on your own, just as it's not strictly impossible to come upon ideas that are not expressible in your natural language, even if you accept Sapir-Whorf. After all, somebody had to invent the words of natural languages too.
But there is a huge leap between learning a concept(+) and inventing it. Natural languages evolved over thousands (millions?) of years; modern mathematics took a couple thousand years to discover. Yet most children learn their native languages effortlessly, and a high school kid learns centuries worth of mathematical advances in a few years.
So yes, you could think of the thoughts that higher level programming languages afford without having ever been exposed to those languages, but that would be an exercise of lucidity comparable to finding a bunch of significant new mathematical theorems, or to inventing new words for concepts that can't be readily expressed in English, without having learned about those concepts in French or Japanese before.
(+) edit: idea->concept
And I think learning different languages in particular is valuable because it helps to intimately introduce one to various useful concepts.
But in general the most valuable of those concepts are both simple and language independent. Typically you can map such concepts used in one domain onto another domain and leverage them there as well.
I don't see the "languages" as being as important or as absolutely dominant over thought as the Sapir-Whorf style arguments imply. Plus I don't believe the arguments in an absolute, philosophical sense. And I've seen the argument made too many times in a way that tends to insult some of our fellow programmers for no good reason.
Anyway, I think we're probably in agreement about a lot of things but perhaps the Internet is getting in the way of our communication. Interesting talk, take care and good luck!
This isn't to say that C++ is necessarily bad, but I wouldn't want to work in it (again) either.
In the context of I want to accomplish as much as possible in my life, all other things being equal the particular language you happen to be using for the next few month-years will probably prove insignificant.
If you're going to settle on programming language choice so you can learn all the other stuff, you have to be willing to cut said successful startup loose and strike out on your own once you've learned all the other stuff. This will look increasingly irrational the better you do at your job.
If they are using them for efficiency reasons, then this may be a case prematurely optimization, and they may not like the tools either, but feel trapped into using them.
On the other hand they may be using them because they are most comfortable and experienced using them. This is a pretty good reason to use a language, but eventually leads to stagnation.
Whether you admire them or not is another issue entirely.
There could be a lot of reasons why very large software companies are using the same languages.
It's questionable that there is much overlap between the "hows and whys" of the practices of these companies (that count their employees by the thousands and their bottom line by the billions), with the "hows and whys" of what you need for a startup.
Any opportunity to learn is valuable; whether learning the MS/Google way is a good choice depends on your alternatives.
A better test, for someone starting a startup now, would be to look at what's used by the companies started in the last year that seem most likely to one day have billion dollar market caps.
Ultimately, the question of what to code in is not nearly as crucial to success as we're making it out to be. And answering that question "correctly" has a lot to do with who's coding, how the code's used now, how you think it'll be used later, and many other questions.
I think it's at least worthwhile to know why other people use boring languages. Then feel free to use cool ones instead, not because you're impressed with how well Basecamp runs, but because you know you don't need Google-sized scalability right out of the box.
Instead, how about looking at what companies with billion dollar market caps are buying. After all, that's the biggest statement of "We think this is really promising, but we can't build it internally, so we're going to fork over a billion dollars for it" that a big company can make.
Judging from this, the big languages seem to be Python (YouTube, Reddit) and Java (FeedBurner, Zenter). There are also a lot of recent acquirees where I haven't seen anything about their technologies - it's certainly conceivable that many of those are C++. Really, if I had to draw conclusions, it'd be "The language you use doesn't really matter - the important thing is that you build something people want."
Not really true, unless you mean "have web-facing apps written in C++ and Java" in the same sense that they "have web-facing apps written in PHP and Python". I posted a list on Reddit, based on publicly available information (employee blog posts, mailing lists):
http://programming.reddit.com/info/2614t/comments/c264lk
There's some Java and C++, but there's also a lot of Python and PHP.
That said, sure, folks use other languages, too. Yahoo and Facebook are particularly good examples of companies that have more than the typical share of a non-Java/non-C++ language for their apps. And even they use C++ (and maybe Java) elsewhere.
The flip side of that is that perhaps Java and C++ are huge because it takes more engineers and lines of code to accomplish the same task, and hence the potential financial payoff and organizational importance needs to be higher to justify their use. ;-)
Correlation is not causation. These software companies just happen to use C++ and Java. It's not because they use C++ and Java that they have market caps north of a billion dollars. They're making a product or selling a service that people want and if they used a different language, they would still be making a lot of money.
Personally, I write code in C. Does this mean I write fewer lines of code? Possibly. Does it mean that I write fewer GOOD lines of code? Definitely not. Working in C forces me to think about what I'm doing in a way that I wouldn't do if I were using a more flexible language like perl; and as I've written about before, I firmly believe that thinking before coding is a key ingredient in producing good code.
Returning to the original question: I would never work for a startup which was using C++ or Java, simply because those languages are too flexible. If you don't know what function pointers are, you shouldn't be using them -- and that applies doubly if you don't even realize that you're using them.
I'm happy to say that I no longer hack C++. I loved C++ until I realized that you have little hope of using C++'s features correctly unless you sink 5 years into becoming a C++ expert. Digital Mars D looks pretty damn good, but I haven't looked into it very deeply.
Whereas C doesn't give you all the wizzbang C++ features, but it has the important property that wrong code looks wrong; the language is simple, and there's often "one logical way" to implement a given algorithm. That translates into simpler code (albeit often less expressive), and fewer bugs.
If you're such a believer in thinking before coding, why do you need your language to force you to?
But this wasn't his question. If he has what it takes to get really good at C++, he will probably get really good at Ruby or Python in that time.
I happen to work in a place where we use Python and C++, and I claim that for any problem domain for which higher level (lightweight?) languages are suitable, they are a clear productivity win over C++, for people of similar experience.
I agree that people are more important than language, but the choice of language also tells you something about the people. I suppose the poster has more relevant information about the people, though.
Remember, that when it comes to programming language choice, you often end up with programmer happiness (low ramp-up time to get something implemented) vs. performance.
It would be good to find out how open the place is to different languages. You may be able to write most of it in the language of your choice and only have to switch to C++/Java where necessary. This should especially be true at a Web-focused company.
Java, one the other hand, works pretty well if you have a lot of experience with it and use the right tools (IntelliJ IDE). I feel like I am more productive with Java+IntelliJ than with Python.
Good luck with your decision.
Only crap companies like ID Software use that. What has Quake got on the awesome expressiveness of Flickr, or Facebook or Google Suggest? I mean, just in terms of sheer output, consider that BOTH Flickr and Facebook are able to...display text on a screen! And put jpegs in neat columns in div tags!
Pshaw. What has C++ got on that?
Seriously. Do away with the tunnel vision. When you're talking consumer software, all of the output of all of the languages of the world combined absolutely pale compared with that of C/C++.
Flickr and Facebook don't display text on a screen. The web browser does that. What Flickr and Facebook do is serve content to huge amounts of people. In order to scale to these extents, your choice of language is not nearly the most relevant decision.
Also, speed of execution is critical for web companies, while one of id's mottos is "it's done when it's done".
Overall, I would do it over again but probably will not remain with them for much longer, if that makes any sense. Some observations:
The language choice will grate on you after a while. I dunno what the background of posters saying "Be professional. Suck it up." is, but I actually liked Java coding when I started, and have since learned to hate it. If you're going in with a strong aversion to Java & C++ already, it'll probably only get worse.
Flip side is that you do get better at these languages after you work with them a while, as long as you keep an open mind. There are tricks and tools in C++ to help you manage memory - you shouldn't be tracing pointers from new to delete. And Java's verbosity isn't as bad once you get used it and consider "for(int i = 0; i < array.length; ++i)...." to be a single map function that just has a really long name. ;-)
One question to ask that'll help you determine if the language will end up becoming a total drag: are they using it because the problem fits the language's strengths, or are they using it because they don't know any better and aren't comfortable with multi-language solutions? Every mainstream language is good for something. In my case, I was perfectly happy as long as I was writing IDE plugins and server software in Java, and then became very unhappy once I had to write a webapp. (IMNSHO, Java is irredeemably broken for webapps; the only sane way to do them is to strip out all the JavaEE bullshit and program on bare servlets, but then you get something that's nowhere near as nice as Python/PHP/Perl.)
There are plenty of things beyond programming that you learn from working in a successful (profitable) startup. OTOH, it's not rocket science. Basically, you can boil it all down to: 1.) Make something people want, 2.) Charge more for it than it costs you, and 3.) Fix problems now rather than later. Every failed startup I've been involved with has neglected at least one of these: every successful startup has done all three.
I dunno what you expect financially out of this, but be aware that founders get rich, late-stage employees get paid, and early-stage employees get screwed. At least in proportion to the amount of effort they put in. One startup I worked in went bust, taking my 0.1% of stock options with it. One that I interviewed at offered me about 0.01% of the company; I did the math, and calculated that at their expected $40M exit, I would get a whole $4000. I have no equity at my current employer. My cubemate was an early employee at CCBN, which was sold to Thomson for about $40M. He got $3K or so. I have another friend who was employee #35 at Stratus and later a VP; she was rich for a while when they ended up with a billion-$ market cap, but ended up poor again after the stock crashed. If you plan on being an early employee at a startup, you should do it for learning or for the experience rather than any perceived financial rewards.
I've heard that the options pool is usually about 20% of the company, the first hire gets about 2.5%, and then it decreases exponentially from there. So the second hire might get 1.5%, the third 1%, the tenth about 0.2%, the 20th 0.01% (perhaps a bit higher; it seemed low to me too, which is why I didn't take the job), and on down. If you gave 2% to each of the first 10 employees, the options pool would be exhausted right there.
Of course, the company is hopefully growing all this time. But if you're employee #20 or even #10 and the company is profitable, they may be heading for a liquidity event soon, in which case there's not much time for growth.
My current situation - no equity at all - is atypical, because it's a bootstrapped startup and the founder really wants to maintain control. IMHO it's probably a mistake - I know I'd work a whole lot harder if I had equity. But I get a decent salary, and it's really the founder's call...
[pg: Anyway, why is it that you can't correct your mistakes/change your mind when voting? I think reddit's way of marking your current vote with colored arrows, which you can click again if you change your mind, is better (you may prefer to use shades of grey, or the YComb orange color for the 'chosen' arrow.)]
Early employees should get the highest bit, and it should drop off sharply after. Depending on the size of the company, you should look for 1-3% if you're under 10, vested over 1-2 years. That's assuming the company is small and plans to exit within a year or two.
A lot of people will probably say 1-3% is a huge amount of equity, even for an employee #10, but I've seen what happens when you don't give good equity to the earliest employees. I'm the type of person who would rather give more equity in order to keep people pretty focused. It probably depends on your opportunity costs, your experience, and how replaceable you are.
I've been in startups where the equity was really low, and the employees will figure out they're being exploited. The rest is history.
The 20% set aside is usually reserved for "key hires" which is assumed to mean a flotilla of VP level people. If you follow the standard Silicon Valley VC-backed startup script, this means the VP of Product, the VP of Product management, the VP of Operations, and so forth. After the A round, engineers are usually looking at an equity maximum of 0.25-0.5%.
"be aware that founders get rich, late-stage employees get paid, and early-stage employees get screwed" is a great maxim. Unless your company is truly on track for a $1B acquisition or IPO, you are not going to be able to buy a house with an early-stage engineer's equity.
Of course, employees #1 and #2 wrote the cool algorithm in Python, hired some other people to do the boring stuff, then let those people argue about Java on message forums while they argue about who gets the "California King" sized bed in the jumbo-jet. ;-)
Why? I'd rather be the Python guy in that scenario :-)
Also, if they're successful enough with their current languages, you will not change them. Taking a job saying "I know they use X, but I'll talk them into using Y instead, and then I'll be happy!" is like entering a relationship saying "I know she does X that drives me nuts, but I know if I pester her enough, she'll stop it, and then I'll be happy!" Doesn't work that way.
That said, I suspect most people that pan C++ have never extensively used or understood the STL or Boost Libraries. Undergrad C++ is nothing more than a basic introduction to the language.
Ask them how they use the languages, and you might find they wrote their own compilers for DSLs or other things you'll enjoy working on.
All that said, the market is ripe right now, and it's a good time to be a prima donna about what you'll work on.
I think much of the negativism stems from the hacker mentality that big companies are evil and that breaking the rules is cool. Therefore anything that big companies do or use is automatically uncool.
Nothing wrong with this mindset, but I think it often goes too far with some. Java and C++ are not bad languages. Yes, most large software companies use them but there are some reasons why they might be a desirable choice. One is that these languages work well in a collaborative work environment. There are many proven debugging tools, established QA practices, very good IDEs with integrated revision synchronization tools, etc. While these may not matter for the hacker or small group of hackers creating something cool, they are very important considerations for a growing software company who has plans to scale.
So with this understanding in mind I wouldn't automatically rule out a company based on the fact they code in C++/Java. Ask them why do and you might discover that there's more there than what meets the eye.
So, what're your languages/tools of choice?
What are you using for learning Scheme? I recommend this one: http://herdrick.blogspot.com/2006/03/what-all-books-ought-to...
After that, take a look at the Scheme Cookbook for specific tasks. http://schemecookbook.org/Cookbook/
Then again, if you don't want to wait for SICP I fully understand you too.
Who knows, you might be able to embed scripting in their product. Maybe automate a test suite with dynamic bindings to their libraries. Or maybe be the voice of reason when someone on the team discovers design patterns or IoC and gets delusions of grandeur.
Also, if your ability to "accomplish as much as possible" in your life is so severely limited by the programming language s(i.e. tool) you use, then you should probably rethink your approach to engineering.
Knowing how much reddit dudes love LISP, Haskell, Ruby and Python, I was very surprised to see that almost exclusively everyone's favorite piece of code was written... you guessed it - in C.
Of course not. This thread has turned it around a bit - phrasing the question as if you wanted to work for a C++/Java startup (or at least if you felt neutral about it).
I'm not surprised that's what's being discussed, because those are the more interesting questions. But if you feel in your gut that you don't want to work in C++ or Java, then for god's sake man, don't do it. You'll be really unhappy, and I'm sure you'll have other opportunities.