Earlier quoted context omitted.
So that was "You can always just refuse to run any function [at] compile time that has not yet passed termination check."? All of this is certainly the case, and useful, and interesting. It doesn't contradict the point that 1) guaranteeing termination and 2) guaranteeing you return "no" on every incorrectly typed program are incompatible, which was approximately the original question.
"1) guaranteeing termination and 2) guaranteeing you return "no" on every incorrectly typed program are incompatible" You do need more bandwidth. Trivial counterexample (for any reasonable inference of the semantics of the source code of this made-up language): define isCorrectlyTyped( program P) as return "no". Of course, a practical version would have to have the function return "yes" on more valid programs :-) By…
Programming paradigms that change how you think about coding
161–170 of 206 posts
Re: Programming paradigms that change how you think about coding
#162Earlier quoted context omitted.
Agreed in general, but it is possible to enable this style of constraint propagation by being restrictive about what kind of contraints you can write. In particular, the "LIQUID" family of languanges that have been developed at UCSD allows properties which are conjunctions of LInear IneQUlites, and can infer them automatically. The programmer would annotate one declaration of a variable with a constraint like (0 Thei…
Yeah, less power means greater inference. You can model liquid types in a DT language I believe, but you'll never have the same convenience.
Re: Programming paradigms that change how you think about coding
#163Re: Programming paradigms that change how you think about coding
#164Earlier quoted context omitted.
Yeah, less power means greater inference. You can model liquid types in a DT language I believe, but you'll never have the same convenience.
"Dependent types" is a quite broad term. The Liquid types people certainly call their work dependent types, even though it has a different flavour than e.g. Coq or Agda.
Re: Programming paradigms that change how you think about coding
#165Earlier quoted context omitted.
>Basically, yes. If you want your type checker to be decidable, you're going to have to restrict the type language to be much smaller. In general, dependent types are undecidable to type check. In dependently typed programming languages like agda and Idris typechecking is decidable. You are wrong here.
You're right. I was being handwavey, and I apologize for that. Let me clarify my position: In theory yes, you're right, it is decidable. In practice Agda and Coq force you to prove pretty much everything about your program using expensive annotations, in order to satisfy the typechecker. It's like pulling teeth. The type checker must be taught that your program terminates, and it must be taught that you maintain even…
That's why we need gradual typing. Some critical parts should be written with full dependent types with termination checker, etc, but most of the code should be just type checked.
P.S. I have some dependent types experience, including applying Coq in commercial projects.
Re: Programming paradigms that change how you think about coding
#166The concurrent by default paradigm looks like it could be really useful for some cases. Does anyone know of any more well-used languages that support it?
http://hackage.haskell.org/package/monad-par-0.3.4.6/docs/Co...
Re: Programming paradigms that change how you think about coding
#167QML [1] is an interesting example of declarative programming. It allows constraints and relationships to be defined and the runtime will do the rest. Perhaps it's not as powerful as other languages but in its domain it does very well. [1] https://en.wikipedia.org/wiki/Qt_Modeling_Language
Re: Programming paradigms that change how you think about coding
#168I think an underrated non-standard approach to programming is graphical programming. Though this approach doesn't seem to received significant uptake amongst professional programmers, there is an application called max [0] that is popular amongst musicians and artists and quite surprisingly powerful and effective. There's an interesting article [1] on how Jonny Greenwood of Radiohead uses it extensively, in there you…
There are many solved problems in text-based programming that would need to be resolved in order for a graphical programming language to be as useful.
How would one post a "snippet" to StackOverflow? How would diffs work? Consequently, how would source code management work?
Re: Programming paradigms that change how you think about coding
#169Earlier quoted context omitted.
Mathematica[0] and The Wolfram Language[1] are two different things. The Wolfram Language is a sort of extension of their Wolfram Alpha service, which Wolfram itself describes as "Knowledge Based." Mathematica is still just Mathematica. [0] http://www.wolfram.com/mathematica/ [1] https://www.wolfram.com/language/
No. Mathematica is a commercial piece of desktop software that uses the Wolfram Language. Just like how RStudio uses R. There are other product platforms (coming soon) that employ the Wolfram Language, both in cloud and desktop incarnations: http://www.wolframcloud.com/
Re: Programming paradigms that change how you think about coding
#170Earlier quoted context omitted.
I never said it wasnt useful, I said that it was dead...much in the same sense as COBOL. I use datalog and constraint programming extensively, but I'm a black sheep.
It's not dead, until no one is using it. You can say APL is dead and I might believe you. So long as there's still people using prolog or other form of logic programming. It's not dead, all it needs is one killer application and everyone will jump on it. Erlang's popularity has surged since Whatsapp got acquired. Lots of people are learning about Erlang's root from Prolog and likewise getting somewhat curious about P…
Prolog on the other hand...I'm not aware of any commercial projects actively using it, but it is still alive as a hobbyist/learning language.