Apologies, I need a better mail client.
On 17 September 2014 07:39, Ralph Eastwood <tcmreastwood_AT_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.teich_AT_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
> tcmreastwood_AT_gmail.com
--
Tai Chi Minh Ralph Eastwood
tcmreastwood_AT_gmail.com
Received on Wed Sep 17 2014 - 08:41:50 CEST