Main Lessons
Priorities of a startup
In order of importance:
- Use the right tool/tech for the task. Even if you are not familiar with.
- Speed
- Quick Prototyping
- Quick Iteration in bringing features to market
- Initial growth rate should be higher than average (10% a year) to survive.
- Let out as little information about your success as possible to stay competitive.
Analyzing Competitors
- Look at their job postings to understand what they are doing.
Programming Languages
Individual Articles in Descending Order of Publication
Java’s Cover
Link: http://www.paulgraham.com/javacover.html
Summary of points Points made against Java (or ideally any other language)
- Source/Motivation
- It is artificially hyped by a body (company or government).
- It has ulterior motives other than providing best tool.
- DoD likes it.
- It is born out of an attempt to secure market share.
- Language Development:
- Has too many cooks (not developed by small number of enthusiasts)
- Target audience:
- It is aimed Low (written for mediocre programmers).
- It is written for other people to use (than the developers of the language).
- Designed for large organizations which has large number of mediocre programmers.
- Even users of it doesn’t like it. People are forced to use it.
- Wrong people like it (non-programmers exp: managers).
- Usage:
- It is bureaucratic. Too many protocols for doing things.
Another essay Being Popular, Graham makes the point that a good language only needs hackers to love it and only hacker can distinguish a good language from bad one. Who is a hacker, and how can we learn if they are in agreement on the fact that a specific language is good/bad is not clear though.
Beating the Averages
Link: http://www.paulgraham.com/avg.html Verdict: Dive In
It should be kept in mind that this article is about an attempt that was successful (Development of Viaweb in Lisp) written from the view of the winner. Although many points can be relevant to success, they may not have playes as key roles. See also: Survivorship Bias
The Secret Weapon praises Lisp’s role in the success of their first company. He then refers to analogies made between Latin - Lisp (although no one uses it, if you know it, it will make you a better speaker/writer - programmer). Then goes on to explaining that, this analogy doesn’t completely hold because computers do use Lisp and it is enough.
I believe one aspect this statement is missing, which is that software is not only written for the computer. (If we were only concerned about the ability to do things in a language and it being understood by computer, Assembly would be the best language since there is no other language as flexible as it is.) May be at a time when functional software could be written in couple hundred lines of code, scalability (let alone other quality metrics such as readibility) wasn’t the biggest problem. But in 2023, the size of a software can go up to millions of lines of code and there may be hundreds if not thousands of people working on the same code base. And these numbers will only go up from this day. Most recent paradigm in software development write code for other programmers.
Python for one -now one of the most used language on planet- is designed for understandability/readibility. Language features of C++, such as class private, public, protected members, or pass-by-value argument having const modifier, are not serving to compiler/computer. They are mainly written for the benefit of the next time when the code to be edited, whether by same or a different programmer.
I have to admit that his argument is mainly suggesting that Lisp was the best tool for the task, and that is a very valid and important point. He had/has been advocating that speed should be what startups prioritizing which I agree with.
Today, using a non-common technology unlikely to bring you speed due to following in order of importance:
- Lack of community support
- Time to find someone to hire
- Cost of hiring (someone with a unique skill will cost you higher)
- Being the motivator of the choice makes you essential in the project and reduces flexibility in roles.
Only way to beat those issues are:
- You have to be expert in the technology
- Scalability shouldn’t have to happen in short horizon
- You shouldn’t have any other important plans/changes about your life for next couple of years.
Understandably Graham makes a case for his favorite language (seeing that he had written a book about it) and I respect that and he also states that it was an experiment. But readers of 2023 should be aware of the evolution of software science and new environment that we are in today.
The Blub Paradox
It is amazing how accurate the following statement still is:
If you’re writing a program that only has to do something very simple, like number crunching or bit manipulation, you may as well use a less abstract language, especially since it may be slightly faster. And if you’re writing a short, throwaway program, you may be better off just using whatever language has the best library functions for the task. But in general, for application software, you want to be using the most powerful (reasonably efficient) language you can get, and using anything else is a mistake, of exactly the same kind, though possibly in a lesser degree, as programming in machine language.
Power Hierarchy of Languages
Programmers get very attached to their favorite languages, and I don’t want to hurt anyone’s feelings, so to explain this point I’m going to use a hypothetical language called Blub. Blub falls right in the middle of the abstractness continuum. It is not the most powerful language, but it is more powerful than Cobol or machine language.
And in fact, our hypothetical Blub programmer wouldn’t use either of them. Of course he wouldn’t program in machine language. That’s what compilers are for. And as for Cobol, he doesn’t know how anyone can get anything done with it. It doesn’t even have x (Blub feature of your choice).
As long as our hypothetical Blub programmer is looking down the power continuum, he knows he’s looking down. Languages less powerful than Blub are obviously less powerful, because they’re missing some feature he’s used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn’t realize he’s looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.
By induction, the only programmers in a position to see all the differences in power between the various languages are those who understand the most powerful one.
Although I agree that a person who is not familiar with another language is not in the position to evaluate it (especially claim that it is inferior to the one they know), I don’t believe there is a hierarchy. To me,languages are more like sets (of features). There may be some sets encapsulating other sets (such as C++ mostly encapsulating C), but in most cases difference between two sets in either direction will have significant amount of items in them, making it hard to embed them in a two dimensional space (such as hierarchies).
Graham himself makes it a bit more clear in the end notes:
Note to nerds: or possibly a lattice, narrowing toward the top; it’s not the shape that matters here but the idea that there is at least a partial order. I guess the question now is that: how clear is suggested order.
Aikido for Startups
Ordinarily technology changes fast. But programming languages are different: programming languages are not just technology, but what programmers think in. They’re half technology and half religion.
Following is a great advice that I have been doing and seems to be a popular strategy
If you ever do find yourself working for a startup, here’s a handy tip for evaluating competitors. Read their job listings. Everything else on their site may be stock photos or the prose equivalent, but the job listings have to be specific about what they want, or they’ll get the wrong candidates.
Programming Bottom-Up
Link: http://www.paulgraham.com/progbot.html Verdict: Skip
I have learned of Lisp in my undergraduate studies. But I didn’t know the concept of extendable language or as they say here at this stackoverflow question programmable programming language. According to explanations in the answers, what Graham was referring to was the use of Macros, which get executed in compile time to transform your program.