Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #68739 > unrolled thread

a style question:

Back to article view | Back to comp.lang.c

Contents

  a style question: G G <gdotone@gmail.com> - 2015-08-31 02:30 -0700
    Re: a style question: Ian Collins <ian-news@hotmail.com> - 2015-08-31 21:40 +1200
    Re: a style question: jt@toerring.de (Jens Thoms Toerring) - 2015-08-31 09:52 +0000
    Re: a style question: Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-31 03:24 -0700
      Re: a style question: Bartc <bc@freeuk.com> - 2015-08-31 11:50 +0100
        Re: a style question: Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-31 13:21 +0100
          Re: a style question: Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-31 05:41 -0700
          Re: a style question: Bartc <bc@freeuk.com> - 2015-08-31 14:55 +0100
            Re: a style question: Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-31 15:50 +0100
              Re: a style question: Bartc <bc@freeuk.com> - 2015-08-31 18:40 +0100
        Re: a style question: Melzzzzz <mel@zzzzz.com> - 2015-08-31 17:46 +0200
          Re: a style question: Bartc <bc@freeuk.com> - 2015-08-31 17:27 +0100
            Re: a style question: Melzzzzz <mel@zzzzz.com> - 2015-08-31 18:42 +0200
        Re: a style question: Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-08-31 17:41 +0000
          Re: a style question: Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-31 15:33 -0700
            Re: a style question: Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-01 08:34 +0000
        Re: a style question: Ian Collins <ian-news@hotmail.com> - 2015-09-01 07:40 +1200
          Re: a style question: Bartc <bc@freeuk.com> - 2015-08-31 21:36 +0100
            Re: a style question: Ian Collins <ian-news@hotmail.com> - 2015-09-01 08:51 +1200
              Re: a style question: Bartc <bc@freeuk.com> - 2015-08-31 22:37 +0100
                Re: a style question: Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-31 15:24 -0700
                  Re: a style question: Ian Collins <ian-news@hotmail.com> - 2015-09-02 19:37 +1200
            Re: a style question: jt@toerring.de (Jens Thoms Toerring) - 2015-08-31 23:33 +0000
              Re: a style question: Bartc <bc@freeuk.com> - 2015-09-01 01:13 +0100
                Re: a style question: Ian Collins <ian-news@hotmail.com> - 2015-09-01 18:21 +1200
                Re: a style question: jt@toerring.de (Jens Thoms Toerring) - 2015-09-01 15:23 +0000
                  Re: a style question: Bartc <bc@freeuk.com> - 2015-09-01 18:06 +0100
                    Re: a style question: Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-01 20:39 +0000
                    Re: a style question: jt@toerring.de (Jens Thoms Toerring) - 2015-09-01 20:45 +0000
                      Re: a style question: Bartc <bc@freeuk.com> - 2015-09-01 22:53 +0100
              Re: a style question: Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-31 17:51 -0700

Page 2 of 2 — ← Prev page 1 [2]

#68783

On Monday, August 31, 2015 at 10:38:05 PM UTC+1, Bart wrote:
> On 31/08/2015 21:51, Ian Collins wrote:
>
> > Do they?  Mine certainly don't.  Yes I have specialised numeric types
> > and associative arrays (JSON types) in my libraries, but they can't be
> > implemented without operator overloading.
> 
> Numeric types are one of the very few examples where overloading might 
> actually be needed. But I don't think it's a common enough general 
> requirement.
> 
> Associative arrays I don't know about; you mean just to overload "[]"? I 
> would also consider that rare enough that it can be done with function 
> calls. If you really need it with "[]", then it could be done partly 
> behind the scenes with my #pragma method. It keeps the main language 
> simple. /And/ stops people using such features inappropriately.
> 
I've got a need for JSON in my program.

So I've got a JParser class which you initialise with a JSON string,
then you call getReal(), getInteger(), getString() or getObject()
to query the structure. getObject() returns another JParser.
There's also something for arrays.

To create a JSON string from a  C++ structure, you call sprintf()
or family. (If you insist you can use the C++ stream libraries with
a string interface). Writing is easy, reading is hard, as is typical
with data in a non-trivial format.

However that's only acceptable because our need is to get some JSON
(actually from a third party library called Sciter), pull out 
known fields, then generate some JSON, almost always a fairly simple
structure, to send back. We don't need to pass JSON objects
about C++ functions and manipulate them.

[toc] | [prev] | [next] | [standalone]

#68961

Malcolm McLean wrote:
> On Monday, August 31, 2015 at 10:38:05 PM UTC+1, Bart wrote:
>> On 31/08/2015 21:51, Ian Collins wrote:
>>
>>> Do they?  Mine certainly don't.  Yes I have specialised numeric types
>>> and associative arrays (JSON types) in my libraries, but they can't be
>>> implemented without operator overloading.
>>
>> Numeric types are one of the very few examples where overloading might
>> actually be needed. But I don't think it's a common enough general
>> requirement.
>>
>> Associative arrays I don't know about; you mean just to overload "[]"? I
>> would also consider that rare enough that it can be done with function
>> calls. If you really need it with "[]", then it could be done partly
>> behind the scenes with my #pragma method. It keeps the main language
>> simple. /And/ stops people using such features inappropriately.
>>
> I've got a need for JSON in my program.
>
> So I've got a JParser class which you initialise with a JSON string,
> then you call getReal(), getInteger(), getString() or getObject()
> to query the structure. getObject() returns another JParser.
> There's also something for arrays.

Which is rather inelegant.

Manipulating JSON objects is an ideal use for operator overloading. 
Using operator[] to access sub-objects makes JSON manipulation much 
cleaner and mode like JSON in its home language, JavaScript.

> However that's only acceptable because our need is to get some JSON
> (actually from a third party library called Sciter), pull out
> known fields, then generate some JSON, almost always a fairly simple
> structure, to send back. We don't need to pass JSON objects
> about C++ functions and manipulate them.

Once something like JSON objects is made simple and the design makes 
them light weight to pass around, they are a convenient container for 
heterogeneous data.  If the interface is clunky, they won't find favour 
which is why I've not seen heterogeneous containers heavily used in C.

I use JSON for most of my inter-process communication (especially when 
the other end is a web page!), so the objects tend to propagate through 
the code.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#68787

Bartc <bc@freeuk.com> wrote:
> But I can't follow C++ because, when people make full use of its 
> features as they like to do;

Have you ever asked yourself why people like to to use them, even
though you consider them to be "useless", "horrible", "over-com-
plex" and what else? It's simple: because they're so damned use-
ful and extend the expressiveness of the language into realms you
can't even start imagining as long as you expect that everything
must be done as it's done in C or similar lower-level languages.

Perhaps you should attempt to realize that "higher-level lan-
guage" doesn't mean "more functions to do some things that some
people may want to do" (say printing an array or a structure,
which all non-terminally-stupid users could do with a function
of their own or might be supplied via a library). It means
introducing new, more abstract concepts that allow the users
of the language to do things that, in a lower-level language,
not only are impossible but hardly can be thought of.

                             Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [prev] | [next] | [standalone]

#68790

On 01/09/2015 00:33, Jens Thoms Toerring wrote:
> Bartc <bc@freeuk.com> wrote:
>> But I can't follow C++ because, when people make full use of its
>> features as they like to do;
>
> Have you ever asked yourself why people like to to use them, even
> though you consider them to be "useless", "horrible", "over-com-
> plex" and what else? It's simple: because they're so damned use-
> ful and extend the expressiveness of the language into realms you
> can't even start imagining as long as you expect that everything
> must be done as it's done in C or similar lower-level languages.
>
> Perhaps you should attempt to realize that "higher-level lan-
> guage" doesn't mean "more functions to do some things that some
> people may want to do" (say printing an array or a structure,
> which all non-terminally-stupid users could do with a function
> of their own or might be supplied via a library). It means
> introducing new, more abstract concepts that allow the users
> of the language to do things that, in a lower-level language,
> not only are impossible but hardly can be thought of.

What sort of things?

I normally use a dynamic language, which is actually quite low-level 
compared with some, that can do much of what C++ can do, and with none 
of the fuss.

I remember nearly a year ago needing a JPEG library, and I could only 
find a C++ version that took ages to try and decipher. Eventually I 
found a C version (it might be the one Malcolm kindly sent me), that did 
the same thing and was far simpler. The C++ seemed to just be using all 
its bells and whistles for the sake of it. Because they are there.

In my position, I am unlikely to write or generate C++ code. But I 
sometimes need to interface to it, or to understand other people's code, 
or to convert it to a different language and for that purpose its 
features get in the way. Then, the less esoteric and abstract the better!

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#68795

Bartc wrote:
> On 01/09/2015 00:33, Jens Thoms Toerring wrote:
>> Bartc <bc@freeuk.com> wrote:
>>> But I can't follow C++ because, when people make full use of its
>>> features as they like to do;
>>
>> Have you ever asked yourself why people like to to use them, even
>> though you consider them to be "useless", "horrible", "over-com-
>> plex" and what else? It's simple: because they're so damned use-
>> ful and extend the expressiveness of the language into realms you
>> can't even start imagining as long as you expect that everything
>> must be done as it's done in C or similar lower-level languages.
>>
>> Perhaps you should attempt to realize that "higher-level lan-
>> guage" doesn't mean "more functions to do some things that some
>> people may want to do" (say printing an array or a structure,
>> which all non-terminally-stupid users could do with a function
>> of their own or might be supplied via a library). It means
>> introducing new, more abstract concepts that allow the users
>> of the language to do things that, in a lower-level language,
>> not only are impossible but hardly can be thought of.
>
> What sort of things?
>
> I normally use a dynamic language, which is actually quite low-level
> compared with some, that can do much of what C++ can do, and with none
> of the fuss.

If that is the case, you have discovered the holy grail of programming 
languages!

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#68867

Bartc <bc@freeuk.com> wrote:
> On 01/09/2015 00:33, Jens Thoms Toerring wrote:
> > Bartc <bc@freeuk.com> wrote:
> >> But I can't follow C++ because, when people make full use of its
> >> features as they like to do;
> >
> > Have you ever asked yourself why people like to to use them, even
> > though you consider them to be "useless", "horrible", "over-com-
> > plex" and what else? It's simple: because they're so damned use-
> > ful and extend the expressiveness of the language into realms you
> > can't even start imagining as long as you expect that everything
> > must be done as it's done in C or similar lower-level languages.
> >
> > Perhaps you should attempt to realize that "higher-level lan-
> > guage" doesn't mean "more functions to do some things that some
> > people may want to do" (say printing an array or a structure,
> > which all non-terminally-stupid users could do with a function
> > of their own or might be supplied via a library). It means
> > introducing new, more abstract concepts that allow the users
> > of the language to do things that, in a lower-level language,
> > not only are impossible but hardly can be thought of.

> What sort of things?

You've been told by not too small a number of people (and given
all kinds of examples) that e.g. the ability to create new types
that are aligned to the problem you have to solve and having them
treated on the same footing as built-in types is one of them.
And that, in turn, requires operator overloading. And to make
creation of types really powerful you need tempkates. With all
this you can extend the language to be able to deal with pro-
blems in the most simple and transparent way. And you've been
told about the way memory issues can be dealt with in an auto-
matic manner that reduces the amount of code you've got to write
considerably and decreases the chance of introducing bugs and me-
mory leaks along the way. But you must give it a try to under-
stand it - just talking about it is like discussing colors with
someone who has decided to keep his eyes firmly shut all of his
life.

> I normally use a dynamic language, which is actually quite low-level
> compared with some, that can do much of what C++ can do, and with none
> of the fuss.

If that is true I'd very much tempted to try that language. Alas,
I've never seen any documentation for it, just some often inscru-
table code snippets you post from time to time. So I still have
to be convinced that you found the silver bullet.

> I remember nearly a year ago needing a JPEG library, and I could only
> find a C++ version that took ages to try and decipher. Eventually I
> found a C version (it might be the one Malcolm kindly sent me), that did
> the same thing and was far simpler. The C++ seemed to just be using all
> its bells and whistles for the sake of it. Because they are there.

> In my position, I am unlikely to write or generate C++ code. But I
> sometimes need to interface to it, or to understand other people's code,
> or to convert it to a different language and for that purpose its
> features get in the way. Then, the less esoteric and abstract the better!

Let me translate what you write into some equivalent example:

  I need some crucial information and have found out that it is
  supposed to be contained in a book written in Spanish. Now I've
  had several years of Latin in school as well as a bit of French,
  and I got some exposure to Italian, all languages nearly related
  to Spanish. But when I open that book it looks tantalizingly like
  things I know, many words are ringing a bell etc., but I still
  don't understand what's written. But instead of learning the re-
  quired amount of Spanish (or getting some help with a trans-
  lation) I start running around, telling everyone in sight what a
  horrible language Spanish is and imply that anyone making the
  effort to learn it must be a moron. If those damned Spaniards
  wouldn't be such a bunch of arrogant bastards they'd use proper
  words instead of inventing new ones, just to spite me!

Put like that what would you call me? But then I'm more and
inclined to suspect that you're just trolling...

                               Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [prev] | [next] | [standalone]

#68883

On 01/09/2015 16:23, Jens Thoms Toerring wrote:
> Bartc <bc@freeuk.com> wrote:

>> What sort of things?
>
> You've been told by not too small a number of people (and given
> all kinds of examples) that e.g. the ability to create new types
> that are aligned to the problem you have to solve and having them
> treated on the same footing as built-in types is one of them.
> And that, in turn, requires operator overloading. And to make
> creation of types really powerful you need templates. With all
> this you can extend the language to be able to deal with pro-
> blems in the most simple and transparent way.

But, IMO, the set of mechanisms to do all this is too intrusive and it 
dominates the language. From the C++ code I have seen, you don't usually 
end up with perfectly clear, clean-looking code.

  And you've been
> told about the way memory issues can be dealt with in an auto-
> matic manner that reduces the amount of code you've got to write
> considerably and decreases the chance of introducing bugs and me-
> mory leaks along the way. But you must give it a try to under-
> stand it - just talking about it is like discussing colors with
> someone who has decided to keep his eyes firmly shut all of his
> life.
>
>> I normally use a dynamic language, which is actually quite low-level
>> compared with some, that can do much of what C++ can do, and with none
>> of the fuss.
>
> If that is true I'd very much tempted to try that language. Alas,
> I've never seen any documentation for it, just some often inscru-
> table code snippets you post from time to time. So I still have
> to be convinced that you found the silver bullet.

That language has been developed since the 1980s. It's a not very 
remarkable interpreted, dynamic language, yet it has always been able to 
deal with those memory problems you mention, and can handle flexible 
vectors, strings and bit-arrays and much more.

It doesn't have general purpose OO features; one reason is that many of 
the problems for which they would be needed in C++, are already solved 
in the language (generics and polymorphism for example). (The main such 
requirement has actually been overloading 'to-string' for printing user 
types, and that can be done with a discreet mechanism to link a type 
with a function).

>> In my position, I am unlikely to write or generate C++ code. But I
>> sometimes need to interface to it, or to understand other people's code,
>> or to convert it to a different language and for that purpose its
>> features get in the way. Then, the less esoteric and abstract the better!
>
> Let me translate what you write into some equivalent example:
>
>    I need some crucial information and have found out that it is
>    supposed to be contained in a book written in Spanish. Now I've
>    had several years of Latin in school as well as a bit of French,
>    and I got some exposure to Italian, all languages nearly related
>    to Spanish. But when I open that book it looks tantalizingly like
>    things I know, many words are ringing a bell etc., but I still
>    don't understand what's written. But instead of learning the re-
>    quired amount of Spanish (or getting some help with a trans-
>    lation) I start running around, telling everyone in sight what a
>    horrible language Spanish is and imply that anyone making the
>    effort to learn it must be a moron. If those damned Spaniards
>    wouldn't be such a bunch of arrogant bastards they'd use proper
>    words instead of inventing new ones, just to spite me!

OK, let me try an analogy too. Suppose someone took assembly language 
and extended it by trying to add high level constructs, type systems and 
so on. And did it largely by devising a really complicated macro system.

You would probably be bemused by the effort, mainly because the 
resulting language would be a poor imitation of a real HLL.

The proper thing to do is to create a new, higher level language (eg. 
C). Then you do all your programming in this new language where all 
those features are built-in and can be used effortlessly without anyone 
being able to see the 'strings'.

You probably won't need to write much assembly again.

This is my view of C++: C with a very sophisticated macro system used to 
pretend it's a higher level language than it really is. But you can 
still see the strings.

(Your own analogy is flawed I think; it wouldn't be Spanish I'd be 
complaining about, it would be Spanish written in legalese; the sort of 
language that gets in the way of the message.)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#68926

On Tue, 2015-09-01, Bartc wrote:

> This is my view of C++: C with a very sophisticated macro system used to 
> pretend it's a higher level language than it really is. But you can 
> still see the strings.

Repeating what Ian Collins wrote upthread:

  "You really should learn to understand something before you start
  slagging it off.  If you did, you would either be able to do a much 
  better job or you wouldn't need to."

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#68927

Bartc <bc@freeuk.com> wrote:
> >> I normally use a dynamic language, which is actually quite low-level
> >> compared with some, that can do much of what C++ can do, and with none
> >> of the fuss.
> >
> > If that is true I'd very much tempted to try that language. Alas,
> > I've never seen any documentation for it, just some often inscru-
> > table code snippets you post from time to time. So I still have
> > to be convinced that you found the silver bullet.

> That language has been developed since the 1980s. It's a not very 
> remarkable interpreted, dynamic language, yet it has always been able to 
> deal with those memory problems you mention, and can handle flexible 
> vectors, strings and bit-arrays and much more.

> It doesn't have general purpose OO features; one reason is that many of 
> the problems for which they would be needed in C++, are already solved 
> in the language (generics and polymorphism for example). (The main such 
> requirement has actually been overloading 'to-string' for printing user 
> types, and that can be done with a discreet mechanism to link a type 
> with a function).

In other posts you had given the impression that it were a com-
piled language, but now it's an interpreted one. I guess you are
aware that there are some differences between those two and that
an interpreted language may take some "liberties" that aren't
possible for a compiled one. So it's a bit like comparing apples
to bananas. What about the execution speed? C++ aims at retaining
a similar speed as C and seems to fare not too bad in that respect.
I guess that this hardly is possible with an interpreted one. Care
to show any meaningful benchmarks?

Is it bound to single processor architecture and/or operating
system? Inquirung minds may want to know.

And then I've still not seen a shred of a real description of your
language, just a very vague and general description, which might fit
the advertizing blurb for a lot of other interpreted languages. With-
out any reasonable documentation there's nothing to compare it to
C++, it's all claims you made. You wrote

  "that can do much of what C++ can do, and with none of the fuss"

Either substantiate your claims or better refrain from making
them. Post a link to some real specifications that go beyond
the "it's better than C++" stage. Hic Rhodus, hic salta!

> OK, let me try an analogy too. Suppose someone took assembly language 
> and extended it by trying to add high level constructs, type systems and 
> so on. And did it largely by devising a really complicated macro system.

Are you talking about C? ;-)

> You would probably be bemused by the effort, mainly because the 
> resulting language would be a poor imitation of a real HLL.

> The proper thing to do is to create a new, higher level language (eg. 
> C). Then you do all your programming in this new language where all 
> those features are built-in and can be used effortlessly without anyone 
> being able to see the 'strings'.

> You probably won't need to write much assembly again.

We're all waiting for you to tell us how this silver bullet
language works. But some may not be holding their breaths.

> This is my view of C++: C with a very sophisticated macro system used to 
> pretend it's a higher level language than it really is. But you can 
> still see the strings.

Still to be able to "see the strings" as you call it has always
been an explicit design goal for C++. It is supposed to cater to
both worlds: as low level as you can go in C on the one hand, and
having all the features exptected from a higher-level language on
the other. So they seem to have achieved at least that first de0
sign goal quite nicely, even in your opinion...

But then I've got to disappoint you: C++ has done away with lots
of reasons to use macros (but still supports them). And charac-
terizing C++ as C with macros is, IMHO, not a very fitting de-
scription (it may have been 25 years ago, but times have changed).
But then, some people may describe the space shuttle as "just an
airplane with a rocket strapped on to it". This may cover a few
aspects, but, as a genuine description, it might be seen as a
bit short of the mark.
                               Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [prev] | [next] | [standalone]

#68938

On 01/09/2015 21:45, Jens Thoms Toerring wrote:
> Bartc <bc@freeuk.com> wrote:

>> It doesn't have general purpose OO features; one reason is that many of
>> the problems for which they would be needed in C++, are already solved
>> in the language (generics and polymorphism for example). (The main such
>> requirement has actually been overloading 'to-string' for printing user
>> types, and that can be done with a discreet mechanism to link a type
>> with a function).
>
> In other posts you had given the impression that it were a com-
> piled language, but now it's an interpreted one. I guess you are
> aware that there are some differences between those two and that
> an interpreted language may take some "liberties" that aren't
> possible for a compiled one.

I have two private languages: one is statically typed and compiled, at 
about the same level as C, and the other is dynamically typed and 
interpreted. It's the latter that has all the features, and I use the 
first one to implement it. Notice there's a big gap in the middle where 
some people like to put C++, but I have no need for!

Similarly, CPython is currently implemented in C. I don't see what 
benefit there would be in switching to C++. Python has, for example, 
flexible strings, but it doesn't need the implementation language to 
have flexible strings too!

  So it's a bit like comparing apples
> to bananas. What about the execution speed? C++ aims at retaining
> a similar speed as C and seems to fare not too bad in that respect.
> I guess that this hardly is possible with an interpreted one. Care
> to show any meaningful benchmarks?

I'm not going to pretend the interpreted language is as fast as C or 
C++. In numeric benchmarks, it might be a magnitude slower.

(But I have long experience of balancing the two kinds of language I 
use: if you get it right, an application mixing compiled and dynamic 
languages is not going to be significantly slower than one that has 100% 
native code.)

This is not the point however (and after all some clever chap can come 
along and a create a fast JIT tracing compiler for it); I'm using this 
as an example of designing a language where you can have the features, 
without the visible overheads and complexity. A lot can be applied to a 
C-like static language too.

> Is it bound to single processor architecture and/or operating
> system? Inquirung minds may want to know.

(The interpreter can be translated to C source, and therefore could run 
on a wide range of platforms. It's been tried on x86, x64, ARM-32, and 
on Windows and Linux. Notice again, I don't need to target C++; it 
doesn't buy me anything.)

> And then I've still not seen a shred of a real description of your
> language, just a very vague and general description, which might fit
> the advertizing blurb for a lot of other interpreted languages. With-
> out any reasonable documentation there's nothing to compare it to
> C++, it's all claims you made. You wrote
>
>    "that can do much of what C++ can do, and with none of the fuss"
>
> Either substantiate your claims or better refrain from making
> them.

I've already explained above. I didn't go into details because it's not 
that different from many other dynamic languages. Just substitute 
Python, Ruby, Lua etc, they can all do the same. (Although they do all 
have OO too, they don't need it for this basic stuff.)

(The language is real enough though; here's an example: 
http://pastebin.com/dCpGzUps, which is part of a compiler, that 
generates C code. As I said, nothing remarkable, but it does make use of 
expanding lists and strings with little fuss, as I also said.)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#68792

On Tuesday, September 1, 2015 at 12:33:36 AM UTC+1, Jens Thoms Toerring wrote:
> Bartc <bc@freeuk.com> wrote:
> > But I can't follow C++ because, when people make full use of its 
> > features as they like to do;
> 
> Have you ever asked yourself why people like to to use them, even
> though you consider them to be "useless", "horrible", "over-com-
> plex" and what else? It's simple: because they're so damned use-
> ful and extend the expressiveness of the language into realms you
> can't even start imagining as long as you expect that everything
> must be done as it's done in C or similar lower-level languages.
>
My theory is that the more boring, routine and unchallenging the
programming, the more elaborate the programming language used
to express it.  
>
> Perhaps you should attempt to realize that "higher-level lan-
> guage" doesn't mean "more functions to do some things that some
> people may want to do" (say printing an array or a structure,
> which all non-terminally-stupid users could do with a function
> of their own or might be supplied via a library). It means
> introducing new, more abstract concepts that allow the users
> of the language to do things that, in a lower-level language,
> not only are impossible but hardly can be thought of.
> 
Serialisation is in my view a "special case", like memory allocation.
It can be done via normal functions in a low level language, but
it's so fundamental that it's better to have some built-in support.

In a sense that makes languages more high level, but by definition 
you only have a few special cases. It doesn't unleash a cascade of
more features needing more features to support them or exploit them.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web