On the topic of compiling itself I'm not sure what false dichotomy you are seeing in my statement. I'm not saying it's impossible that you can find an interpreted language faster than a compiled one, just that the speed boost granted by compilation is large enough to make it improbable. It's like if I pick a bunch of random people and ask them "pick a random number". I think we'll all agree that the vast majority of people are going to pick a low number just due to picking bias. I then divide the results into two random groups, and compare A + 200 against B. The vast majority of the time A +200 is probably going to be higher. Similarly the actual act of compilation gives enough benefits in terms of optimization and running speed with modern compilers that in many cases the benefit gained from that it is going to outweigh any particular speed benefits created by language choice if that language is not compiled. It's not impossible that you could find an interpreted language that is faster than a compiled one, just unlikely, and that benefit would most likely be limited to only handful of processes.
As for SBCL and co., what's going on there is just that you're using a language that can alter how much of the work is done through interpretation (thus allowing for easier code modification and debugging) and how much is done through compilation (for fast running speed). This allows you to perform many operations much faster than purely interpreted competitors (such as Python) and lets you determine exactly what balance between speed and dynamism you want to have (which can be a major advantage to that language).
SBCL does not rely on an interpreter. If you enter something into the REPL it is first compiled and then run. That means if you enter a function definition, the function is compiled and then stored in compiled form for later use. The enhanced debugging is not due to interpretation but due to incremental compilation. That is the false dichotomy I meant.
Any program compiled with SBCL will always be fully compiled. SBCL actually does contain an interpreter, but it is disabled by default and if it has a use, it is probably only to check for semantic differences between interpreted and compiled Common Lisp (unfortunately that kind of stuff is in the standard, but that doesn't concern me when I only use compiled Common Lisp), not interactively running code.
There actually are trade-offs involved in Common Lisp programming regarding optimization, but these are between run-time type checking, whether debugging information is retained, speed and size. It has nothing to do with interactivity.
Of course really every language is just a tool. My university even occasionally offers a course on "picking the right language for a given task", because every language has it's benefits and drawbacks, and ideally programmers should be familiar enough with as many languages as possible that they can pick the one that works best at their specific given task, instead of just whatever one they happen to be most familiar with. Even esoteric languages like Ante might hypothetically be the best choice if for some reason your need for code obfustication was so high that it outweighed the additional cost of time and debugging ease to actually write the program.
Yes, no argument there.
@Gatleos:
I use emacs, but that is kind of the opposite of lightweight.
Use whatever editor you feel most comfortable with.
Author
Topic: if self.isCoder(): post() #Programming Thread (Read 902759 times)