I was a little disappointed that Factor[1] didn't get a mention in the 'Concatenative' section. Its stack effect checker takes care of a lot of the problems he mentions, IMO. 1: factorcode.org
Postscript is another excellent example of the type.
Programming paradigms that change how you think about coding
61–70 of 206 posts
Re: Programming paradigms that change how you think about coding
#62Some notes: - parallel and concurrent are 2 different things - the 'symbolic languages' definition seems off. Wikipedia puts it right: > symbolic programming is computer programming in which the program can manipulate formulas and program components as data So it's not "using graphs & such to program"
> parallel and concurrent are 2 different things That should be an implementation detail as far as the programmer is concerned. And languages should strive for parallelism anyway, not merely concurrency.
The idea that parallel code is executed through a concurrency mechanism should be hidden, but it doesn't mean that the distinction between the two should be.
http://existentialtype.wordpress.com/2011/03/17/parallelism-... http://existentialtype.wordpress.com/2014/04/09/parallelism-...
Re: Programming paradigms that change how you think about coding
#63A thought on dependent types:
Can a dependent type system catch all type errors at compile time? For example, suppose I write the following (in pseudo-code):
// Variable x is an integer greater than or equal to 0 and less than 256.
int x (>=0, int x (>= 0, // x is a value that is either 1) an int from 0 to 10, or 2) nothing at all.
maybe (int (>= 0, = 0, Either way, applyConstraint would be required any time a computation could return an invalid value. That would get tricky, because the compiler would have to track the constraints on every variable, even where those constraints aren't declared. For example:
int w (>= 0, = 0, = 0, Do any languages currently take the idea this far (or farther)?
Re: Programming paradigms that change how you think about coding
#64I wish APL/J/K were on here, but I guess that doesn't really change the way I think about coding... it just blows my mind.
Re: Programming paradigms that change how you think about coding
#65Isn't "Dependent types" just re-inventing how Fortran handles non allocatable array and character variables i.e. those who's length is declared at compile time using a parameter?
It's a bit more than that. Let's assume Vector is a typed list type of know length
[1,2,3] : Vector 3 Int
append : (Vector n a, Vector m a) -> Vector (n + m) a
Here's another (slightly pathological) dependent type. Normally `if` statements require that the then and the else branches result in the same type, but in a DT language you can write
if' : (cond : Bool) -> a -> b -> (if cond then a else b)
Both of these examples would be proud to call themselves trivial. The DT rabbit hole goes very deep.
Re: Programming paradigms that change how you think about coding
#66In the "concurrent by default" section I would add the hardware description languages like VHDL and Verilog. Learning Verilog was an eye opening experience for me. It reminded me of the time I switched from unstructured BASIC to C when I was a kid. At first it seems complex and weird then suddenly it clicks and it all starts making sense.
It also kind of reminded me of Pi calculus (http://en.wikipedia.org/wiki/Pi_calculus). It's pretty fun to play around with and try to understand and replicate those examples on the page.
Re: Programming paradigms that change how you think about coding
#67A thought on dependent types: Can a dependent type system catch all type errors at compile time? For example, suppose I write the following (in pseudo-code): // Variable x is an integer greater than or equal to 0 and less than 256. int x (>=0, I can imagine how a compiler could catch that kind of error. But that's trivial. What happens in programs like this: int x (>= 0, Now the compiler can't know for sure whether t…
Yes, Depently Typed languages can. They are full blown theorem provers...
Re: Programming paradigms that change how you think about coding
#68A thought on dependent types: Can a dependent type system catch all type errors at compile time? For example, suppose I write the following (in pseudo-code): // Variable x is an integer greater than or equal to 0 and less than 256. int x (>=0, I can imagine how a compiler could catch that kind of error. But that's trivial. What happens in programs like this: int x (>= 0, Now the compiler can't know for sure whether t…
Your idea about `maybe (int (>= 0, In a DT language when you express such a type the compiler will demand that you write a type like maybe which can fail at runtime and demand that you handle that failure.
To the compiler, `int` and `int (>= 0, To you final point about tracking constraints, even those defined implicitly, I think the answer is no-ish. Most frequently, DT languages have such a richness of types that there's no way to infer them—you're forced to write out all of the top-level types. But the idea of passing around constraints like you're suggesting here is not impossible.
You might imagine a pair type like (in no particular notation)
(x, x => [Constraint])
Re: Programming paradigms that change how you think about coding
#69A thought on dependent types: Can a dependent type system catch all type errors at compile time? For example, suppose I write the following (in pseudo-code): // Variable x is an integer greater than or equal to 0 and less than 256. int x (>=0, I can imagine how a compiler could catch that kind of error. But that's trivial. What happens in programs like this: int x (>= 0, Now the compiler can't know for sure whether t…
[deleted]
Re: Programming paradigms that change how you think about coding
#70LabVIEW is concurrent by default; control flow is done by linking the outputs of one function to the inputs of another. This makes writing concurrent loops ridiculously easy: just put two loops next to each other. I rarely use it because organization is such a pain, but its "data-flow" paradigm does simplify a lot of logic.
Happy to see another LV user here.
Organization gets much, much easier once you get the big architecture concepts - produce/consumer patterns, messenger-queues, event structures, actor framework. Yes, it can be painful, but the newer functionalities (clean-up, riddiculously easy sub-vi creation,..) subtly improve it.
Btw: If you are using LabVIEW and have never used Quickdrop, try it. It is the most underutilized and amazing feature.