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

Near Future of Programming Languages [pdf]

dev.stephendiehl.com

Post reply on HN
Print view View original

231–240 of 306 posts

Re: Near Future of Programming Languages [pdf]

#231

Post by stmw »

machiaweliczny wrote: post #136
kowdermeister wrote: post #83

Earlier quoted context omitted.

I've seen a comparison lately with static vs. dynamic languages and it compared bugs/open issues and there was not really an advantage there IIRC.

It's just my opinion, but there definitely is difference in favor of optional static typing. It simply adds more expressivness to language - you get free documentation standard (input,output,structures) backed in. You don't have annoying typos and you leave data manipulation computation to computer lowering programmer cognitive load. Also you can change code in editor(fastest feedback loop) without even running it(ve…

That, and also there are so many independent confounding factors in these comparison studies that I am not sure they can ever outperform reasoning or personal experience. The reasoning part in your comment - lowering cognitive load, faster feedback cycles (in editor, in compiler, etc.), fewer typo-induced problems - seems hard to argue with.

Re: Near Future of Programming Languages [pdf]

#232

Post by david927 »

ghthor wrote: post #141
david927 wrote: post #40

This is a brilliant synopsis of the state of the art -- truly fantastic -- and yet the presentation concludes with, "The innovation won't happen because I can't see where it will come from," and that's not entirely fair. Some areas he covers aren't exhaustively covered and what's missing is quite interesting. In other words, cheer up, there's more hope than what's shown here.

I think this is just a fustration with how little direct incentive there is from our economic system to fix the problem. The only chance of this paradigm existing is as a long shot project that is gifted to society, and the person that makes this gift has the slim chance that it doesn't succeed and all the effort is wasted.

The only chance of this paradigm existing is as a long shot project

I couldn't agree more but I also am not as pessimistic as he is at its chances of happening.

Re: Near Future of Programming Languages [pdf]

#233

Post by pron »

AnimalMuppet wrote: post #230
pron wrote: post #198

Earlier quoted context omitted.

> When your constraints mean that only the right thing can be done, you can make the thing implicit. Except that sometimes, when you think about the practical issue long and hard enough, you can find that some constraints need not be stated at all, and can be completely factored out of the language, at least in most cases. For example, GC removes resource management out of the equation (it's not always the right solu…

> If Idris is a big step ahead of Java, by how much do you think costs at, say, Google or Amazon or Citibank would drop if they decided they would all switch to Idris tomorrow? I'm fairly certain that it wouldn't be anywhere near 30%, and I'm not even sure costs wouldn't actually rise. How much would something like Idris lower costs at Experian? That is, in your "cost" metric, what weight do you assign to the cost of…

> How much would something like Idris lower costs at Experian? That is, in your "cost" metric, what weight do you assign to the cost of catastrophic bugs?

As a practitioner (and evangelist) of formal methods, you won't hear anything from me against the use of formal methods, although I have plenty of reason to believe that Idris (as an example of a particular design) is not very good at formal verification. The cost of bugs must be factored in, but we haven't seen the Idris approach effective at reducing bugs at a cost commensurate with their impact, except when their impact can be truly catastrophic. All the effective formal methods I know of look nothing like Idris.

As someone who has used formal methods to good effect (I believe) and is now learning Lean (which is can be put in roughly the same camp as Idris), I find it very interesting, but I cannot even imagine how it can form the basis for something that will one day be used at scale, especially given that there are such better alternatives.

Re: Near Future of Programming Languages [pdf]

#234

Post by pron »

lmm wrote: post #228
pron wrote: post #221

Earlier quoted context omitted.

> I don't see the need to do anything more radical. I do, because the things that you mostly value (I guess I value them a lot less) seem to me incredibly complex for the good that they do, and we already have some alternatives that seem both more powerful and vastly simpler. But I am skeptical of them, too, though :) > I think the industry switching to Idris-level languages will bring a factor of 10 to 100 improveme…

> That is a very powerful statement, and I'd like to know why you'd think that. I would even like to know what makes you think that any language (never mind which) can make such an impact, even though we've seen nothing of this sort. I think we have; I think we've seen dramatically accelerating programmer productivity. I think language improvements compound heavily: if a language is slightly more efficient in the sma…

> I think we've seen dramatically accelerating programmer productivity.

Really? I think that the change that has contributed to the lion's share of that boost has nothing to do with language features, and has everything to do with the availability of open-source libraries. The other major contributions have been the widespread adoption of automated unit tests -- also not a language feature, and the practicality of GCs -- if considered a language feature, it's a transparent one.

When Brooks said, around '85, I think, that we won't see a single improvement contributing to a 10x improvement within a single decade, people said he was pessimistic. After 30 years I don't think we've seen a 10x improvement with all methods combined, and if we have, most of it is due to libraries.

Do you think that writing, say, an ERP, a power-station control and management software or an air-traffic control system from scratch (without off-the-shelf/open-source libraries) today would be 10x less costly than it was using C++ in 1987, or even 3x less costly than using Java in 2002 (I'm taking 30 and 15 years respectively as milestones)? Remeber that 10x within a decade was seen as pessimistic.

Although I was just a novice programmer in 1987, I think that the answer to both is an emphatic no. Even when it comes to small/simple programs (which are a completely separate domain), I'm pretty sure that aside from the availability of libraries, Python doesn't have even a 3x factor over VB/Delphi/other "RAD" languages, as they were called way back when.

Re: Near Future of Programming Languages [pdf]

#235

Post by pron »

bjz_ wrote: post #204
pron wrote: post #191

Earlier quoted context omitted.

> Idris can often infer entire functions from their types if the domain is amenable to accurate type-based specification. This is a great example of what I'm talking about. The kind of functions Idris can generate is that of functions that you could manually write with only marginally more effort -- if that -- than the effort required to write the precise type. I don't think those functions ever form a significant po…

> If you've spent a significant amount of time with such proof assistants, you'd see that the proof search is rather pitiful. Afaik, Idris' proof search was hacked together in an afternoon just to see if it would work. And it did, surprisingly well considering. Don't know how much it has been worked on since then though. But yes, still leaves a bit to be desired compared to other systems.

I wasn't just talking about Idris. There isn't a single tool out there that can automatically prove that your quicksort implementation actually sorts without pretty significant work.

Re: Near Future of Programming Languages [pdf]

#236

Post by hwayne »

samcodes wrote: post #41

This is a great deck... but leaving TLA+ out of Formal Methods? It is hands down the most important thing going on there. And it is a combo between academia and industry. Amazon uses it extensively.

It also left out Alloy, which is another really exciting formal method that a lot of really cool work has been done in.

Re: Near Future of Programming Languages [pdf]

#237

Post by cestith »

chrisseaton wrote: post #145
jamesrom wrote: post #36

So are we just going to pretend Perl doesn't exist?

You can't expect 20-or-so slides to cover all languages. And I'm not aware of any PL research topics being explored in Perl, so not sure how talking about Perl would fit in.

Perl6 in its spec has auto-parallelization of at least the hyperoperators. It has hyperoperators themselves. It has full LL and LR grammars as part of the language. It has optional strong typing for support of incrementally typing your source. It has junctions. It has a native MOP. It has active metadata on all data types (values, variables, subroutines, and types themselves).

Beyond what might be purely PL research, there are some other neat ideas being explored. It does function currying, lazy evaluation, grapheme-level Unicode support, and custom operators from any Unicode grapheme.

It's definitely a language I'd be watching if I was writing about near-future languages.

Re: Near Future of Programming Languages [pdf]

#238

Post by kd0amg »

david927 wrote: post #40

This is a brilliant synopsis of the state of the art -- truly fantastic -- and yet the presentation concludes with, "The innovation won't happen because I can't see where it will come from," and that's not entirely fair. Some areas he covers aren't exhaustively covered and what's missing is quite interesting. In other words, cheer up, there's more hope than what's shown here.

The central claim isn't that innovation won't happen. It's that they won't go mainstream because nobody has both the means and motive for good tech transfer work.

Re: Near Future of Programming Languages [pdf]

#239

Post by Animats »

Twisol wrote: post #147
Animats wrote: post #78

Things to think about for the near future of programming languages: - The borrow checker in Rust is a great innovation. Previously the options were reference counts, garbage collection, or bugs. Now there's a new option. Expect to see a borrow checker in future languages other than Rust. - Formal methods are still a pain. The technology tends to come from people in love with the theory, resulting in systems that are…

> - Interprocess communication could use language support. I'm really interested in hearing more of your thoughts on this, since it touches on one of my personal research interests. What kind of language support for IPC are you looking for? Something in the vein of session types [1], which checks that two parties communicate in a "correct" sequence of messages? [1] https://dl.acm.org/citation.cfm?id=1328472

Lower level than that. Languages should have marshaling support. Marshaling is a low-level byte-pushing operation for which efficient hard machine code can be generated.

I'd suggest offering two forms of marshalling - strongly typed and non-typed. Strongly typed marshaling means sending a struct to something that expects exactly that struct. That will usually be another program which is part of the same system. Structs should be able to include variable-length items for this purpose, so you can send strings. Checking involves something like function signature checking at connection start. This should have full compiler support.

Non-typed marshalling includes JSON and protocol buffers. The data carries along extensive description information, and the sender and recipient don't have to be using exactly the same definition.

Both are needed. Non-typed marshalling is too slow for systems which are using multiple processes for performance. Typed marshalling is too restrictive for talking to foreign systems.

Post reply on HN