Very disappointed not to see Cilk included.
Near Future of Programming Languages [pdf]
21–30 of 306 posts
Re: Near Future of Programming Languages [pdf]
#22Perhaps 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 more like a composition of machine learning models.
Re: Near Future of Programming Languages [pdf]
#23> Languages that have dabbled with modeling effects with row types have backtracked on it in favor of IO. Interesting. I thought algebraic effects + handlers were the new hotness in modeling effects with types.
They are hotness because they are having trouble getting them to work (trouble = open research topic :) ), and they want to convince the monad proponents that they are better.
Re: Near Future of Programming Languages [pdf]
#24One 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…
I can imagine something like a code-collapse indicator next to every method in a class (or function or code block, whatever), which would expand tests that can be run on-the-fly - even while you type. Kind of like how comments can be collapsed in some IDEs.
Technically, these could very well be simple commented annotations that point to a separate .test file or something, but are shown in-line by your favorite IDE or code-editor.
Re: Near Future of Programming Languages [pdf]
#25In case of anyone interested a reasonable engineered language that supports Closure Serialization (mentioned as "hard" in last slide), checkout:
Gambit Scheme: A fast scheme implementation. http://github.com/gambit/gambit
Gerbil Scheme: Provides full module and syntactic tower on top of Gambit Scheme. https://github.com/vyzo/gerbil
Re: Near Future of Programming Languages [pdf]
#26One 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…
I don’t do coding tests. I talk to the candidate about programming and I only require one interview. I haven’t made a hiring mistake in 6 years.
Re: Near Future of Programming Languages [pdf]
#27One 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…
William Byrd's work in program synthesis is an interesting take on this, where an IDE can, guided by test cases written for a function, actually auto-complete code itself whilst writing the function, or tell the programmer when they have something wrong by violating a test case. Of course it is impractical right now, but a good step nonetheless.. It (Barliman) is demoed near the end of this video: https://youtu.be/OyfBQmvr2Hc
Re: Near Future of Programming Languages [pdf]
#28Perhaps 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…
Of course in practice we know is a lot easier to build and use probabilistic models. However, I hope we don't give up on proovable systems.
When given enough time, if math can stay pure and adequately abstract to eventually describe our entire universe concisely. Shouldn't code similarly have no limitation?
Re: Near Future of Programming Languages [pdf]
#29“It just feels readable”. -> “It looks like this other language I know.”
But: that language might be English (or other natural language). Which is to say maybe computer languages are leveraging the human "language faculty" and rightly so. Which may mean that some languages are always going to feel more foreign.
Re: Near Future of Programming Languages [pdf]
#30One 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…
I don’t do coding tests. I talk to the candidate about programming and I only require one interview. I haven’t made a hiring mistake in 6 years.
Uh, this is about automated testing of programs, not interviewing.