Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Programming paradigms that change how you think about coding

brikis98.blogspot.com

Post reply on HN
Print view View original

151–160 of 206 posts

Re: Programming paradigms that change how you think about coding

#151

Post by saosebastiao »

segmondy wrote: post #131
saosebastiao wrote: post #103

I'm a huge fan of the declarative programming paradigm, but outside of Regexp and SQL and a handful of other DSLs, it's dead. Its death should be a case study in Open Source strategy: It died because it became boring before it became useful. SQL and Regexp have stuck around because they did something useful immediately. I think that any future that the Declarative paradigm has within general purpose languages is the…

You are very mistaken. Prolog is still very much alive. You can find us on ##prolog in freenode. You can build a web application with prolog. When the 2048 madness was going on, I implemented in prolog in about 200 lines in 2 hours and I had about 3 weeks of prolog under my belt at that time. It's a very powerful concept. I didn't have to figure out the how to implement it, I just broke 2048 down into rules, declared…

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.

Re: Programming paradigms that change how you think about coding

#152

Post by jessaustin »

mnarayan01 wrote: post #95
arh68 wrote: post #92

Earlier quoted context omitted.

> Can a dependent type system catch all type errors at compile time? I'm probably not clever enough, but someone could probably prove that'd be equivalent to solving the halting problem. It seems impossible. > because the value of getKeyboardInput could be anything That makes my brain hurt. I think implicitly narrowing the type is stylistically better. Maybe just adding a dependent type declaration: x = (parseInt(get…

> I'm probably not clever enough, but someone could probably prove that'd be equivalent to solving the halting problem. It seems impossible. Guessing you're plenty clever...just didn't think about it enough :) Simply transform a program into one which halts on a type error rather than whatever else it might be doing. Done.

This proof is missing a few steps, at least if it's meant to convince slow thinkers like myself. b^)

Re: Programming paradigms that change how you think about coding

#153

Post by rybosome »

ibdknox wrote: post #124
AlexanderDhoore wrote: post #121

The aurora language seems very interesting. Too bad there is already another language called Aurora... I makes me think of Elm [1] and (functional) reactive programming. Reactive programming is fantastic. It's kind of like how a spreadsheet program works. If a variable changes, all variables who depend on it change as well. Given "a = b + c", if c increments by 1, so does a. It has many advantages over event based sy…

we're actually in the process of changing the name :) EDIT: re FRP, you might find this Lambda The Ultimate post insightful: http://lambda-the-ultimate.org/node/4900 FRP has issues with openness and isn't real great at dealing with collections. It also forces you to express things kind of unnaturally (e.g. instead of "click this and increment x", you say "the counter is the count of all click events"). There are othe…

"It also forces you to express things kind of unnaturally (e.g. instead of 'click this and increment x', you say 'the counter is the count of all click events')"

I suppose it's personal preference, but I actually think that the latter of the two statements is much more understandable. This is why I like functional programming in general; a single value can be expressed as a declarative transformation of other pieces of data, making it clear how the value is derived. Using the imperative model, it's up to variable names and documentation to make it clear what 'x' is. It's like looking at one of those pictures that contains multiple shapes simultaneously; suddenly you see the one you haven't been seeing, and then you wonder how you didn't see it all along.

Re: Programming paradigms that change how you think about coding

#154

Post by marcosdumay »

adwn wrote: post #25
simias wrote: post #2

In 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.

... and then suddenly you realize what a horrible, horrible language it is. I'm not exaggerating, it isn't even well-suited for the domain it is mainly used for (i.e., designing digital hardware circuits). For example: 1) Synthesis/simulation mismatch: Your design might work in simulation but not in hardware, and vice versa . Often, this is due to X-value (representing unknown/invalid values) problems. 2) Signed data…

Well, #1 is a problem of the tools, not the language.

Re: Programming paradigms that change how you think about coding

#156

Post by RogerL »

jarrett wrote: post #63

A 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…

In Ada you have subtype, so you would write

subtype my_type is Integer range 0..10; my_type x = 9; my_type y = 10; my_type a = x + y;

So, obviously there is enough information to deduce at compile time that the sum operation yields an incorrect value. In practice, as many of the replies point out, you can determine no such thing (my_type x = user_input()).

In that case Ada will throw a runtime exception. All this checking is expensive, so it ends up being much like C/C++, where you have debug and release builds, where the release builds do not do the checking.

Re: Programming paradigms that change how you think about coding

#157

Post by segmondy »

saosebastiao wrote: post #151
segmondy wrote: post #131

Earlier quoted context omitted.

You are very mistaken. Prolog is still very much alive. You can find us on ##prolog in freenode. You can build a web application with prolog. When the 2048 madness was going on, I implemented in prolog in about 200 lines in 2 hours and I had about 3 weeks of prolog under my belt at that time. It's a very powerful concept. I didn't have to figure out the how to implement it, I just broke 2048 down into rules, declared…

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 Prolog.

I might be wrong, but I think where the logic community failed is in taking advantages of multiple processors. Goals can be broken down and shared across multiple core/processors. So without changing code, the same program can be parallelized. It's just seems no one has implemented it yet.

Re: Programming paradigms that change how you think about coding

#158

Post by jamii »

AlexanderDhoore wrote: post #130
ibdknox wrote: post #124

Earlier quoted context omitted.

we're actually in the process of changing the name :) EDIT: re FRP, you might find this Lambda The Ultimate post insightful: http://lambda-the-ultimate.org/node/4900 FRP has issues with openness and isn't real great at dealing with collections. It also forces you to express things kind of unnaturally (e.g. instead of "click this and increment x", you say "the counter is the count of all click events"). There are othe…

Well, I'm not a fan of the "use folds over time" concept either. FRP is too complex, but there's some great ideas there. Would you say Aurora and these other languages are "reactive"? Or do you have a better term for it? BTW: I'm reading "Toward a better programming" right now :)

Our current design takes a lot of ideas from Functional Relational Programming (http://shaffner.us/cs/papers/tarpit.pdf) and Bloom (http://bloom-lang.net/) as well as building on the ideas from Light Table.

Re: Programming paradigms that change how you think about coding

#159

Post by evincarofautumn »

untothebreach wrote: post #43

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

“Stack checking” is definitely the ticket to maintainable stack programs. I have been working on a statically typed concatenative language called Kitten[1] off and on for a while, and while the error messages leave something to be desired, they can at least help you understand how data is flowing through a program, and of course rule out some bugs.

[1]: http://github.com/evincarofautumn/kitten

Re: Programming paradigms that change how you think about coding

#160

Post by Someone »

dllthomas wrote: post #123
Kutta wrote: post #119

Earlier quoted context omitted.

Both Idris and Agda check whether functions provably terminate. Halting problem notwithstanding it is possible to have conservative checks that never return false positives, so that an OK from the checker implies termination, but a FAIL doesn't imply non-termination. Idris is not total by default, so it is not required that all functions pass the termination check. However, when Idris does the type checking it has to…

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 the way: compilers for languages such as Java and C# do something similar: they reject all programs that may use a variable before a value is assigned to it, at the price of rejecting some programs that properly assign a value to each variable before use on the grounds that the compiler cannot prove it. Typically, the language specification describes exactly how smart compilers can be (or rather, how stupid compilers must be) when checking this, to ensure that all compilers agree about what programs are valid.

Post reply on HN