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

201–210 of 306 posts

Re: Near Future of Programming Languages [pdf]

#201

Post by Symmetry »

fasquoika wrote: post #55
joe_the_user wrote: post #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.

Considering how many programmers will tell you that C style semicolons and curly braces are more readable than using keywords, I think they've got a point

At some extremes yes but, for example, I've spent at least twice as much time programming C and C+ than I have with Python but I still find Python generally more readable. Maybe if the ratio were 100 to 1 instead of 2 to 1 I'd feel differently but that suggests there are actually intrinsic differences in readability apart from just familiarity.

Re: Near Future of Programming Languages [pdf]

#202

Post by theoh »

hood_syntax wrote: post #180
theoh wrote: post #142

Earlier quoted context omitted.

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 don't know, it's far from perfect, but is there a better way to do sequencing in a pure functional language? You have to be able to specify order of execution to tackle real world tasks unless you do callback/continuation passing style right? I find that a lot less intuitive for most applications.

Do notation isn't about sequencing, it's syntactic sugar for the monadic 'bind' operator. Sequencing happens because of data dependencies. This is part of the confusing story about monads -- the fact that every monad is a monoid doesn't imply a straightforward linear sequencing, as something like the tardis monad illustrates.

https://wiki.haskell.org/Do_notation_considered_harmful

More constructively, it could be argued that IO just does not fall in the remit of functional programming. SPJ doesn't refer to Peter Landin much, but Landin's perspective is valuable. In 1964 he wrote "Is there some way of extending the notion of [arithmetic expressions] so as to serve some of the needs of computer users without all the elaborations of using computers?" (The Mechanical Evaluation of Expressions).

IMO this is exactly what the Haskell tradition is pursuing. Landin, quite modestly, doesn't anticipate that entire computer systems will be expressible in functional form. Implicit data structures are just one example of a mechanism that is incompatible with the idea that everything is an expression whose internal representation is managed by the language runtime (itself presumably involving mutable data).

I don't think Landin was experiencing a failure of vision--I think he saw clearly that some of the "elaborations" of computing are remote from a functional model.

Re: Near Future of Programming Languages [pdf]

#203

Post by TheOtherHobbes »

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.

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 problems, but so many useful systems rely on mutable state - at practical application levels - that it might be interesting to design robust systems that manage state, context, and relationship instead of trying to create contrived examples of state-free systems.

There seems to be a cognitive bias against this in CS. Most developers appear to love puzzle systems made of hard little components with solid edges, and thinking in terms of context and relationships seems to be disturbingly alien. So there aren't many programming paradigms that explicitly work with contextual inference instead of trying to rigidly delimit interfaces.

But there are real prizes to be won from associative context-smart computing, and IMO the domain is wide open for innovation - because it may be possible to give up the pursuit of complete safety and predictability (which doesn't exist anyway) in return for new kinds of powerful, productive, and smart features.

Re: Near Future of Programming Languages [pdf]

#204

Post by bjz_ »

pron wrote: post #191
mrkgnao wrote: post #169

Earlier quoted context omitted.

> What you get "for free" from such languages may not be significant enough to justify the cost of adoption Idris can often infer entire functions from their types if the domain is amenable to accurate type-based specification. For instance, taking the common "sized vector" example, where `Vec n a` refers to a length-n vector of values of type a, functions like zip : Vec n a -> Vec n b -> Vec n (a, b) can be automati…

> Idris can often infer entire functions from their types if the domain is amenable to accurate type-based specification. This is a great example of what I'm talking about. The kind of functions Idris can generate is that of functions that you could manually write with only marginally more effort -- if that -- than the effort required to write the precise type. I don't think those functions ever form a significant po…

> If you've spent a significant amount of time with such proof assistants, you'd see that the proof search is rather pitiful.

Afaik, Idris' proof search was hacked together in an afternoon just to see if it would work. And it did, surprisingly well considering. Don't know how much it has been worked on since then though. But yes, still leaves a bit to be desired compared to other systems.

Re: Near Future of Programming Languages [pdf]

#205

Post by tomelders »

closeparen wrote: post #30
tomelders wrote: post #26

Earlier quoted context omitted.

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.

I'm an idiot.

Re: Near Future of Programming Languages [pdf]

#206

Post by chrisseaton »

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…

> Only if you ignore the dynamic state of the language, of associated libraries, of processor architectures, and so on

I don't understand why any of this means you can't have a compile as a pure function. A pure function can cope with things changing internally - it just creates new data structures to represent things that have changed in the old data structures and then passes the new data structures onto the next phase.

A pure function just means you can't do something like a package manager that needs to read files from disk or download things.

> but so many useful systems rely on mutable state

You don't have to argue this to me - I wrote the first half of my PhD on the importance of mutable state.

I'm just arguing against the nonsense that it is impossible to write a useful real-world application as a pure function.

I work in the VM research group at Oracle, and guess what? Our JIT compiler is basically a pure function. It takes in some bytecode and produces some machine code. It's structured a little differently in reality, but it is logically, and almost in practice, a pure function from one to the other.

I'm writing a presentation about this right now.

Re: Near Future of Programming Languages [pdf]

#207

Post by fnord123 »

TuringTest wrote: post #165
vanderZwan wrote: post #138

Earlier quoted context omitted.

I find the jab at Bret Victor especially undeserved. He's an interaction designer (a really good one who sees through all the fads[0], which is kind of the opposite of what this one-liner implies). His focus is on better interface design, not formal language design; why criticize someone for something they're not trying to do? And it's not useless; we probably wouldn't have had Elm without Bret Victor's Inventing on…

Quite true. I find likely that the next revolution in programming languages will come from designing a PL that's a good fit for these programmable environments. Maybe it should break from current undisputed conventions like the radical separation between "data" and "source code", and be more like a spreadsheet. End-User Development has lots of under-explored ideas on how to build software automatisms that don't requi…

There is a dichotomy between sealed programs and evolving programs. Evolving programs like Smalltalk or REPLs are great for exploratory work. Almost everyone wants sealed programs for systems to work reliably. This runs along the lines of Ousterhout's dichotomy as well - scripting vs systems languages.

The engineering break through will be when we have a scripting/evolving system that can be more easily distilled into sealed systems. So people poking around in a spreadsheet will be able to turn that into a reliable application.

IMO, TDD and BDD could be seen as attempts to do exactly this.

Re: Near Future of Programming Languages [pdf]

#208

Post by TuringTest »

fnord123 wrote: post #207
TuringTest wrote: post #165

Earlier quoted context omitted.

Quite true. I find likely that the next revolution in programming languages will come from designing a PL that's a good fit for these programmable environments. Maybe it should break from current undisputed conventions like the radical separation between "data" and "source code", and be more like a spreadsheet. End-User Development has lots of under-explored ideas on how to build software automatisms that don't requi…

There is a dichotomy between sealed programs and evolving programs. Evolving programs like Smalltalk or REPLs are great for exploratory work. Almost everyone wants sealed programs for systems to work reliably. This runs along the lines of Ousterhout's dichotomy as well - scripting vs systems languages. The engineering break through will be when we have a scripting/evolving system that can be more easily distilled int…

> The engineering break through will be when we have a scripting/evolving system that can be more easily distilled into sealed systems. So people poking around in a spreadsheet will be able to turn that into a reliable application.

Yeah, I see that as a likely evolution as well.

In some ways, an IDE is already an exploratory system with a focus on delivering a sealed system - the final compiled software represented by the source code. I believe this combination is what made IDEs so successful and universally desirable, and future programmable environments should share these traits.

Auto-completion, refactoring and code-browsing tools support the exploratory work. The problem is that IDEs are not so good at exploration as a REPL because they're unable to store intermediate results and states. TDD could then be seen as an ad-hoc way to store such intermediate state.

Re: Near Future of Programming Languages [pdf]

#209

Post by pjmlp »

lispm wrote: post #194
throwaway7645 wrote: post #126

Earlier quoted context omitted.

If you keep your head to the ground, there are quite a few companies like Facebook that use Haskell for important things in production, but it isn't the language even 50% of the company is using. I'm sure there is a lot more lisp in production, but you typically hear about the same ratio from both camps in the blogosphere.

I would guess that in a company like Facebook, 99.5% of the code they wrote is not Haskell. If they have, say, 200MLOC of code written (just a number), this would be 1MLOC...

There are companies using a bit more of Haskell in production.

http://cpmed.de/jobs/

Re: Near Future of Programming Languages [pdf]

#210

Post by toolslive »

iitalics wrote: post #23
curryhoward wrote: post #14

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

what trouble ? http://www.eff-lang.org/
Post reply on HN