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.
24 comments
If you think you'll be unhappy doing the actual work that you'll be doing when you take the job, the job isn't worth it. There's no difference between being employee #9 or being employee #99999 in that regard.
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.
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.
I've noticed there is a negative bias towards the "enterprise" languages by many on this forum. Not calling out gregwebs in particular, just speaking generally.
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.
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.
There is definitely something wrong with the mindset that big companies being evil. However, the bias towards "enterprise" languages does not come from this. It stems from experience in working in big companies that are unproductive. It also comes from personal use of the languages, and reading about, exploring, and programming in different languages.
If you are really good at C++ (gork template metaprogramming, Alexandrescu's Modern C++ design) you will be as or more productive than most average people programming in Ruby or Python. Instead of focusing on the language think about the kind of people you are working with. Today you will find a lot of kool aid drinking kids coding in lightweight languages and quoting from Hackers and Painters at every opportunity. That does not mean they produce high quality software
That's not saying much in favor of C++ is it? If you are really really good at assembly you will be more productive than most average people programming in any language. That's because most average people aren't very productive at all.
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.
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.
It also doesn't mean that they don't produce high quality software.
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.
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.
There are many more factors to accomplishing as much as possible than coding efficiently. Go join them and find out what they're doing right. Later you can do your own project and add the advantage of a superior language to the advantage of knowing what a successful startup looks like.
A caution: if they're doing everything else right except the language choice, then chances are they will end profitable and successful by at least some definition of success, but will not be as successful as they could be. It's very tempting in this situation to sit back and enjoy being an employee at a successful company. That will not get you any of the big payoffs or excitement of a startup.
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 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.
Definitely. If your main goal is joining a startup with a chance of success then you should be evaluating the people involved. Their language choice should be a data point, but ought to be taken strongly in context of their backgrounds and the problem they are trying to solve.
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.
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.
As much as I am a huge Lisp fan, you give some excellent advice.
C++. Pshaw.
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++.
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++.
Nope. Hand optimized assembly pwns C/C++. And still, ID uses almost none of that. Do they have tunnel vision too?
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".
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".
I hear you. Right after grad school, I turned down an offer to work in a small (and very profitable) CAD company with good people mainly because I didn't want to code in C++ (and wanted to work with the web). A year later I chose a smaller web company over Microsoft partially for the same reason.
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.
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.
I think there is nothing more miserable than working with tools that you don't like. Part of the allure of starting a startup was not compromising an inch on the exact tools you want. Follow your bliss, not your stock options.
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.
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.
I think the important question is "why are they using C++/Java?"
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.
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.
From what I gather, it would always be better for their product to run faster, so they probably felt they had to use C++. I believe they are using Java for the front end because they found good libraries for what they wanted to do. It is possible they are being productive with their Java code by using pre-exising libraries, but their C++ is from scratch.
It does also seems that they are comfortable and experienced using both languages. I don't think it crossed their mind to use other fast languages in place of C++ such as D, O'Caml, or Haskell.
Personally I'd take a great team of smart, flexible people over my choice of programming language any day. I think it all comes down to the specifics of your nature, the team, and its environment.
Going to dissent with the other respondents. If you think you'll be unhappy (and therefore probably unproductive) using C++ then don't do it. There are other startups, and of course you could always do your own thing and pick your tools.
This isn't to say that C++ is necessarily bad, but I wouldn't want to work in it (again) either.
This isn't to say that C++ is necessarily bad, but I wouldn't want to work in it (again) either.
I don't think I would be unhappy and uproductive, just not as happy and productive as I could be.
I am in almost the exact same situation, except with 2 years of hindsight. I joined a startup straight out of college as employee #13 (at the time, it had about 8 employees in the office at any given time). It was profitable, I liked the people, and they were doing some pretty cool stuff.
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.
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 think your experience as an early employee may have been unusual. A startup getting a series A round is typically made to set aside about 20% of the stock for new hires. So .01% is a preposterously low offer, unless the company was huge.
I would've been employee #22 at the company. I also worked at another startup - 0.1% for employee #13. That may have been low-balled a bit because I was straight out of high school.
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...
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...
I downmodded you by mistake because of my fat fingers on this iPhone. I guess either I need to zoom in next time or Paul needs bigger buttons. :)
I upmodded to compensate :).
[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.)]
[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.)]
It doesn't sound TOO unusual. Facebook apparently is the next Google, and there is no shortage of news about projects being started by ex-facebook engineers. Why would they leave, unless their equity package was pathetic?
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.
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.
Oh, and... eventually you need to know C++, anyway. How it works these days is: employee #9 makes the site in Rails, or Python, or PHP. She makes $70K a year and 0.25% of the company. Eventually, she burns out and goes backpacking in Thailand for a year. Everything tips over, and you need to hire employees 30 and 31. They get paid $170K a year with no equity, cuz they are the only ones who know how to make it all work fast in C++.
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. ;-)
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. ;-)
> ...eventually you need to know C++...
Why? I'd rather be the Python guy in that scenario :-)
Why? I'd rather be the Python guy in that scenario :-)
So what is the typical % for employee # < 10 ? I know that there will be variance depending on the employee and the employer so I am asking about the average range.
The common setup is like this: 1) 1/3 equity for co-founders, 2) 1/3 equity for investors, 3) 1/3 equity for employees.
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.
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.
In case nobody tells you today, this is a damn good post.
There's a broad line with "C++/Java". You can use C++ as a safer C, and yes, that's generally unpleasant. But if you're leveraging STL, Boost, and some GC like Boehm, among other extensions, it's a great deal better. Same with Java -- if you're leveraging Java 5/6 functionality, using Groovy for scripting, etc., you're going to be stretching your brain with something other than memory management.
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.
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.
If you really want to accomplish as much as possible in your life, you could start by throwing out your prejudices. Computer languages aren't religions, they're tools, get over it.
Throwing out predjudices is always good advice. However, Paul Graham and others have argued (convincingly) that a language is not a tool. A compiler is a tool. A language is the actual medium that a programmer works in. It will effect every aspect of a software project, including the way in which the programmers think.
Sucks to your Sapir-Whorf hypothesis! That said higher-level languages do have real, non-mythical advantages over lower-level ones if one is trying to work quickly and with minimal effort. Good luck with your decision.
What is the tradeoff you imply here?
I don't suppose you think there are situations where you want to be slower or spend more effort just for the sake of it?
I don't suppose you think there are situations where you want to be slower or spend more effort just for the sake of it?
My point is that there are many really good, legitimate and numerically quantifiable reasons for using a high-level language that have nothing to do with the mythical, unprovable Sapir-Whorf justification.
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.
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.
Saying that the programming language conditions how you think is not equivalent to Sapir-Whorf. Think of it this way: an expert Lisp programmer using C++ will be very aware of the shortcuts, simplifications, generalizations, ... that he could be implementing with higher order functions, closures, macros, etc. He can have these thoughts even though he is using C++, so no Sapir-Whorf here. But many of these thoughts will only serve to cause him pain, since the required techniques are impossible or not worth it in the less expressive language.
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.
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.
If you read my replies carefully you will realize that we are likely in agreement on many points and that you are putting words into my mouth.
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?
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?
Sorry if I gave that impression. I realise some of the things I said in my latest reply may come across as trying to refute arguments which you of course didn't make. My intention was to go deeper into what you said about the tradeoffs involved. I admit my arguing for high level languages was a bit out of place in that context; I guess I got carried away by the tone in the rest of the thread. In particular, in my last paragraph I didn't mean to imply that you were proposing C++ as a pragmatic solution, esp. for startups. So please accept my apologies.
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
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
I completely agree about learning rather than reinventing.
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!
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!
Yet another thought! :-) Since company is so small, you can actually get them to migrate from C++ to D! That would have been awesome...
I think you're being petty. If you like the vibe of the startup and you think they have a future then go ahead.
I know I'm chiming in very late here. The original post asked if it is "bad if I don't want to work at a C++/Java startup."
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.
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.
All languages suck, they're all Blub. Get over it. It seems kind of silly to be a language snob if the team and opportunity are right.
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.
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.
Nobody in their right mind has been coding "memory management" in C++ for the last 10 years. This is not early 90s anymore.
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.
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.
It depends, If you don't like doing C++/Java don't go for that. imo don't force yourself to do anything you don't like for that matter. True that C++ is losing its sheen and Java is being called a new age Cobol , but they still dominate the scene, its a matter of personal preference.
Another thought. Just very recently someone posted "Ask Reddit: what is the most beautiful code you've ever seen?"...
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.
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.
Why place so much emphasis on the language rather than the outlook of the startup? If the startup looks promising and you believe in it. It shouldn't matter if you need to work in _____(Write language here), I'd certainly go for it.
Don't be fulled by selective perception. C++ and Java are the backbone of software.
Your instincts are good - I'd guess that you'd slowly come to despise your job
So, what're your languages/tools of choice?
So, what're your languages/tools of choice?
I am still working on the language of choice- I am learning Haskell and Scheme.
Great. I don't know much about Haskell, but Scheme is a great language for startups. Start your own and apply to YC!
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/
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/
I am going through SICP. I planned to look at the Little Schemer afterwards. The cookbook link will be very helpful- thanks.
I followed the same route and I kinda regret it. The Little Schemer is best read with a Lisp-virgin mind. If you intend to read it at all, do it before SICP.
Then again, if you don't want to wait for SICP I fully understand you too.
Then again, if you don't want to wait for SICP I fully understand you too.
This is some hardcore language hate. C++ is the production coding language. Java is the enterprise coding language. You should want to join these guys just to get your head around why all the companies who make a truckloads of money doing software use these languages.
What is "production?" Whatever it is, few web apps I admire do it, if it means writing code in C++.
The fact that very few web applications use C++ doesn't mean that using C++ is a bad idea. Most web applications are absolute garbage, both in terms of the concepts behind them and the actual implementations.
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.
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.
Does it mean your good lines of code achieve less than the good lines of code of someone with comparable experience in a high level language? I bet that's the case.
If you're such a believer in thinking before coding, why do you need your language to force you to?
If you're such a believer in thinking before coding, why do you need your language to force you to?
As an aside, function pointers are the closest C++ has to lambdas. If C++ is too flexible for having them, you shouldn't go near anything LISPy.
Well, technically boost::lambda (http://www.boost.org/doc/html/lambda.html) is the closest C++ has to lambdas. ;-)
boost::lambda still blows. I avoid using C++'s <functional> and friends because of the crap-tastic missing support for lambda expressions. Luckily there are a couple of sane proposals to fix this in the next version of C++ (aka "C++0x"). http://www.research.att.com/~bs/N1968-lambda-expressions.pdf
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.
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.
Yeah, I think that is precisely the problem with C++. The language lets you do some amazing things, but it is just way too complicated. Unless you've spent a long time becoming an expert at the language, it is all too easy to write C++ code that looks correct, but it is actually wrong (either poorly performant, or non-portable, or subtly buggy).
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.
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.
I'd still use C++ over C... virtual functions, inheritance, RAII, and standard containers are too useful. The important thing is to not get caught up in C++ voodoo magic land, and spend 2 weeks trying to get a template with Alexandrescu typelists working correctly when nobody is going to even going to reuse the code, nor wants to learn your fancy interface, nor wants to maintain your fancy code.
I have programmed a little D, and although you will be stuck in the imperative/object-oriented mindframe as with C++, D is quite useable. The overall design is coherent, and anyone with a basic understanding of C++ should be able to pick it up very quickly. It even has some lambdaness.
Those boost kids...They do great work.
I think your statement implies that you don't know what function pointers are. :/
Point taken, but mine still stands. Basically all of the software companies with market cap north of a billion dollars have web-facing apps written in C++ and Java.
Whether you admire them or not is another issue entirely.
Whether you admire them or not is another issue entirely.
"Basically all of the software companies with market cap north of a billion dollars have web-facing apps written in C++ and Java."
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.
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.
You're collapsing stuff down in an interesting way that makes these marginal languages look more important than they probably are. If you were to do it by lines of codes, organizational importance, financial pay off, number of engineers working in a language, or pretty much any metric other than "does ___ use ___ somewhere in their codebase?," I think you'll find that Java and C++ are huge.
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.
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.
"If you were to do it by lines of codes, organizational importance, financial pay off, number of engineers working in a language, or pretty much any metric other than "does ___ use ___ somewhere in their codebase?,"
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. ;-)
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. ;-)
Deep.
It takes a while to get a billion dollar market cap. So if you use that test you're looking at old technology decisions.
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.
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.
It's too hard to judge which apps started this year will most likely have billion dollar market caps - after all, if you'd done that in 1996, you'd think "AltaVista, Excite, Value America" and other similar nonsense.
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."
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."
I don't know if you're entirely correct on the old school/new school comparison. It's not as if Google decided way back in the late 90's that they'd (re-)implement Writely in Java just because it was en vogue. That's a newer technology decision than implementing reddit in python...
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.
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.
I suspect Google decided long ago to create a server infrastructure for programs written in certain languages, which in turn dictated how they rewrote Writely years later.
Choice of programming language may improve performance by a constant factor at best. I can't see how Google-sized scalability depends on that. I'd be happy to grow 1/10 or 1/100 of Google!
That's not necessarily significant unless you want to take it a step further and claim C++ and/or Java have a causal relationship with those market capitalizations.
There could be a lot of reasons why very large software companies are using the same languages.
There could be a lot of reasons why very large software companies are using the same languages.
It's certainly not coincidence that both Microsoft and Google use C++ for their big web apps. I'm suggesting that the opportunity to learn how and why their systems work as they do is a valuable one, even if you'd rather be coding in Python, Ruby, or Arc.
The poster talks about being the <10th employee, so I don't think he's considering going to work for Microsoft or Google.
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.
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.
I couldn't agree more
If you look at what the Java world is doing, you'll see that experts try to keep their Java code as far away from the web layer as possible. That's what velocity, webmacro, cocoon, JSTL, etc. etc. etc. are for. There's probably a tool to keep Java away from the web for every letter of the alphabet.
> Point taken, but mine still stands.
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.
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.
Why would you join a 10-person company to figure out why a billion dollar company behaves a particular way?
You should join the 10-person company to figure out why a 10-person company behaves a particular way. I wouldn't be surprised if a number of aspects aligned between companies big and small with regard to choice of language.