Live data from Hacker News

Near Future of Programming Languages [pdf]

dev.stephendiehl.com

141–150 of 306 posts

Re: Near Future of Programming Languages [pdf]

#141

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.

Re: Near Future of Programming Languages [pdf]

#142
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…

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

Presumably animats is talking about things like "do notation" in Haskell, not innocuous cases of function composition or first-class functions in imperative languages.

Re: Near Future of Programming Languages [pdf]

#143
Well this person sure seems very angry and opinionated, yet there's hardly any justifications for his criticisms in this childish rant. I mean if you're going to say everything is "dumb", and "shit" and whatnot, at least tell us why. As it stands this is definitely a case of "maximal opinions and minimal evidence".

Re: Near Future of Programming Languages [pdf]

#144

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

Was the talk recorded?

Re: Near Future of Programming Languages [pdf]

#146
post #60

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

I just don't experience these problems since I moved to functional style; I find it hard to remember that they even existed. Separate state from logic, separate initialization from operation, and you never have problems with initializing state. If your logic needs to perform effectful operations, separate that out using a monad. Good code structure for production is the same as good code structure for testing, because the needs of code structure are the same in both cases.

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]

#147
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

Re: Near Future of Programming Languages [pdf]

#148
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…

Multi threaded + async isn't a problem if the runtime system supports it.

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]

#149
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…

My son. You don't choose parallelism. Parallelism chooses you.

Re: Near Future of Programming Languages [pdf]

#150

Earlier 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.

Unless you want logging with timestamps.
Post reply on HN