Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Near Future of Programming Languages [pdf]

dev.stephendiehl.com

Post reply on HN
Print view View original

261–270 of 306 posts

Re: Near Future of Programming Languages [pdf]

#261

Post by YZF »

rexpop wrote: post #60
YZF wrote: post #16

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…

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?

It's supposed to be this way but in practice it doesn't seem to work. With methods/functions it's a problem when they call other functions.

So really the idea that a good design is also testable is somewhat of an approximation of reality, It has some elements of truth but at some point making your code more testable actually makes it worse, often you need to make other compromises. Then the interactions of pieces of code typically happens in much more brittle system/integration tests. YMMV, this is just my experience.

A lot of interesting pointers in the replies, thanks!

Re: Near Future of Programming Languages [pdf]

#262

Post by noam87 »

pron wrote: post #250
noam87 wrote: post #248

Earlier quoted context omitted.

Pron, what are the better alternatives / more promising lines of research you keep referring to?

I think they're better largely because I'm more aesthetically drawn to them (so I will be biased, but no more so than the author, who also only mentions techniques he's aesthetically drawn to), but also because I think they have shown more success in practical industry use. For programming interactive systems, a very interesting approach which has been quite successful in realtime software and hardware systems, is sy…

Eve looks interesting, thanks I'll try it out. (And the detailed response.)

Most of my programming is in the domain of "take some data, do stuff to it, produce an output" and my experience with Idris so far is very positive -- more so than Haskell (which I admittedly gave up on early on), the language does feel ergonomic, and like the type system is "guiding me" rather than getting in the way. I also find its approach to metaprogramming interesting. Whether this translates to Real World™ productivity / maintainability gains vs a mainstream language, it's too early for me to compare.

Re: Near Future of Programming Languages [pdf]

#263

Post by fulafel »

stmw wrote: post #231
machiaweliczny wrote: post #136

Earlier quoted context omitted.

It's just my opinion, but there definitely is difference in favor of optional static typing. It simply adds more expressivness to language - you get free documentation standard (input,output,structures) backed in. You don't have annoying typos and you leave data manipulation computation to computer lowering programmer cognitive load. Also you can change code in editor(fastest feedback loop) without even running it(ve…

That, and also there are so many independent confounding factors in these comparison studies that I am not sure they can ever outperform reasoning or personal experience. The reasoning part in your comment - lowering cognitive load, faster feedback cycles (in editor, in compiler, etc.), fewer typo-induced problems - seems hard to argue with.

It seems both camps count lowering the cognitive load and faster feedback cycles to their advantage!

Good dynamic systems have long done live-coding against the running system with instant feedback. Even recent static languages like Rust and Scala have notoriously long compile times and thus slow feedback loops.

Also there's along tradition of querying the system for things like auto-completion / doc display.

The cognitive load of fancy type systems like Haskell's is seen as very high.

Re: Near Future of Programming Languages [pdf]

#264

Post by flavio81 »

PaulRobinson wrote: post #89
Animats wrote: 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…

I disagree with a few of your thoughts, but they're good thoughts! * Javascript everywhere is a function of low barrier-to-entry for it, but almost everybody agrees it is flawed as a language. If that's the future, we are screwed as an industry. One thing I've noticed (and I say this as a guy who wrote Ruby for 10+ years), is that type safety is becoming a hugely desired feature for developers again. * WYSIWYG web de…

>* If that's the future, we are screwed as an industry.*

Agree 100%. However, i find Javascript pretty good for quick and dirty "MVPs".

Re: Near Future of Programming Languages [pdf]

#265

Post by flavio81 »

marcosdumay wrote: post #229
lhnz wrote: post #220

Earlier quoted context omitted.

Almost none of the things I mentioned are solutions to 'a problem created by JavaScript' therefore your question seems deliberately misleading. An accepting community can be a large funnel: it doesn't need to mean that nobody improves or that there are no selection effects. More candidates means more chaff, but also more wheat. Babel isn't merely contributing to a 'lack of a good VM'. It's more valuable to see it as…

> More candidates means more chaff, but also more wheat. That needs substantiation. It's not immediately obvious in any way. About Babel, notice how we never had a problem playing with language-level features that target the PC? That's the difference a good VM makes (although on the PC case, it's not virtual). Besides, you are conflating VMs and languages somehow - they have only a tenuous relation. About the speed,…

>Overall, the reason Javascript still exists and is viewed as a serious language is all because it has a monopoly on the browsers.

Basically, this. ClojureScript and others are simply the efforts of sane, experienced developers that don't want to cope anymore with Javascript and its warts.

Re: Near Future of Programming Languages [pdf]

#266

Post by flavio81 »

lhnz wrote: post #245
marcosdumay wrote: post #229

Earlier quoted context omitted.

> More candidates means more chaff, but also more wheat. That needs substantiation. It's not immediately obvious in any way. About Babel, notice how we never had a problem playing with language-level features that target the PC? That's the difference a good VM makes (although on the PC case, it's not virtual). Besides, you are conflating VMs and languages somehow - they have only a tenuous relation. About the speed,…

I don't think that comment requires more substantiation than yours that there are "low enough standards that newbies feel empowered without learning anything new". The more people that learn your language, the more likely it is that you will find some that can contribute to its state-of-the-art. A low bar doesn't effect people that would surpass a higher bar with ease: they still wish to learn and sate their natural…

>You can transpile ClojureScript, Elm, Reason, PureScript and many other languages to it. Yet -- surprise! It is still in use. Do you honestly think this is just inertia?

No, it isn't inertia -- one important reason is that creating a transpiler to JS invariably ends up with a crippled (feature-restricted), slower version of the original language (Clojure, etc.)

Thus the hope placed in Webassembly.

Re: Near Future of Programming Languages [pdf]

#267

Post by flavio81 »

SiVal wrote: post #260
Chris_Newton wrote: post #249

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?

Yes, they exist and have been used for decades; two well known examples are Common Lisp and Scheme.

For example you can do functional, imperative and OO programming in Common Lisp, and it brings extensive features for working in all these three paradigms.

More recent examples, Racket and Julia.

Re: Near Future of Programming Languages [pdf]

#268

Post by wsxiaoys »

mrkgnao wrote: post #199
wsxiaoys wrote: post #25

In 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

Does Guile (or even Chicken) do anything similar? (My only exposure to it is from Andy Wingo's blog, and I don't know much about Scheme.)

Nope.

Re: Near Future of Programming Languages [pdf]

#269

Post by flavio81 »

TheOtherHobbes wrote: post #203
chrisseaton wrote: post #170

Earlier quoted context omitted.

Right - a compiler. That's a real-world application isn't it? A compiler can be a pure function - accepting source text as input, and producing machine code as output. Yes more complicated languages do more complicated things, but for several languages you could write a state-of-the-art compiler as a pure function.

Only if you ignore the dynamic state of the language, of associated libraries, of processor architectures, and so on - i.e. the context the compiler is working in and the mutable state of the language and development environment as a whole. The idea of pure functions is a false friend in CS because it tries to solve the problem of state by wrapping it up and wishing it away. It's true that state causes a lot of probl…

This is the best HN post i've read today. You should expand it into a blog post.

I also agree - context and state are important and useful, because many real-life problems or processes rely on such a model and thus translate naturally when state is a "first-class citizen."

Re: Near Future of Programming Languages [pdf]

#270

Post by Chris_Newton »

SiVal wrote: post #260
Chris_Newton wrote: post #249

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?

None of the programming languages that I know well myself provides the sort of balance I’d like to see between:

(a) strong visibility of and control over effects,

(b) an emphasis on powerful tools to represent and manipulate data, and

(c) straightforward imperative/stateful aspects when required.

Of course that isn’t to say that no such language exists, but if it does then sadly I have yet to become aware of it. New ideas are always welcome…

Post reply on HN