71–80 of 306 posts
Perhaps the future of programming isn't in linear deterministic code but in stochastic or probablistic languages dealing with machine learning or biology. Maybe we're hitting Godel/Turing-like wall and as we strive for more perfection and provable soundness, we will find we can't scale up to bigger and bigger systems. We'll be stuck with human debuggable linear languages like we have today or systems which operate mo…
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…
Much of the time, new languages lead to new design paradigms. As a general rule, newer languages are more abstracted than older ones. When people don't need to get hung up on the intricacies of low level programming, real progress can be made on the design paradigm front.
"One True Pairing"?
"Online Transaction Processing"?
probably not "On The Phone".
This is a great presentation, I wish I could hear the talk track. While we can all differ on the right "winner" for the next programming language (I don't think Clojure is the right answer, someone else might), we are all stuck with the same set of facts - and this covers the state of things very well. Most importantly, it explains certain truths of the social/economic ecosystem for programming languages - which is w…
"OTP" on p. 23? "One True Pairing"? "Online Transaction Processing"? probably not "On The Phone".
"OTP" on p. 23? "One True Pairing"? "Online Transaction Processing"? probably not "On The Phone".
- 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 too hard to use. Yet most of the stuff you really need to prove is very dumb. X can't affect Y. A can't get information B. Invariant C holds everywhere outside the zone (class, module, whatever) where it is transiently modified. No memory safety violations anywhere. What you really need to prove, and can't establish by testing, is basically "bad thing never happens, ever". Focus on that.
- The author talks about "Java forever". It's more like Javascript Everywhere.
- Somebody needs to invent WYSIWYG web design. Again.
- Functional is OK. Imperative is OK. Both in the same program are a mess.
- Multithread is OK. Event-driven is OK. Coroutine-type "async" is OK. They don't play well together in the same program. Especially if added as an afterthought.
- Interprocess communication could use language support.
- We still can't code well for numbers of CPUs in triple digits or higher.
- How do we talk to GPU-type engines better?
Earlier quoted context omitted.
"Coq" means "Rooster" in French. Coq (the software) started development at INRIA (France) in 1984 as a small R&D project. I am not particularly shocked that the original developers did not realize the possible double meaning in another language, and being as dismissive as you are seems uncalled for. There are countless startups whose names in English mean something else entirely in another language. For example "Cocu…
The original developers include Thierry Coquand. Also there's a tradition of naming theorem provers after birds (that might have started with Coq though). But they definitely knew that this pun was there.
One 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…
> tests without cluttering the production code and excessive mocking
IMHO, tests should be an integral part of production code. In MPWTest[1], tests are typically expressed on the class side of the class under test, in a category called Testing, though it's easy to override that. This solves 2 of my major annoyances with xUnit-style testing: dual class/test hierarchies and (with static typing) the need to add public interface for the tests, which don't have privileged access.
Mocking in particular and stubbing should be eliminated as much as possible, but this is not a programming language issue[2], more a "not making architectural assumptions too early" issue.