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

181–190 of 306 posts

Re: Near Future of Programming Languages [pdf]

#181

Post by mrkgnao »

geogriffin wrote: post #27
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…

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

MagicHaskeller[0] (which seems to sadly be offline at present) is a similar project that infers Haskell functions from properties like

   reverse "abcde" = "edcba"
Other, older projects include Exference[1] and Djinn[2], in decreasing order of power.

Also, this is really similar to how Idris and Agda work, except they use expressive types to generate the code (using the Emacs modes) rather than test cases.

[0]: http://nautilus.cs.miyazaki-u.ac.jp/cgi-bin/MagicHaskeller.c...

[1]: https://github.com/lspitzner/exference/

[2]: http://www.hedonisticlearning.com/djinn/

Re: Near Future of Programming Languages [pdf]

#182

Post by marcosdumay »

throwaway7645 wrote: post #122
blipblop wrote: post #118

Earlier quoted context omitted.

> but almost everybody agrees it is flawed as a language. If that's the future, we are screwed as an industry. What language is not flawed? And why are we "screwed"? I don't get this FUD...there are more important things than language-choice such as dependency management system + community + ecosystem. JS lets you get on with the job and get things done quickly. You need performance - use C/C++ bindings. Its been cle…

It doesn't bother you that huge portions of our tech stack are sitting on top of layers of terrible language design that our ancestors will have to deal with? Perhaps the parent post is looking more to the future. Of course it all still works, but when you think we could be doing the same job with Lisp, Smalltalk, (insert any non perfect, but much better than JS technology), it does make me cringe a little.

> that our ancestors will have to deal with

You meant descendants?

Anyway, they won't. They will throw away the garbage and rewrite anything good they find. Just like we do.

Re: Near Future of Programming Languages [pdf]

#183

Post by marcosdumay »

giantsloth wrote: post #153
d13 wrote: post #135

Earlier quoted context omitted.

It's flawed because 99.999% of the time your code will work just fine. Job done. Then one day, "undefined is not a function" and your airplane falls out of the air.

This happens in all languages... look at the Toyota acceleration bug for a real world of example of your hyperbole. They were using MISRA C. Languages dont fix spaghetti, laziness, tight deadlines, bad engineers, etc.

> This happens in all languages...

To some extent, yes, that happens in all languages. To some extent 10^100 and 1 are both numbers. That does not mean you can even compare them.

Re: Near Future of Programming Languages [pdf]

#184

Post by TeMPOraL »

chrisseaton wrote: post #170
TeMPOraL wrote: post #163

Earlier quoted context omitted.

Ok, to clarify - I didn't mean program as in a simple function. I meant a program as in application, something that accepts some real-world input and produces some real-world consequences.

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.

Hm.

Fair enough.

Re: Near Future of Programming Languages [pdf]

#185

Post by fnord123 »

chrisseaton wrote: post #151
fnord123 wrote: post #150

Earlier quoted context omitted.

Unless you want logging with timestamps.

My point was that it is not impossible to write useful programs as pure functions. You can't counter that with an example of a program that you can't write as a pure function.

Sure, it's not impossible to write something as a pure function. But it's not an interesting statement to make unless you also apply the implied context that it may be desirable to do so. Do you think it is desirable to make these pipeline components as programs using pure functions?

Re: Near Future of Programming Languages [pdf]

#186

Post by [deleted] »

fnord123 wrote: post #185
chrisseaton wrote: post #151

Earlier quoted context omitted.

My point was that it is not impossible to write useful programs as pure functions. You can't counter that with an example of a program that you can't write as a pure function.

Sure, it's not impossible to write something as a pure function. But it's not an interesting statement to make unless you also apply the implied context that it may be desirable to do so. Do you think it is desirable to make these pipeline components as programs using pure functions?

[deleted]

Re: Near Future of Programming Languages [pdf]

#187

Post by marcosdumay »

theoh wrote: post #142
stdbrouw wrote: post #90

Earlier quoted context omitted.

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

I read it as being about Scala and similar languages, where you can not freely rewrite function compositions because they may have side effects. It may not be big problem from the programmer's point of view. But the compiler surely suffers because of that.

Interestingly, on Haskell-land the debate is about merging "do notation" and normal notation. On practice the difference is limiting, and arguably the types alone are enough to represent the difference.

Re: Near Future of Programming Languages [pdf]

#188

Post by yogthos »

polymeris wrote: post #58
yogthos wrote: post #37

Earlier quoted context omitted.

I recommend taking a look at Clojure Spec https://clojure.org/about/spec or Racket Contracts https://docs.racket-lang.org/guide/contracts.html

I get clojure.spec is primary a way to define a schema and validate against it, and that you can use it for automatic test generation, too. But I feel I fail to grok the whole extent of the possibilities it offers. Does it address any of the other things YZF mentions? Specially, the "prevent excessive mocking" part?

I think this is a good example of Spec being used to guide the solution http://gigasquidsoftware.com/blog/2016/05/29/one-fish-spec-f...

I don't think Spec alone removes the need for mocking, using Clean Architecture is probably more important for that https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-arc...

If you structure your app so that any IO lives at the edges, it becomes possible to test all your business logic without mocking. Spec can help at that point by providing generative testing.

Since Spec

Re: Near Future of Programming Languages [pdf]

#189

Post by trgv »

harimau777 wrote: post #155
PaulRobinson wrote: post #89

Earlier quoted context omitted.

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…

What causes you to say that JavaScript is a flawed language? Not trying to be snarky or saying you're wrong, just want to better understand your reasoning. It seems to me that at one point JavaScript had a lot of confusing/bad design decisions but that more recent changes have largely eliminated them. For example, I almost never have to worry about "this" anymore. I recently worked on a project using TypeScript and I…

I don't think "this" in JavaScript was a bad design decision. The bad decision was how functions create their own scope in unexpected situations. Also, I think modern JavaScript still requires a lot of "this," just much less ".bind(this)" or "var that = this."

But the thing is, just because arrow functions exist doesn't mean people are going to use them. Similarly, just because modern browsers allow "let" and "const" doesn't mean people will stop using "var."

I agree that JavaScript is generally fine if you stick to the new parts of the language, but that in itself is a pretty big problem. Maybe not for me and you, but for software development in JavaScript generally it's really not ideal.

Re: Near Future of Programming Languages [pdf]

#190

Post by [deleted] »

mrkgnao wrote: post #172
lispm wrote: post #96

Looking at the 2010 Haskell report: most of the committee members come from 'Academia': https://www.haskell.org/onlinereport/haskell2010/haskellli2.... How is it an 'industrial' language? Haskell is the main 'academic' language for a branch of Functional Programming. 'industrial' is just another weasel word.

Haskell lends itself pretty well to "backend"[0] work, and there are more than a few organisations using it to write servers, trading systems, and so on. It definitely fits his metric, which is "> 1000 industrial users". [0] (Unlike applying it to the frontend, which is a comparatively less mature situation with multiple proposed solutions.)

[deleted]
Post reply on HN