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

291–300 of 306 posts

Re: Near Future of Programming Languages [pdf]

#291

Post by shalabhc »

TuringTest wrote: post #208
fnord123 wrote: post #207

Earlier quoted context omitted.

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 b…

Agree on the benefits of IDEs and REPLs. An IDE/language with integrated notebook-style REPLs might be useful too. Maybe you want to create parts of the system by interacting with a REPL (instead of writing a static block of text) - and then you'd want to record how you created this specific artifact.

The other thing that would help, and my personal wish, is better simulation and the ability to see indirect effects of changes - instead of only showing what is directly modified (i.e. a line of code) and leaving the simulation up to the human.

Re: Near Future of Programming Languages [pdf]

#292

Post by shalabhc »

fnord123 wrote: post #278
shalabhc wrote: post #257

Earlier quoted context omitted.

Do you see this as a useful dichotomy? In reality no system is truly sealed - it's just temporarily sealed between evolution steps, no?

I do find it a useful dichotomy because I work with people who evolve their code and wonder why I get my back up about monkey patching (because it's often my job to turn research or prototype quality code into reliable code). If you've ever had to make another person's research or prototype quality code more robust it can be easy to wonder how on Earth they work the way they do. Having this dichotomy in mind makes it…

Ah I see. So with 'sealed' you mean things like reproducible builds and being able to determine the exact set of sources, etc?

The containerization movement is interesting - while having these 'sealed' virtual environments and reproducible system builds is the right direction, I'm amazed at the size and weight of each of these.

Re: Near Future of Programming Languages [pdf]

#293

Post by smaddox »

tom_mellior wrote: post #288
smaddox wrote: post #286

Earlier quoted context omitted.

Yes, you can always generate a new union type for your return type and then pattern match on it. That is certainely better than C where you must use unsafe tagged unions or void pointers. It is more verbose than in dynamic duck-typed languages, though I'll give you that it's quite compact in OCaml. In a dependently typed language, you could reduce verbosity at the use site as well as avoid the extra runtime branch.

So how exactly would you write the above five lines of OCaml in fewer than five lines in Idris?

The verbosity is not in the function definition, its in the match expression needed at _every single call site_. In Idris, the definition would be similar length or longer, but call sites would not need a match expression.

Re: Near Future of Programming Languages [pdf]

#294

Post by rurban »

bjz_ wrote: post #160
josefrichter wrote: post #91

Just curious where does Elixir fall in this scheme of things? Any experienced devs who could give a qualified answer, please?

Elixir doesn't really push much of the state of the art forward. It's pretty much Erlang with new clothes (and some nice cleanups). I worked with it for over a year and while I loved the 'fail fast' model of programming, most of the errors that were caught were stupid programming errors that would have been trivial to catch by a type system. What I really want is a type system for reasoning about distributed, statefu…

Distributed Pony will be there soon.

https://www.doc.ic.ac.uk/~scd/Disributed_Pony_Sept_13.pdf [pres], https://www.ponylang.org/media/papers/a_string_of_ponies.pdf [paper]

I'm not sold on Cloud Haskell or Clojure.

Re: Near Future of Programming Languages [pdf]

#295

Post by TuringTest »

shalabhc wrote: post #291
TuringTest wrote: post #208

Earlier quoted context omitted.

> 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 b…

Agree on the benefits of IDEs and REPLs. An IDE/language with integrated notebook-style REPLs might be useful too. Maybe you want to create parts of the system by interacting with a REPL (instead of writing a static block of text) - and then you'd want to record how you created this specific artifact. The other thing that would help, and my personal wish, is better simulation and the ability to see indirect effects o…

> Maybe you want to create parts of the system by interacting with a REPL (instead of writing a static block of text) - and then you'd want to record how you created this specific artifact.

Yes, exactly. You get that with a REPL (e.g. Lisp or Python) and copy-pasting to the source code files, but it's far from ideal.

> The other thing that would help, and my personal wish, is better simulation and the ability to see indirect effects of changes

So, sort like explorable explanations[1][2], but aimed at developing a new model and not just exploring one that has been already made? That's what I'd like to see, too.

[1] http://worrydream.com/ExplorableExplanations/

[2] http://worrydream.com/TenBrighterIdeas/

Re: Near Future of Programming Languages [pdf]

#296

Post by vorg »

smaddox wrote: post #244
ryanmarsh wrote: post #171

Earlier quoted context omitted.

type safety is becoming a hugely desired feature for developers again I don’t think anyone ever hated type safety, I think they hated verbose syntax and unfortunately conflated the two. Now we’re finding a happy medium with compiler type inference and people are like, wait what?

Dynamic typing is objectively much more flexible and easier to prototype in. Static typing is much easier to build large and robust systems in. Eventually we'll get to the point where everything you can do in dynamicly languages can be done in staticly typed languages (more verbosely), but we're not there yet. For example, functions that return a different type depending on the values passed in are a useful pattern,…

> provides a (runtime) safe and low-verbosity way to write dynamically-typed code, i.e. `interface{}`

Since Go 1.9 was released with its new Type Aliases feature a few months ago, the verbosity is even lower. By putting `type any = interface{}` somewhere in your package, you can just write `any` instead of the verbose `interface{}` everywhere you want some dynamic typing.

Re: Near Future of Programming Languages [pdf]

#297

Post by catnaroek »

timthelion wrote: post #123
aryehof wrote: post #61

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…

I agree, and from a different perspective, I would compare this to literature. In English literature we have many different paradigms: Victorian literature, Modernism, Post modernism, Post colonial ect. The language has to be expressive, and in being expressive, it can express any of these different paradigms. The fact that the vocabulary is shared between the "eras" of literature is only a bonus which makes authors…

In Haskell you don't ever take the `head` of a list, because `head` is an evil non-total function. Instead you pattern-match the list: in one branch, the head is given to you for free; in the other branch, there's no head at all.

Re: Near Future of Programming Languages [pdf]

#298

Post by catnaroek »

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…

> Previously the options were reference counts, garbage collection, or bugs.

I think you mean “lack of memory safety” rather than bugs. Garbage collection doesn't magically free you from finalization bugs, it just makes their consequences less disastrous.

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

Clearly, the solution is getting rid of people, but it isn't entirely clear on which end to get rid of people.

Re: Near Future of Programming Languages [pdf]

#299

Post by pdimitar »

wolfgke wrote: post #290
PaulRobinson wrote: post #116

Earlier quoted context omitted.

I said 'almost everybody'. Even the most ardent JS fans I work with call it objectively bad.

> Even the most ardent JS fans I work with call it objectively bad. Counterargument: Read Douglas Crockford - JavaScript: The Good Parts Even though this book is somewhat "aged" (it is from 2008), I know no better book where it is presented so well what is so interesting about JavaScript and how this language is so often misunderstood. If after reading this book you still consider JavaScript as "objectively bad", so…

It is very telling that you don't see the irony of the fact that a language needs a book titled "Language X: the good parts".

Good tech mostly speaks for itself. When you need entire books to convince you that a language has good parts, then you know the language has a problem.

Re: Near Future of Programming Languages [pdf]

#300

Post by pdimitar »

blipblop wrote: post #118
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…

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

Well, you were right about one thing: you don't get it. ;)

Just look at the prototype hell. Look at the quirkiness of the comparison operator. Type inference. The mess piles up extremely quickly.

"Disciplined devs don't make those mistakes" is NOT an argument and never was. Decades later, people believing themselves to be godlike C/C++ devs still make stupid mistakes.

But I guess learning from the past won't happen for people who fanboy and have a survivorship bias. And have money on the line.

Post reply on HN