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

Why programming languages matter [video]

youtube.com

Post reply on HN
Print view View original

101–110 of 129 posts

Re: Why programming languages matter [video]

#101

Post by nonameiguess »

justinpombrio wrote: post #74
pdimitar wrote: post #52

Earlier quoted context omitted.

I wouldn't say it's trivial but yes it's there and it's very helpful.

There are many cases where you can replace a call to `.iter()` in your Rust code to a call to `.par_iter()` from `rayon`. Those cases are trivial, and it's great.

That's a very nice feature but I don't know that it belongs in the category of new ideas from programming language theory. Fortran 90 had automatically parallelized language constructs and OpenMP added them to C and C++ as compiler intrinsics in 2002.

Re: Why programming languages matter [video]

#102

Post by matheusmoreira »

pdimitar wrote: post #83
matheusmoreira wrote: post #81

Earlier quoted context omitted.

I made my own lisp because it was the simplest, easiest language to parse and implement. Lisps are essentially frontends for C data structures. I wanted to get some ideas working and that was the easiest way. Still one of the most fulfilling projects I've made. > We should start folding some languages inside others. (Or abandon them.) Who's "we" though? No one decides what we work on unless they pay us for that privi…

We who want to achieve stuff, not play all our careers. :/

What's the difference between play and achievement? Someone running the so called "toy" in the production server?

Re: Why programming languages matter [video]

#103

Post by gumby »

medo-bear wrote: post #100
gumby wrote: post #95

Earlier quoted context omitted.

the idea that a byte was 8 bits and not some dynamic length bitstream took at least 20 years, so don't get too excited. So many ideas from Lisp have slowly become mainstream (lambdas, closures, GC, interpreters with dynamic typing, languages both interpreted and compiled...) that I feel like any convergence is far off.

repl based development, or until people see how cool structural editing really is

Agree on the REPL and exploratory programming!

But can’t agree on the structured editing side.

I used to do use structured editing (D-Edit on the Interlisp-D machines) and found it annoying, but perhaps that was due to the mandatory mouse use. The structured editing built into emacs is pretty good mainly because it’s an option you can use at any time rather than a single paradigm.

Also the only way to use comments in a structure-based system is to extend the syntax of the language, and that is awful IMHO.

Re: Why programming languages matter [video]

#104

Post by pdimitar »

matheusmoreira wrote: post #102
pdimitar wrote: post #83

Earlier quoted context omitted.

We who want to achieve stuff, not play all our careers. :/

What's the difference between play and achievement? Someone running the so called "toy" in the production server?

You can put a program with 50 lines and 10 bugs in production. :)

To me "production" also means "runs reliably over long periods of time, does not fall over under load, and has no unexpected panics". Well, and also "makes full use of the available computing resources and prevents lag as much as possible".

"Toy" is basically "I am such a huge fan of LISP, I am convinced that the world absolutely needs one more interpreter!".

Re: Why programming languages matter [video]

#105

Post by wredue »

epgui wrote: post #64
wredue wrote: post #54

Earlier quoted context omitted.

Functional programmers regularly claim: -Haskell is faster than C (lol) -FP gives you free concurrency -FP makes code more testable -FP is easier to read -FP is easier to consume for people -FP results in no bugs -FP is easier to change -FP will literally suck your peepee -Actually FP is the second coming for Christ It’s really funny how you also pretend you’ve never heard of all the silver bullet claims that are inc…

I agree with some of these points, but none of them are claims I made in the context of this discussion, so I’m not sure why you’re even arguing about those. It’s irrelevant.

They’re false claims. And I didn’t bring up the false claims FP programmers make until you asked for it to happen. I simply said that rejecting the ridiculous silver bullet claims that FP programmers make is completely fine because they don’t provide any evidence and that which is asserted without evidence can be dismissed without it.

Not that that matter because all of those claims are demonstrably false anyway!

Re: Why programming languages matter [video]

#106

Post by kaba0 »

charcircuit wrote: post #15
epgui wrote: post #14

Earlier quoted context omitted.

Except for all the research around functional programming? This is like when I hear people claim that physics has not advanced in the last 50-70 years.

Functional programming is not based off how hardware is implemented. Serial execution of instructions and mutating chunks of memory at a time are all core parts of how the hardware works which aren't functional. Doing graph reduction and making tons of copies will be slow.

Are we still doing this stupid ass reasoning around FP? Is the CPU really that serial, when it literally reschedules your instructions based on the graph of their interconnections?

Also, just think about all the optimizations your "serial" programming language does -- are your yourself really write all those mutations? Or is that the compiler, that in many cases can do a much better job? Now what if the language's semantics allowed even more freedom for the compiler in exchange for more restrictions on the language? Sure, we still don't have "sufficiently advanced compilers" that would replace programmers, but FP languages absolutely trade blows with most imperative languages in many different kinds of problems. Very visibly when parallelism comes to the picture, as it turns out, a smart parallel-aware data structure will easily beat out their serial counterparts here.

Re: Why programming languages matter [video]

#107

Post by kaba0 »

wredue wrote: post #24
sidlls wrote: post #19

Earlier quoted context omitted.

"FP" camps tend to come in two flavors: "I'm a mathematician writing a computer program, and all problems will be made to look like math problems even if it means the program becomes an inscrutable mess of types and dense syntax" and "functional-ish idioms are included". The latter is useful, sometimes, for cloud computing and parallel computation; the former tends to have too many problems (slow build, slow executio…

Is “wanting evidence for constant silver bullet claims that never actually pan out” really “obviously biased”? It’s not just you. Functional Programming really does not adequately solve any of the problems that its advocates claim while refusing to provide any evidence. And it’s not “biased” to write these claims off.

Then why has it been slowly incorporated into literally every mainstream PL? You do know you don't have to be an extremist, and your code can contain both FP, OOP and imperative parts, whichever makes the most sense? FP and OOP are not even opposites.

They absolutely solve real issues, and it's just sticking your head into sand to say otherwise.

Re: Why programming languages matter [video]

#108

Post by kaba0 »

corinroyal wrote: post #91
arzke wrote: post #47

Earlier quoted context omitted.

> Referential transparency is related to the concept of "function purity" (in the sense that either one usually guarantees the other), which you will often hear people talk about as well. Isn't referential transparency (the property of a function that allows it to be replaced by its equivalent output) a consequence of function purity? In other words: could a pure function not be referentially transparent? Also, I rem…

"Could a pure function not be referentially transparent?" Yes there are pure functions which are not referentially transparent. A pure function with side effects, such as printing a result to standard output, is not referentially transparent. You can't replace the function with it's return value, since that doesn't replicate the printing side effect.

A pure function is by definition side-effect free. What you write makes 0 sense. Maybe thinking of total functions?

But not all FP languages have to be so puritan to only allow pure functions, most have escape hatches and it is just good form to prefer purity (even in more mainstream languages!). The most common way to circumvent this problem is through a Monad, which very naively put, just a description of the order of side-effecting functions, and their inter-dependencies. This will later get executed at a specific place, e.g. the main function -- the point is, that a large part of the code will be pure, and much easier to reason about.

Re: Why programming languages matter [video]

#109

Post by kaba0 »

Chris_Newton wrote: post #90
AnimalMuppet wrote: post #50

Earlier quoted context omitted.

Well... if code were pure (in the FP sense), then a "sufficiently smart compiler" could move it around to extract the maximum performance. But, as always, the sufficiently smart compiler never shows up. So we're left with the humans doing the tuning, and as you say, FP is kind of antithetical to that approach.

But how will language performance evolve as the nature of the hardware our programs run on evolves? IMHO this is not an easy question to answer right now. C compilers don’t produce 100% optimal assembly language in all cases, but typically the assumptions they make are light. The executable code they output is somewhat predictable and often close enough to hand-optimised assembly in efficiency that we ignore the diff…

> C compilers don’t produce 100% optimal assembly language in all cases, but typically the assumptions they make are light. The executable code they output is somewhat predictable

Lol, since when? C compilers literally will run some of your code at build time, and only write the results into the binary and they do all sort of crazy "mental gymnastics" to make people believe it is still a dumb single-pass compiler.

Re: Why programming languages matter [video]

#110

Post by roenxi »

wredue wrote: post #54
epgui wrote: post #26

Earlier quoted context omitted.

I don't know what "silver bullet" claims you've heard, but I'm not sure how that is relevant to this thread. I don't think I've made any outlandish claims, or any claims that aren't substantiated by a preponderance of academic literature.

Functional programmers regularly claim: -Haskell is faster than C (lol) -FP gives you free concurrency -FP makes code more testable -FP is easier to read -FP is easier to consume for people -FP results in no bugs -FP is easier to change -FP will literally suck your peepee -Actually FP is the second coming for Christ It’s really funny how you also pretend you’ve never heard of all the silver bullet claims that are inc…

> -FP will literally suck your peepee

> -Actually FP is the second coming for Christ

On a style point, you've rather undermined yourself that these are common claims because there are entries on this list that are clearly fabricated, as well as others that look like wilful misinterpretations of what someone else said. That casts doubt on the more reasonable entries. There are annoying FP evangelists out there, but the overall tone pattern matches straw-manning.

You'd have made it easier for everyone taking the whole list seriously. Transparently mixing fact and fiction just makes it harder for people who aren't already part of a conversation.

Post reply on HN