1,171 karma · joined February 20, 2007
http://lists.clug.org.za/pipermail/clug-work/2008-July/00062...
[1] http://codesynthesis.com/~boris/blog/2008/11/10/develop-new-...
This is, of course, quite a bit simplified. In any non-trivial venture there will be a significant number of things that need to be done and that you don't particularly enjoy doing. But if the greater part is fun then it is easier to sometimes buckle down and get through the mundane parts.
I guess it also largely depends on the personality. I, for example, hate having to do something quickly, without fully understanding the area, and moving on. On the other hand, if I have a chance to spend time and get exhaustive knowledge about something then I genuinely enjoy working on it even if on the outset it seemed unattractive (think sales, marketing, writing, etc., vs hacking some interesting piece of software).
If I get paid from US-based company personally (not through company), do I have to pay taxes to US gov on these incomes?
You don't pay taxes to US gov unless any of the following two things are true: (1) you are a US resident (2) your income is produced in the US.
There is a precise definition of being a US resident for tax purposes but it basically boils down to you staying in the US for the majority of the time.
The production of income is a bit more tricky. It basically says that if you use US "infrastructure" to produce your income then you have to pay taxes. The common example of this situation would be rental income from a property in the US. An example when this does not apply would be sitting in front of a computer in another country and writing a web app.
http://lists.clug.org.za/pipermail/clug-work/2008-July/00062...
As for who would pay for this, manually parsing any substantial XML vocabulary using DOM or SAX is a major PITA so there are always people willing to pay for automating this task.
Inlining in the same translation unit is possible though its application is too limited to explain why C is faster than dynamically-typed languages.
"C is really fast, because among other things, the compiler can inline function calls. It's gonna use some heuristics, so it doesn't get too much code bloat, but if it sees a function call, it can inline it: it patches it right in, ok, because it knows the address at link time."
This statement shows that Steve has no idea how the base of every modern OS works: separate compilation, calling conventions, machine code, shared objects (libraries), etc.
Once I compile a .c file which defines a function into object code, there is no practical way for the linker to "patches it right in" -- that would require actually decompiling the function to get rid of the calling convention implementation as well as tie-in all the argument references in the function body to those in the calling code.
I noticed something similar a while ago in one of his posts about Lisp (I think it was about why Lisp is not an acceptable Lisp). There he made pretty strong statements and when people who actually know and have used Lisp in real world pointed to his numerous mistakes in comments, Steve admitted that he actually doesn't know the subject matter very well.
Let's say an angel would invest at the same valuation as the VC, then for $1M they would get 12.5% of the company. That would mean that when acquired for $20M, founders are left with $17.5M. For VCs with 50% stake and $40M acquisition founders are left with $20M. Not sure where Bentley's come from.
4. Try not to touch any old projects. Instead try to "own" a new one where you can do things the right way.
There are, however, a few problems with this approach: your will probably be implementing the whole thing alone and will quickly become unpopular with the others.
In my case I ended up implementing a compiler frontend alone from scratch while everybody else were thinking it was a waste of time and we should have based our work on the old code (which, agreed by everybody, was hell of a mess). When time came to implement the backend, I had to bring one of the "old-timers" on board which caused a lot of tension (he preferred to do things the "old way", for example, to indent the generated C++ code manually instead of using the automatic indenter that I wrote).
One other thing that I tried with mixed results was to "recruit" new hires with some sense of design to work with me on the project before they got exposed to the "dark side".
In the end I left that place not the least because of the "us vs you" attitude which was, on the most part, the result of my own actions. I couldn't stand the attitude most people working there had towards software design (most of them were grad students so they weren't there for the long haul). I am now running my own development tools company and find it a much better way to spend my time.
In the end I suggest that anyone stuck in a situation like this get out of it as soon as possible. The extra effort required to make it work is just a waste of your life.
Seriously, perhaps Apple is trying to discourage people from developing MacOS applications using Java in order not to make the whole experience appear slow. Their OS is already quite inefficient (which, BTW, makes me wonder why on earth anybody would make a Mac their development machine).
No wonder there are so many useful applications written on D!
Also note that educating the customer about the value (in monetary terms) that they will receive by using your service is the key to make this strategy work.
It's all in the details. Let's say we have the same success rate for single founder and multiple founders ventures. There are many more multiple founders startups for at least two reasons: (1) it takes some guts to go alone and (2) VC/angels won't fund solo undertakings. Since the multiple founders pool is bigger, there are more successfull startups of this kind. Here you've got your misleading statistics.