71–80 of 109 posts
Earlier quoted context omitted.
> First of all, the problem isn't that it's "compiled" - Python is "compiled" too, but still has one of the best REPLs available. In a way it is. For a REPL you most likely need an interpreter for your language, like Cling is for C++.
It can be argued that "compiled/interpreted" is not a property of programming languages, but of programming language implementations .
Well, here is why not. AFAK, it still lacks support for parallelism / multicore programming. Please correct me if I'm wrong. Once it has that, I'll be happy to learn it, but currently it's concurrency seems to be as limited as Racket's. That's a big obstacle for early adoption, since the trend is going towards 64 cores sooner than later. My current CPU already has 8 physical cores and 16 logical cores, and I'd like t…
This is a big advantage of Nim ( https://nim-lang.org/ ), which on the face of it is a pretty similar kind of language with a more Python-like syntax. Nim supports real threads with message passing channels (similar to Go).
Could you specify what are the differences from Go, in this regard are, please?
Well, here is why not. AFAK, it still lacks support for parallelism / multicore programming. Please correct me if I'm wrong. Once it has that, I'll be happy to learn it, but currently it's concurrency seems to be as limited as Racket's. That's a big obstacle for early adoption, since the trend is going towards 64 cores sooner than later. My current CPU already has 8 physical cores and 16 logical cores, and I'd like t…
Are you sure Racket doesn't support parallelism?
Before you criticize me for this statement, please let me assure you that it's based on plenty of experience. I'm using Racket for almost all my programming since Racket 2 and have contributed libraries.
My hope is that they add good parallelism support in Racket 7, and since it's based on Chez scheme all thread support should already be built in. Places suck.
Earlier quoted context omitted.
I'm similar to you. An every-day / almost every day C++ user. I've been using Clojure for a personal project and I really enjoy the much-reduced overhead imposed by the language. Unfortunately it runs on the JVM so that's not something I'm super stoked about. But this language seems interesting. The interoperability with C libs gives it a head start. The syntax seems much nicer than Rust. Too bad about the parallelis…
Lisps are all very, very cool -- you basically get to build your own world. And the macros -- so powerful. But the parens! Not the number of them, as that is about the same as other langs, but the placement of them: Sample factorial function: (define fac (lambda (n) (if (= n 0) 1 (* n (fac (- n 1)))))) ; And with Clojure, you don't have proper tail recursion, so you'll have to add some Clojure-only thing in there to…
what I dream of is a Lisp with an additional mechanism to define precedence of functions/operators. And infix operators. Almost like Haskell.
> Because Crystal is compiled, it is impossible to have a true REPL Impossible, or just hard?
The main difference between compiled and static languages is that compiled languages go through a phase of "checking your work", where it compares parts of your program to other parts before running it. For example, if you misspelled a name, the compiler will look everywhere in your program for that name before you run it, and tell you it can't find the name. That's why we like compiled languages. By contrast, dynami…
SBCL:
* (defun foo (a) (+ a 42))
FOO
* (defun bar (b) (foo 10 20))
; in: DEFUN BAR
; (FOO 10 20)
;
; caught STYLE-WARNING:
; The function was called with two arguments, but wants exactly one.
; (SB-INT:NAMED-LAMBDA BAR
; (B)
; (BLOCK BAR (FOO 10 20)))
;
; caught STYLE-WARNING:
; The variable B is defined but never used.
;
; compilation unit finished
; caught 2 STYLE-WARNING conditions
BAREarlier quoted context omitted.
/smug-lisp-weenie-mode I didn't realise that SBCL is interpreted.
I'm not sure how SBCL is implemented, but I've written my own Lisp. It's incrementally compiled to byte code - the compiler is called when defun or defmacro is evaluated - but the REPL still relies on the interpreter, the same interpreter which does everything until the compiler compiles itself during a clean build. So compiled code can have a REPL, but a REPL needs an interpreter as well.
OTOH LispWorks uses an interpreter for the REPL interaction.
Yes, an Interpreter offers some more interactive features - but usually lacks the compile-time warnings/errors.
Don't forget about Nim. Nim is similar except it's Pythonish syntax with C speed instead of Rubyish syntax.
Earlier quoted context omitted.
Parallelism is large part of the answer to question of "how do we make this thing as fast as hardware allows" (most people will add "easily" to that). Or "as fast as our users demand" if it makes it easier to understand. The use for that comes with scale, there is a one caveat though: it is often impossible to add this as an afterthought to your program and to programming language. If you choose programming language…
Thank you for taking the time to answer the question. In principle, I know how it ought to work. But when would I need to use it? For instance, if someone is making a web api, and you're pulling data from a database, should one think about it? If one is doing some data analysis, should one think about it? I always thought that it is a "low level" program that takes care of it. So tensorflow might worry about it, but…
You should worry about it when you want to do something faster than you are already or want to do more things at once. Maybe someone's framework/service has done it for you maybe not.
For a web api, the workload _usually_ looks like: {database call} -> {do some work} -> {maybe more calls} -> {more local work} -> {done}.
In the python/node/ruby world where you have mostly single process workers. You get some parallelism by doing work locally while the database call is made asynchronously. If you want to handle more requests on a host you'll just run more processes and load balance across the front (nginx, gunicorn, etc). In languages with threads you usually do that INSIDE your program. A single process load balances across worker threads internally.
At first blush, multiple threads are pretty similar to just running multiple programs. It gets more complicated when you start talking about how you want to communicate between them or share resources across them.
For data analysis you often have algorithms that are embarrassingly parallel[0] chained together. You use threads the same way you'd call three friends to help you move. You all pack boxes at the same time without really needing to coordinate and then you start loading the truck where you have to talk more. One might wait in the truck and organize while 2 or 3 others might be shuttling boxes outside. Maybe everyone sits around while the stairs are blocked by one person moving a shelf. It just depends. Having 4 people helps sometimes or is disruptive in others.
[0]: https://en.wikipedia.org/wiki/Embarrassingly_parallel
P.S. - To address your examples: tensorflow, map-reduce, orms. etc.
It's all still about parallelism but not necessarily about threads.
Parallelism is just doing more things at the same time. Threads are (mostly) about CPU parallelism, but many of those use other resources to get parallelism. Tensorflow might use the GPU, which has many threads internally (simplification), to do one thing while the CPU does another. Mapreduce will use a lot of different machines across a cluster, but maybe only a thread or two on each, to archive parallelism (and really getting disk IO parallelism). And ORM will call the database and let it do work while your CPU else instead of wait.