3 ms·

This is an discussion topic, and this text provides a viewpoint. However, from how I read it, the "current paradigm" is imperative languages like C/C++, and "ne

by theamk 8y ago

This is an discussion topic, and this text provides a viewpoint. However, from how I read it, the "current paradigm" is imperative languages like C/C++, and "next paradigm programming language" is Datalog (this word occurs 31 times on 9 pages of text). What is missing are functional and descriptive languages. No explicit loops? "heavily leverage parallelism, yet completely hide it"? lazy evaluation? This sound like functional languages. "Example: An Interactive Graphical Application." describes HTML+CSS exactly. I understand author really loves Datalog, but omission of other languages makes the message less effective.

tsimionescu 8y ago
> "heavily leverage parallelism, yet completely hide it"? lazy evaluation? This sound like functional languages. I agree with your general comment, but this statement seems a bit optimistic on the functional languages side. Lazy-evaluation? Haskell does it, but most other functional languages don't. Heavily leverage parallelism but hide it - this is often touted as an advantage of pure functional languages, but from what I've heard, in practice it has never panned out, at least if I'm interpreting it correctly as automatic parallelization. Turns out, while the compiler can prove it would be safe to do so, a lot of the time it would massively hurt performance, and the compiler can't tell when that is the case or not. So, even in a language like Haskell, you still have to explicitly parallelize code, think about chunking etc. And if we stray from pure parallelism and into concurrency, all of the problems of having to do explicit synchronization come back, you just have less to worry about with no(/less) shared state. Funny thing, one langauge that does 'leverage parallelism, but hide it' is x86_64 assembly, where the processor automatically executes (parts of) assembly instructions in parallel, based on data dependencies and available compute ports.

by theamk 8y ago

tsimionescu 8y ago

> "heavily leverage parallelism, yet completely hide it"? lazy evaluation? This sound like functional languages. I agree with your general comment, but this statement seems a bit optimistic on the functional languages side. Lazy-evaluation? Haskell does it, but most other functional languages don't. Heavily leverage parallelism but hide it - this is often touted as an advantage of pure functional languages, but from what I've heard, in practice it has never panned out, at least if I'm interpreting it correctly as automatic parallelization. Turns out, while the compiler can prove it would be safe to do so, a lot of the time it would massively hurt performance, and the compiler can't tell when that is the case or not. So, even in a language like Haskell, you still have to explicitly parallelize code, think about chunking etc. And if we stray from pure parallelism and into concurrency, all of the problems of having to do explicit synchronization come back, you just have less to worry about with no(/less) shared state. Funny thing, one langauge that does 'leverage parallelism, but hide it' is x86_64 assembly, where the processor automatically executes (parts of) assembly instructions in parallel, based on data dependencies and available compute ports.