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

251–260 of 306 posts

Re: Near Future of Programming Languages [pdf]

#251

Post by marcosdumay »

js8 wrote: post #242
marcosdumay wrote: post #195

Earlier quoted context omitted.

The types line is what some people do with Haskell, Idris. I do personally favor writing the large-scale types beforehand, because that gives the compiler a chance of saying "look, you program is wrong", what is way more useful than "hey, your program has this type". Besides, abstract-type driven programming is an incredibly good methodology where it's applicable. On code understanding, what makes it better than the…

Thanks, I will respond to other people here as well. I know a bit of Haskell and want to look at Idris, someday. My point was, there should be a clean (best if even syntactic) separation between code itself (i.e. what should actually be done) and its properties (like types). Also, because there are two points of view about the properties (human and computer), this separation needs to be there twice (so for example, e…

You mean that types should reside on different files, and be inputed by different means?

Now I get the entire programming-compiler conversation. It is interesting. I can see some potential there. Yet, I shrug when I think about all the sparse metadata that I will have to check once I discover a low level bug (there is a reason I'm not programming in Smalltalk).

Somehow the best place for all that stuff to live is right there at the source code. That means the compiler (IDE) should be editing your files, so it better have a great integration with your version control system.

Re: Near Future of Programming Languages [pdf]

#252

Post by marcosdumay »

azangru wrote: post #247
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,…

> Javascript misses most of the expressiveness of Python and Ruby. Could you please give examples of expressiveness of Python or Ruby that Javascript lacks?

You can't change the rules interpreting your source code so that the parser will expand a small command into an entire program, or that it will read a more fitting DSL that does not resemble your original language.

You can not inspect an object and change its type or the set of available properties based on some calculation.

You can not run some code in a controlled environment separated from your main code.

Re: Near Future of Programming Languages [pdf]

#253

Post by Myrmornis »

aryehof wrote: post #227
Myrmornis wrote: post #219

Earlier quoted context omitted.

I’m not sure I understand everything you said there. Software engineers are often tasked with designing and implementing “business processes”, just as they are tasked with implementing correct logic in a concurrent threaded program, or system of microservices. Don’t you feel that when they step up to the whiteboard and draw yet another completely ad-hoc diagram, for any of the above problems, with no agreed rules of…

There are some that can walk up to a white-board and (repeatedly and predictably) create a domain object model representing complex business requirements. One directly convertible to code. They can do this because they know a set of higher order patterns, beyond just a knowledge of "objects" and "classes". Beyond just a design approach of identifying classes as the "nouns" in a problem domain. These higher order patt…

OK, so that covers data modeling, and I agree with you that that is a rare and yet critical skill. But if I'm envisioning correctly the talents that you're describing, that still leaves a large amount of concurrent/asynchronous logic undescribed/undesigned. I expect you know what I mean; maybe a jumble of words like "multiple superimposed event-driven parallel state-machines" gives the idea.

You mention a "domain object model". Are you talking about diagrams that capture much of the dynamics/asynchronous behavior that I described (in which case, where can I learn about such a diagramming language?) or is it more restricted to the nouns?

Re: Near Future of Programming Languages [pdf]

#254

Post by aphextron »

marcosdumay wrote: post #174
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…

About WYSIWYG, we are missing standards on our APIs. SOAP was going that way but it was way too much, way too early. Either that, or an ASP.Net view where the backend is interacting with the user through a browser. But that doesn't work well. It's much better to standardize the backend API than the entire frontend.

>SOAP was going that way but it was way too much, way too early.

I think SOAP successfully demonstrated that rigorous "API standards" are a pipe dream. Swagger/REST is probably as good as it's going to get.

Re: Near Future of Programming Languages [pdf]

#255

Post by dllthomas »

tdb7893 wrote: post #9
drefanzor wrote: post #7

TLDR The future of programming languages should involve not naming your language "Coq". I know I am going through the lowest common denominator, but how do you explain to your boss that you're proficient with using Coq. Ugh. Or professor, since apparently it's a proofing language for academia.

I would just pronounce it like "coke" and it would just sidestep the whole pronunciation issue. I'm not sure how most people pronounce it but that's what I would do to talk to my boss about it.

My favorite quote on the topic: https://news.ycombinator.com/item?id=10728995

Re: Near Future of Programming Languages [pdf]

#256

Post by tom_mellior »

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

> For example, functions that return a different type depending on the values passed in are a useful pattern, but not allowed in staticly typed languages, except those with dependent types (Idris) or runtime downcasting (Go). There's always a way to acheive the same thing, but usually at the cost of safety or much more verbosity.

Look at this verbose OCaml:

    type my_return_type = AFloat of float | AnInt of int | AString of string;;

    let my_fun n =
        if n
(But yes, to use these values you have to do pattern matching, and if you're in a FUD mood, that is "runtime downcasting" and incurs a "cost of safety".)

Re: Near Future of Programming Languages [pdf]

#257

Post by shalabhc »

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…

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

Re: Near Future of Programming Languages [pdf]

#258

Post by js8 »

marcosdumay wrote: post #251
js8 wrote: post #242

Earlier quoted context omitted.

Thanks, I will respond to other people here as well. I know a bit of Haskell and want to look at Idris, someday. My point was, there should be a clean (best if even syntactic) separation between code itself (i.e. what should actually be done) and its properties (like types). Also, because there are two points of view about the properties (human and computer), this separation needs to be there twice (so for example, e…

You mean that types should reside on different files, and be inputed by different means? Now I get the entire programming-compiler conversation. It is interesting. I can see some potential there. Yet, I shrug when I think about all the sparse metadata that I will have to check once I discover a low level bug (there is a reason I'm not programming in Smalltalk). Somehow the best place for all that stuff to live is rig…

> Somehow the best place for all that stuff to live is right there at the source code.

That's what I am saying, and that's why it has to be syntactically distinct.

Also it needs to be clear what was input by computer and what was input by human, that's the second distinction. Because of how the conversation works. You don't want computer to erase human input, but the result also has to be logically sound. So you need to know both inputs for the comparison and synthesis, which happens at each conversation turn, both human's and computer's.

And that's what "type holes" and similar systems lack - they only record the result of the synthesis, not the two different opinions. Which is IMHO wrong.

Re: Near Future of Programming Languages [pdf]

#259

Post by marcosdumay »

js8 wrote: post #258
marcosdumay wrote: post #251

Earlier quoted context omitted.

You mean that types should reside on different files, and be inputed by different means? Now I get the entire programming-compiler conversation. It is interesting. I can see some potential there. Yet, I shrug when I think about all the sparse metadata that I will have to check once I discover a low level bug (there is a reason I'm not programming in Smalltalk). Somehow the best place for all that stuff to live is rig…

> Somehow the best place for all that stuff to live is right there at the source code. That's what I am saying, and that's why it has to be syntactically distinct. Also it needs to be clear what was input by computer and what was input by human, that's the second distinction. Because of how the conversation works. You don't want computer to erase human input, but the result also has to be logically sound. So you need…

> You don't want computer to erase human input

I will contest that one too :)

As long as it is interactive enough, and the history is well marked, there is no reason not to rewrite human code.

Re: Near Future of Programming Languages [pdf]

#260

Post by SiVal »

Chris_Newton wrote: post #249
smaddox wrote: post #246

Earlier quoted context omitted.

Rust doesn't require use of unsafe for cacheing 15 levels deep if you use the right primitives, i.e. a Mutex. If you dont use safe primitives, then yes you need to use the unsafe keyword to mark the code as unsafe. How is that unreasonable?

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?
Post reply on HN