At the risk of being pedantic, there's no reason you can't have both a compiled and interpreted implementation of a language - for example, Haskell has GHC, which compiles down to native code, and the lapsed Hugs implementation, which is an interpreted implementation of Haskell. Scheme and ML are other languages which have both interpreted and compiled implementations. Then you get into interesting territory with languages like Java, which are compiled to bytecode, and the bytecode is interpreted (and possibly just-in-time compiled) at runtime. A lot of interpreted languages - Python, Ruby, Lua - actually compile to bytecode and execute that when you run a script.
Performance is a big factor when it comes to interpreted vs compiled - the rule of thumb is that compiled is faster than interpreted, but there are fancy interpreted systems which will generate faster code (I think some commercial Smalltalk implementations do this).
One nice thing about compiling down to native code is that you can ship binaries without needing to deploy a runtime; this is one of Go's strongest features, in my opinion!
I don't think this is pedantic, I feel like it's a great evaluation of the whole question.
I personally take the give and take of each scenario and don't draw the line for my own uses.
In my life these days, I've been writing Ruby and JS for the most part but a bit more Swift for iOS lately. I don't like that I have to wait to compile and run when I write native in Swift, but I accept it as part of the world I'm in when I work with this tool.
I hope in the long run that good work keeps going into making interpreted code more performant and compiled code easier to work with.
I'm sure Swift compilation phase is also "slowed" from the enourmous amount of stuff you have to compile for a mobile app to function :D
Yes. The complacency with regards to the scenario described in the XKCD contributes to a developer experience which could have been different whether it had to do with compile time or otherwise.
Flutter and React Native offer a much better dev feedback loop. It's a shame this wasn't made possible in the most native case.
Flutter and React Native offer a much better dev feedback loop. It's a shame this wasn't made possible in the most native case.
I've gone through Flutter's tutorial just out of curiosity and it's amazing to see controls, colors, text and everything else changing in such a short time on the device plugged to the computer (the emulator is noticeably slower but that's true for all platforms I guess). It reminded me of hot module replacement with JS/webpack apps.
I was less happy about the amount of stuff I had to install to make everything work :D
I had the same journey. My unhappiness hit when I realized the key native functionality I needed was nowhere to be found. I’ve been through this pain and it made me reconsider Flutter at this time.
Glad to see someone got hooked to Flutter. Try it in profile/release mode(emulators doesnt support release/profile mode), you be stunned in its performance and productivity. Interpreted languages are good for beginners because they get overwhelmed with data types. Dart is statically and optionally typed language(dynamic type supports but I wouldnt recommend using it). Good for beginners if they want to use var only, it may infer its type in runtime. new and const are optional to optimize productivity, people still get confused new and const to a widget.
I've been using flutter for 6 months and now my productivity gets higher as I implement changes with their guidelines. But flutter is moving so fast, it is expected to release their v1.0 on November-December. Now I can easily switch language and easier to understand(Next is Go).
I was about to say one thing, then saw you mention Go, which can be run either way.
So....
There is the speed benefit for compiled code, to be sure, but most places I've worked have focused more on developer time than run time, which argues toward interpreted and/or dynamic languages.
I know developers who balk at the weakly-typed nature of dynamic languages, seeing it not as a benefit to speed but as check against error. There's nothing stopping anyone from making a strongly-typed interpreted language, except for lack of user interest.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
At the risk of being pedantic, there's no reason you can't have both a compiled and interpreted implementation of a language - for example, Haskell has GHC, which compiles down to native code, and the lapsed Hugs implementation, which is an interpreted implementation of Haskell. Scheme and ML are other languages which have both interpreted and compiled implementations. Then you get into interesting territory with languages like Java, which are compiled to bytecode, and the bytecode is interpreted (and possibly just-in-time compiled) at runtime. A lot of interpreted languages - Python, Ruby, Lua - actually compile to bytecode and execute that when you run a script.
Performance is a big factor when it comes to interpreted vs compiled - the rule of thumb is that compiled is faster than interpreted, but there are fancy interpreted systems which will generate faster code (I think some commercial Smalltalk implementations do this).
One nice thing about compiling down to native code is that you can ship binaries without needing to deploy a runtime; this is one of Go's strongest features, in my opinion!
I don't think this is pedantic, I feel like it's a great evaluation of the whole question.
I personally take the give and take of each scenario and don't draw the line for my own uses.
In my life these days, I've been writing Ruby and JS for the most part but a bit more Swift for iOS lately. I don't like that I have to wait to compile and run when I write native in Swift, but I accept it as part of the world I'm in when I work with this tool.
I hope in the long run that good work keeps going into making interpreted code more performant and compiled code easier to work with.
That's one of the "selling" points for Go, the fast compilation times, in my experience it invalidates this:
I'm sure Swift compilation phase is also "slowed" from the enourmous amount of stuff you have to compile for a mobile app to function :D
Yes. The complacency with regards to the scenario described in the XKCD contributes to a developer experience which could have been different whether it had to do with compile time or otherwise.
Flutter and React Native offer a much better dev feedback loop. It's a shame this wasn't made possible in the most native case.
I've gone through Flutter's tutorial just out of curiosity and it's amazing to see controls, colors, text and everything else changing in such a short time on the device plugged to the computer (the emulator is noticeably slower but that's true for all platforms I guess). It reminded me of hot module replacement with JS/webpack apps.
I was less happy about the amount of stuff I had to install to make everything work :D
I had the same journey. My unhappiness hit when I realized the key native functionality I needed was nowhere to be found. I’ve been through this pain and it made me reconsider Flutter at this time.
The released a new preview version just yesterday: Flutter Release Preview 2: Pixel-Perfect on iOS
Glad to see someone got hooked to Flutter. Try it in profile/release mode(emulators doesnt support release/profile mode), you be stunned in its performance and productivity. Interpreted languages are good for beginners because they get overwhelmed with data types. Dart is statically and optionally typed language(dynamic type supports but I wouldnt recommend using it). Good for beginners if they want to use var only, it may infer its type in runtime. new and const are optional to optimize productivity, people still get confused new and const to a widget.
I've been using flutter for 6 months and now my productivity gets higher as I implement changes with their guidelines. But flutter is moving so fast, it is expected to release their v1.0 on November-December. Now I can easily switch language and easier to understand(Next is Go).
I was about to say one thing, then saw you mention Go, which can be run either way.
So....
There is the speed benefit for compiled code, to be sure, but most places I've worked have focused more on developer time than run time, which argues toward interpreted and/or dynamic languages.
I know developers who balk at the weakly-typed nature of dynamic languages, seeing it not as a benefit to speed but as check against error. There's nothing stopping anyone from making a strongly-typed interpreted language, except for lack of user interest.