5 ms·

Most languages have most of the listed features. The most interesting uncommon idea on that list to me is model of time. But only when it allows reversible comp

by Dn_Ab 15y ago

Most languages have most of the listed features. The most interesting uncommon idea on that list to me is model of time. But only when it allows reversible computing. I don't know how practical that is though. Anyways I've separated out the parts of the list which I think are less common. And listed examples off the top of my head so by no means is the below meant to be exhaustive. The uncommon ones: * Units - F# and Frink * homoiconicity - Lisps, Prolog, Io, Factor, Pure?, ... * macros and extensible syntax - the above list, Nemerle, Dylan * Unification - Prolog, Mercury - logic languages. anyone with type inference. anyone with predicate dispatch, a full example of which I do not know. F# Active patterns and scala extractors are close. * Error (managing numeric Imprecision) - Best I can understand I can only note that I have seen people treat similar concepts with monads. So haskell and any language which allows easy monads. So scala, f#, haskell, clojure, nemerle * Math types - Axiom/Aldor. To an extent, dependently typed languages - not practical. yet? * Polymorphism - Although it sounds more like structural typing. So OCaml, Scala. Also F#, haskell partially. * Aspects - Metaprogramming makes this relatively easy and clean to implement. so anyone with macros too. Arguably, monads are another way to follow the same philosophy. * term rewriting - not common, very niche and not mentioned, but pure-lang allows this and for abstract math programming it is a really fun & powerful concept. * pluggable types - F# has this as type providers. Gosu open types. I have used it in F#. At a start, it is a very awesome way to consume an api. Less Uncommon: * pattern matching - most functional languages. to a small extent the java.nexts * Immutable values - most functional languages * Parser - parser combinators or any language which implements PEGs e.g. Nemerle * Design by contract - eiffel and as a library in most languages * laziness - the usual functional suspects.

smcj 15y ago
Great overview, thanks! I added some new stuff to my reading list. :-) Just some notes from a Scala user: Regarding Units: I bundled some work done before by other people into a nicer package/syntax, apart from a few missing bits working with Units looks quite nicely in Scala, even without any special support for it: val mass: Mass[Double] = 4.0 kg val longMass: Mass[Long] = mass asLong val length: Length[Int] = (5 m) * 3 val time: Time[Int] = 1 s val doubleTime: Time[Int] = time + time val temp: Temperature[BigDecimal] = BigDecimal("22.22") k val speed: Speed[Int] = length / time val area: Area[Int] = length * length val volume: Volume[Int] = (23 m) * (1 m) * (1 m) val smallVolume: Volume[Double] = (volume asDouble) / 12.0 val area2: Area[Int] = volume / (23 m) val accel: Acceleration[Double] = (10.0 m) / ((2.0 s) * (1.0 s)) val accelNum: Double = accel toDouble The type annotations are not needed, but helps undestanding the design. Scala will very likely get macros in the next version, together with pluggable types/type providers. Macros not in a Lisp or "extend syntax" sense, but more in a Nemerle sense. Scala macros are written in fully statically typed Scala and are checked at compile time before and after expansion.
deleted 15y ago
[deleted]
ericn 15y ago
> Most languages have most of the listed features. Most of the features are not hard to find, but you have to switch languages a lot if you want to use them all.
gosub 15y ago
I think that the full numeric tower of scheme is what the author had in mind for Math types: big nums, true rationals, strong sense of exactness, etc... Also, CLOS (Common Lisp) has after, before and around methods for "aspect oriented".
lloeki 15y ago
> homoiconicity Python is not homoiconic but the ast module allows for wicked stuff. > Error (managing numeric Imprecision) Python decimal module does not handle precision error but handles significance, so that(from the doc) "for instance, 1.3 * 1.2 gives 1.56 while 1.30 * 1.20 gives 1.5600". This underrated module also does much more. Anyway I feel this precision stuff might be a job for numpy/scipy.

by Dn_Ab 15y ago

smcj 15y ago

Great overview, thanks! I added some new stuff to my reading list. :-) Just some notes from a Scala user: Regarding Units: I bundled some work done before by other people into a nicer package/syntax, apart from a few missing bits working with Units looks quite nicely in Scala, even without any special support for it: val mass: Mass[Double] = 4.0 kg val longMass: Mass[Long] = mass asLong val length: Length[Int] = (5 m) * 3 val time: Time[Int] = 1 s val doubleTime: Time[Int] = time + time val temp: Temperature[BigDecimal] = BigDecimal("22.22") k val speed: Speed[Int] = length / time val area: Area[Int] = length * length val volume: Volume[Int] = (23 m) * (1 m) * (1 m) val smallVolume: Volume[Double] = (volume asDouble) / 12.0 val area2: Area[Int] = volume / (23 m) val accel: Acceleration[Double] = (10.0 m) / ((2.0 s) * (1.0 s)) val accelNum: Double = accel toDouble The type annotations are not needed, but helps undestanding the design. Scala will very likely get macros in the next version, together with pluggable types/type providers. Macros not in a Lisp or "extend syntax" sense, but more in a Nemerle sense. Scala macros are written in fully statically typed Scala and are checked at compile time before and after expansion.

deleted 15y ago

[deleted]

ericn 15y ago

> Most languages have most of the listed features. Most of the features are not hard to find, but you have to switch languages a lot if you want to use them all.

gosub 15y ago

I think that the full numeric tower of scheme is what the author had in mind for Math types: big nums, true rationals, strong sense of exactness, etc... Also, CLOS (Common Lisp) has after, before and around methods for "aspect oriented".

lloeki 15y ago

> homoiconicity Python is not homoiconic but the ast module allows for wicked stuff. > Error (managing numeric Imprecision) Python decimal module does not handle precision error but handles significance, so that(from the doc) "for instance, 1.3 * 1.2 gives 1.56 while 1.30 * 1.20 gives 1.5600". This underrated module also does much more. Anyway I feel this precision stuff might be a job for numpy/scipy.