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

171–180 of 206 posts

Re: Programming paradigms that change how you think about coding

#171

Post by seanmcdirmid »

rybosome wrote: post #153
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…

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

Explicitly manipulating events as a stream has performance problems; mainly time leaks. Another issue is that it makes debugging really difficult, as you've now converted much of your control flow (that you could step through) into data flow (that you cannot), while there is very little progress on building good data flow debuggers.

Finally, events are often manipulated in very tricky ways. Take the problem of implementing a drag adapter: you have to remember to capture the mouse on the down event and release your capture on the up event, but then you also need to capture widget and mouse positions on the down event so you can compute deltas that avoid sampling resolution problems on the move events. Rx always gets these two points wrong, which is very annoying, but they have to fudge it otherwise event stream processing can't win in elegance.

Re: Programming paradigms that change how you think about coding

#172

Post by ufo »

leoc wrote: post #120
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. IIRC dependently-typed languages dodge this bullet by not being completely Turing-complete (as 'twere).

The real way dependently typed languages dodge the undecidability problem is taht they "give up" on some valid programs. The output of the typechecker is either "proved the program is correct", "proved the program is incorrect" or "incondusive". If the result is "inconclusive" then it means that the programmer needs to manually provide a proof of correctness.

Re: Programming paradigms that change how you think about coding

#173

Post by [deleted] »

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…

[deleted]

Re: Programming paradigms that change how you think about coding

#174

Post by Ralith »

chriswarbo wrote: post #142
leoc wrote: post #120

Earlier quoted context omitted.

> I'm probably not clever enough, but someone could probably prove that'd be equivalent to solving the halting problem. It seems impossible. IIRC dependently-typed languages dodge this bullet by not being completely Turing-complete (as 'twere).

Not quite. Many dependently-typed languages aren't Turing-complete, but that's no how they 'dodge this bullet'. Think about the following Java code: public int getMyInt() { return getSomeOtherInt(); } How hard does Java have to work to figure out whether getMyInt is well-typed? Does it have to solve the halting problem? No. It just checks the information that you have given it. If you wrote that getSomeOtherInt has r…

You can compromise on turing-completeness, too. Idris, for example, lets the programmer decide whether a given definition should be required to provably terminate or not.

Re: Programming paradigms that change how you think about coding

#175

Post by Solarsail »

seanmcdirmid wrote: post #170
segmondy wrote: post #157

Earlier quoted context omitted.

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…

APL is far from dead, there is a lot of living legacy code and old timers with APL skills still actively using it commercially. 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.

Well, if you're only looking for logic languages instead of Prolog itself, then there's http://www.princexml.com/ written in Mercury.

Re: Programming paradigms that change how you think about coding

#176

Post by jroesch »

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…

Prolog is an interesting exercise and occasionally useful as a tool, but most implementations leave a lot to be desired as a general purpose programming language. An example of this is SWIPL's 3 string types and their crazy behavior. You are also stuck in a first order language that is essentially pure, and have no abstractions for common patterns except meta programming which makes code even more difficult to reason about.

That being said I love having logical variables and I would love having them in other situations.

Re: Programming paradigms that change how you think about coding

#177

Post by seanmcdirmid »

Solarsail wrote: post #175
seanmcdirmid wrote: post #170

Earlier quoted context omitted.

APL is far from dead, there is a lot of living legacy code and old timers with APL skills still actively using it commercially. 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.

Well, if you're only looking for logic languages instead of Prolog itself, then there's http://www.princexml.com/ written in Mercury.

Of course. Datalog also gets alot of use in industry.

Re: Programming paradigms that change how you think about coding

#178

Post by mindcrime »

singold wrote: post #149
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…

How/where do you recommend to learn prolog? The concept looks really interesting and useful, at least for me.

There are a lot of good Prolog resources on the web. I gathered up a little list some time ago. You can find it here:

http://fogbeam.blogspot.com/2013/05/prolog-im-going-to-learn...

Re: Programming paradigms that change how you think about coding

#179

Post by rybosome »

seanmcdirmid wrote: post #171
rybosome wrote: post #153

Earlier quoted context omitted.

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

Explicitly manipulating events as a stream has performance problems; mainly time leaks. Another issue is that it makes debugging really difficult, as you've now converted much of your control flow (that you could step through) into data flow (that you cannot), while there is very little progress on building good data flow debuggers. Finally, events are often manipulated in very tricky ways. Take the problem of implem…

I haven't done any serious FRP, but thinking about your example of the drag adapter, wouldn't it be possible to do something like the following?

  - Declare a stream consisting of the composite of two stream: a mouse down and a mouse up
  - Map over the mouse down portion, transforming into an (x, y) coordinate
  - Map over the mouse up portion, transforming into an (x, y) coordinate
  - Produce a tuple of the two values
  - Use the resulting signal that determines what to do with the drag
In Bacon.js, I think it would look something like this (haven't tested it):

  var makeCoordinate = function(v) { return {x: v.clientX, y: v.clientY}; }
  var mergeStreams = function(v1, v2) { return {down: makeCoordinate(v1), up: makeCoordinate(v2)}; };

  var $html = $('html');
  var mousedownStream = $html.asEventStream('mousedown');
  var mouseupStream = $html.asEventStream('mouseup');
  var dragStream = mousedownStream.flatMap(function() {
    // Ensure that we only sample a single mousedown/mouseup pair.
    return Bacon.zipWith([mousedownStream, mouseupStream], mergeStreams).
        takeUntil(mouseupStream);
  };
I don't mean to be pedantic - your point is well taken. This was definitely a mental exercise to write, and I have no experience debugging (though I imagine it would be difficult).

EDIT: For this particular example I actually made it more complicated than it needs to be. Example JS Fiddle here: http://jsfiddle.net/w6mCK/

Re: Programming paradigms that change how you think about coding

#180

Post by adwn »

marcosdumay wrote: post #154
adwn wrote: post #25

Earlier quoted context omitted.

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

No, it's a problem of the language. If the tools wanted to avoid this problem, they'd be non-compliant.
Post reply on HN