Live data from Hacker News

Near Future of Programming Languages [pdf]

dev.stephendiehl.com

301–306 of 306 posts

Re: Near Future of Programming Languages [pdf]

#301
post #260

Earlier quoted context omitted.

I was commenting on the beneficial influences from functional programming on mainstream languages, and noting that a purely functional programming style with no effects isn’t (IMHO) particularly necessary or desirable. I don’t know much about Rust so I can’t comment much on that. The intended point of my example was that in a purely functional environment, you can’t have a local, low-level cache, because updating a c…

Are there any languages you know of that are somewhat close to what you describe?

Unless I am misreading your question... Erlang / Elixir?

They are purely functional in the sense that NO VARIABLE inside your code can be ever mutable.

However, they do have ETS (which is an in-process cache inside the VM) which is fully mutable and people have long made wrapping libraries around it for transparently working with mutable arrays, double-linked lists, queues, matrices, graphs and what have you.

The philosophy basically is "always work with immutable data except when mutable is more performant or is otherwise more practical". They don't shut the door on you, they just force you to make your intention to work with mutable storage very explicit and clear. That helps a lot when you go hunting inside your code for side effects, too.

As a maturing Elixir dev I can say this philosophy works incredibly well in practice. Code is smaller, much more readable, you don't worry about side effects like ever -- except in very, and I mean VERY RARE occasions (for 1 year of working with it I only had to do that twice) -- and finding a bug is times faster compared to Ruby, Javascript, PHP, Java.

Re: Near Future of Programming Languages [pdf]

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

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…

Erlang / Elixir are 100% immutable inside the code (no var can ever be mutable).

However, they have a mutable in-process cache (living in the BEAM VM) that many people have written libraries around for stuff like mutable arrays, matrices, graphs, and many others.

It goes like this: do 99.5% functional programming and you have the imperative / stateful tools for when they are absolutely necessary.

This works. Extremely well.

Re: Near Future of Programming Languages [pdf]

#303
post #147

Earlier quoted context omitted.

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

I don't disagree but during my career I've found surprising amount of cases where ASN.1 and its practical encodings like DER, BER and PER work impressively well.

Human readability however has always been the selling point of terrible formats like XML and JSON.

Not sure how can a binary-compact format ever account for that. Maybe excellent cross-platform tools that allow you to inspect and modify the binary-compact format wherever it is? (I mean not only standalone CLI and GUI software; I also mean native browser support in the Dev Tools space and going down the line in the future -- transparent support for the format[s] natively in the programming languages / VMs themselves.)

Re: Near Future of Programming Languages [pdf]

#304
post #61

My thoughts are that we don't really need more languages. Arguably we don't need better ones either, because they aren't the problem in general computing. Instead we need better design paradigms that better let us model complex requirements and systems into code. Let's have new languages that then support those paradigms. We continue to struggle abstracting complex problems using functional decomposition, structured…

> A focus on programming languages in my opinion, masks the real issues we face. Indeed, major problems of programming languages can hardly be solved in the area of programming languages itself as it is being done now. I would say that one needs a new programming or computing model so it is not about languages. At least it is my conclusion after 10+ years of research and attempts to develop such a new programming par…

Doing such a huge research has to have phases of some sort. At certain point you should stop, re-evaluate, and say "okay, where I am at now is good enough to solve problems X and Y, most of the time".

Otherwise it's endless and one loses motivation.

Re: Near Future of Programming Languages [pdf]

#305

Earlier quoted context omitted.

I do find it a useful dichotomy because I work with people who evolve their code and wonder why I get my back up about monkey patching (because it's often my job to turn research or prototype quality code into reliable code). If you've ever had to make another person's research or prototype quality code more robust it can be easy to wonder how on Earth they work the way they do. Having this dichotomy in mind makes it…

Ah I see. So with 'sealed' you mean things like reproducible builds and being able to determine the exact set of sources, etc? The containerization movement is interesting - while having these 'sealed' virtual environments and reproducible system builds is the right direction, I'm amazed at the size and weight of each of these.

Sure. By sealed I mean you compiled the program, you might have a turing incomplete configuration (e.g. ini, toml, json) and you can reason about the program. And by evolving (or, I guess unsealed) you are in the process of editing the program. Or you monkey patch it when you run it.

But with things like LD_PRELOAD, different .so minor versions, etc, a compiled program suddenly straddles the categories. Hence my comment about reproducible builds and containerization.

Re: Near Future of Programming Languages [pdf]

#306

Earlier quoted context omitted.

Agree on the benefits of IDEs and REPLs. An IDE/language with integrated notebook-style REPLs might be useful too. Maybe you want to create parts of the system by interacting with a REPL (instead of writing a static block of text) - and then you'd want to record how you created this specific artifact. The other thing that would help, and my personal wish, is better simulation and the ability to see indirect effects o…

> Maybe you want to create parts of the system by interacting with a REPL (instead of writing a static block of text) - and then you'd want to record how you created this specific artifact. Yes, exactly. You get that with a REPL (e.g. Lisp or Python) and copy-pasting to the source code files, but it's far from ideal. > The other thing that would help, and my personal wish, is better simulation and the ability to see…

Yes, somewhat like these, but having the ability to inspect and simulate effects on intermediate forms and systems. So something along the lines of light table but being able to show more than just the immediate program.

Copying something I wrote in another thread: I want to see not just the immediate program I'm manipulating (text or otherwise) but also the implications - the affected parts of various other intermediate representations all the way to the running, live system that will be affected.

Post reply on HN