/tech/ - Technology★

>Parallel processing

I don't know if concurrent languages like erlang count, or if this means more like CUDA.

>>996393 (OP)

>Logic

Prolog

Prolog for logic programming. There are many languages using the logical computation paradigm but prolog is to logical programming what LISP is to functional programming.

Anyone here ever used prolog? It's like an alien world to me, only mentioned in some obscure japanese A.I. paper.

>>996420

>but prolog is to logical programming what LISP is to functional programming.

AKA not very logical, and in the case of LISP not very functional. Prolog has an inferior inference algorithm that means that many functions have to written in horrible ways. Instead of concentrating on the function / relation you waste time on the interpreter / compiler implementation details. For a real modern logic language try "mini kanren". You can do things like write a scheme interpreter in the langauge, and then simply ask the language "generate programs for this interpreter that always evaluate to 2", and mini kanren will go on and generate every possible one forever (or up to your cap). As for functional programming Haskell is a much better example than Lisp. Lisps use imperative programming absolutely everywhere.

>>996435

Interesting, very interesting. Still you have to keep in mind that LISP was proposed in a time when actual boomers were going through puberty/wetting their bed. Haskell is indeed more pure but it doesn't have the same mantle that LISP has, it also hasn't survived for 60 years.

>>996438

>it also hasn't survived for 60 years.

Yes anon it is only 30 years old. Woop woop.

>>996440

I'm not saying it as a good or a bad thing. It just means that LISP is in the very root of functional programming while haskell just came along.

People have lived shorter lives than the difference between the two languages' ages, just because the numbers are above 10 doesn't make the difference trivial.

>>996393 (OP)

> represent the peak of each paradigm.

>>996441

Sorry anon when did op say oldest possible example?

>>996393 (OP)

Procedural

Computers

Functional

Mathematics

Object-Oriented

Cog oriented book authors

>>996393 (OP)

Per Haskell, there was a recent paper, Exceptionally Monadic Error Handling? It's quite a nice arguement for throwing more mathematics at the problem to eventually solve it. As well as Ghost of Departed Proofs, which is another interesting manner by which we can enrich the type system without going full dependent types. The main issue is paying the complexity cost where it isn't necessary.

For something like C, Haskell, languages that end up mattering is a rekindling interest in functorial programming. Instead of dealing with the primitives of the languages, compilers, but forming meaningful algebras/contexts/DSLs on top of the base language like previous paragraph related.

>>996435

>>996420

>>996418

Iirc, datalog was used for optimising relational databases, and this was later improved with the reapplication of proof propagators from SAT/SMT solvers. Needless to say, you can really throw more math at the problem. Remember, CHL Iso is real, and whatever you use to extend one of the related theories can be used to extend another. Epistemic logic extends not only logic, but also type theory allowing for language constructs to have a concept of not having total information, but that some remote computational node does. Distributed computing.

>>996393 (OP)

Thinking of, that last example is probably the beginning and end of "parallel processing". For data-flow processing, I think you'd base your computational graphs in terms of Arrows, a la Tweag's Funflow workflow library.

>>996441

It was something like LISP to various research languages which I think eventually sorted itself out into the Schemes and MLs. Some small languages like Miranda and so on happened, but died out, each with their own novelty. Then Haskell was a strange case where the people that would've made thousands of research languages and some undying languages, they decided to put all their efforts into making one language.

Haskell is a strangely lively language, and while GHC dominates, there's been recent moves to absorb all the novelties of the rare or dead compilers. As it turns out GHC hasn't been able to steal anything new from ML for a few decades.

>>996393 (OP)

>Functional

>Haskell

I'd say ML in general, though.

There are some languages that are good examples of a paradigm, but they are not at a peak because they can still be improved. They also have different philosophies and principles.

Procedural: Ada, Algol, Fortran, Pascal, PL/I

Object-Oriented: Common Lisp (CLOS), Dylan, Smalltalk

Functional: Haskell, "pure" Scheme

Java can't be the archetype or peak of OOP because there were a lot of advances in OOP before Java like multiple inheritance, multiple dispatch, and everything being an object. The reason so many people complain about "OOP" is that UNIX languages like C++ and Java ignore decades worth of solutions that solve the problems they have in those languages. Weenies will say some bullshit about the solutions being "bloated" so they never get used, then they complain about a lack of solutions even though they work fine in other languages. In many cases, the solutions are older than the problems they created by not understanding the solutions.

C is the peak and archetype of the suck paradigm. If C++, Java, JavaScript, and all these other UNIX languages were not based on C, they would be higher quality, simpler, and more productive.

C is supposed to be a "simple" language but they didn't even think of the interaction between macros and the { and } in compound literals. This is considered a minor cosmetic problem but it would have been a complete embarrassment if this kind of thing happened in a good language. This is another example of the solutions being older than the problem. The "designers" didn't care and neither do the standards committee, and it sucks.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2299.htm

What really sucks is that the people who wrote the C standard don't even understand what they wrote. This kind of bullshit has nothing to do with any paradigm.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2243.htm

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2263.htm

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2294.htm

   I've been confusing my compiler class with this one for
   a while now.  I pull it out any time someone counters my
   claim that C has no block structure.  They're usually
   under the delusion that {decl stmt} introduces a block
   with its own local storage, probably because it looks
   like it does, and because they are C programmers who use
   lots of globals and wouldn't know what to do with block
   structure even if they really had it.

   But because you can jump into the middle of a block, the
   compiler is forced to allocate all storage on entry to a
   procedure, not entry to a block.

    But it's much worse than than because you need to invoke
this procedure call before entering the block.
Preallocating the storage doesn't help you.  I'll almost
guarantee you that the answer to the question "what's
supposed to happen when I do <the thing above>?" used to be
"gee, I don't know, whatever the PDP-11 compiler did."  Now
of course, they're trying to rationalize the language after
the fact.  I wonder if some poor bastard has tried to do a
denotational semantics for C.  It would probably amount to a
translation of the PDP-11 C compiler into lambda calculus.

>>996774

>they are not the peak because they can still be improved

The best language available to represent or implement a programming paradigm is what he wants, i think he doesn't care much about theoretical maximums.

As someone whose only ever programmed C for embedded stuff and python/bash scripts functionally, could someone explain/provide some good links or reading on dataflow programming? this is the first time I've heard of it, probably because i don't write programs to crunch numbers or interpret data. It sounds fairly interesting, I would like to know more.

inb4 "but the infallible Multicians made a PL/I compiler"

Both the EPL compiler and its replacement were slow as shit (both compiling and the output's execution speed) and the multicians site admits this: they had to use a subset of the language to get anything resembling reasonable performance and even after that it still sucked dick compared to their Fortran compiler.