#BEST LANGUAGE FOR WEBSCRAPER CODE#

(Also, good to know Python dev environments have improved, but I guess it's to be expected, 10 years is a long time :-). To some ears, 'interpreted' can sound synonymous with 'slow', which is I guess what prompted my comment.įinally, to me the place where you can enter expressions to try out your program interactively is the REPL, not the interpreter.Īnyway, thanks for explaining your position to me.

#BEST LANGUAGE FOR WEBSCRAPER CODE#

It's fuzzy, I know, since there is some continuum between interpreting an AST directly, compiling the AST to bytecode and running the bytecode on a VM, JIT compiling the bytecode to machine code on the fly, and compiling offline direct to machine code (like C/Go/Rust). To me 'interpreter' refers to a language implementation strategy. But I would still consider Haskell a compiled language, not an interpreted one, since you never run code in production under ghci, you always ship your binaries. Expressions entered at the REPL get compiled directly to machine code, so there's no difference in performance for a function entered at the REPL (or via SLIME C-c C-c) and one built as part of a batch compile.Ĭontrast that to Haskell's ghci interpreter, which is slower (last time I checked) than the same code built on the command line with ghc, the compiler. Well, SBCL does not ship with an interpreter, for example. You can open a python process with C-c C-p and then send the buffer, functions, marked areas, lines etc. I should probably have used the term 'ships with an interpreter' :)īTW the current python-mode in Emacs also allows SLIME-like behaviour. For optimization reasons the implementation probably uses some sort of compilation but you can still use the built-in interpreter on all of these 'interpreted' languages. I regard dynamically typed languages that ship with an interpreter as interpreted languages. Sorry if my terminology has caused you trouble. you can write your programs incrementally, going back and forth between the REPL. With languages like Javascript, Lisp, Python, Ruby etc. With compiled languages (following this logic) such as Java or Go or C, you need to write your program pass it through a compiler to get an output. Whether it's compiled to bytecode and then executed from there is IMHO an implementation detail. I instinctively used the 'interpreted' term, because mainly you can execute instructions on the fly in an interpreter the language ships with. Such approach essentially sidesteps the functional part of Elixir, and instead attempts to simulate objects with processes. agents) for this is a mistake I see people make frequently.

If those concepts are more complex, it’s worth implementing them in separate modules and functions to separate different concerns and keep each part of our code focused and concise. > The construct “thought concern” here refers to ideas which exist in our mind, such as order, order item, and product for example. > Do not use processes (not even agents) to separate thought concerns. > Use processes to separate runtime concerns. > Use functions and modules to separate thought concerns. > But before starting, since this is going to be a long article, I want to immediately share my main points: I can highly recommend this article (also just in general for people curious about Elixir): Using processes for state as if they're objects is generally considered bad practice. While I don't disagree entirely, I find that Elixir is actually quite functional.

Best language for webscraper