Apologies, I need a better mail client. On 17 September 2014 07:39, Ralph Eastwood <tcmreastw...@gmail.com> wrote: > Maxime Coste wrote: >> That last one is by far the most interesting, Bartos being very familliar >> with >> C++. Note that its not C that is advocated, but haskell... > > I would advocate functional languages (not necessarily Haskell) over C++ any > day > - although implementations of functional languages have this far > disappointed me slightly. > I'm hoping a good multi paradigm language will appear some day. > > > On 17 September 2014 06:57, Markus Teich <markus.te...@stusta.mhn.de> wrote: >> Maxime Coste wrote: >>> That is the complaint I mostly hear about Go, the lack of Generic. That and >>> garbage collection. >> >> Why would I want to apply the same algorithm to semantically different >> arguments? Appart from different kinds of number representations no useful >> example comes to mind. > > That is a good point; I think the current purpose of generics in other > languages is to > enforce type checking and provide implicit pointer conversion (for > example in C if you > had a data structure/algorithm that took in a generic type argument as > a pointer). > These are conveniences, and not necessities. > > However, there is one more valid use in the case of a generic > algorithm/data structure. > Imagine you have subroutines/functions that relate to your data > structure and you want > to add an item. Generics allow you to write one piece of code to deal > with all types and > let you pass the items *by value* rather than *by reference*. This > would be useful when > your item data type is small so it can be optimised by the compiler. > It's not like this can't be done in C, you can use X-Macros [1] to do this > (I realised after writing this example). I guess, it's arguably less elegant. > For more syntactic sugar, _Generic from C11 would work, but is not necessary. > > On a more constructive note, I think a list of C++ paradigms that are commonly > used could be compared with their C counterparts... That would make it a > useful > reference for suckless programmers. > > What are people's views on literate programming for maths heavy code? > Like Maxime, operator overloading in C++ for maths code offloads the > brain so you can > focus more on the algorithmic detail and remember what you have done > when you return > to the code after a long time (or if someone else has to read it). > I think, however, literate programming using LaTeX would allow the > same degree of > expression and probably be even better for readability. > I realise suckless code doesn't tend to make use of literate > programming often, particularly > because the code is relatively simple, memory management patterns > which C programmers > would have seen countless times over, but for complicated and novel > algorithms, > different thought patterns are necessary. > > C++ provides error-checking facilities that C does not possess. > However, I think these are > rather limited in scope. I would rather go for verification proofs [2]. > > Although C is good enough for most of us, I can't help but wonder if ideas > from > Forth, Haskell, Lisp, Alef (and so on) could somehow provide a clean systems > language without feature bloat. For instance in C (yes C), I can > immediately think of > 6 different recursive mechanisms/keywords... is that many necessary??? > > [1] http://en.wikipedia.org/wiki/X_Macro > [2] http://frama-c.com/ > > Cheers > > -- > Tai Chi Minh Ralph Eastwood > tcmreastw...@gmail.com
-- Tai Chi Minh Ralph Eastwood tcmreastw...@gmail.com
