What will be the next MAJOR programming language for commercial use?
lvirden
the majority of the applications I was writing.
Next came PL/I. After a few years, C became the primary development
language written about, promoted and of course adopted by companies.
Then came C++ and after that Java.
It seems that languages go through cycles. And the current Java cycle
has been going on for some time now.
What do people see coming down the pike next? Some programming
language that will be able to be used across various sized servers and
desktops, across platforms, etc.?
Any new languages coming along? It won't be a scripting language -
most larger companies still suffer under the misconception that
scripting languages "are not real programming languages".
Or has programming language evolution reached its ultimate form in Java?
Jon Harrop
> Or has programming language evolution reached its ultimate form in Java?
OCaml is a much better language than Java, IMHO, and there are still
imperfections in OCaml...
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Walter
"lvirden" <lvi...@yahoo.com> wrote in message
news:1122648221.6...@g49g2000cwa.googlegroups.com...
The D Programming Language, www.digitalmars.com/d/
-Walter
Digital Mars
Jon Harrop
> The D Programming Language, www.digitalmars.com/d/
AFAIK, although D improves upon C++ in many ways, it still lacks many
features found in other programming languages. Off the top of my head:
Safety
Polymorphism
Closures
Higher-order functions
Type inference
Strong static type checking
Variants
Polymorphic variants
Pattern matching
Modules
Functors
Native lists
List comprehensions
Type classes
Safety first: given the trend of industry towards safer programming, I think
D's low-level approach will hinder its adoption.
Brevity: although D is more concise than C++ it is still much more verbose
than many other languages.
I'd like to see D implementations of my ray tracer benchmark:
http://www.ffconsultancy.com/free/ray_tracer/comparison.html
http://www.ffconsultancy.com/free/ray_tracer/languages.html
If any D compiler was available as a Debian package then I'd probably have
written it myself...
Walter
"Jon Harrop" <use...@jdh30.plus.com> wrote in message
news:42eb7bc2$0$14673$ed26...@ptn-nntp-reader02.plus.net...
> Walter wrote:
> > The D Programming Language, www.digitalmars.com/d/
>
> AFAIK, although D improves upon C++ in many ways, it still lacks many
> features found in other programming languages. Off the top of my head:
>
> Safety
> Polymorphism
> Closures
> Higher-order functions
> Type inference
> Strong static type checking
> Variants
> Polymorphic variants
> Pattern matching
> Modules
> Functors
> Native lists
> List comprehensions
> Type classes
D has most of the items on that list already.
> Safety first: given the trend of industry towards safer programming, I
think
> D's low-level approach will hinder its adoption.
Among it's other safety features, D has Contract Programming, which is a
major leap forward in creating safe, robust programs.
> Brevity: although D is more concise than C++ it is still much more verbose
> than many other languages.
>
> I'd like to see D implementations of my ray tracer benchmark:
>
> http://www.ffconsultancy.com/free/ray_tracer/comparison.html
> http://www.ffconsultancy.com/free/ray_tracer/languages.html
>
> If any D compiler was available as a Debian package then I'd probably have
> written it myself...
GDC, the Gnu D Compiler, should be on Debian.
-Walter
www.digitalmars.com/d/ the D Programming Language
Andreas Koch
> What do people see coming down the pike next? Some programming
> language that will be able to be used across various sized servers and
> desktops, across platforms, etc.?
I don't say its good but its mainstream...
Jon Harrop
>> Safety
>> Polymorphism
>> Closures
>> Higher-order functions
>> Type inference
>> Strong static type checking
>> Variants
>> Polymorphic variants
>> Pattern matching
>> Modules
>> Functors
>> Native lists
>> List comprehensions
>> Type classes
>
> D has most of the items on that list already.
I've just checked the D web pages and your statement seems to be far from
correct. D does support (both OO and parametric) polymorphism and HOFs (I
think). D partially supports closures. But it doesn't seem to support any
of the other features. And you can add "Currying" to the list.
There may be some confusion about what I meant so I'll clarify some of the
points:
Safety: programs should never be able to segfault, corrupt memory etc.
Variants: types such as "type x = A | B | C".
Pattern matching: expressions such as "function A -> 1 | B -> 2 | C -> 3".
Native lists: a syntax for lists such as "[1; 2; 3]".
Currying: function return values such as "fun a b -> a + 2*b".
It would be nice to have a more comprehensive list of features supported by
various languages. I can't find a comparison between D and any ML, for
example.
> Among it's other safety features, D has Contract Programming, which is a
> major leap forward in creating safe, robust programs.
What can cause a D program to segfault, for example?
>> If any D compiler was available as a Debian package then I'd probably
>> have written it myself...
>
> GDC, the Gnu D Compiler, should be on Debian.
I can't find it on Debian (stable, testing or unstable). Can you give us a
link to the .deb, please?
Walter
> Walter wrote:
> >> Safety
> >> Polymorphism
> >> Closures
> >> Higher-order functions
> >> Type inference
> >> Strong static type checking
> >> Variants
> >> Polymorphic variants
> >> Pattern matching
> >> Modules
> >> Functors
> >> Native lists
> >> List comprehensions
> >> Type classes
> >
> > D has most of the items on that list already.
>
> I've just checked the D web pages and your statement seems to be far from
> correct. D does support (both OO and parametric) polymorphism and HOFs (I
> think). D partially supports closures. But it doesn't seem to support any
> of the other features. And you can add "Currying" to the list.
> >> Safety
Yes.
> >> Polymorphism
Yes.
> >> Closures
Yes. (dynamic closures)
> >> Higher-order functions
Don't know what that means.
> >> Type inference
Not sure what you mean.
> >> Strong static type checking
Yes.
> >> Variants
Can be done using a user defined class.
> >> Polymorphic variants
Can be done using a user defined class.
> >> Pattern matching
? Supports function overloading, template partial specialization, and
regular expression pattern matching.
> >> Modules
Yes.
> >> Functors
Yes.
> >> Native lists
Can be done simply with a user defined class.
> >> List comprehensions
I don't know what that is.
> >> Type classes
Not sure what you mean, but all types in D are represented with a "TypeInfo"
class instance giving information about it.
> There may be some confusion about what I meant so I'll clarify some of the
> points:
>
> Safety: programs should never be able to segfault, corrupt memory etc.
> Variants: types such as "type x = A | B | C".
> Pattern matching: expressions such as "function A -> 1 | B -> 2 | C -> 3".
> Native lists: a syntax for lists such as "[1; 2; 3]".
> Currying: function return values such as "fun a b -> a + 2*b".
>
> It would be nice to have a more comprehensive list of features supported
by
> various languages. I can't find a comparison between D and any ML, for
> example.
You can try www.digitalmars.com/d/comparison.html
> > Among it's other safety features, D has Contract Programming, which is a
> > major leap forward in creating safe, robust programs.
>
> What can cause a D program to segfault, for example?
A seg fault is just a thrown exception, the same thing that happens when a
contract violation occurs.
> >> If any D compiler was available as a Debian package then I'd probably
> >> have written it myself...
> >
> > GDC, the Gnu D Compiler, should be on Debian.
>
> I can't find it on Debian (stable, testing or unstable). Can you give us a
> link to the .deb, please?
I think DMD will work out of the box on Debian. Some people have compiled
GDC for Debian, but I don't know if they've put up a link for the binaries.
cr88192
> the majority of the applications I was writing.
> Next came PL/I. After a few years, C became the primary development
> language written about, promoted and of course adopted by companies.
> Then came C++ and after that Java.
afaict c still exceeds c++ in terms of use by a small margain.
java, as of yet, is not much competition for c/c++, and if it will gain some
dominance, it has not done so yet.
> It seems that languages go through cycles. And the current Java cycle
> has been going on for some time now.
>
maybe, maybe not.
> What do people see coming down the pike next? Some programming
> language that will be able to be used across various sized servers and
> desktops, across platforms, etc.?
>
well, in a way, c and c++ allready do this pretty well. yes, you have to
recompile, and (sometimes) excert some effort in porting, but these costs
are minor in comparrison to some "other" costs.
> Any new languages coming along? It won't be a scripting language -
> most larger companies still suffer under the misconception that
> scripting languages "are not real programming languages".
>
a problem imo with java is that it falls in the land between conventional
programming and scripting languages.
for example, it has lots of things controlled by the vm (eg: memory
management), and lacks such things as pointers (imo, quite necessary for
many programming tasks, or at least absent some other "high-level"
mechanisms). in particular, for many "less straightforwards" tasks, it is
sometimes necessary to do some rather ugly things with pointers.
some things are just convinient, eg, having a pointer into an array being
used as a primitive object. quite common is use of pointers into float
arrays (or matrices) as vectors, for example. also, pointers are imo
necessary for management of many kinds of in-memory compressed structures.
many c apps, for example, do some of their own memory management for various
reasons. in my case, it was wanting dynamic typing and garbage collection.
some code also does specialty memory management, for example, "rotating
allocators" (allocating some kinds of data temporarily, in a way that they
will be overwritten once the buffer wraps around). also, doing allocation
into an array can be pretty convinient, as then one has both an allocator,
and a convinient indexing mechanism.
java is likely to force objects in these cases, and would likely expect
methods for all possible uses (a matrix class with an 'extract vector'
method).
in many ways, java still looks and behaves like a conventional language
(this could be good, at least it allows fast/efficient vm's, but java is
not-so-great sometimes in script language terms).
I am not really given dynamic/variant typing, there are not things like
lexical scope and closures (actually, lack of lexical scope may be a plus in
a few situations as well). there are lack of "lists". "arrays" are really a
different concept, and "container classes" are just kind of lame.
likewise, having to handle "all" exceptions is annoying, sometimes the
developer "wants" to ignore some errors, or allow the vm to blow up due to
an unhandled exception (if it is important, and the developer didn't bother,
then blowing up is likely the best course of action).
additionally, it has the vm endlessly carried around, and not as cleanly
integrated into the os as is with conventional apps (or the .net vm in the
case of windows). also, the sometimes lack of a clear entry point, class
directory/heirarchy issues, ... can be a hassle.
all in all, all this is not looking like a plus for java, it could be
better. there are still many cases where the java design makes sense (some
kinds of applications, servers, game-scripts, ...), but it is doubtful it
will be able to compete with c and c++ "in general", or at least not at this
time.
> Or has programming language evolution reached its ultimate form in Java?
>
as noted above, I seriously doubt it.
imo, c# is more likely to be a competitor with c++ than java, but c# is
currently not-very-portable.
now: java and c# vs c++, what really do they have apart from marginally
increased newbie friendliness or cleaner syntax?
I can't think of much.
my oppinion:
there is no one true language.
c and c++ have their domains (important to note is, even between these,
there is a little bit of a seperation between c and c++ domain).
java has its domain.
scripting languages have their domains.
using a language outside its domain is likely to introduce an unpleasant
experience.
so, I live primarily within the land of c (with scripting languages as well,
but doing scripting...), and with my personal garbage collection and dynamic
typing systems.
I have ventured some into c++. c++, for some of it's costs, does offer a lot
of really nice features.
as a particular example, c++'s features could actually be used, for example,
to make my dynamic typing system actually nicer (than in c). some other
features would likely be nice though (namely, if they existed, would allow
cleaner integration of dynamic typing into the base language).
in c, most of the conversion is done explicitly, but oh well...
c++ offers some tempting features, so eventually I may do more stuff in it.
for now my codebase is a rather large mass of c.
Jon Harrop
>> >> Safety
>
> Yes.
Does D support pointer arithmetic? If so, what happens when an invalid
pointer is dereferenced?
>> >> Polymorphism
>
> Yes.
D supports OO and parametric polymorphism (via templates). However, in ML,
type inference allows many functions to be polymorphic without the
programmer having to explicitly do anything. For example, the following
function accepts a function "g" and a value "x" and returns "g(g(x))":
$ ocaml
Objective Caml version 3.08.3
# let f g x = g(g(x));;
val f : ('a -> 'a) -> 'a -> 'a = <fun>
#
The function is then valid for any type 'a. For example, this computes the
increment of the increment of 3:
# f (fun n -> n+1) 3;;
- : int = 5
>> >> Closures
>
> Yes. (dynamic closures)
I'm not sure what a "dynamic" closure is. Your web page states "The stack
variables, however, are not valid once the function declaring them has
exited, in the same manner that pointers to stack variables are not valid
upon exit from a function". This is a very low-level notion of a closure
that I've never come across. In ML, you just return a function and the
compiler takes care of working out what environment values need to be kept.
For example, the following (convoluted!) addition function is valid in OCaml
but, presumably, the equivalent would be invalid in D because the argument
"x" to "f" might be stored on the stack?
# let f x =
let g y = x + y in
g;;
val f : int -> int -> int = <fun>
In D, can you partially apply a function? For example, the following OCaml
defines an "add" function and then an "incr" function in terms of "add" and
finally increments 3 to get 4:
# let add i j = i+j;;
val add : int -> int -> int = <fun>
# let incr = add 1;;
val incr : int -> int = <fun>
# incr 3;;
- : int = 4
>> >> Higher-order functions
>
> Don't know what that means.
A higher-order function is a function that accepts a function as an
argument. The "map" function is the pedagogical example. It accepts a
function "f" and a list "[a; b; c; ...]" and returns the list "[f(a); f(b);
f(c); ...]". I think D will do this ok but you probably have to write
function-pointer-style type declarations?
>> >> Type inference
>
> Not sure what you mean.
With type inference, types are inferred by the compiler and do not have to
be written explicitly by the programmer. For example, the following OCaml
function increments the given integer but the type "int" is not written
explicitly in the function:
# let succ n = 1 + n;;
val succ : int -> int = <fun>
This is the main reason for OCaml's brevity.
> > >> Variants
>
> Can be done using a user defined class.
That's a no. :-)
Variants can be considered as such a common OO pattern that it is worth
having syntactic sugar to support them. For an example of OO vs a variant
type, look at the C++ and OCaml implementations of the scene tree in my ray
tracer:
http://www.ffconsultancy.com/free/ray_tracer/comparison.html
>> >> Polymorphic variants
>
> Can be done using a user defined class.
In addition to the benefits of ordinary variant types, polymorphic variants
can be even more useful in the presence of type inference. For example,
consider the following interpreter:
# type expr =
Int of int
| Var of string
| Let of string * expr * expr
| Add of expr * expr;;
type expr =
Int of int
| Var of string
| Let of string * expr * expr
| Add of expr * expr
# let rec eval state = function
Int i -> i
| Var s -> List.assoc s state
| Let (s, body, rest) -> eval ((s, eval state body) :: state) rest
| Add (e1, e2) -> eval state e1 + eval state e2;;
val eval : (string * int) list -> expr -> int = <fun>
This can be used to interpret the program "let x=2 in x+3":
# eval [] (Let("x", Int 2, Add(Var "x", Int 3)));;
- : int = 5
The program can be written without defining the type "expr" by using
polymorphic variants. OCaml then infers the variant type:
# let rec eval state = function
`Int i -> i
| `Var s -> List.assoc s state
| `Let (s, body, rest) -> eval ((s, eval state body) :: state) rest
| `Add (e1, e2) -> eval state e1 + eval state e2;;
val eval :
('a * int) list ->
([< `Add of 'b * 'b | `Int of int | `Let of 'a * 'b * 'b | `Var of 'a ]
as 'b) ->
int = <fun>
I can't see how this can be done using ordinary classes in D.
>> >> Pattern matching
>
> ? Supports function overloading, template partial specialization, and
> regular expression pattern matching.
Yes, I meant ML pattern matching rather than regexps. Sorry, I forgot how
many of these terms have different meanings...
ML pattern matching is an advancement upon the switch statement. For
example, this convoluted C code:
int fib(int n) {
switch (n) {
case 1 : return 1;
case 2 : return 1;
default : return fib(n-1) + fib(n-2);
}
}
can be written in OCaml as:
# let rec fib n = match n with 1 -> 1 | 2 -> 1 | n -> fib(n-1) + fib(n-2);;
val fib : int -> int = <fun>
However, ML pattern matches can be applied to many other types. For example,
given the following definition of a (polymorphic) tree as a variant type:
# type 'a tree = Empty | Node of 'a tree * 'a * 'a tree;;
type 'a tree = Empty | Node of 'a tree * 'a * 'a tree
This function counts the number of non-leaf nodes:
# let rec count = function
Empty -> 0
| Node(l, v, r) -> count l + 1 + count r;;
val count : 'a tree -> int = <fun>
# count (Node(Node(Empty, 1, Empty), 2, Empty));;
- : int = 2
As lists are built-in, they can be decomposed in a pattern just as they are
constructed by an expression. Specifically, the list "[1; 2; 3]" can also
be written "1 :: 2 :: 3 :: []" and the pattern "h :: t" gives the head "h"
of the list (the first element) and the tail "t" (the list containing the
remaining elements). For example, the following function counts the number
of elements in a list:
# let rec length = function [] -> 0 | _ :: t -> 1 + length t;;
val length : 'a list -> int = <fun>
ML pattern matching is a huge topic with lots of interesting aspects,
including the catching of redundant patterns and the optimisation of
complicated pattern matches, e.g. using perfect hashes.
>> >> Modules
>
> Yes.
>
>> >> Functors
>
> Yes.
There may be another discrepancy here. In ML, functors are module-level
functions that map modules onto modules. For example, the OCaml stdlib
contains a module "String" which implements strings. This can be applied to
the functor "Set" to obtain a module implementing a set of strings:
# module StringSet = Set.Make(String);;
module StringSet :
sig
type elt = String.t
type t = Set.Make(String).t
val empty : t
val is_empty : t -> bool
val mem : elt -> t -> bool
val add : elt -> t -> t
val singleton : elt -> t
val remove : elt -> t -> t
val union : t -> t -> t
val inter : t -> t -> t
val diff : t -> t -> t
val compare : t -> t -> int
val equal : t -> t -> bool
val subset : t -> t -> bool
val iter : (elt -> unit) -> t -> unit
val fold : (elt -> 'a -> 'a) -> t -> 'a -> 'a
val for_all : (elt -> bool) -> t -> bool
val exists : (elt -> bool) -> t -> bool
val filter : (elt -> bool) -> t -> t
val partition : (elt -> bool) -> t -> t * t
val cardinal : t -> int
val elements : t -> elt list
val min_elt : t -> elt
val max_elt : t -> elt
val choose : t -> elt
val split : elt -> t -> t * bool * t
end
>> >> Native lists
>
> Can be done simply with a user defined class.
Again, the result will require much more code. Consider this function which
dices a list into a list of 3-element lists:
# let rec dice3 = function
[] -> []
| [_] | [_; _] as l -> [l]
| h1 :: h2 :: h3 :: t -> [h1; h2; h3] :: dice3 t;;
val dice3 : 'a list -> 'a list list = <fun>
# dice3 [1; 2; 3; 4; 5; 6; 7; 8];;
- : int list list = [[1; 2; 3]; [4; 5; 6]; [7; 8]]
>> >> List comprehensions
>
> I don't know what that is.
Syntactic sugar for building lists. For example, a list of even numbers can
be built in Python like this:
>>> print [i for i in range(20) if i%2 == 0]
[0, 2, 4, 6, 8, 10, 12, 14, 16, 18]
>> >> Type classes
>
> Not sure what you mean, but all types in D are represented with a
> "TypeInfo" class instance giving information about it.
Type classes are a very generic and powerful type system construct made
famous by the programming language Haskell. For example, with type classes
you can represent a function with the type:
val add : 'a -> 'a -> 'a
for all 'a in {int, float}.
>> It would be nice to have a more comprehensive list of features supported
> by
>> various languages. I can't find a comparison between D and any ML, for
>> example.
>
> You can try www.digitalmars.com/d/comparison.html
That was the page I was reading. It is great for someone coming from a C++
background (which is most readers, after all) but it lists very few
features found in other state-of-the-art programming languages. I think
that would be very interesting, although it wouldn't show D in such a
positive light.
>> > Among it's other safety features, D has Contract Programming, which is
>> > a major leap forward in creating safe, robust programs.
>>
>> What can cause a D program to segfault, for example?
>
> A seg fault is just a thrown exception, the same thing that happens when a
> contract violation occurs.
I don't know anything about contract programming, although I have heard of
it. Must contracts be verified at run-time?
>> > GDC, the Gnu D Compiler, should be on Debian.
>>
>> I can't find it on Debian (stable, testing or unstable). Can you give us
>> a link to the .deb, please?
>
> I think DMD will work out of the box on Debian. Some people have compiled
> GDC for Debian, but I don't know if they've put up a link for the
> binaries.
I'll have a go and see if I can port my ray tracer.
Great work on D, BTW. :-)
Christopher Browne
>
> Don't know what that means.
Unlikely that it supports that, then.
>> >> Type inference
>
> Not sure what you mean.
If you don't know what it means, then it's unlikely that it is
supported, as you can't be aware of the typical algorithm used for it.
>> >> Pattern matching
>
> ? Supports function overloading, template partial specialization, and
> regular expression pattern matching.
None of those are language-based pattern matching.
An ML-based expression is the pattern matching approach to factorial:
let fact 0 = 1
| fact n = n * fact(n-1)
The explicit control structure is thus:
match expr with
p1 -> action1
| p2 -> action2
| p3 -> action3
| p4 -> action4
For this to be useful, you need to have some form of native tuple/list
comprehension as well as a wildcard pattern.
match value with
(true,false) -> action_for_true_and_false
| (true,true) -> action_for_both_true
| (false,_) -> action_for_false_and_any_value
This is *stunningly* useful when writing compilers.
>> >> Native lists
>
> Can be done simply with a user defined class.
How will the above pattern matching work, then?
>> >> List comprehensions
>
> I don't know what that is.
It's like sequence generators in Icon.
>> >> If any D compiler was available as a Debian package then I'd probably
>> >> have written it myself...
>> >
>> > GDC, the Gnu D Compiler, should be on Debian.
>>
>> I can't find it on Debian (stable, testing or unstable). Can you give us a
>> link to the .deb, please?
>
> I think DMD will work out of the box on Debian. Some people have compiled
> GDC for Debian, but I don't know if they've put up a link for the binaries.
If it is available on Debian, then there should certainly be an entry
in the package listings at <http://debian.org/>.
If there isn't one, then it has to be hacked in by hand, which means
few will be interested in bothering.
--
let name="cbbrowne" and tld="acm.org" in String.concat "@" [name;tld];;
http://cbbrowne.com/info/rdbms.html
Rules of the Evil Overlord #153. "My Legions of Terror will be an
equal-opportunity employer. Conversely, when it is prophesied that no
man can defeat me, I will keep in mind the increasing number of
non-traditional gender roles." <http://www.eviloverlord.com/>
Marco
example, this convoluted C code:
int fib(int n) {
switch (n) {
case 1 : return 1;
case 2 : return 1;
default : return fib(n-1) + fib(n-2);
}
}
can be written in OCaml as:
# let rec fib n = match n with 1 -> 1 | 2 -> 1 | n -> fib(n-1) +
fib(n-2);;
val fib : int -> int = <fun>
"
why is the OCaml code clearer? not to me, if one was trained on C
and/or Pascal style languages like me
the OCaml just uses a different syntax and jams more info on a single
line which makes finding and modifying a single case potentially more
difficult
D is catering to current C, C++, Java, C# folks (currently a huge
majority of the commercial programming world - the post topic) and
makes no apologies otherwise
At least OCaml appears readable versus some of the other languages
I've seen!
Walter
"Marco" <prenom...@yahoo.com> wrote in message
news:1122828657.3...@z14g2000cwz.googlegroups.com...
> D is catering to current C, C++, Java, C# folks (currently a huge
> majority of the commercial programming world - the post topic) and
> makes no apologies otherwise
That's true. D was not designed as a better OCaml <g>, a language I am not
familiar enough with to make an intelligent comment about.
Walter
"Christopher Browne" <cbbr...@acm.org> wrote in message
news:m3wtn7s...@mobile.int.cbbrowne.com...
> > ? Supports function overloading, template partial specialization, and
> > regular expression pattern matching.
>
> None of those are language-based pattern matching.
>
> An ML-based expression is the pattern matching approach to factorial:
>
> let fact 0 = 1
> | fact n = n * fact(n-1)
That's pretty much how C++ (and D) template metaprogramming looks, although
the syntax isn't as simple. Template partial specialization appears to be
language based pattern matching.
Walter
"cr88192" <cr8...@NOSPAM.hotmail.com> wrote in message
news:111f7$42ec11a0$ca80176e$31...@saipan.com...
> for example, it has lots of things controlled by the vm (eg: memory
> management), and lacks such things as pointers (imo, quite necessary for
> many programming tasks, or at least absent some other "high-level"
> mechanisms). in particular, for many "less straightforwards" tasks, it is
> sometimes necessary to do some rather ugly things with pointers.
One litmus test for me for a "systems programming language" is can one
implement a decent garbage collector with it? I can't see how one could
practically implement, for example, the Java vm in Java, so Java isn't a
systems programming language.
Jon Harrop
> "ML pattern matching is an advancement upon the switch statement. For
> example, this convoluted C code:
>
> int fib(int n) {
> switch (n) {
> case 1 : return 1;
> case 2 : return 1;
> default : return fib(n-1) + fib(n-2);
> }
> }
>
> can be written in OCaml as:
>
> # let rec fib n = match n with 1 -> 1 | 2 -> 1 | n -> fib(n-1) +
> fib(n-2);;
> val fib : int -> int = <fun>
> "
>
> why is the OCaml code clearer?
It isn't. That example was just to show the equivalence for simple patterns.
> not to me, if one was trained on C
> and/or Pascal style languages like me
> the OCaml just uses a different syntax
No, OCaml is the same for this simple case but substantially better for more
advanced patterns.
> and jams more info on a single
> line which makes finding and modifying a single case potentially more
> difficult
You can write the OCaml over several lines, of course:
let rec fib n = match n with
1 | 2 -> 1
| n -> fib(n-1) + fib(n-2);;
For a slightly more advanced example, the following dissects a simple
built-in variant type "None | Some of 'a":
# let may f = function None -> () | Some x -> f x;;
val may : ('a -> unit) -> 'a option -> unit = <fun>
# may print_endline None;;
- : unit = ()
# may print_endline (Some "Hello world");;
Hello world
- : unit = ()
The C, C++, Java, C# and D equivalents of that 1-line OCaml function are
substantially more obfuscated. For example, the following 32 lines of C++
are the nearest I can get:
#include <iostream>
#include <string>
class option {
public:
template<typename T>
void may(void (*)(T)) = 0;
};
class None : public option {
public:
None() {}
template<typename T>
void may(void (*)(T)) {}
};
template<typename T>
class Some : public option {
public:
T data;
Some(T x) : data(x) {}
void may(void (*f)(T)) { f(data); }
};
void print_endline(std::string s) { std::cout << s << std::endl; }
int main() {
None().may(print_endline);
Some<std::string>("Hello world").may(print_endline);
return 0;
}
> D is catering to current C, C++, Java, C# folks
Yes, absolutely.
> (currently a huge majority of the commercial programming world - the post
> topic)
No, the post topic was about the future of commercial programming. I see no
reason for commerce to continue along the C++ path. For example, Java is
now very popular in industry and it represents a significant departure from
C++...
> and makes no apologies otherwise
My objection was to the author claiming that D supports many languages
features that it clearly doesn't. I'm sure D is a substantial improvement
upon C++ but, from my point of view, a fair comparison should include other
languages, like OCaml, SML, Ruby, Python, Clean and so on.
I also appreciate the huge amount of work that Walter clearly has and
continues to put into D. It is a very interesting project and has gained a
lot of interest. However, it lacks may very useful features found in other
programming languages. In their simplest form, many of these features would
not be difficult to add, so I'm really advocating that Walter take a closer
look at the other languages, like OCaml.
Jon Harrop
>> An ML-based expression is the pattern matching approach to factorial:
>>
>> let fact 0 = 1
>> | fact n = n * fact(n-1)
>
> That's pretty much how C++ (and D) template metaprogramming looks,
> although the syntax isn't as simple. Template partial specialization
> appears to be language based pattern matching.
OCaml can do a huge amount more with pattern matching. You don't need to
make the above example much more complicated before the amount of
equivalent C++ (or D) code explodes. See my other posts.
Note that I am (was) familiar with template metaprogramming and partial
specialisation.
Walter
> Walter wrote:
> >> >> Safety
> > Yes.
> Does D support pointer arithmetic?
Yes.
> If so, what happens when an invalid pointer is dereferenced?
You get a hardware generated exception. You can argue that this makes D
inherently "unsafe". I would argue that "safety" is a continuum between more
safe and less safe, and there is no obvious dividing line between the two. I
will also argue that D has many characteristics that make the need for
pointers much less than in, say, C, so one rarely has to deal with pointers.
Also, D has Contract Programming which can help a great deal.
> >> >> Closures
> > Yes. (dynamic closures)
> I'm not sure what a "dynamic" closure is. Your web page states "The stack
> variables, however, are not valid once the function declaring them has
> exited, in the same manner that pointers to stack variables are not valid
> upon exit from a function".
That's exactly what a dynamic closure is. A static closure would "capture"
the local variables so they survive the function exit.
> This is a very low-level notion of a closure
> that I've never come across.
It's very useful, and much more efficient than a static closure, although
less functional.
> In D, can you partially apply a function? For example, the following OCaml
> defines an "add" function and then an "incr" function in terms of "add"
and
> finally increments 3 to get 4
I don't get it.
> >> >> Higher-order functions
> > Don't know what that means.
> A higher-order function is a function that accepts a function as an
> argument. The "map" function is the pedagogical example. It accepts a
> function "f" and a list "[a; b; c; ...]" and returns the list "[f(a);
f(b);
> f(c); ...]". I think D will do this ok but you probably have to write
> function-pointer-style type declarations?
Since D supports function literals, you can do this directly.
> >> >> Type inference
> > Not sure what you mean.
> With type inference, types are inferred by the compiler and do not have to
> be written explicitly by the programmer. For example, the following OCaml
> function increments the given integer but the type "int" is not written
> explicitly in the function:
>
> # let succ n = 1 + n;;
> val succ : int -> int = <fun>
>
> This is the main reason for OCaml's brevity.
You can do this in D (a bit clumsilly) using the typeof construct. Making
this work more naturally is an often asked for feature, and will get added.
> > > >> Variants
> >
> > Can be done using a user defined class.
>
> That's a no. :-)
>
> Variants can be considered as such a common OO pattern that it is worth
> having syntactic sugar to support them.
I've made just this argument in support of D's builtin arrays, associative
arrays, complex numbers, etc. I'm not sold, though, on doing it for
variants.
> >> >> Functors
> >
> > Yes.
>
> There may be another discrepancy here. In ML, functors are module-level
> functions that map modules onto modules.
In C++ and D, a functor is essentially a function pointer that also contains
persistent state. It is implemented by overloading the () operator for a
class.
> >> >> Native lists
> > Can be done simply with a user defined class.
> Again, the result will require much more code. Consider this function
which
> dices a list into a list of 3-element lists:
You'd probably do this with dynamic arrays in D.
> That was the page I was reading. It is great for someone coming from a C++
> background (which is most readers, after all) but it lists very few
> features found in other state-of-the-art programming languages. I think
> that would be very interesting, although it wouldn't show D in such a
> positive light.
D isn't a functional programming language, and it would be hard to create
such a table and have it have any real meaning. Comparison tables only work
when languages are reasonably similar. One problem, for example, is that
terms like "functor" have very different meanings in very different
languages.
> I don't know anything about contract programming, although I have heard of
> it. Must contracts be verified at run-time?
Yes.
> I'll have a go and see if I can port my ray tracer.
>
> Great work on D, BTW. :-)
Thanks!
cr88192
"Walter" <wal...@digitalmars.nospamm.com> wrote in message
news:bu-dnezgieJ...@comcast.com...
likewise, I can imagine many other things that would be problematic.
whether this is good or bad, ofcourse, depends on its intended use, however,
I feel something this signifigant imo rules out the language as a canidate
for a replacement of c/c++.
c and c++ have their limits, namely, changing much of anything post-build
can be very painful, and sometimes getting an app to recompile is itself
horridly painful. likewise, for code that is modified fairly often (or after
app build) imo it makes sense (actually, from the user perspective likely it
is a lot better than many apps which use globs of code compiled to dll's,
even with the source it is often difficult to create dll's which still work
with the app).
java does have a plus here. it is that, or an actual scripting language.
depending on needs (and the script interpreter), java is likely to give
superior performance. it is also likely to be a little easier to
autogenerate ffi code than would be with many (dynamically typed) scripting
languages.
I don't know.
in my case I have a scripting language. it works...
a sad point is that I don't put much work into the language anymore, but it
typically works well enough when I try to use it.
rough description: a language resembling javascript, with semantics a little
closer to many other prototype oo, and a few more fp features thrown on.
I have, however, often considered the idea of a statically typed script
language with more c (or java) like behavior, which would be a little more
suitible for tasks that might require some actual computation or whatever,
but is still bytecoded and runs in a vm (java would work, but so would a
"mini-c").
motivation, however, is lacking. I don't really "need" something like
this...
Jon Harrop
>> If so, what happens when an invalid pointer is dereferenced?
>
> You get a hardware generated exception. You can argue that this makes D
> inherently "unsafe". I would argue that "safety" is a continuum between
> more safe and less safe, and there is no obvious dividing line between the
> two.
The dividing line used in ML is: No self-contained ML program should be able
to cause a segfault.
OCaml mostly complies with this by enforcing bounds checking and static type
checking and so forth. However, there are a few places that are not type
safe (e.g. marshalling) where segfaults can still occur.
[dynamic closures]
>> This is a very low-level notion of a closure that I've never come across.
>
> It's very useful, and much more efficient than a static closure, although
> less functional.
I'd like to see a performance comparison between D and OCaml closures then.
Also, how can you tell when something is stored on the stack, to know that
it is safe to use a dynamic closure?
>> In D, can you partially apply a function? For example, the following
>> OCaml defines an "add" function and then an "incr" function in terms of
>> "add"
> and
>> finally increments 3 to get 4
>
> I don't get it.
Here's another example. This calculates the max of 5 and each element in a
list in turn, clamping the values to be >=5:
# List.map (max 5) [1; 2; 3; 4; 5; 6; 7; 8; 9];;
- : int list = [5; 5; 5; 5; 5; 6; 7; 8; 9]
>> >> >> Type inference
>> This is the main reason for OCaml's brevity.
>
> You can do this in D (a bit clumsilly) using the typeof construct. Making
> this work more naturally is an often asked for feature, and will get
> added.
I think type inference is a great feature and I look forward to seeing it in
D!
>> > > >> Variants
>> Variants can be considered as such a common OO pattern that it is worth
>> having syntactic sugar to support them.
>
> I've made just this argument in support of D's builtin arrays, associative
> arrays, complex numbers, etc. I'm not sold, though, on doing it for
> variants.
In OCaml code, variants are more common than arrays, associative arrays,
complex numbers and many other constructs. Indeed, they are one of the most
important, primitive language constructs. I think they would be a welcome
addition to D (provided you also support pattern matching).
>> >> >> Native lists
>> > Can be done simply with a user defined class.
>> Again, the result will require much more code. Consider this function
> which
>> dices a list into a list of 3-element lists:
>
> You'd probably do this with dynamic arrays in D.
Right, you'd do it the same way in Fortran. OCaml's lists have the advantage
that they can be pulled apart (using pattern matching) as easily as they
were constructed.
Personally, I'd like to see D support lists and pattern matching but adding
more powerful pattern matching over arrays. For example, you can decapitate
a list to get the head and tail in OCaml but you cannot "decapitate" an
array to get the first element and the subarray of the remaining elements.
That would allow you to write remarkably succinct, comprehensible and
efficient code. My favourite example is a 1D wavelet transform:
# let haar l =
let rec aux l s d = match l, s with
[s], [] -> s :: d
| [], s -> aux s [] d
| h1::h2::t, s -> aux t (h1+h2::s) (h1-h2::d)
| _ -> invalid_arg "haar" in
aux l [] [];;
val haar : int list -> int list = <fun>
>> That was the page I was reading. It is great for someone coming from a
>> C++ background (which is most readers, after all) but it lists very few
>> features found in other state-of-the-art programming languages. I think
>> that would be very interesting, although it wouldn't show D in such a
>> positive light.
>
> D isn't a functional programming language, and it would be hard to create
> such a table and have it have any real meaning. Comparison tables only
> work when languages are reasonably similar. One problem, for example, is
> that terms like "functor" have very different meanings in very different
> languages.
True. I'd like to try... :-)
Marcin 'Qrczak' Kowalczyk
>> If so, what happens when an invalid pointer is dereferenced?
>
> You get a hardware generated exception.
This probably means that D is unsafe. If you are not lucky, the
pointer will access a random other object.
> I would argue that "safety" is a continuum between more safe and
> less safe, and there is no obvious dividing line between the two.
There is: either it's guaranteed that no program has undefined
behavior (when it can execute random bits of memory as code or
shoot at arbitrary data memory) or not.
There are languages which are technically unsafe but they contain a
useful safe subset which encompasses almost the whole language and
it's easy to find all uses of unsafe features.
It happens that most languages with GC are safe or almost safe. Most
languages without GC are either unsafe or have limited data structures
(all values are independent, there is no conceptual sharing of
subobjects).
There is a related notion which is not that strict: features which
under some circumstances return a result which is almost always
undesirable instead of signalling an error, for the sake of efficiency,
are similar to unsafe features but don't cause undefined behavior.
Examples:
- ignoring overflow on integer arithmetic
- messing up with a data structure on concurrent access (but without
crashing nor shooting at random other data)
The next thing also sometimes called "unsafety" is when the language
has a habit of accepting almost arbitrary input instead of signalling
that it's probably wrong when it looks wrong. Perl is the primary
example of that. It will accept "foo" as a number (treated as 0)
and an array reference as a strong (treated as something like
"ARRAY(0x804cc28)"). Usually it doesn't check for too many or too few
arguments (unless the function is statically known and declared with
a prototype). The behavior is documented but mistakes aren't treated
as errors.
But the first notion is the primary meaning of "unsafe language".
> I will also argue that D has many characteristics that make the need
> for pointers much less than in, say, C, so one rarely has to deal
> with pointers.
Can you make a tree (e.g. abstract syntax tree for the sake of
example) without pointers?
> That's exactly what a dynamic closure is. A static closure would
> "capture" the local variables so they survive the function exit.
I haven't encountered your terminology and I'm not sure whether I
understand it. Do you mean that D supports only downward closures
(which are valid only as long as the containing function is running)
and not upward closures (with indefinite lifetime, independent from
the execution of functions)?
--
__("< Marcin Kowalczyk
\__/ qrc...@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Jon Harrop
>> I will also argue that D has many characteristics that make the need
>> for pointers much less than in, say, C, so one rarely has to deal
>> with pointers.
>
> Can you make a tree (e.g. abstract syntax tree for the sake of
> example) without pointers?
Excellent question. :-)
>> That's exactly what a dynamic closure is. A static closure would
>> "capture" the local variables so they survive the function exit.
>
> I haven't encountered your terminology and I'm not sure whether I
> understand it. Do you mean that D supports only downward closures
> (which are valid only as long as the containing function is running)
> and not upward closures (with indefinite lifetime, independent from
> the execution of functions)?
I do not think that is what Walter means. Downward and upward closures have
a high-level definition (i.e. nothing to do with stacks and heaps). I think
Walter's dynamic closures have a much lower-level defintion: they are
always valid downwards but are only valid upwards when the environment they
use is on the heap and not on the stack. I hope the compiler enforces
correct use, rather than generating unsafe code...
My problem with that definition is that you now need to know what goes on
the stack and what goes on the heap. For example, are function arguments on
the stack or are they references to values in the heap or can they be
either (e.g. an int vs an array)?
Walter
"Marcin 'Qrczak' Kowalczyk" <qrc...@knm.org.pl> wrote in message
news:87zms1p...@qrnik.zagroda...
> > I will also argue that D has many characteristics that make the need
> > for pointers much less than in, say, C, so one rarely has to deal
> > with pointers.
>
> Can you make a tree (e.g. abstract syntax tree for the sake of
> example) without pointers?
Yes.
> > That's exactly what a dynamic closure is. A static closure would
> > "capture" the local variables so they survive the function exit.
> I haven't encountered your terminology and I'm not sure whether I
> understand it. Do you mean that D supports only downward closures
> (which are valid only as long as the containing function is running)
> and not upward closures (with indefinite lifetime, independent from
> the execution of functions)?
Yes, the two sets of terms mean the same thing.
Walter
> [dynamic closures]
> >> This is a very low-level notion of a closure that I've never come
across.
> >
> > It's very useful, and much more efficient than a static closure,
although
> > less functional.
>
> I'd like to see a performance comparison between D and OCaml closures
then.
There's the great computer language shootout series of benchmarks.
> Also, how can you tell when something is stored on the stack, to know that
> it is safe to use a dynamic closure?
The obvious cases, yes, but it is not possible in the general case. The idea
behind D is that you can do anything you want, so it won't be necessary to
dip into C. But also that to do unsafe things requires extra work, so the
natural thing will be to use the safe things.
> >> In D, can you partially apply a function? For example, the following
> >> OCaml defines an "add" function and then an "incr" function in terms of
> >> "add"
> > and
> >> finally increments 3 to get 4
> >
> > I don't get it.
>
> Here's another example. This calculates the max of 5 and each element in a
> list in turn, clamping the values to be >=5:
>
> # List.map (max 5) [1; 2; 3; 4; 5; 6; 7; 8; 9];;
> - : int list = [5; 5; 5; 5; 5; 6; 7; 8; 9]
Sorry, this just looks like an array?
> >> >> >> Native lists
> >> > Can be done simply with a user defined class.
> >> Again, the result will require much more code. Consider this function
> > which
> >> dices a list into a list of 3-element lists:
> >
> > You'd probably do this with dynamic arrays in D.
>
> Right, you'd do it the same way in Fortran. OCaml's lists have the
advantage
> that they can be pulled apart (using pattern matching) as easily as they
> were constructed.
So can D's arrays!
> Personally, I'd like to see D support lists and pattern matching but
adding
> more powerful pattern matching over arrays. For example, you can
decapitate
> a list to get the head and tail in OCaml but you cannot "decapitate" an
> array to get the first element and the subarray of the remaining elements.
Sure you can:
// get first element:
first = foo[0];
// replace foo with subarray of remaining elements:
foo = foo[1 .. length];
> >> That was the page I was reading. It is great for someone coming from a
> >> C++ background (which is most readers, after all) but it lists very few
> >> features found in other state-of-the-art programming languages. I think
> >> that would be very interesting, although it wouldn't show D in such a
> >> positive light.
> >
> > D isn't a functional programming language, and it would be hard to
create
> > such a table and have it have any real meaning. Comparison tables only
> > work when languages are reasonably similar. One problem, for example, is
> > that terms like "functor" have very different meanings in very different
> > languages.
>
> True. I'd like to try... :-)
Feel free. If you do, I can post a link to it.
A.L.
>
>Or has programming language evolution reached its ultimate form in Java?
No, Visual Basic is much better.
A.L.
Jon Harrop
>> Also, how can you tell when something is stored on the stack, to know
>> that it is safe to use a dynamic closure?
>
> The obvious cases, yes, but it is not possible in the general case. The
> idea behind D is that you can do anything you want, so it won't be
> necessary to dip into C. But also that to do unsafe things requires extra
> work, so the natural thing will be to use the safe things.
Yes, I think that is as good an approach as any.
>> >> In D, can you partially apply a function? For example, the following
>> >> OCaml defines an "add" function and then an "incr" function in terms
>> >> of "add"
>> > and
>> >> finally increments 3 to get 4
>> >
>> > I don't get it.
>>
>> Here's another example. This calculates the max of 5 and each element in
>> a list in turn, clamping the values to be >=5:
>>
>> # List.map (max 5) [1; 2; 3; 4; 5; 6; 7; 8; 9];;
>> - : int list = [5; 5; 5; 5; 5; 6; 7; 8; 9]
>
> Sorry, this just looks like an array?
Yes, it is the same with arrays:
# Array.map (max 5) [|1; 2; 3; 4; 5; 6; 7; 8; 9|];;
- : int array = [|5; 5; 5; 5; 5; 6; 7; 8; 9|]
But you're supposed to be looking at the expression "max 5", not the data
structure. The expression "max 5" returns a function that computes the
maximum of 5 and the given number. Mapping "max 5" over the elements in a
container therefore computes a container where each element is the max of 5
and the corresponding element from the input.
Thus, "max 5" is an example of a function ("max") returning a function, i.e.
a curried function. It may be nice to be able to do this easily in D.
>> Right, you'd do it the same way in Fortran. OCaml's lists have the
> advantage
>> that they can be pulled apart (using pattern matching) as easily as they
>> were constructed.
>
> So can D's arrays!
I thought D didn't have pattern matching?
>> Personally, I'd like to see D support lists and pattern matching but
> adding
>> more powerful pattern matching over arrays. For example, you can
> decapitate
>> a list to get the head and tail in OCaml but you cannot "decapitate" an
>> array to get the first element and the subarray of the remaining
>> elements.
>
> Sure you can:
>
> // get first element:
> first = foo[0];
> // replace foo with subarray of remaining elements:
> foo = foo[1 .. length];
For lists, the OCaml equivalent of your code is simply "h::t" and it runs in
T(1) time and space.
But does that last statement copy the elements, i.e. it is T(n-1)? I want
something that will refer back to the old array without copying its
elements, i.e. the subarray should contain a reference to the old array and
the start and end indices of the subarray.
This brings me to another point. Can you write:
(first, foo) = (foo[0], foo[1 .. length]);
Walter
> Walter wrote:
> >> Right, you'd do it the same way in Fortran. OCaml's lists have the
> > advantage
> >> that they can be pulled apart (using pattern matching) as easily as
they
> >> were constructed.
> > So can D's arrays!
> I thought D didn't have pattern matching?
You can pull apart and put together arrays in D. Whether you'd call that
pattern matching or not, I don't know.
> >> Personally, I'd like to see D support lists and pattern matching but
> > adding
> >> more powerful pattern matching over arrays. For example, you can
> > decapitate
> >> a list to get the head and tail in OCaml but you cannot "decapitate" an
> >> array to get the first element and the subarray of the remaining
> >> elements.
> >
> > Sure you can:
> >
> > // get first element:
> > first = foo[0];
> > // replace foo with subarray of remaining elements:
> > foo = foo[1 .. length];
>
> For lists, the OCaml equivalent of your code is simply "h::t" and it runs
in
> T(1) time and space.
>
> But does that last statement copy the elements, i.e. it is T(n-1)?
No. Under the hood, it just manipulates a pointer and a length field. It's
T(1).
> I want
> something that will refer back to the old array without copying its
> elements, i.e. the subarray should contain a reference to the old array
and
> the start and end indices of the subarray.
Yes, that's just what D arrays do.
> This brings me to another point. Can you write:
>
> (first, foo) = (foo[0], foo[1 .. length]);
No, D doesn't do tuples.
Bruce Stephens
[...]
> Or has programming language evolution reached its ultimate form in
> Java?
I don't think anyone claims that Java is "ultimate" in any meaningful
sense, do they? I view it more in engineering terms: it trades off
various factors and has found a worthwhile range of uses, while likely
not being "the best" in any of them.
Friedrich Dominicus
> "ML pattern matching is an advancement upon the switch statement. For
> example, this convoluted C code:
>
> int fib(int n) {
> switch (n) {
> case 1 : return 1;
> case 2 : return 1;
> default : return fib(n-1) + fib(n-2);
> }
> }
>
> can be written in OCaml as:
>
> # let rec fib n = match n with 1 -> 1 | 2 -> 1 | n -> fib(n-1) +
> fib(n-2);;
> val fib : int -> int = <fun>
> "
Nun warum benutzt Du lesbares C und knallst alle in einen Ocaml
Kuddelmuddel.
Fair wäre gewesen
int fib(int n) {
switch (n) {
case 1 : return 1; case 2 : return 1; default : return
fib(n-1) + fib(n-2);} }
Oder vielleicht lesbares Ocaml?
let rec fib n = match n
with 1 -> 1
| 2 -> 1
| n - fib (n-1) + fib(n-2);
oder "lesbares" Ocaml vielleicht so etwas wie:
let rec fib n =
match n
with 1 -> 1
| 2 -> 1
| n -> fib (n-1) + fib(n-2);;
let rec fib1 n =
if ((n =1) or (n = 2)) then 1
else fib (n-1) + fib(n-2);;
>
> why is the OCaml code clearer? not to me, if one was trained on C
> and/or Pascal style languages like me
> the OCaml just uses a different syntax and jams more info on a single
> line which makes finding and modifying a single case potentially more
> difficult
If you do it that way, of course but not if you write "readable"
Regards
Friedrich
--
Please remove just-for-news- to reply via e-mail.
Marco van de Voort
>>
>> What do people see coming down the pike next? Some programming
>> language that will be able to be used across various sized servers and
>> desktops, across platforms, etc.?
>
> gets hyped or marketed.
>
> Why did we use C rather than PL/I? C was being given away with Unix.
> Why do people use Java? Because Sun hyped it as an internet lanaguage at
> the height of the Dotcom boom.
And now C# and VB.NET get pushed hard by Microsoft.
I fully agree, it was what I thought when I saw the original post too.
Language popularity matters more what they are combined with then not.
Even aside from that, there are a lot more other factors:
- cost (Turbo Pascal took of because it was generally available and cheap)
- compiler. (interfacing, speed of compilation, speed of code, IDE etc)
- libraries, headers, examples etc.