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

Groups > alt.os.development > #8903

Re: Smaller C

Show all headers | View raw

On Sat, 10 Oct 2015 04:48:19 -0400, Alexei A. Frounze <alexfrunews@gmail.com> wrote:

> On Friday, October 9, 2015 at 7:18:41 PM UTC-7, Rod Pemberton wrote:
>> On Fri, 09 Oct 2015 05:50:47 -0400, Alexei A. Frounze <...@gmail.com> wrote:

>> > I wonder if there ever was an attempt to come up
>> > with a language that could be automatically "zoomed in and
>> > out" without breaking any code written in it, but by just
>> > providing different views/interpretations of it. E.g. some
>> > obscure or non-trivial feature could be expressed as a series
>> > of easy to grasp features and they could be collapsed back
>> > into the obscure non-trivial one back, all by a press of
>> > a key or a turn of a wheel.
>> >
>>
>> Every object in C maps onto an array of C bytes.  Is something
>> like that what you meant?  Or, did you mean something more
>> along the lines of expanding and collapsing items in a list
>> in a browser, and dragging and dropping a link into a folder?
>
> Yes and no.
>
>> So, James was recently discussing modules, and you seem to be
>> thinking about containers, I'd say in a similar manner.  You
>> both seem to want some way to organize, build up, and group
>> smaller pieces into large pieces like Minecraft or Forth or
>> MacDraw or Visio a does.  Point, click, drag, drop, organize,
>> link, connect, group, *BOOM* working code ...  Wasn't that
>> the point of Visual Basic, Visual C/C++, and Visual Studio, etc?
>
> I'm frustrated with large C++ projects and I bet I'm not alone
> here. I can't see what's behind a line of seemingly innocuous
> code without finding types and reading lots of declarations
> and definitions and that can go on recursively, in depth and
> in breadth. That's not C++'s fault entirely. You can write
> large and complex software in other languages as well. But with
> C++ it's very easy to lose an important detail, which you don't
> see, because it's thousands of lines away from where you're
> now and because there's something happening implicitly per
> the rules of the language. What I (and, I guess, many others)
> would really like to see is where instances (including
> short-lived temporary ones) are created, what the assignment
> operator (and others) unfolds into and things like that. I have
> no hopes ever knowing C++ nearly as well as I do C or assembly.
> Several times in my career I have had to resort to reading
> disassembly of compiled C++ code in order to understand the
> grand plan of the author, who generously used classes and
> templates. But that's not how it should be. Either you don't
> complicate the language (code complexity is more than enough
> already) or you provide tools to deal with this complexity.
> In C++ there doesn't seem to be enough good tools for the
> language complexity. So, if you let your compiler figure out
> which type/function to substitute, which constructor to
> call and so on, the IDE must be able to show you on demand
> the decisions that the compiler makes when it compiles the
> code. Our C++ IDEs are still piss poor with things like that.
> I'm not sure the language is properly designed if you
> have such problems with source code written in it.

I have two thoughts on that.

1) Well, if C++ clearly isn't the solution, then I would
strongly guess that C is since C++ is a language which once
compiled to C, just like all the other languages.  I did
say all roads lead to Rome.

2) You just argued for more complexity to be introduced into
the libraries due to their necessity, but also stated above
that "code complexity is more than enough already."  So,
which is it?

(You can't see me grinning for either reply.)

> Either you don't complicate the language [...] or you provide
> tools to deal with this complexity.  In C++ there doesn't seem
> to be enough good tools for the language complexity.

Well, obviously, I would argue for simplicity.

I recall a problem posted to comp.lang.c some years ago
where a student wanted a solution using a linked-list.
It was probably a requirement from their teacher.  So,
I posted a solution that didn't use a linked-list, and
stated that the solution was too simple to use a
linked-list, which it was.  I used counters.  I'm sure
the student submitted the solution thinking the novel
solution would impress their teacher.  Perhaps, they
had no other choice, i.e., they couldn't solve it.  It
was likely that their teacher was bombarded with 3 or 15
or maybe even 30 copies of my solution.  It's possible
they received even more, perhaps even 10,000, since this
was for someone from China where they test large groups.
"All them couldn't possibly have arrived with the exact
same solution."  Fail for cheating.  Fail for not
following the directions, i.e., didn't use a linked-list.

The point is that most Computer Science professors place
way too much emphasis on using linked-lists, structs,
local variables, etc.  So, their students use linked-lists,
even for trivial solutions where a LIFO stack or a counter
or an array would work.  So, I'd have to argue that having
fewer libraries available actually contributes to better
solutions and code.  I.e., the path of least resistance
is likely to be a mistake.


Rod Pemberton


-- 
Just how many texting and calendar apps does humanity need?
Just how many food articles from neurotic millenials do we need?

Back to alt.os.development | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: Smaller C Peter Cheung <mcheung63@gmail.com> - 2015-10-07 00:10 -0700
  Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-10-07 00:52 -0700
    Re: Smaller C Peter Cheung <mcheung63@gmail.com> - 2015-10-07 02:51 -0700
      Re: Smaller C "wolfgang kern" <nowhere@never.at> - 2015-10-07 21:01 +0200
        Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-10-08 00:25 -0700
          Re: Smaller C "wolfgang kern" <nowhere@never.at> - 2015-10-08 10:50 +0200
            Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-10-08 02:06 -0700
              Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-08 19:39 -0400
                Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-10-09 01:00 -0700
                Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-09 20:28 -0400
      Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-10-08 00:22 -0700
        Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-08 20:19 -0400
          Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-10-09 02:50 -0700
            Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-09 22:18 -0400
              Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-10-10 01:48 -0700
                Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-12 01:52 -0400
                Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-10-11 23:49 -0700
                Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-12 20:33 -0400
              Re: Smaller C James Harris <james.harris.1@gmail.com> - 2016-01-16 16:50 +0000
                Re: Smaller C Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-01-23 13:19 -0500
                Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2016-01-23 13:54 -0800

csiph-web