Dynamic analysis + machine learning could become next-generation coding: https://maierfelix.github.io/Iroh/
Near Future of Programming Languages [pdf]
81–90 of 306 posts
Re: Near Future of Programming Languages [pdf]
#82Re: Near Future of Programming Languages [pdf]
#83This could be titled "Static typing is not going to save you"? There's nothing but static typing languages and related theorem provers from the timeline slide onwards and the conclusion is that it's too hard. This is a good companion piece for the recent Rich Hickey Clojure/Conj talk :)
I don't really see where you get that. Is dynamic typing demonstrating a lot of sustainable success?
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.
Re: Near Future of Programming Languages [pdf]
#84OCaml is as "industrial" as Haskell is.
Re: Near Future of Programming Languages [pdf]
#85Earlier quoted context omitted.
Huh, TIL. As a non-native English speaker, I have always pronounced "route" as "raowt", probably influenced by the pronunciation of "router". Btw, why is it "pronUnciation", but "pronOUced". English is hard.
> Btw, why is it "pronUnciation", but "pronOUced" In Australian English, it is "pronOUNCiation"
A quick Google didn't supply any supporting evidence. Do you know of a reference?
Re: Near Future of Programming Languages [pdf]
#86"Where will the next great programming language come from?" Interestingly Scala has come from Academia, Industry, and Hobbyists. And for me it's already the next great programming language. Yeah, it has some warts and is hard to learn but that's true of all great things. :)
Yeah this comment stuck out to me in the presentation. Industry has a great record of creating + supporting languages. C#, F#, Dart, Swift, Rust, D are all languages that are actively supported by industry, and some were even created by industry too. Just seemed like a weird statement for the slides to say that new languages just aren’t going to appear.
Re: Near Future of Programming Languages [pdf]
#87One area I haven't seen any good solutions for is the interleaving of tests with production code. I think we need better ways to express tests without cluttering the production code and excessive mocking. What I'd like to do, and really can't in any language/tooling that I know of, is to extract some arbitrary subset of the code and surround it with tests or a test harness. I'd also like to specify various injection…
[deleted]
Re: Near Future of Programming Languages [pdf]
#88Earlier quoted context omitted.
> Btw, why is it "pronUnciation", but "pronOUced" In Australian English, it is "pronOUNCiation"
A quick Google didn't supply any supporting evidence. Do you know of a reference?
That that's how it's pronounced in Australia? I don't know of any specific reference, it's just what I know from being familiar with Australian pronounciation (it's where I was born and live).
BTW, in case there has been some confusion here, since the topic was how things were said, I have been assuming this is what the person I was replying to was talking about, not spelling.
Re: Near Future of Programming Languages [pdf]
#89Things 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…
I disagree with a few of your thoughts, but they're good thoughts!
* Javascript everywhere is a function of low barrier-to-entry for it, but almost everybody agrees it is flawed as a language. If that's the future, we are screwed as an industry. One thing I've noticed (and I say this as a guy who wrote Ruby for 10+ years), is that type safety is becoming a hugely desired feature for developers again.
* WYSIWYG web design (a la Dreamweaver) died off a little because the tools saw a web page as standing in isolation. We know however that isn't interesting on its own - it needs to be hooked up to back-end functionality. Who is producing static HTML alone these days? In the case of SPAs it needs API integration. In the case of traditional web app dev, it needs some inlining and hooks to form submission points and programatically generated links to other "pages". Making that easier is the hard part - seeing a web document as an artefact of an output from a running web application container.
* Multi-threaded, event-driven, coroutine-type patterns are fine in Go, to my eye. What's making you think we can't mix this up with the right type of language and tooling support?
* Is it that we can't code well for CPU counts > 100 or that the types of problems we're looking at right now that need that level of parallelism tend to be targeted towards GPUs or even ASICs? I think I'd need to see the kind of problems you're trying to solve, because I'm not sure high CPU counts are the right answer.
* Talking to GPU-type engines is actually pretty simple, we will deal with it the same way we deal with CPU-type engines: abstraction through a compiler. Compilers over time will learn how to talk GPU optimally. GPU portability over the next 20 years will be a problem to solve as CPU/architecture portability was over the last 40.
Re: Near Future of Programming Languages [pdf]
#90Things 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…
> Functional is OK. Imperative is OK. Both in the same program are a mess.
I guess you're referring to languages that are not-quite-without-side-effects, but I'd say the biggest influence the functional paradigm has had on other (imperative) programming languages is actually the addition of higher-level data manipulation operations. The functional utility libraries you see for languages such as Python and JavaScript exist solely because sometimes functional idiom like "map this onto this" or "take that only if this holds" or "let's make a new function by pre-filling these function arguments" is more intuitive than having for loops all over the place. And it mixes just fine with other imperative code.