Are there inherent advantages/disadvantages to either option? If a new language was to be made which would you prefer it to be?
For further actions, you may consider blocking this person and/or reporting abuse
Are there inherent advantages/disadvantages to either option? If a new language was to be made which would you prefer it to be?
For further actions, you may consider blocking this person and/or reporting abuse
Ben Halpern -
Abraham Romero -
Vinod Kumar -
Shafayet Hossain -
Top comments (29)
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.
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).
The released a new preview version just yesterday: Flutter Release Preview 2: Pixel-Perfect on iOS
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.
I am a huge Java and Kotlin (compiled languages) fanboy, and really don't care much for Groovy, Javascript, Ruby, or Python (all interpreted languages). One of the main reasons why I like compiled languages is because it gives me a sense of safety in refactoring that you don't get with interpreted languages.
For example, if I change a variable name and forget to update the code that used that variable, a compiled language will fail to compile, and I am forced to fix it everywhere. In an interpreted language, even one that is preprocessed using something like Webpack, you can't know for sure that you've renamed the variable everywhere until you start getting errors at runtime. You can mitigate it with static analyzers, but that's just an extra thing you have to get set up, which comes for free with compiled languages.
That's the case for JavaScript, but most interpreted languages I know will throw a compile-time error (call it parse-time if you want) if they find an unknown variable. Perl 6 does that by default, and Perl does it if you do
at the beginning, which you should do anyways.
I agree, but on the other hand: fixing something in the backend and not having to recompile and restart the server is awesome once you get used to it.
Trade-offs, trade-offs...
Getting into this a bit late but most statically typed languages support incremental compilation so you only have to compile the part which changed. Also, Java server-based applications I have worked on support hot-code reloading in development mode. The feedback loop is not as bad as people think.
Whatever gets the job done honestly. So many different languages have their own use-cases that they fit the best.
To me, the use-case is so much more important than compiled vs interpreted. I wouldn't write a web-app using C++, but I might use it to write a command-line tool, as an example.
Ideally, it would be like Common Lisp in that it has interpretation and compilation both built in from the start. ANSI Common Lisp described it as having "the whole language there all the time": you can compile code at runtime, or run code at compile time (which allows for lots of metaprogramming).
When you want fast iterative development, you want interpreted code. In production (and especially on resource-constrained devices), you want code to run as fast and memory-efficiently as possible, so you want it compiled. The ideal language would make it effortless to transition between the two as needed.
Compiled languages just win on everything (performance, reliability,
But, most famous enterprise backend langs (Python, C#, Java... etc) are using both of the best worlds... they get compiled into some special binary format, then an interpreter on any platform (android, ios, win, linux) gets that special code and execute it.
All that to achieve super cross-platform, and they do work on virtually all devices.
Ah, JS is an exception :D
You can't just "win" at performance. It will depend on payload. Languages such as Perl might be faster at regexes than compiled languages (whose implementation is, often, based on Perl). Compiled languages have a wide range of performance on a wide range of features; interpreted languages too, and they often overlap.
Some interpreted languages, like Perl 6, have a JIT compiler that optimizes a program as it runs. All optimizations for compiled languages are done at compile time. So you would really have to look at particular payloads.
Ditto for reliability. I can't see C being more reliable than Haskell, for instance.
You can't generalize just because Perl regex "seemed" faster... you were programming since the 19s and not everyone did like you, so you know why a low-level lang like Assembly should be faster than writing the same app in C.
Same goes to interpreted languages, it all depends on the implementation. If Perl is faster than Java in regex, it means their implementation is just faster... nothing more.
C / C++ are just faster than any other lang (given we use the latest compiler optimizations and the right implementation of the software)... Perl interpreter itself is implemented in C & C++.
All the people here agree on this point: news.ycombinator.com/item?id=8626131
From my experience, run-time errors occur more in interpreted languages than compiled languages. I do Python and C#, and I face lots of run-time errors in Python than C#.
Well, Java is slower than almost anything in Regexes (and apparently buggy), according to this post: attractivechaos.github.io/plb/ Lua clocks in very good time, and Javascript (interpreted, with a JIT compiler) is faster than C# (compiled to bytecode).
This is only a particular case, dealing with regexes. In general, you can't make a sweeping statement on general performance. Your mileage might vary depending on the actual application you are running, and the actual implementation you use (different compilers will have different performance, for instance).
I agree on what you say.
All that being said, the performance difference isn't really affecting the business cuz most companies, banks, and organizations are happy with Java & C#.
So, I really think it's pointless to make a decision out of these metrics.
I presume you forgot about JIT languages, or considered them as interpreted.
Beside the obvious pros and cons, there are 2 languages that stand out in this regard (from what I know of course):
Go - it is compiled but the compiling time usually is smaller than running a nodeJS instance.
Dart - it is JIT when you develop (for fast iterations, hot reload, on mobile this is a HUGE advantage over competitors), and is compiled to native code when needed. More about it here: hackernoon.com/why-flutter-uses-da...
If any of these would compile to something that browsers can run it (and with access to DOM) would be great alternatives to JS. (yes I know about gopherJS, dartto js and webassembly, but they are not there yet ..).
Honorable mention: JVM, that beast beats the law of physics, a JIT shouldn't be that fast.
Other examples of JITs: PyPy for Python, LuaJIT for Lua, CLR for all .NET languages...
I think only WebAssembly has a shot, in the sense that there's no replacing JS for the time being. What you can do is to hit JS pain points, on one side with better language constructs going forward (pipeline operator is smooth), typescript for those wanting type checking and WebAssembly to increase performance (I can see libraries used by Node and client side JS being written in whatever language which then generates WebAssembly). I don't think people will start overnight throwing away JS tooling and knowledge and start using server side languages to write SPAs. Maybe in time, who knows.
Well, it's the result of millions of dollars in research by multiple complanies and millions of man hours. It better be fast ;D
A downside of JITs: they suck if startup time is an issue.
Interpreted languages can often give you more instant feedback when coding. But they also typically have slower code and you might have to ship your code in source (or obfuscated) form with the run-time interpreter which is often less than ideal.
Then there are intermediate languages that are compiled a bit, but still use a run-time. Java and C# come to mind here.
Then there are fully compiled languages. Compiling your code to native machine code is nice for source security. Performance is often better as well, but the compile process can take time.
I guess I would prefer a fast, compiled language these days.
Some languages come with compilers that are fast enough to make them equally suited for frequent changes (e.g. Go). Compilers can also help you find problems early - the Elm compiler is famous for this - which can be a boon when making frequent changes.
In theory being interpreted or compiled is often not a property of the language. I've seen C interpreters and JavaScript compilers. Although I'm not sure if you can create an interpreter for declarative languages, as they do not have statements that can be 'executed' line-by-line.
When it comes to muddying the waters, I'd go so far as to say interpreted and compiled are different ends of a spectrum rather than enumerable values.
There is a great talk that touches on that topic youtu.be/0arFPIQatCU I'll paraphrase a part that summarises "people who win Hackathons don't use OCaml, they use Python. For a larger long lived project the types will derive change..."
I think it's an interesting point of view on building solid projects with a typed language, in their case Ocaml.
A lot of people are arguing about performance.
Assuming good implementation:
Compiled languages are faster in general because they don't need to run through any intermediate interpreter. Instead of finding out what needs to be done and then doing it, at run time the program just does what needs to be done.
In an interpreted language, the program needs to first figure out what needs to be done (be interpreted), then it can go and do it. The sorts of optimizations that this allows can reduce the interpretation overhead, but I can't think of a practical and useful way it can turn that overhead around into an advantage.
All that being said, I don't really care if my CMake script takes a bit long to run. I won't be running it every day.