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.
Near Future of Programming Languages [pdf]
141–150 of 306 posts
Re: Near Future of Programming Languages [pdf]
#142Things 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…
Re: Near Future of Programming Languages [pdf]
#143Re: Near Future of Programming Languages [pdf]
#144Earlier quoted context omitted.
Outsystems and Jetbrains are these examples but on the other hand they are not; they are 'old'; they both exist since 2000 and at that time pushing into the market was a lot easier. I was more thinking of a company starting now, to which I'll check out Anvil.Works. There are more new companies working in the space, for sure, but they all miss the breadth that Borland had (they really had a lot of cash and developers…
Anvil founder here! The crucial difference between Outsystems(/Bubble/etc) and Anvil is that Outsystems tries to be a "no-code" environment, and we think that's a mistake (or at least, a different market). Delphi and Visual Basic proved that writing code isn't the problem - code is the best way to tell a computer what to do. But writing code in five different languages to produce "Hello World" on the web...now that w…
Re: Near Future of Programming Languages [pdf]
#145So are we just going to pretend Perl doesn't exist?
Re: Near Future of Programming Languages [pdf]
#146Earlier quoted context omitted.
Forgive me, this is going to sound snarky but I promise I am earnest: > I'd also like to specify various injection points for tests right as I'm writing the code You mean, like methods/functions? > extract some arbitrary subset of the code and surround it with tests You mean, like modules/classes?
Kind of, but three big problems in practice are: - runtime state you need to initialize if your code is written in a stateful manner - other methods/functions in different modules/classes the code you want to test calls out to - the fact that method/function and module/class separation is (and IMO always should be) primarily driven by needs of production architecture, not testing, means that it may not be perfect for…
Text substitution is impossible to reason about; magic test frameworks sound like a good idea because every kind of magic sounds like a good idea in isolation, but they'll always end up getting you in trouble. Plain old code, plain old functions, parameters, and modules, always win in the end, because every bit of brainpower you can save from understanding magic is brainpower you can spend understanding the details of your actual test instead.
Re: Near Future of Programming Languages [pdf]
#147Things 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'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?
Re: Near Future of Programming Languages [pdf]
#148Things 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…
Async + Event driven works transparently with higher order frp with the usual tradeoffs of first order vs higher order frp.
Multi threaded + Event driven seems like a mess as soon as state gets involved. Some transaction based system might be interesting.
Re: Near Future of Programming Languages [pdf]
#149Things 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…
Re: Near Future of Programming Languages [pdf]
#150Earlier quoted context omitted.
Great points, but I have a question about one of them in particular: > - Functional is OK. Imperative is OK. Both in the same program are a mess. What do you mean by that? My experience is that functional alone is impossible, since the only useful thing a program can do is through state changes; imperative is a-OK, and functional+imperative in the same program is the best way to do things (i.e. well-defined stateful…
> My experience is that functional alone is impossible, since the only useful thing a program can do is through state changes Some programs are simply pure functions. If your program entry point accepts a string and returns a string, then you can write useful things, such as compilers, image processing, grep, etc, entirely as pure functions.