7 ms·

Here are some heretical thoughts. The language is irrelevant. The text editor is irrelevant. The OS is irrelevant. The size of your monitor is irrelevant. All y

Here are some heretical thoughts. The language is irrelevant. The text editor is irrelevant. The OS is irrelevant. The size of your monitor is irrelevant. All your productivity hacks are irrelevant. The only relevant thing is your ability to formulate and solve problems. You might say the language can help with both the formulation and the solution but I'd say that just comes down to what language you're most comfortable with and how good of a problem solver you are. So you can use lisp and I'll use ruby and at the end it'll all be a wash because the fundamental bottleneck will always be the speed at which you can formulate and solve problems and how quickly you can respond to market dynamics. All other choices are accidents of history. Graham and his buddy were just good problem solvers.

raspasov 11y ago
You are absolutely right. However, if you use a cluttered language with a dozen choices for a data structure or concurrency (as far as I know Ruby is not one of them), you'll run into many accidental problems before you even get to solving your business domain problem.
agumonkey 11y ago
It goes hand in hand. Back in the days people said lisp in newbies hands will be backfire, but handled by those with abstraction skills it will give you ability to express things you cannot with other systems. Many here agree that technology should not matter, but it does at one point. Some trait of the culture behind and around languages are very very important. Lisp tree recursion, "lexicality" and ad-hoc genericity is not present in other languages. Immutability in the ml land (even though side effects are permitted in some) is also something few people have to live in and understand. Both these things give you new idioms, hints, point of view about how to solve problems. It also sheds light on the other ones.
- dkarapetyan 11y ago
  I'm not really a programmer. All my training is in abstract math so whenever I see people arguing over language X and Y it always seems weird to me. I don't write code until I've sketched things out with pencil and paper and by necessity I have to disentagle the syntax of the language from the essence of the problem. Turns out when I do things that way translating the solution back into a language X ends up being the easy part and it really doesn't matter what the target language ends up being. Adding macros and types just shifts how I encode the solution and in no way affects its abstract formulation. So I don't think it goes hand in hand. The fundamental bottleneck is always what's in your head.
  - metaobject 11y ago
    But depending on the language you intend to use, you may approach the problem from a different angle. A Lisp solution may look very different from a Python or C solution.
    - sheepmullet 11y ago
      The same is true in maths as well.
  - tangled 11y ago
    This is approach is great for greenfield development, but when it comes to software maintenance I find myself having to think in terms of the target language so that I can formulate the right long-term solution for the codebase in question.
    - dkarapetyan 11y ago
      Yes, this is true. For maintenance projects I've noticed that before I can sketch things out I have to translate the existing codebase into the proper abstract domain but in my experience this is just an extra step and does not negate the general approach of thinking in a domain that is completely free of programming language related issues.
  - gnaritas 11y ago
    > and by necessity I have to disentangle the syntax of the language from the essence of the problem. Doing that is why programmers prefer different languages, some language allow that to be easier than others do. Some language allow a much more direct expression of the essence of the problem. > Adding macros and types just shifts how I encode the solution and in no way affects its abstract formulation. Sure it does, it allows you express the abstract formulation more directly with less syntactic fluff. Ideally you wind up with a DSL that allows the problem to be solved as tersely yet readably as possible.
    - Goladus 11y ago
highwind 11y ago
Irrelevant might be too strong of a word. Yes, it might not be as significant as your own problem solving skills but they are still important. You have to remember that tools chosen by you to solve problems. You wouldn't say what tools you use to build a house is irrelevant only carpenter's skills. Picking the right tool for the right problem is part of problem solving. Sometimes picking the right tool might boil down to what you are most comfortable with, or sometimes it might be learning a tool that you are not familiar with. (Of course, you shouldn't flock to a particular tool just because someone else said so.) Anyways, picking the right tools are important part of your problem solving skills. Graham and his buddy were good problem solvers who picked the right tool for the problem that they were solving.
Scarbutt 11y ago
I wonder if Graham was presented with the same problem today, will he pick a lisp and write everything from scratch or pick up a less "expressive" language because it has a strong and mature ecosystem of libs.
- DonaldFisk 11y ago
  You can have your cake and eat it. It's possible for Lisps to use library code in less expressive languages, such as C, via a variety of mechanisms (foreign function interface, extending the virtual machine, ...). If you want access to Java libraries, you can use Kawa, Clojure, or Armed Bear Common Lisp.
- agumonkey 11y ago
  There's a solid trend to do that, Norvig wrote a lot of recent articles in python, colleges are replacing Java with it too. Lisp genes have spread so it's not as alternative as it used to be. That said, SBCL seems to have possibilities and performance unmatched by all the tiny trendy languages of the day (except for v8 maybe and lua maybe).
- deleted 11y ago
  [deleted]
- byron_fast 11y ago
  The reason Paul Graham used Lisp is it was the only reasonable way at the time to implement RTML, which was the HTML macro language with online editor that Viaweb was built out of. RTML was how every website in Viaweb was constructed, it is what allowed them to move quickly and customers to customize with unequaled flexibility. It was their key competitive advantage and Lisp was critical to its creation and function. It would be foolish to attempt to implement RTML in something else. Perhaps slightly less foolish in 2015 but not by much.
- nnq 11y ago
  At the time when PG was solving a web development problem, web development problems were "new and interesting", so it made sense to use a Lisp. Nowadays it probably doesn't make sense to use Lisps for web, but it would absolutely make sense if you are solving something that is actually a new and interesting problem nowadays...
MichaelGG 11y ago
I doubt this. Looking at some stuff done in C - a ton of time is simply wasted shuffling bytes around and fixing the resulting memory issues. If your point is that language alone isn't gonna decide much, that's probably mostly right. FB used/uses PHP. Harry Potter was written on pen and paper. I don't think either is much of an argument about tools.
sklogic 11y ago
> The only relevant thing is your ability to formulate and solve problems. The maximum level of abstraction available for your language is indeed a hard upper limit on how you formulate and solve problems. Solving a complex problem on a high level of abstraction can be trivial, and the same problem may be nearly impossible on lower levels.
bbcbasic 11y ago
If your startup is dependent on solving chicken and egg marketing problems the choice of Lisp vs. something else is fairly irrelevant as you said. This is the case in most startups that take a traditional business (e.g. Taxi) and modernise it (e.g. uber). The level of tech required to do that is not going to be cutting edge. It is quite rote to solve these things in RoR or PHP. On the other hand there may be some startups where the choice of language really matters. One thing I can think of is how a lot of Enterprise software is a big feature fest with massive complicatedness coming from a mixture of the real-world muckiness of the problem, and poor architectural choices. Such shops require armies of programmers to maintain their bloated wares. Maybe a startup with a much more thoughtful approach, using a Lisp/Haskell/etc. type language and a small number of developers can have a big competitive advantage. Customer "we need a new feature". Startup "sure we'll add a rule and you'll have that tomorrow". Old business "that will take 3 months and cost $1m"
- dkarapetyan 11y ago
  I think you're making the case for language irrelevance even more. The reason big corp. can't move fast isn't because of their technology choices. It is because of all the bloatware and bureaucracy. You can be bureaucratic and bloated in any language.
  - backlava 11y ago
    But in some languages bloat is a best practice.
    - bbcbasic 11y ago
      It's all about how many adjectives you can get into your class name. e.g. SingletonFactoryAdaptorFacadeProviderEnumerator<BridgeAbstractFactory2_Hack> myClass; With Haskell it is about how big your monad stack is StateT ReaderT WriterT LensifierT MaybeT BeerT (IO Int).
      - eru 11y ago
discreteevent 11y ago
" I think Lisp still has an edge for larger projects and for applications where the speed of the compiled code is important. But Python has the edge (with a large number of students) when the main goal is communication, not programming per se. In terms of programming-in-the-large, at Google and elsewhere, I think that language choice is not as important as all the other choices: if you have the right overall architecture, the right team of programmers, the right development process that allows for rapid development with continuous improvement, then many languages will work for you; if you don't have those things you're in trouble regardless of your language choice." - Peter Norvig https://news.ycombinator.com/item?id=1803815 https://news.ycombinator.com/item?id=1803815
discreteevent 11y ago
" I think Lisp still has an edge for larger projects and for applications where the speed of the compiled code is important. But Python has the edge (with a large number of students) when the main goal is communication, not programming per se. In terms of programming-in-the-large, at Google and elsewhere, I think that language choice is not as important as all the other choices: if you have the right overall architecture, the right team of programmers, the right development process that allows for rapid development with continuous improvement, then many languages will work for you; if you don't have those things you're in trouble regardless of your language choice." - Peter Norvig https://news.ycombinator.com/item?id=1803815 https://news.ycombinator.com/item?id=1803815
sheepmullet 11y ago
> but I'd say that just comes down to what language you're most comfortable with and how good of a problem solver you are. Techniques and concepts influence your ability to reason about problems. If you don't understand dictionaries (hashes), or trees, or macros, or reflection, or first class functions etc, then you will think about a problem very differently. If you understand the concepts then you can usually get away with not having those features readily available in your language. For example if your language doesn't have strong macro support you can get away with using code-gen instead. Likewise if your language doesn't have built in dictionary support, you can get away with rolling your own, or finding a library that adds it. Or if your language doesn't support first class functions you can often get away with patterns like the command pattern instead. But if you don't understand the concepts then your ability to think about the problem becomes much more limited.
- davexunit 11y ago
  But why would you want to use a language that didn't have such things? Not having lexical scope, first-class functions, and macros is a huge hinderance to me. Sure, I can work around it, but it's a terribly inefficient and unsatisfying way to work.
- pjmlp 11y ago
  That's why CS matters. Anyone with a good CS background can think abstractly in terms of algorithms and data structures, instead of focusing in language X with feature list Y.
  - Scarblac 11y ago
    But languages differ in how much of that they abstract away from you. If the language already does a lot of those algorithms and data structures with minimal syntax, the CS guy can think on an even higher level of abstraction.
    - pjmlp 11y ago
      There is not much more level abstraction than lambda calculus, logic, denotational semantics and similar though processes. But I get your point of not having to deal with low level details.
sjatkins 11y ago
Heretical or not you are dead wrong. Don't think so? Go program in Forth or Assembler instead of your current main language for a while and get back to me. There would have been no reason to invent any HLL or even assembler if you were correct. Put aside your ruby and try to do the same work in vanilla C and get back to me.
- Adlai 11y ago
  Forth is as high-level as you'd like it to be. http://www.colorforth.com/POL.htm http://www.colorforth.com/POL.htm
  - e12e 11y ago
    Indeed, a strange one to pick. I'd even say that if portability isn't a concern, working with x86_64 assembly is quite pleasant. If you avoid the lure of premature optimization, and stick with either function oriented, or at least procedure oriented programming, without too many long jumps -- I think you could get on quite fine in assembly. The biggest issue, might be one that (sadly too) many low-level languages share: with the move to UTF-8 as the only sane choice for text, there are no string/char datatypes any more. No reason one can't use procedures/functions to deal with strings in assembly, but it would require a bit more planning than in a language that have "native" UTF-8 support. [ed: I think Kollibri OS proves both points: it's a working OS, but they've yet to port from 32bit to 64bit even though they upstream they forked from (Menuet OS) has a 64 bit version (that's not Free software/open source). http://kolibrios.org/en/ http://kolibrios.org/en/ Another "big" asm OS project is: https://github.com/ReturnInfinity/Pure64 https://github.com/ReturnInfinity/Pure64 ]
- wpietri 11y ago
  I think you're taking his point too literally. Yes, you can find a pathological interpretation of his words and beat that up. But his point is that most of the arguments people have here over language choice are irrelevant, because whether you're using PHP or Python or Ruby or Scala or Go is not the bottleneck in the system. Personally, I agree. I've never seen a bad team succeed because of a good language, and I've never seen a good team fail because of a bad one. We argue over languages not because it makes or breaks companies, but because that's the most obvious feature of our days. We form tribes around languages the way non-programmers do around sports teams, and as with sports teams, minor differences get blown up into major social divisions. It's our own version of the streetlight effect: https://en.wikipedia.org/wiki/Streetlight_effect https://en.wikipedia.org/wiki/Streetlight_effect I'm all for people arguing about language features when they are actually designing languages. But as far as building businesses around software, I think "Language X is a secret weapon" is absurd. If a good team picks something they're happy working in, then the biggest problem with a project will almost never be the language they picked.

raspasov 11y ago

You are absolutely right. However, if you use a cluttered language with a dozen choices for a data structure or concurrency (as far as I know Ruby is not one of them), you'll run into many accidental problems before you even get to solving your business domain problem.

agumonkey 11y ago

It goes hand in hand. Back in the days people said lisp in newbies hands will be backfire, but handled by those with abstraction skills it will give you ability to express things you cannot with other systems. Many here agree that technology should not matter, but it does at one point. Some trait of the culture behind and around languages are very very important. Lisp tree recursion, "lexicality" and ad-hoc genericity is not present in other languages. Immutability in the ml land (even though side effects are permitted in some) is also something few people have to live in and understand. Both these things give you new idioms, hints, point of view about how to solve problems. It also sheds light on the other ones.

dkarapetyan 11y ago
I'm not really a programmer. All my training is in abstract math so whenever I see people arguing over language X and Y it always seems weird to me. I don't write code until I've sketched things out with pencil and paper and by necessity I have to disentagle the syntax of the language from the essence of the problem. Turns out when I do things that way translating the solution back into a language X ends up being the easy part and it really doesn't matter what the target language ends up being. Adding macros and types just shifts how I encode the solution and in no way affects its abstract formulation. So I don't think it goes hand in hand. The fundamental bottleneck is always what's in your head.
- metaobject 11y ago
  But depending on the language you intend to use, you may approach the problem from a different angle. A Lisp solution may look very different from a Python or C solution.
  - sheepmullet 11y ago
    The same is true in maths as well.
- tangled 11y ago
  This is approach is great for greenfield development, but when it comes to software maintenance I find myself having to think in terms of the target language so that I can formulate the right long-term solution for the codebase in question.
  - dkarapetyan 11y ago
    Yes, this is true. For maintenance projects I've noticed that before I can sketch things out I have to translate the existing codebase into the proper abstract domain but in my experience this is just an extra step and does not negate the general approach of thinking in a domain that is completely free of programming language related issues.
- gnaritas 11y ago
  > and by necessity I have to disentangle the syntax of the language from the essence of the problem. Doing that is why programmers prefer different languages, some language allow that to be easier than others do. Some language allow a much more direct expression of the essence of the problem. > Adding macros and types just shifts how I encode the solution and in no way affects its abstract formulation. Sure it does, it allows you express the abstract formulation more directly with less syntactic fluff. Ideally you wind up with a DSL that allows the problem to be solved as tersely yet readably as possible.
  - Goladus 11y ago

highwind 11y ago

Irrelevant might be too strong of a word. Yes, it might not be as significant as your own problem solving skills but they are still important. You have to remember that tools chosen by you to solve problems. You wouldn't say what tools you use to build a house is irrelevant only carpenter's skills. Picking the right tool for the right problem is part of problem solving. Sometimes picking the right tool might boil down to what you are most comfortable with, or sometimes it might be learning a tool that you are not familiar with. (Of course, you shouldn't flock to a particular tool just because someone else said so.) Anyways, picking the right tools are important part of your problem solving skills. Graham and his buddy were good problem solvers who picked the right tool for the problem that they were solving.

Scarbutt 11y ago

I wonder if Graham was presented with the same problem today, will he pick a lisp and write everything from scratch or pick up a less "expressive" language because it has a strong and mature ecosystem of libs.

DonaldFisk 11y ago
You can have your cake and eat it. It's possible for Lisps to use library code in less expressive languages, such as C, via a variety of mechanisms (foreign function interface, extending the virtual machine, ...). If you want access to Java libraries, you can use Kawa, Clojure, or Armed Bear Common Lisp.
agumonkey 11y ago
There's a solid trend to do that, Norvig wrote a lot of recent articles in python, colleges are replacing Java with it too. Lisp genes have spread so it's not as alternative as it used to be. That said, SBCL seems to have possibilities and performance unmatched by all the tiny trendy languages of the day (except for v8 maybe and lua maybe).
deleted 11y ago
[deleted]
byron_fast 11y ago
The reason Paul Graham used Lisp is it was the only reasonable way at the time to implement RTML, which was the HTML macro language with online editor that Viaweb was built out of. RTML was how every website in Viaweb was constructed, it is what allowed them to move quickly and customers to customize with unequaled flexibility. It was their key competitive advantage and Lisp was critical to its creation and function. It would be foolish to attempt to implement RTML in something else. Perhaps slightly less foolish in 2015 but not by much.
nnq 11y ago
At the time when PG was solving a web development problem, web development problems were "new and interesting", so it made sense to use a Lisp. Nowadays it probably doesn't make sense to use Lisps for web, but it would absolutely make sense if you are solving something that is actually a new and interesting problem nowadays...

MichaelGG 11y ago

I doubt this. Looking at some stuff done in C - a ton of time is simply wasted shuffling bytes around and fixing the resulting memory issues. If your point is that language alone isn't gonna decide much, that's probably mostly right. FB used/uses PHP. Harry Potter was written on pen and paper. I don't think either is much of an argument about tools.

sklogic 11y ago

> The only relevant thing is your ability to formulate and solve problems. The maximum level of abstraction available for your language is indeed a hard upper limit on how you formulate and solve problems. Solving a complex problem on a high level of abstraction can be trivial, and the same problem may be nearly impossible on lower levels.

bbcbasic 11y ago

If your startup is dependent on solving chicken and egg marketing problems the choice of Lisp vs. something else is fairly irrelevant as you said. This is the case in most startups that take a traditional business (e.g. Taxi) and modernise it (e.g. uber). The level of tech required to do that is not going to be cutting edge. It is quite rote to solve these things in RoR or PHP. On the other hand there may be some startups where the choice of language really matters. One thing I can think of is how a lot of Enterprise software is a big feature fest with massive complicatedness coming from a mixture of the real-world muckiness of the problem, and poor architectural choices. Such shops require armies of programmers to maintain their bloated wares. Maybe a startup with a much more thoughtful approach, using a Lisp/Haskell/etc. type language and a small number of developers can have a big competitive advantage. Customer "we need a new feature". Startup "sure we'll add a rule and you'll have that tomorrow". Old business "that will take 3 months and cost $1m"

dkarapetyan 11y ago
I think you're making the case for language irrelevance even more. The reason big corp. can't move fast isn't because of their technology choices. It is because of all the bloatware and bureaucracy. You can be bureaucratic and bloated in any language.
- backlava 11y ago
  But in some languages bloat is a best practice.
  - bbcbasic 11y ago
    It's all about how many adjectives you can get into your class name. e.g. SingletonFactoryAdaptorFacadeProviderEnumerator<BridgeAbstractFactory2_Hack> myClass; With Haskell it is about how big your monad stack is StateT ReaderT WriterT LensifierT MaybeT BeerT (IO Int).
    - eru 11y ago

discreteevent 11y ago

" I think Lisp still has an edge for larger projects and for applications where the speed of the compiled code is important. But Python has the edge (with a large number of students) when the main goal is communication, not programming per se. In terms of programming-in-the-large, at Google and elsewhere, I think that language choice is not as important as all the other choices: if you have the right overall architecture, the right team of programmers, the right development process that allows for rapid development with continuous improvement, then many languages will work for you; if you don't have those things you're in trouble regardless of your language choice." - Peter Norvig https://news.ycombinator.com/item?id=1803815 https://news.ycombinator.com/item?id=1803815

discreteevent 11y ago

sheepmullet 11y ago

> but I'd say that just comes down to what language you're most comfortable with and how good of a problem solver you are. Techniques and concepts influence your ability to reason about problems. If you don't understand dictionaries (hashes), or trees, or macros, or reflection, or first class functions etc, then you will think about a problem very differently. If you understand the concepts then you can usually get away with not having those features readily available in your language. For example if your language doesn't have strong macro support you can get away with using code-gen instead. Likewise if your language doesn't have built in dictionary support, you can get away with rolling your own, or finding a library that adds it. Or if your language doesn't support first class functions you can often get away with patterns like the command pattern instead. But if you don't understand the concepts then your ability to think about the problem becomes much more limited.

davexunit 11y ago
But why would you want to use a language that didn't have such things? Not having lexical scope, first-class functions, and macros is a huge hinderance to me. Sure, I can work around it, but it's a terribly inefficient and unsatisfying way to work.
pjmlp 11y ago
That's why CS matters. Anyone with a good CS background can think abstractly in terms of algorithms and data structures, instead of focusing in language X with feature list Y.
- Scarblac 11y ago
  But languages differ in how much of that they abstract away from you. If the language already does a lot of those algorithms and data structures with minimal syntax, the CS guy can think on an even higher level of abstraction.
  - pjmlp 11y ago
    There is not much more level abstraction than lambda calculus, logic, denotational semantics and similar though processes. But I get your point of not having to deal with low level details.

sjatkins 11y ago

Heretical or not you are dead wrong. Don't think so? Go program in Forth or Assembler instead of your current main language for a while and get back to me. There would have been no reason to invent any HLL or even assembler if you were correct. Put aside your ruby and try to do the same work in vanilla C and get back to me.

Adlai 11y ago
Forth is as high-level as you'd like it to be. http://www.colorforth.com/POL.htm http://www.colorforth.com/POL.htm
- e12e 11y ago
  Indeed, a strange one to pick. I'd even say that if portability isn't a concern, working with x86_64 assembly is quite pleasant. If you avoid the lure of premature optimization, and stick with either function oriented, or at least procedure oriented programming, without too many long jumps -- I think you could get on quite fine in assembly. The biggest issue, might be one that (sadly too) many low-level languages share: with the move to UTF-8 as the only sane choice for text, there are no string/char datatypes any more. No reason one can't use procedures/functions to deal with strings in assembly, but it would require a bit more planning than in a language that have "native" UTF-8 support. [ed: I think Kollibri OS proves both points: it's a working OS, but they've yet to port from 32bit to 64bit even though they upstream they forked from (Menuet OS) has a 64 bit version (that's not Free software/open source). http://kolibrios.org/en/ http://kolibrios.org/en/ Another "big" asm OS project is: https://github.com/ReturnInfinity/Pure64 https://github.com/ReturnInfinity/Pure64 ]
wpietri 11y ago
I think you're taking his point too literally. Yes, you can find a pathological interpretation of his words and beat that up. But his point is that most of the arguments people have here over language choice are irrelevant, because whether you're using PHP or Python or Ruby or Scala or Go is not the bottleneck in the system. Personally, I agree. I've never seen a bad team succeed because of a good language, and I've never seen a good team fail because of a bad one. We argue over languages not because it makes or breaks companies, but because that's the most obvious feature of our days. We form tribes around languages the way non-programmers do around sports teams, and as with sports teams, minor differences get blown up into major social divisions. It's our own version of the streetlight effect: https://en.wikipedia.org/wiki/Streetlight_effect https://en.wikipedia.org/wiki/Streetlight_effect I'm all for people arguing about language features when they are actually designing languages. But as far as building businesses around software, I think "Language X is a secret weapon" is absurd. If a good team picks something they're happy working in, then the biggest problem with a project will almost never be the language they picked.