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

181–190 of 206 posts

Re: Programming paradigms that change how you think about coding

#181

Post by aidenn0 »

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.

I can write a compiler in 5 minutes that handles both #1 and #2. It returns no on every program. Therefore it always terminates and always returns "no" on every incorrectly typed program.

Re: Programming paradigms that change how you think about coding

#182

Post by tarblog »

humanrebar wrote: post #168
lolo_ wrote: post #21

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

I've used graphical programming in the past. It sounds amazing in abstract, but ends up being a mess when it is implemented. It basically requires a "sufficiently smart editor", which, even if implemented perfectly, would not leave a lot of room for a third-party ecosystem to be built around the language. There are many solved problems in text-based programming that would need to be resolved in order for a graphical…

The solution that comes to mind is that the graphical elements are backed by text for these purposes. Then, the graphical interface amounts to an editor for this meta-language.

Re: Programming paradigms that change how you think about coding

#183

Post by NathanOsullivan »

sergiosgc wrote: post #96

Where is Aspect Oriented Programming and all the other offspring of the Inversion of Control pattern (Dependency Injection, Dependency Inversion, ...)? Is this line of evolution in languages considered dead?

Came here to say the same thing. Learning about Inversion of Control utterly changed how I program on a day-to-day basis.

It may not be a language feature, but the things in the article seem rather academic by comparison.

Re: Programming paradigms that change how you think about coding

#184

Post by taliesinb »

seanmcdirmid wrote: post #169
taliesinb wrote: post #133

Earlier quoted context omitted.

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/

I'm not great at following markitecture, but didn't Mathematica exist and have a language before this language was rebraded as the Wolfram Language? There is nothing really wrong with this, but its understandable that people might be confused about it right now.

That's right, and what seems to be confusing people is that the language underlying Mathematica-the-product was always, implicitly, "Mathematica".

We were a one-product company, and it didn't make sense to distinguish Mathematica-the-product and the language it ran.

The last time we'd tried to branch the underlying language off into its own thing was in the early nineties, where a certain intern by the name of Brin was in the middle of refactoring the code before he went off to do other things :).

My prediction is that the confusion will pass soon once we have these concrete products actually out in the world.

A new generation of people will be using and seeing the language for the first time. And they'll be doing stuff that old-school Mathematica-the-product (and most of its user base) would find quite alien.

Things like trying code out in online sandboxes, coding things in the cloud IDE (or locally, via Eclipse or "Wolfram Desktop"), deploying public APIs for other people to use, building websites totally within the language, doing internet-of-things type stuff, embedding chunks of WL code in Java or Python or whatever, writing natural language parsers on top of Alpha's technology, creating data science workflows, making private clouds, designing interactive visualizations, tweeting code at our executor-bot... and on and on...

Re: Programming paradigms that change how you think about coding

#185

Post by seanmcdirmid »

rybosome wrote: post #179
seanmcdirmid wrote: post #171

Earlier quoted context omitted.

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

Compare with the control flow heavy managed time [1] version:

  on widget.Mouse.Down:
  | var pw = widget.position
  | var pm = widget.Mouse.Position
  after:
  | widget.Mouse.Capture()
  | widget.position = pw + (widget.Mouse.Position - pm)
  | on widget.Mouse.Up:
  | | widget.position = widget.position # freeze widget position
  | | break                             # stop the after block so capture/dragging stops
[1] http://research.microsoft.com/pubs/211297/managedtime.pdf

Re: Programming paradigms that change how you think about coding

#186

Post by untothebreach »

evincarofautumn wrote: post #159
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

very cool, I will definitely take a look at this

Re: Programming paradigms that change how you think about coding

#187

Post by JadeNB »

solomatov wrote: post #127
JadeNB wrote: post #76

Earlier quoted context omitted.

Gödel guarantees that full-blown theorem provers, even with human guidance, cannot prove all true statements about sufficiently rich systems. 'Sufficiently rich' here just means 'includes Peano arithmetic', and you can find tons of tutorials for doing just that (Church encoding) in even the simplest type systems. (This bit of pure-mathematics wonkery ignores the substance of jarrett's question, though; one doesn't ne…

>Gödel guarantees that full-blown theorem provers, even with human guidance, cannot prove all true statements about sufficiently rich systems. 'Sufficiently rich' here just means 'includes Peano arithmetic', and you can find tons of tutorials for doing just that (Church encoding) in even the simplest type systems. They don't prove theorems. You do this by writing a program.

Sure, but, regardless of agency, human or automated, it is still not possible to prove all true theorems. (The human / automated distinction comes in more sharply in the halting problem, where any potential halting decider will choke on some program that proveably terminates.)

Re: Programming paradigms that change how you think about coding

#188

Post by JadeNB »

cpa wrote: post #112
Dewie wrote: post #105

Earlier quoted context omitted.

I wonder; have mathematicians found something that they know with every fibre of their being is true, but that they can't prove? And do they then try to prove it in another formal system instead? Or do these unprovable-but-true facts mostly elude them, since they are operating in a formal system that 'hides' them?

Mathematicians say that formula F is true in system S iff one can find a proof of F in the context S. So truthness is always considered with respect to some system. Thus, there are no formula which is "true" but that one can't prove, by definition. (That's the kind of smartassery mathematicians like.) But the Godel's incompleteness theorem states that for all system that includes (Peano's) arithmetic, one can find a…

Words in mathematics mean what they are defined to mean, so there's no point arguing about the correctness of definitions. Yours is essentially the constructivist perspective on truth; but it is not the only one. It will declare that certain statements are neither true nor false, which some find distasteful.

A more model-theoretic approach says that a formula is true in a theory (not a system, although the word choice doesn't matter) if it is true in all models of that theory—a statement that can (in principle) be concretely verified simply by testing in each such model. Then it may (and will) be true that a statement is true in "all possible worlds", but that there is no way of proving it from the rules that constrain 'possibility'.

Re: Programming paradigms that change how you think about coding

#189

Post by noobiemcfoob »

vkjv wrote: post #24
bru wrote: post #3

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

If you want concurrent by default, try an HDL. :)

I had the same thought. I find it odd he didn't mention them.

Re: Programming paradigms that change how you think about coding

#190

Post by zenbowman »

hibikir wrote: post #146
archena wrote: post #52

Earlier quoted context omitted.

Why do you think SQL doesn't qualify? it's certainly not the only example of declarative programming, and maybe not the most interesting, but it is one which most developers have come across.

In theory, SQL is a declarative programming language, in practice, past the simplest of examples, there are dozens, if not hundreds of ways to ask the same question, and each one of them performs differently. The moment one starts to do things like add anonymous views, the declarative facade tends to disappear. Let's also remember that many companies stuck with big RDBMs systems have entire teams of people whose job…

Sure, but there is continuum here. It's not a binary decision.

For example, I consider the sublanguage in printf to be more declarative than the rest of C as well.

SQL as it stands, especially in contrast to what the existing models were at the time it was introduced, such as CODASYL.

SQL is the one language we use that somewhat operates at the level of thought.

Post reply on HN