Return to Answer

There are REPLs and Interpreters for C++ and most compiled languages

https://replit.com/languages/cpp

http://www.hanno.jp/gotom/Cint.html

But they aren't used often

Why? Because compiling adds checks for things and enforces extra rules like type safety, and those languages were built around enforcing those extra checks. Compiling is a feature!

For example.

Many interpreted languages use "Duck Typing". The interpreter sees if it looks like a duck and quacks like a duck, then it's probably a duck. I know plenty of Ruby devs that swear by it, and it's a great thing until you use an object that doesn't have the right functions and the program blows up in production!

This would never happened in a compiled language. Because we took minutes (and occasionally hours) to meticulously check for it beforehand.

Projects that use compiled languages have decided it's worth more time up-front to ensure type safety.

Projects that use interpreted languages have decided it's worth more testing and QA after-the-fact to get to play a bit fast-and-loose with types.

EDIT

Why don't developers use interpreters and then compile once every so often? Best of both worlds!

Because you can quickly get into a nightmare situation that causes multiple compile issues because an interpreter won't be able to check everything in anywhere near real-time. Any interpreter will have to play a little fast-and-loose with the rules. You'll probably end up spending any time-savings fixing compile issues only found doing it "the long way."

In practice, stuff like incremental compiles and breaking things into libraries lessens the pain of compiling. Some C/C++ code uses Void* pointers, which negate type saftey. On the flip side, some interpreted languages like TypeScript allow and encourage type safety.

If you want a real-world example, look at some of the "hot-deploy" development environments in Java, which tried to do what you're talking about. I almost always turned them off because they were hit-and-miss.

There are REPLs and Interpreters for C++ and most compiled languages

https://replit.com/languages/cpp

http://www.hanno.jp/gotom/Cint.html

But they aren't used often

Why? Because compiling adds checks for things and enforces extra rules like type safety, and those languages were built around enforcing those extra checks. Compiling is a feature!

For example.

Many interpreted languages use "Duck Typing". The interpreter sees if it looks like a duck and quacks like a duck, then it's probably a duck. I know plenty of Ruby devs that swear by it, and it's a great thing until you use an object that doesn't have the right functions and the program blows up in production!

This would never happened in a compiled language. Because we took minutes (and occasionally hours) to meticulously check for it beforehand.

Projects that use compiled languages have decided it's worth more time up-front to ensure rules such as type safety are enforce.

Projects that use interpreted languages have decided it's worth more testing and QA after-the-fact to get to play a bit fast-and-loose with the rules.

EDIT

Why don't developers use interpreters and then compile once every so often? Best of both worlds!

Because you can quickly get into a nightmare situation that causes multiple compile issues because an interpreter won't be able to check everything in anywhere near real-time. Any interpreter will have to play a little fast-and-loose with the rules. You'll probably end up spending any time-savings fixing compile issues only found doing it "the long way."

In practice, stuff like incremental compiles and breaking things into libraries lessens the pain of compiling. Some C/C++ code uses Void* pointers, which negate type saftey. On the flip side, some interpreted languages like TypeScript allow and encourage type safety.

If you want a real-world example, look at some of the "hot-deploy" development environments in Java, which tried to do what you're talking about. I almost always turned them off because they were hit-and-miss.

There are REPLs and Interpreters for C++ and most compiled languages

https://replit.com/languages/cpp

http://www.hanno.jp/gotom/Cint.html

But they aren't used often

Why? Because compiling adds type safety features, and those languages were built around type safety. Compiling is a feature!

Many interpreted languages use "Duck Typing". The interpreter sees if it looks like a duck and quacks like a duck, then it's probably a duck. I know plenty of Ruby devs that swear by it, and it's a great thing until you use an object that doesn't have the right functions and the program blows up in production!

This would never happened in a compiled language. Because we took minutes (and occasionally hours) to meticulously check for it beforehand.

Projects that use compiled languages have decided it's worth more time up-front to ensure type safety.

Projects that use interpreted languages have decided it's worth more testing and QA after-the-fact to get to play a bit fast-and-loose with types.

EDIT

Why don't developers use interpreters and then compile once every so often? Best of both worlds!

Because you can quickly get into a nightmare situation that causes multiple compile issues because an interpreter won't be able to check everything in anywhere near real-time. Any interpreter will have to play a little fast-and-loose with the rules. You'll probably end up spending any time-savings fixing compile issues only found doing it "the long way."

In practice, stuff like incremental compiles and breaking things into libraries lessens the pain of compiling. Some C/C++ code uses Void* pointers, which negate type saftey. On the flip side, some interpreted languages like TypeScript allow and encourage type safety.

There are REPLs and Interpreters for C++ and most compiled languages

https://replit.com/languages/cpp

http://www.hanno.jp/gotom/Cint.html

But they aren't used often

Why? Because compiling adds checks for things and enforces extra rules like type safety, and those languages were built around enforcing those extra checks. Compiling is a feature!

For example.

Many interpreted languages use "Duck Typing". The interpreter sees if it looks like a duck and quacks like a duck, then it's probably a duck. I know plenty of Ruby devs that swear by it, and it's a great thing until you use an object that doesn't have the right functions and the program blows up in production!

This would never happened in a compiled language. Because we took minutes (and occasionally hours) to meticulously check for it beforehand.

Projects that use compiled languages have decided it's worth more time up-front to ensure type safety.

Projects that use interpreted languages have decided it's worth more testing and QA after-the-fact to get to play a bit fast-and-loose with types.

EDIT

Why don't developers use interpreters and then compile once every so often? Best of both worlds!

Because you can quickly get into a nightmare situation that causes multiple compile issues because an interpreter won't be able to check everything in anywhere near real-time. Any interpreter will have to play a little fast-and-loose with the rules. You'll probably end up spending any time-savings fixing compile issues only found doing it "the long way."

In practice, stuff like incremental compiles and breaking things into libraries lessens the pain of compiling. Some C/C++ code uses Void* pointers, which negate type saftey. On the flip side, some interpreted languages like TypeScript allow and encourage type safety.

If you want a real-world example, look at some of the "hot-deploy" development environments in Java, which tried to do what you're talking about. I almost always turned them off because they were hit-and-miss.

There are REPLs and Interpreters for C++ and most compiled languages

https://replit.com/languages/cpp

http://www.hanno.jp/gotom/Cint.html

But they aren't used often

Why? Because compiling adds type safety features, and those languages were built around type safety. Compiling is a feature!

Many interpreted languages use "Duck Typing". The interpreter sees if it looks like a duck and quacks like a duck, then it's probably a duck. I know plenty of Ruby devs that swear by it, and it's a great thing until you use an object that doesn't have the right functions and the program blows up in production!

This would never happened in a compiled language. Because we took minutes (and occasionally hours) to meticulously check for it beforehand.

Projects that use compiled languages have decided it's worth more time up-front to ensure type safety.

Projects that use interpreted languages have decided it's worth more testing and QA after-the-fact to get to play a bit fast-and-loose with types.

EDIT

Why don't developers use interpreters and then compile once every so often? Best of both worlds!

Because you can quickly get into a nightmare situation that causes multiple compile issues because an interpreter won't be able to check everything in anywhere near real-time. Any interpreter will have to play a little fast-and-loose with the rules. You'll probably end up spending any time-savings fixing compile issues only found doing it "the long way."

In practice, stuff like incremental compiles and breaking things into libraries lessens the pain of compiling. On the flip side, interpreted languages like TypeScript allow and encourage type safety.

There are REPLs and Interpreters for C++ and most compiled languages

https://replit.com/languages/cpp

http://www.hanno.jp/gotom/Cint.html

But they aren't used often

Why? Because compiling adds type safety features, and those languages were built around type safety. Compiling is a feature!

Many interpreted languages use "Duck Typing". The interpreter sees if it looks like a duck and quacks like a duck, then it's probably a duck. I know plenty of Ruby devs that swear by it, and it's a great thing until you use an object that doesn't have the right functions and the program blows up in production!

This would never happened in a compiled language. Because we took minutes (and occasionally hours) to meticulously check for it beforehand.

Projects that use compiled languages have decided it's worth more time up-front to ensure type safety.

Projects that use interpreted languages have decided it's worth more testing and QA after-the-fact to get to play a bit fast-and-loose with types.

EDIT

Why don't developers use interpreters and then compile once every so often? Best of both worlds!

Because you can quickly get into a nightmare situation that causes multiple compile issues because an interpreter won't be able to check everything in anywhere near real-time. Any interpreter will have to play a little fast-and-loose with the rules. You'll probably end up spending any time-savings fixing compile issues only found doing it "the long way."

In practice, stuff like incremental compiles and breaking things into libraries lessens the pain of compiling. Some C/C++ code uses Void* pointers, which negate type saftey. On the flip side, some interpreted languages like TypeScript allow and encourage type safety.