7 ms·

Yeah, I certainly understand various language trade-offs, but in my experience any of these early wins of interpreted languages come back to haunt you at signif

Yeah, I certainly understand various language trade-offs, but in my experience any of these early wins of interpreted languages come back to haunt you at significant cost. If you understood the wins of untyped languages, you'd be aware that this is often the most optimal path for a startup to take. Get features done now + fix them later is, in hundreds of cases, the way that startups win. It's also a win for people who come home from work and want to get features done on their side projects rather than write perfect code. It's beginning to get tiresome to continually hear the Rust community go on and on about how amazing Rust is and say, with a straight face, that eventually there will be no reason to write anything in not-Rust. Are you serious? The hubris is off the charts. If your language doesn't have a REPL, your language is less productive. Deal with it. That said, the engineering tradeoffs are often a win. I love Rust; borrow checking is frankly incredible. But it's important to keep perspective.

zzalpha 9y ago
If your language doesn't have a REPL, your language is less productive. Deal with it. Oh hardly. As someone who's developed software in Perl, Python, C, Java, C#, Haskell, and a few others besides, a REPL is the one thing I use the least. I've honestly never understood the obsession with it. Is a rapid compile-run-debug cycle important? Absolutely. If I want to test something in isolation, being able to rapidly turn out a UT to prove my code does what I think it does is incredibly important. But a REPL is a nice-to-have. Nothing more. Treating its absence as some fundamental black mark on a language is completely absurd.
- sillysaurus3 9y ago
  I tend to agree, but being able to have a REPL at all is a symptom that your language is capable of an extremely fast compile-run-debug cycle. In other words, if you can't implement a REPL, that's the definition of "less productive language." It's not about the REPL itself but the capability of implementing one. Think about it like this: On your list of languages, which of them would you say is most productive? It depends on the context, certainly: libraries, familiarity, etc. But let's assume the languages had identical ecosystems, and that you were competent in all of them. Which of them would take the smallest amount of time to write your feature? That'd probably be Python, Haskell, or even Perl. It seems very difficult to argue that Rust would top them. And the reasons why this is might be true are worth examining. Here's another aspect. Is the Rust community claiming that the entire history of computing has lead up to this point, where Rust exists, and now nobody needs to write anything in not-Rust? Are people 200 years from now going to write Rust and nothing else? How about 20? 2? It becomes very difficult to argue that your programming language is the lingua franca of the future. (And that's probably true for every language, not just Rust.)
  - zzalpha 9y ago
    Think about it like this: On your list of languages, which of them would you say is most productive? Define productive. Are you measuring raw lines of code generated? Or are we measuring amount of production-ready code? My bet: with an experienced, diligent developer it's a wash. My gut says what you lose in a slow code-execute cycle of static, compiled languages you gain in lower defect rates from compile-time checks. Conversely, what you gain in a dynamic language, you lose in errors caught at run-time. At that point I'd select for languages that are simpler with fewer surprising semantics (crossing Perl and Javascript off the list), with more built-in run-time and/or compiler safety (knocking things like C off the list). I generally also prefer compile-time safety over run-time safety, as I'd rather find problems on my workstation than in the field because I missed testing a codepath.
    - kbenson 9y ago
      > with fewer surprising semantics (crossing Perl and Javascript off the list) Actually, I think Perl has fairly few surprising semantics after you learn the major ones. The real problem is that the major one (or specifically the major one, context) is somewhat hidden in normal C-like usage until it jumps out at you and confuses you. Once you understand what it is, it's not all that surprising (but there are a few annoyances with it that still persist and cause problems). You can write Perl that looks almost exactly like C 95% of the time, but that 5% where it matters makes people that do this very confused. There are, of course, other parts of the language that are poorly chosen, but I maintain there are actually far less of them than many people seem to think. As for JavaScript, I still can't get over all the different ways to check for equality and null or undefined. I understand a good portion of that is because I never have to use JS enough to become truly proficient, and some if it is just poor design.
  - tatterdemalion 9y ago
    > Is the Rust community claiming that the entire history of computing has lead up to this point, where Rust exists, and now nobody needs to write anything in not-Rust? Are people 200 years from now going to write Rust and nothing else? Let's be clear - the person who said there'd be no reason to write in anything else is an enthusiastic Rust user, but they don't work on Rust & don't represent "the Rust community." They were speaking from their own experience, based on their own balancing of the trade offs as a user. Presumably a REPL doesn't rate very highly for them. However, the reasons we don't have a REPL are mainly two: the compiler isn't architected for it and code doesn't compile fast. The solutions are: * Re-architect the compiler to support incremental code input. This is pretty similar to what we need to support IDEs (which we're working on), so possibly this will solve the problem. * Get a reimplementation of the backend which is a JIT interpreter instead of LLVM, which takes up most of our compiletime. Work is underway on a project called miri, though it isn't officially supported right now. * Make the typechecking part of the compiler faster. This is underway through a project called chalk. In other words, a REPL is not impossible, it just isn't a top priority right now. There are other lacking tools that we're working on - IDE integration and auto-formatting for example - maybe after those are done it will be the top of the docket.
- dwaltrip 9y ago
  Just because you don't understand the benefits other people get from a REPL doesn't mean they don't exist.
  - zzalpha 9y ago
    Just because there are benefits, doesn't make it a deal-breaker.
    - dwaltrip 9y ago
      I didn't say it was a deal breaker? Your post came off as implying REPLs don't have serious benefits for anyone, which felt a bit presumptuous to me.
      - zzalpha 9y ago
        Yup, that's fair. BTW, I actually stand by your interpretation. I challenge anyone to demonstrate significant productivity gains (as measured by number of lines of tested, production code written) that can be attributed to the availability of a REPL (which was the claim of the poster I was replying to). I honestly don't buy it. I believe it's a very nice tool for learning a new language, and maybe for exploring an existing codebase, but I can't envision a workflow where a REPL provides significant productivity gains for an experienced, professional software developer that aren't realized in other ways (e.g. writing unit tests).
        goatlover 9y ago
        Lispers might be able to meet that challenge.
        nickpsecurity 9y ago
        I could probably have countered it, too, in the same language during the challenge back when I used it. I found the incremental, per-function compilation feature reduced compilation time of most changes to a fraction of a second. Most of time in programming is spent thinking, tweaking, debugging, dealing with 3rd-party libs, etc. I don't think a difference in the source-to-execution part of under 1 second is going to make a big deal. It's high-speed iteration of code one is exploring that makes both REPL's and incremental compilation superior for productivity to full compilation.
- zambal 9y ago
  The usefulness of a REPL depends a lot on the language/interpreter/vm. In Erlang and Elixir the REPL is more than nice to have. Being able to connect to a production node and peeking around what is happening can be very valuable. I guess it's one of those things that's imho hard to appreciate if you never experienced it.
  - zzalpha 9y ago
    The usefulness of a REPL depends a lot on the language/interpreter/vm. In Erlang and Elixir the REPL is more than nice to have. Being able to connect to a production node and peeking around what is happening can be very valuable. That's called a remote debugger, and it's hardly unique to languages supporting a REPL.
- zambal 9y ago
  The usefulness of a REPL depends a lot on the language/interpreter/vm. In Erlang and Elixir the REPL is imo more than a nice to have. Being able to connect to a production node and peeking around what is happening can be very valuable. I guess it's one of those things that's imho hard to appreciate if you never experienced it.
- derefr 9y ago
  > I've honestly never understood the obsession with it. The true key to understanding REPLs is their role in consuming third-party libraries. While languages both with and without REPLs will have well-used packages in their package ecosystems that are well-documented; languages with REPLs will also manage to have well-used, poorly-documented packages: packages whose "documentation" consists only of the de-facto ability to reflect on the API in a REPL, doing the moral equivalent of exploring a filesystem using cd(1) and cat(1), until you figure out what functions—and what arguments—combine to produce an acceptable result for your use-case. That may sound like a bad thing, but it's not! Those packages are packages that wouldn't exist otherwise; they're marginal packages, packages which people wouldn't have had time to write if they were required to also document them properly enough to make use of them without a REPL. They're needs being satisfied, that would otherwise—given the stricter requirement of useful API documentation—be going un-met. If you look at e.g. Ruby's gem ecosystem, there are tons of packages that have more than a million downloads, and either no docs or awful docs. How? Because Ruby is extremely amenable to exploring APIs through a REPL. You take a module or class, ask it what its children are, what its class methods are, what its instance methods are. Find a class with instance methods that sound right, attempt to instantiate it. Figure out you can't do that, look around the class methods for something that sounds like a factory method. What arguments does said factory-function take? Well, feed it some at random and see what error you get. Etc.
  - oblio 9y ago
    Many languages have good IDE support, which is basically REPL on steroids.
    - derefr 9y ago
      True, though "good IDE support" in the sense you're talking about (i.e. being able to discover an API through the IDE) mostly relies on strong typing in the language. (Non-inferred) type declarations are their own form of documentation, with a similar effect on likelihood of a "marginal" ecosystem package getting written.
      - deleted 9y ago
- pjmlp 9y ago
  I love using a REPL, but I kind of agree with you. I happen to use more often the IDE's graphical debugger than the REPL. Still Visual Studio has had immediate mode (aka REPL) since VB days, followed by .NET support.
- sametmax 9y ago
  As a Python dev with 12 years of experience, I still use the REPL every day. When I wonder how something works or if I need my memory to be refreshed, I just fire up jupyter console and test quickly the code. I don't open the doc or search on the net. I have the live result immediatly. When I want to debug my web server, I drop a REPL in the server and play with the code. It's more efficient that just debugging, because I can actually modify the code live and see what happens. When I need to understand a format and how to manipulate / tranform data, I use the REPL (or jupyter notebook) because it's the most natural way to do it. I don't know how much Python you have done, but you have been missing one of the greatest tool of the ecosystem. It's like saying you don't see that much the benefits of an IDE for refactoring in Java. "yeah it's cool but how much do you use it hu ?".
brandur 9y ago
> It's beginning to get tiresome to continually hear the Rust community go on and on about how amazing Rust is and say, with a straight face, that eventually there will be no reason to write anything in not-Rust. Are you serious? The hubris is off the charts. So a few considerations here: (1) I really have no connection with the Rust community aside from curiosity, so it's quite dishonest to project my opinion onto all of them, and (2) this is very much my personal opinion. --- I'd still defend the position though. Every language has merits, but especially for a lot of the older ones, there are so many accumulated problems that it's worth considering newer languages just because they're learned so much for the mistakes of their predecessors. For example, I've been doing Ruby for quite a few years now: * Having so few constraints on implementation (e.g. duck typing) was an interesting concept, but time has proven it to be a nightmare maintainability. It buys you a little early productivity, but any honest person with a huge Ruby codebase can tell you that it's a liability. * The only way to get truly good performance is to write a C extension. The language's whole implementation and performance-sensitive libraries are all C. Contrast this to modern languages where it's an embarrassment if your compiler is _not_ written in the language itself (Rust, Go, Swift, etc.). * Core build infrastructure (Bundler) and environment management (rbenv) is maintained separately from the language. It works fine, but the reason it's not more core is not because it's better that way, but because the language's original designers didn't realize they'd be necessary, so they had to be developed separately. This has the effect of making the whole toolchain complex and hard for beginners to understand because none of it is integrated. * The interpreter starts out faster than a compiler, but it breaks down fast. Codebases in the 100,000s of lines or more will take on the order of 10-100 seconds to start up, and the only way to get back to a fast edit-compile-debug loop is through tricks like Zeus. After you resort to that, unreliable runs and weird loading problems become a part of common life. These aren't small problems. Also, I'm picking on Ruby here, but you could drill into a lot of existing languages and find flaws that are roughly on this level (JS/Python/C++/Erlang are easy, but even fan favorites like Haskell and Scala have pretty serious ones). Newer languages have their problems too, but rarely anything on this sort of existential scale. We should stop pretending that all languages are equal with their own share of upsides and downsides. Given decades of language building, it would be disappointing if lessons hadn't been learned. Luckily this isn't the case. In terms of what we write new projects in given a few years, there are other good contenders, but like I said above, I think that Rust has nailed a performance/safety/productivity/ecosystem compromise that's quite a bit above and beyond most of anything else.
nickpsecurity 9y ago
"If your language doesn't have a REPL, your language is less productive." I think what you really want here is fast compiles and iterations. You can do that without a REPL if using a language that compiles ultra-fast. Industrial BASIC's I used a long time ago compiled in a split second with me seeing the results immediately. Wirth-style languages tend to be able to do that. I hear Go compiles really fast. The wait doesn't really matter at that speed. Highly-optimized, slower compiles and tests can run overnight in background on dedicated machine, too.
bluejekyll 9y ago
> If your language doesn't have a REPL, your language is less productive Am I the only one who sees this as pure BS? Some people like REPL's, and that's cool. But not everyone. I find it utterly annoying that in any REPL I've ever used I first have to import (or similar) the libraries I want access to in that repl environment. You end up generally writing a file to do the imports for you, or cutting and pasting. With all that effort I almost always find it easier to just write a test-case, even in languages with a REPL. At that point I have a repeatable and testable piece of code that can be run, with almost zero error due to the REPL environment not being setup properly.
kibwen 9y ago
> It's beginning to get tiresome to continually hear the Rust community go on and on about how amazing Rust is and say, with a straight face, that eventually there will be no reason to write anything in not-Rust. Are you serious? The hubris is off the charts. Please point to a single place where anyone has ever said this. We have never positioned Rust as an end-all be-all language: it's a language that deliberately makes compromises in order to excel at a niche.

zzalpha 9y ago

If your language doesn't have a REPL, your language is less productive. Deal with it. Oh hardly. As someone who's developed software in Perl, Python, C, Java, C#, Haskell, and a few others besides, a REPL is the one thing I use the least. I've honestly never understood the obsession with it. Is a rapid compile-run-debug cycle important? Absolutely. If I want to test something in isolation, being able to rapidly turn out a UT to prove my code does what I think it does is incredibly important. But a REPL is a nice-to-have. Nothing more. Treating its absence as some fundamental black mark on a language is completely absurd.

sillysaurus3 9y ago
I tend to agree, but being able to have a REPL at all is a symptom that your language is capable of an extremely fast compile-run-debug cycle. In other words, if you can't implement a REPL, that's the definition of "less productive language." It's not about the REPL itself but the capability of implementing one. Think about it like this: On your list of languages, which of them would you say is most productive? It depends on the context, certainly: libraries, familiarity, etc. But let's assume the languages had identical ecosystems, and that you were competent in all of them. Which of them would take the smallest amount of time to write your feature? That'd probably be Python, Haskell, or even Perl. It seems very difficult to argue that Rust would top them. And the reasons why this is might be true are worth examining. Here's another aspect. Is the Rust community claiming that the entire history of computing has lead up to this point, where Rust exists, and now nobody needs to write anything in not-Rust? Are people 200 years from now going to write Rust and nothing else? How about 20? 2? It becomes very difficult to argue that your programming language is the lingua franca of the future. (And that's probably true for every language, not just Rust.)
- zzalpha 9y ago
  Think about it like this: On your list of languages, which of them would you say is most productive? Define productive. Are you measuring raw lines of code generated? Or are we measuring amount of production-ready code? My bet: with an experienced, diligent developer it's a wash. My gut says what you lose in a slow code-execute cycle of static, compiled languages you gain in lower defect rates from compile-time checks. Conversely, what you gain in a dynamic language, you lose in errors caught at run-time. At that point I'd select for languages that are simpler with fewer surprising semantics (crossing Perl and Javascript off the list), with more built-in run-time and/or compiler safety (knocking things like C off the list). I generally also prefer compile-time safety over run-time safety, as I'd rather find problems on my workstation than in the field because I missed testing a codepath.
  - kbenson 9y ago
    > with fewer surprising semantics (crossing Perl and Javascript off the list) Actually, I think Perl has fairly few surprising semantics after you learn the major ones. The real problem is that the major one (or specifically the major one, context) is somewhat hidden in normal C-like usage until it jumps out at you and confuses you. Once you understand what it is, it's not all that surprising (but there are a few annoyances with it that still persist and cause problems). You can write Perl that looks almost exactly like C 95% of the time, but that 5% where it matters makes people that do this very confused. There are, of course, other parts of the language that are poorly chosen, but I maintain there are actually far less of them than many people seem to think. As for JavaScript, I still can't get over all the different ways to check for equality and null or undefined. I understand a good portion of that is because I never have to use JS enough to become truly proficient, and some if it is just poor design.
- tatterdemalion 9y ago
  > Is the Rust community claiming that the entire history of computing has lead up to this point, where Rust exists, and now nobody needs to write anything in not-Rust? Are people 200 years from now going to write Rust and nothing else? Let's be clear - the person who said there'd be no reason to write in anything else is an enthusiastic Rust user, but they don't work on Rust & don't represent "the Rust community." They were speaking from their own experience, based on their own balancing of the trade offs as a user. Presumably a REPL doesn't rate very highly for them. However, the reasons we don't have a REPL are mainly two: the compiler isn't architected for it and code doesn't compile fast. The solutions are: * Re-architect the compiler to support incremental code input. This is pretty similar to what we need to support IDEs (which we're working on), so possibly this will solve the problem. * Get a reimplementation of the backend which is a JIT interpreter instead of LLVM, which takes up most of our compiletime. Work is underway on a project called miri, though it isn't officially supported right now. * Make the typechecking part of the compiler faster. This is underway through a project called chalk. In other words, a REPL is not impossible, it just isn't a top priority right now. There are other lacking tools that we're working on - IDE integration and auto-formatting for example - maybe after those are done it will be the top of the docket.
dwaltrip 9y ago
Just because you don't understand the benefits other people get from a REPL doesn't mean they don't exist.
- zzalpha 9y ago
  Just because there are benefits, doesn't make it a deal-breaker.
  - dwaltrip 9y ago
    I didn't say it was a deal breaker? Your post came off as implying REPLs don't have serious benefits for anyone, which felt a bit presumptuous to me.
    - zzalpha 9y ago
      Yup, that's fair. BTW, I actually stand by your interpretation. I challenge anyone to demonstrate significant productivity gains (as measured by number of lines of tested, production code written) that can be attributed to the availability of a REPL (which was the claim of the poster I was replying to). I honestly don't buy it. I believe it's a very nice tool for learning a new language, and maybe for exploring an existing codebase, but I can't envision a workflow where a REPL provides significant productivity gains for an experienced, professional software developer that aren't realized in other ways (e.g. writing unit tests).
      - goatlover 9y ago
        Lispers might be able to meet that challenge.
        nickpsecurity 9y ago
        I could probably have countered it, too, in the same language during the challenge back when I used it. I found the incremental, per-function compilation feature reduced compilation time of most changes to a fraction of a second. Most of time in programming is spent thinking, tweaking, debugging, dealing with 3rd-party libs, etc. I don't think a difference in the source-to-execution part of under 1 second is going to make a big deal. It's high-speed iteration of code one is exploring that makes both REPL's and incremental compilation superior for productivity to full compilation.
zambal 9y ago
The usefulness of a REPL depends a lot on the language/interpreter/vm. In Erlang and Elixir the REPL is more than nice to have. Being able to connect to a production node and peeking around what is happening can be very valuable. I guess it's one of those things that's imho hard to appreciate if you never experienced it.
- zzalpha 9y ago
  The usefulness of a REPL depends a lot on the language/interpreter/vm. In Erlang and Elixir the REPL is more than nice to have. Being able to connect to a production node and peeking around what is happening can be very valuable. That's called a remote debugger, and it's hardly unique to languages supporting a REPL.
zambal 9y ago
The usefulness of a REPL depends a lot on the language/interpreter/vm. In Erlang and Elixir the REPL is imo more than a nice to have. Being able to connect to a production node and peeking around what is happening can be very valuable. I guess it's one of those things that's imho hard to appreciate if you never experienced it.
derefr 9y ago
> I've honestly never understood the obsession with it. The true key to understanding REPLs is their role in consuming third-party libraries. While languages both with and without REPLs will have well-used packages in their package ecosystems that are well-documented; languages with REPLs will also manage to have well-used, poorly-documented packages: packages whose "documentation" consists only of the de-facto ability to reflect on the API in a REPL, doing the moral equivalent of exploring a filesystem using cd(1) and cat(1), until you figure out what functions—and what arguments—combine to produce an acceptable result for your use-case. That may sound like a bad thing, but it's not! Those packages are packages that wouldn't exist otherwise; they're marginal packages, packages which people wouldn't have had time to write if they were required to also document them properly enough to make use of them without a REPL. They're needs being satisfied, that would otherwise—given the stricter requirement of useful API documentation—be going un-met. If you look at e.g. Ruby's gem ecosystem, there are tons of packages that have more than a million downloads, and either no docs or awful docs. How? Because Ruby is extremely amenable to exploring APIs through a REPL. You take a module or class, ask it what its children are, what its class methods are, what its instance methods are. Find a class with instance methods that sound right, attempt to instantiate it. Figure out you can't do that, look around the class methods for something that sounds like a factory method. What arguments does said factory-function take? Well, feed it some at random and see what error you get. Etc.
- oblio 9y ago
  Many languages have good IDE support, which is basically REPL on steroids.
  - derefr 9y ago
    True, though "good IDE support" in the sense you're talking about (i.e. being able to discover an API through the IDE) mostly relies on strong typing in the language. (Non-inferred) type declarations are their own form of documentation, with a similar effect on likelihood of a "marginal" ecosystem package getting written.
    - deleted 9y ago
pjmlp 9y ago
I love using a REPL, but I kind of agree with you. I happen to use more often the IDE's graphical debugger than the REPL. Still Visual Studio has had immediate mode (aka REPL) since VB days, followed by .NET support.
sametmax 9y ago
As a Python dev with 12 years of experience, I still use the REPL every day. When I wonder how something works or if I need my memory to be refreshed, I just fire up jupyter console and test quickly the code. I don't open the doc or search on the net. I have the live result immediatly. When I want to debug my web server, I drop a REPL in the server and play with the code. It's more efficient that just debugging, because I can actually modify the code live and see what happens. When I need to understand a format and how to manipulate / tranform data, I use the REPL (or jupyter notebook) because it's the most natural way to do it. I don't know how much Python you have done, but you have been missing one of the greatest tool of the ecosystem. It's like saying you don't see that much the benefits of an IDE for refactoring in Java. "yeah it's cool but how much do you use it hu ?".

brandur 9y ago

> It's beginning to get tiresome to continually hear the Rust community go on and on about how amazing Rust is and say, with a straight face, that eventually there will be no reason to write anything in not-Rust. Are you serious? The hubris is off the charts. So a few considerations here: (1) I really have no connection with the Rust community aside from curiosity, so it's quite dishonest to project my opinion onto all of them, and (2) this is very much my personal opinion. --- I'd still defend the position though. Every language has merits, but especially for a lot of the older ones, there are so many accumulated problems that it's worth considering newer languages just because they're learned so much for the mistakes of their predecessors. For example, I've been doing Ruby for quite a few years now: * Having so few constraints on implementation (e.g. duck typing) was an interesting concept, but time has proven it to be a nightmare maintainability. It buys you a little early productivity, but any honest person with a huge Ruby codebase can tell you that it's a liability. * The only way to get truly good performance is to write a C extension. The language's whole implementation and performance-sensitive libraries are all C. Contrast this to modern languages where it's an embarrassment if your compiler is _not_ written in the language itself (Rust, Go, Swift, etc.). * Core build infrastructure (Bundler) and environment management (rbenv) is maintained separately from the language. It works fine, but the reason it's not more core is not because it's better that way, but because the language's original designers didn't realize they'd be necessary, so they had to be developed separately. This has the effect of making the whole toolchain complex and hard for beginners to understand because none of it is integrated. * The interpreter starts out faster than a compiler, but it breaks down fast. Codebases in the 100,000s of lines or more will take on the order of 10-100 seconds to start up, and the only way to get back to a fast edit-compile-debug loop is through tricks like Zeus. After you resort to that, unreliable runs and weird loading problems become a part of common life. These aren't small problems. Also, I'm picking on Ruby here, but you could drill into a lot of existing languages and find flaws that are roughly on this level (JS/Python/C++/Erlang are easy, but even fan favorites like Haskell and Scala have pretty serious ones). Newer languages have their problems too, but rarely anything on this sort of existential scale. We should stop pretending that all languages are equal with their own share of upsides and downsides. Given decades of language building, it would be disappointing if lessons hadn't been learned. Luckily this isn't the case. In terms of what we write new projects in given a few years, there are other good contenders, but like I said above, I think that Rust has nailed a performance/safety/productivity/ecosystem compromise that's quite a bit above and beyond most of anything else.

nickpsecurity 9y ago

"If your language doesn't have a REPL, your language is less productive." I think what you really want here is fast compiles and iterations. You can do that without a REPL if using a language that compiles ultra-fast. Industrial BASIC's I used a long time ago compiled in a split second with me seeing the results immediately. Wirth-style languages tend to be able to do that. I hear Go compiles really fast. The wait doesn't really matter at that speed. Highly-optimized, slower compiles and tests can run overnight in background on dedicated machine, too.

bluejekyll 9y ago

> If your language doesn't have a REPL, your language is less productive Am I the only one who sees this as pure BS? Some people like REPL's, and that's cool. But not everyone. I find it utterly annoying that in any REPL I've ever used I first have to import (or similar) the libraries I want access to in that repl environment. You end up generally writing a file to do the imports for you, or cutting and pasting. With all that effort I almost always find it easier to just write a test-case, even in languages with a REPL. At that point I have a repeatable and testable piece of code that can be run, with almost zero error due to the REPL environment not being setup properly.

kibwen 9y ago