Invisible <voi### [at] devnull> wrote:
> Oh, I have a far bigger "problem" than that: C is the number one 
> language requested in job adverts. :-(

  I feel your pain because I hate C (but for different reasons than you).
See http://warp.povusers.org/grrr/HateC.html

  Your problem is that you project your C prejudices onto C++ as well,
and simply refuse to learn the tools C++ offers to make your life easier.
In a past thread I tried to teach you a few things about C++ which make
it a lot easier to write small programs quickly, and for a moment I thought
that you had actually learned something. Then some time after that you wrote
a new thread where you showed your attempts at writing something and it
seemed like you forgot or ignored *everything* that I had tried to teach you.
At that point I completely lost hope.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>   Do you honestly think that an IDE like Visual Studio is not going to
> automatically create project dependencies for you?

It's not entirely clear to me that the source code alone actually 
provides enough information to do this.

Presumably it's simple enough to figure out which source files depend on 
which header files. Not sure how you proceed from there though.

Post a reply to this message

> If you have automake, a few of those tasks become automated. But 
> seriously, I'm used to having a language where you say "compiler my stuff" 
> and it hands you a runnable program.

VS does most of that for you too (you just press F5 and it compiles and 
links the lot, automatically only compiling files that have changed since 
the last build), and you don't need to have separate header files if you 
don't want to.  A lot of people just find it makes more sense to have one 
file that neatly shows the interfaces and another to actually contain the 
implementation code.

> I guess it's just finding the motivation to use a language which is 
> over-complicated, unsafe and difficult when I could instead use one which 
> is clean, simple and easy...

From my point of view Haskell looks over-complicated, difficult and slow, 
but I suspect that's just because I haven't bothered to learn much about it.

Anyway, the motivation for you is all those job adverts you say you keep 
seeing...

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Warp wrote:

> >   Do you honestly think that an IDE like Visual Studio is not going to
> > automatically create project dependencies for you?

> It's not entirely clear to me that the source code alone actually 
> provides enough information to do this.

  Why wouldn't it? If a source code file needs another source code file,
it will #include it, and the IDE sees that and creates a dependency.

  If you don't #include another source code file then there is no dependency
between those two files.

-- 
                                                          - Warp

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> From my point of view Haskell looks over-complicated, difficult and slow, 
> but I suspect that's just because I haven't bothered to learn much about it.

  My problem with Haskell is that it's hard to learn. It's like it's 1% of
syntax and 99% of "clever" tricks which you just have to learn from somewhere
(often by word of mouth). And these tricks are often rather exotic and
unintuitive to an imperative/OO programmer.

-- 
                                                          - Warp

Post a reply to this message

scott wrote:
>> If you have automake, a few of those tasks become automated. But 
>> seriously, I'm used to having a language where you say "compiler my 
>> stuff" and it hands you a runnable program.
> 
> VS does most of that for you too (you just press F5 and it compiles and 
> links the lot, automatically only compiling files that have changed 
> since the last build), and you don't need to have separate header files 
> if you don't want to.  A lot of people just find it makes more sense to 
> have one file that neatly shows the interfaces and another to actually 
> contain the implementation code.

Now that's interesting.

1. How does it know which files depend on which other files?

2. A header file is what defines what can be accessed from outside a 
given source file. Without a header file, how do you determine what's 
supposed to be public and what isn't?

>  From my point of view Haskell looks over-complicated, difficult and 
> slow, but I suspect that's just because I haven't bothered to learn much 
> about it.

To use Haskell, you need to learn something like half a dozen basic 
principles. After that it's just figuring out "OK, how the hell do I 
perform task X?" Learning C++ it just seems like learning feature after 
feature after feature, seemingly without end. (C is a lot simpler, it's 
just astonishingly easy to shoot yourself in the foot with it.)

> Anyway, the motivation for you is all those job adverts you say you keep 
> seeing...

Yeah, but let's think about this. I could spend a few months failing to 
learn C++. Hell, maybe I could even write a small program that actually 
works. But I'm up against people who have coded in nothing but C++ since 
they were 9 years old. I don't really stand much of a chance here...

Post a reply to this message

Warp wrote:

>   My problem with Haskell is that it's hard to learn. It's like it's 1% of
> syntax and 99% of "clever" tricks which you just have to learn from somewhere
> (often by word of mouth). And these tricks are often rather exotic and
> unintuitive to an imperative/OO programmer.

I must concurr with Warp here on the "not written down anywhere" part. 
People are doing a lot of very cool stuff with Haskell, but it can be 
maddeningly hard to find answers.

(E.g., somebody implemented a Doom clone in Haskell, and wrote a paper 
explaining how they did it. Except that the paper is utterly 
incomprehensible. It makes no sense at all. It's so badly explained that 
I just can't follow any of it.)

Actually, I think Warp's assessment of Haskell is about right. Haskell 
is like Go. The "rules" are simple, but the "game" is not.

Post a reply to this message

>> Oh, I have a far bigger "problem" than that: C is the number one 
>> language requested in job adverts. :-(
> 
>   I feel your pain because I hate C (but for different reasons than you).

It's very popular for "kernel-level development" for some reason.

(Of course, there are still plenty of people doing web development, who 
consequently want Java / Ruby / PHP / ASP / Python / whatever.)

>   Your problem is that you project your C prejudices onto C++ as well,
> and simply refuse to learn the tools C++ offers to make your life easier.

FWIW, it seems C++ has fixed some of the stuff I disliked about C. 
(Although I'm told almost every valid C program is also a valid C++ 
program, so nobody's forcing you to actually make use of these 
improvements...) It still has the problem of being inherantly designed 
to be unsafe, and being very low-level.

I guess it's just a question of motivation. If it weren't for the fact 
that everybody wants C / C++ programmers, I wouldn't even consider 
wasting my time learning it. It's highly unsuited to the kind of 
programs I write. But since everybody wants to use it... well maybe I 
could spend a few months trying to write a working C++ program. But I'm 
up against whizzkids who have been using nothing but C++ since they were 
9 years old. I have to feel I don't really stand a chance here...

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> 1. How does it know which files depend on which other files?

  If you write an #include line, you create a dependency to that file.
It's that simple.

  (In C and C++ there's no difference between source files and header files.
They are just files containing code. You can include anything in anything
else. The compiler (nor the IDE) make any distinction. An automated dependency
tracker simply looks for #included files and creates dependencies based on
that.)

> 2. A header file is what defines what can be accessed from outside a 
> given source file.

  That's actually just a programming convention. As said, the compiler makes
no distinction between "header" files and "source" files. They are just all
the same.

  (Ok, some IDEs support so-called "precompiled headers", but even in those
the distinction is more a question of convention than anything technical.)

> Without a header file, how do you determine what's 
> supposed to be public and what isn't?

  A header file doesn't really determine what is "public" and what isn't.
It's just a convenience technique. It's easier to put declarations in a
common file and then simply #include that file than to have to write the
declarations in all source files which need them.

-- 
                                                          - Warp

Post a reply to this message

>> 1. How does it know which files depend on which other files?
> 
>   If you write an #include line, you create a dependency to that file.
> It's that simple.

True. But presumably if you #include a file that defines a function 
prototype, you also need to compile and link whatever file it is that 
contains the source code for that function? (Except for the OS header 
files; I have literally *no clue* how that works...)

>   In C and C++ there's no difference between source files and header files.
> They are just files containing code.

>   A header file doesn't really determine what is "public" and what isn't.
> It's just a convenience technique. It's easier to put declarations in a
> common file and then simply #include that file than to have to write the
> declarations in all source files which need them.

True... But I'm still wondering how VS does this in the absence of 
header files.

Post a reply to this message