5 ms·

It seems like most languages are converging on a pretty standard feature set -- to the point where what "the" language is might not really matter because all it

It seems like most languages are converging on a pretty standard feature set -- to the point where what "the" language is might not really matter because all its competitors will probably be roughly similar. I think we're at the point where almost every language will have: - Lexical scope & closures - Reflection - Functions-as-objects - The standard map/filter/reduce functions (sometimes under different guises and names) - Immutability mostly by default, with the ability to override it - Some hybrid of dynamic and static typing The last one is probably a sticking point for a lot of people, but as far as I can tell it doesn't seem clear that either dynamic or static typing is obviously better in every context, and it seems like a lot of languages are recognizing that, either by introducing duck typing into a static context (IE, Go, or to an extent templates/generics), or introducing optional type constraints into dynamic languages via hints or asserts or just doing some JIT magic. Anyway, I just see a lot of convergence. In 2000, different programming languages were really a lot different, in 2014... most of them have a pretty similar feature set.

jamii 12y ago
We are working on a language that has no scoping, no data structures and no control flow (incidentalcomplexity.com). There is definitely still a ton of unexplored ground. The last few decades of PLT research feel like a huge depth-first search. Our notions of what programming is settled down in the 80s and haven't changed too much since. I suspect that PLT could do with a little more explore and a little less exploit.
mpweiher 12y ago
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 with C). So far, there is only a rudimentary implementation, but more sophisticated static conversions are planned. - Suitable for large and small applications. Yep, it does scripting and it does software architecture. - Open Source. Well, yes. - OO/Actors + FP. Currently, mostly OO. Higher Order Messaging gives a lot of the HOF/FP flavor, messages will be similar to generic functions (with a few crucial differences). Local vars will be immutable by default. - Theorem Proving system. No, too big. But yes, you will be able to build one yourself and integrated it into the language as if it were built-in. A big part of making this possible are the flexible scheme handlers that support Polymorphic Identifiers[2], meaning you can define storage variables, while flexible messaging lets you implement sophisticated control structures. - Scheme handlers + PIs also decouple storage definition from implementation, so you can have multiple implementations of the same schema. Automatic conversion is not built-in, but should be easy enough to build using the extensive meta-programming facilities. - Simple syntax: yes, first thing I stole from Smalltalk, though it needs extending/adapting here and there to deal with the software architecture aspects. - Easy to build DSLs. With Polymorphic Identifiers and flexible messaging, this is largely covered (also: the ability to define your own software-architectural connectors is largely isomorphic to being able to build your own language primitives). - First class relations. Not full there yet, but first class references/variables + connectors means you have all the tools to build these. - A later comment says 'I'm not sure the future of programming languages is even a "language." I imagine that we'll be connecting components on a bus architecture.'. Again, yes, ObjST's central theme is allowing language users to define architectural styles and then hook up the components. - Graphical: once you have made your software architecture explicit using custom connectors and components, you will often be able to diagram substantial parts of applications. [1] http://objective.st/ http://objective.st/ [2] https://www.hpi.uni-potsdam.de/hirschfeld/publications/media/WeiherHirschfeld_2013_PolymorphicIdentifiersUniformResourceAccessInObjectiveSmalltalk_AcmDL.pdf https://www.hpi.uni-potsdam.de/hirschfeld/publications/media...
- tel 12y ago
  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.
  - mpweiher 12y ago
    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/ http://soft.vub.ac.be/SOUL/
tomp 12y ago
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 (Python) or by being very careful (C++), using just GC and allocating freely (OCaml/Haskell, Java & Nim use "realtime" GC), using uniqueness semantics (Rust, ATS), using memory pools and great care (Objective C) - none of these approaches is perfect and optimal for all situations, and it's very frustrating that they don't really fit together - safety and security - I'm really interested about provable programs, either dependent typing (Agda) or refined types (Liquid Haskell, ATS). Both require quite a bit of "static knowledge" - immutable data structures, or unique mutable data structures, and effect annotations for functions (plus, there are additional problems in lazy languages). All of the above seem really hard to do using a dynamically typed language, but hopefully we can devise a way to have both a dynamic and a static provably efficient and secure code in the same program, same language, with clear split between the two.
- Dewie 12y ago
  > - memory usage - how should we handle deallocation - using reference counting with infrequent GC (Python) or by being very careful (C++), using just GC and allocating freely (OCaml/Haskell, Java & Nim use "realtime" GC), using uniqueness semantics (Rust, ATS), using memory pools and great care (Objective C) - none of these approaches is perfect and optimal for all situations, and it's very frustrating that they don't really fit together There is also ML Kit's usage of regions - I guess this is roughly the same std::Arena library in Rust.
- tel 12y ago
  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.
  - 12y ago

jamii 12y ago

We are working on a language that has no scoping, no data structures and no control flow (incidentalcomplexity.com). There is definitely still a ton of unexplored ground. The last few decades of PLT research feel like a huge depth-first search. Our notions of what programming is settled down in the 80s and haven't changed too much since. I suspect that PLT could do with a little more explore and a little less exploit.

mpweiher 12y ago

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 with C). So far, there is only a rudimentary implementation, but more sophisticated static conversions are planned. - Suitable for large and small applications. Yep, it does scripting and it does software architecture. - Open Source. Well, yes. - OO/Actors + FP. Currently, mostly OO. Higher Order Messaging gives a lot of the HOF/FP flavor, messages will be similar to generic functions (with a few crucial differences). Local vars will be immutable by default. - Theorem Proving system. No, too big. But yes, you will be able to build one yourself and integrated it into the language as if it were built-in. A big part of making this possible are the flexible scheme handlers that support Polymorphic Identifiers[2], meaning you can define storage variables, while flexible messaging lets you implement sophisticated control structures. - Scheme handlers + PIs also decouple storage definition from implementation, so you can have multiple implementations of the same schema. Automatic conversion is not built-in, but should be easy enough to build using the extensive meta-programming facilities. - Simple syntax: yes, first thing I stole from Smalltalk, though it needs extending/adapting here and there to deal with the software architecture aspects. - Easy to build DSLs. With Polymorphic Identifiers and flexible messaging, this is largely covered (also: the ability to define your own software-architectural connectors is largely isomorphic to being able to build your own language primitives). - First class relations. Not full there yet, but first class references/variables + connectors means you have all the tools to build these. - A later comment says 'I'm not sure the future of programming languages is even a "language." I imagine that we'll be connecting components on a bus architecture.'. Again, yes, ObjST's central theme is allowing language users to define architectural styles and then hook up the components. - Graphical: once you have made your software architecture explicit using custom connectors and components, you will often be able to diagram substantial parts of applications. [1] http://objective.st/ http://objective.st/ [2] https://www.hpi.uni-potsdam.de/hirschfeld/publications/media/WeiherHirschfeld_2013_PolymorphicIdentifiersUniformResourceAccessInObjectiveSmalltalk_AcmDL.pdf https://www.hpi.uni-potsdam.de/hirschfeld/publications/media...

tel 12y ago
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.
- mpweiher 12y ago
  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/ http://soft.vub.ac.be/SOUL/

tomp 12y ago

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 (Python) or by being very careful (C++), using just GC and allocating freely (OCaml/Haskell, Java & Nim use "realtime" GC), using uniqueness semantics (Rust, ATS), using memory pools and great care (Objective C) - none of these approaches is perfect and optimal for all situations, and it's very frustrating that they don't really fit together - safety and security - I'm really interested about provable programs, either dependent typing (Agda) or refined types (Liquid Haskell, ATS). Both require quite a bit of "static knowledge" - immutable data structures, or unique mutable data structures, and effect annotations for functions (plus, there are additional problems in lazy languages). All of the above seem really hard to do using a dynamically typed language, but hopefully we can devise a way to have both a dynamic and a static provably efficient and secure code in the same program, same language, with clear split between the two.

Dewie 12y ago
> - memory usage - how should we handle deallocation - using reference counting with infrequent GC (Python) or by being very careful (C++), using just GC and allocating freely (OCaml/Haskell, Java & Nim use "realtime" GC), using uniqueness semantics (Rust, ATS), using memory pools and great care (Objective C) - none of these approaches is perfect and optimal for all situations, and it's very frustrating that they don't really fit together There is also ML Kit's usage of regions - I guess this is roughly the same std::Arena library in Rust.
tel 12y ago
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.
- 12y ago