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

Future of Programming Languages

c2.com

Post reply on HN
Print view View original

61–70 of 73 posts

Re: Future of Programming Languages

#61

Post by pjmlp »

JulianMorrison wrote: post #60

This whole language of the future concept is just mistaken. The era of being able to choose a language, for most operations, is over. That's because the future will be (already somewhat is) the disappearance of PCs, the minimization of overt gadgets, and the rise of ubiquitous, invisible, small, smart, with no user serviceable parts. And in most cases with no option on programming languages. Embedded? You'll probably…

This is nothing new. I learned more than 20 years ago that it is less pain to just use the languages that are part of the OS vendor SDK than spending development time writing yet another FFI wrapper.

This is how C got where it is now, as the language got adopted by OS vendors outside the UNIX world.

Re: Future of Programming Languages

#62

Post by mpweiher »

tel wrote: post #55
mpweiher wrote: post #30

Earlier quoted context omitted.

Yesbut: these are features of the language(s) of the past, or at best the present. I hadn't seen this c2 entry yet and was pleasantly surprised how many of those boxes my own Objective-Smalltalk[1] ticks: - Borrows from Smalltalk but is not a direct descendant (LISP is also there, but less visibly) - Dynamic typing as default with static typing as an addition (optional most of the time, not optional when interfacing…

I'd be very interested to see an example of an embedded theorem proving system here. My understanding is that unless your language lives and breathes type theory you cannot embed a proof system.

Well, considering the c2 entry spoke of a dynamically typed language as base, the authors probably meant something more along the lines of SOURL: http://soft.vub.ac.be/SOUL/

Re: Future of Programming Languages

#63

Post by mpweiher »

pjmlp wrote: post #61
JulianMorrison wrote: post #60

This whole language of the future concept is just mistaken. The era of being able to choose a language, for most operations, is over. That's because the future will be (already somewhat is) the disappearance of PCs, the minimization of overt gadgets, and the rise of ubiquitous, invisible, small, smart, with no user serviceable parts. And in most cases with no option on programming languages. Embedded? You'll probably…

This is nothing new. I learned more than 20 years ago that it is less pain to just use the languages that are part of the OS vendor SDK than spending development time writing yet another FFI wrapper. This is how C got where it is now, as the language got adopted by OS vendors outside the UNIX world.

This is one of the great lessons from Objective-C, IMHO: layering additional functionality in such a way as to be completely compatible with the platform ABI.

There are other compromises you make as a result, but that one feature is a huge win. (And yes, Objective-Smalltalk tries to extend that lesson of connectivity to other areas).

Re: Future of Programming Languages

#64

Post by sklogic »

david927 wrote: post #35

The future of programming should be one language for all layers of the stack, from the database to the model to the UI. I think that hints that it should be a form of declarative. And if it's declarative, it should be focused on managing state. And if it's a thin syntactical representation of its VM, instructions/code could be interpreted immediately at entry and be managed as state, so you wouldn't be working with a…

A curiously limited view of what programming is. Outside of the CRUD world not many things can be described as "database", "model" or "UI".

Re: Future of Programming Languages

#65

Post by sklogic »

lmm wrote: post #37
jared314 wrote: post #11

Earlier quoted context omitted.

> but I don't think LISP DSLs are quite on the level of SQL I'm curious what you mean by this. Is your definition of a DSL based on the language's syntax, or on the language's paradigm? Clojure's core.logic [1] provides logic programming, as apposed to functional programming, but maintains the syntax of a LISP. [1] https://github.com/clojure/core.logic/wiki/Examples

I think the reason LISP remains obscure is that syntax is important and LISP syntax is an unpleasant way to express a lot of domain languages. (I work with embedded DSLs quite a lot, but in Scala, where infix and postfix operators are easy)

Syntax is nothing. It's trivial to build any kind of syntax on top of Lisp, with arbitrary complex DSLs. See an example here: https://github.com/combinatorylogic/mbase

Re: Future of Programming Languages

#66

Post by tomp »

tel wrote: post #56
tomp wrote: post #34

Earlier quoted context omitted.

They are all converging on these features because they have proven universally useful. But there is still a lot of work going on about other, new features. Some examples that interest me: - effects and exceptions - should we use monads (Haskell), macros (Rust), handlers (Eff, algebraic effects), extensible rows (Koka) - memory usage - how should we handle deallocation - using reference counting with infrequent GC (Py…

Theorem proving doesn't require immutability it anything like that—its requirements are far more severe. Your language must have at least some fragment which is the internal proof language of a complete and consistent type theory! This is why, for instance, these languages are always Turing incomplete.

Hm... I'm not so sure about that. Of course, if we're speaking about dependent types, then yes. However, theorem proving could also be done automatically, by an external theorem prover, which would only need the refined type annotations on your variables to prove stuff (using the whatever theories the theorem prover knows about, such as linear integer mathematics, logic, real nonlinear math, vectors, datatypes, etc).

Re: Future of Programming Languages

#67

Post by tel »

tomp wrote: post #66
tel wrote: post #56

Earlier quoted context omitted.

Theorem proving doesn't require immutability it anything like that—its requirements are far more severe. Your language must have at least some fragment which is the internal proof language of a complete and consistent type theory! This is why, for instance, these languages are always Turing incomplete.

Hm... I'm not so sure about that. Of course, if we're speaking about dependent types, then yes. However, theorem proving could also be done automatically, by an external theorem prover, which would only need the refined type annotations on your variables to prove stuff (using the whatever theories the theorem prover knows about, such as linear integer mathematics, logic, real nonlinear math, vectors, datatypes, etc).

That can happen sometimes for some theories. It's super easy to run into places where proof search fails magnificently.

Re: Future of Programming Languages

#68

Post by creadee »

david927 wrote: post #35

The future of programming should be one language for all layers of the stack, from the database to the model to the UI. I think that hints that it should be a form of declarative. And if it's declarative, it should be focused on managing state. And if it's a thin syntactical representation of its VM, instructions/code could be interpreted immediately at entry and be managed as state, so you wouldn't be working with a…

> The future of programming should be one language for all layers of the stack, from the database to the model to the UI.

http://www.red-lang.org/ (a Rebol-like language) promises to do that. And perhaps right down to the OS (if I've understood it correctly).

Re: Future of Programming Languages

#69

Post by 14113 »

david927 wrote: post #35

The future of programming should be one language for all layers of the stack, from the database to the model to the UI. I think that hints that it should be a form of declarative. And if it's declarative, it should be focused on managing state. And if it's a thin syntactical representation of its VM, instructions/code could be interpreted immediately at entry and be managed as state, so you wouldn't be working with a…

The "one langauge for the whole stack" is being developed (for the web at least) through the language Links:

https://en.wikipedia.org/wiki/Links_(programming_language)

http://groups.inf.ed.ac.uk/links/

Re: Future of Programming Languages

#70

Post by david927 »

david927 wrote: post #35

The future of programming should be one language for all layers of the stack, from the database to the model to the UI. I think that hints that it should be a form of declarative. And if it's declarative, it should be focused on managing state. And if it's a thin syntactical representation of its VM, instructions/code could be interpreted immediately at entry and be managed as state, so you wouldn't be working with a…

Something like this: http://vimeo.com/107069470
Post reply on HN