 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Haskell is a small, simple, logical language. C++ is a huge, messy,
>> complex language. I don't see how learning an easy language should enable
>> me to learn a hard language.
>
> Heh, Haskell looks complicated and hard to learn to me.
Well, I guess there are probably people who look at something like
x = (-b +- Sqrt(b^2 - 4ac)/2a
and go "OH MY GOD! That looks SO complicated!" But actually, if you know
a little algebra, you discover that this contraption is actually quite
straight forward.
> I just think that if you have the brain
> to understand all of the constructs Haskell provides and why they're cool or
> interesting, you have the capability to do the same with any other language,
> especially a commonly used one.
Yes - because "commonly used" = "it's very easy". Oh, wait... :-P
>> I already *know* Java. ;-)
>
> Oh; aren't there Java programming jobs around?
My problem is that I'm not finding *any* programming jobs, for *any*
language. (Or rather, I can find a few jobs with titles like "senior
systems architect" and "lead developer", but I'm not finding anything
like "trainee programmer" or "graduate Java developer".)
>>> Why don't you put the time into it?
>> What makes you think I haven't?
>
> The fact that you haven't learned C++ yet. =)
FWIW, I also failed to learn Latin. And that's *supposed* to be easy!
> Well, aside from having a good debugger, you just need to be honest with
> yourself about what parts of your program you do or don't understand.
Well that's just it. It's not like I have any resources telling me how
to actually program in C++. I just sort of have to take a guess. Oddly
enough, that doesn't work very well.
> And of course, getting started is always hard. It took me at least two
> attempts (separated by learning other languages like JavaScript and VB) to
> learn C++.
Ah, VB... That *other* language I completely failed to learn.
>> As I say, the trouble is that if your program doesn't work, there is no
>> way you can ever find out why.
>
> Honestly, binary search with prints works in a lot of cases. If you know
> what the program is supposed to do, then you can identify the places it does
> something wrong.
Like I said, printing stuff out is usually the bit that won't work.
(Although I gather C++ at least managed to fix this part.)
>> (Especially if you're using something like OpenGL. It's an extremely
>> complicated API, and unless you pay money it's not possible to get hold of
>> useful documentation.)
>
> OpenGL can be difficult because if you do something wrong it will sometimes
> silently fail. And yeah, it's hard to get good documentation (I learned it
> by taking a class), but it's fun once you can use it so it may be worth
> buying a book on.
Possibly a dump question, but... can you actually call a C interface
from C++? At any rate, presumably you can completely forget Warp's
"don't use pointers" rule if you want to talk to OpenGL - or any other
API designed for C. ;-)
> Ultimately my point is this: I think you *can* learn it, and if you're
> looking for a good programming job, I think you have a lot to gain by doing
> so.
Hmm. A good Haskell programmer and a very bad C++ programmer. Which one
would you hire?
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-Sep-08 10:16, Invisible wrote:
>>> Haskell is a small, simple, logical language. C++ is a huge, messy,
>>> complex language. I don't see how learning an easy language should
>>> enable me to learn a hard language.
>>
>> Heh, Haskell looks complicated and hard to learn to me.
>
> Well, I guess there are probably people who look at something like
>
> x = (-b +- Sqrt(b^2 - 4ac)/2a
unbalanced parentheses in line 10
> and go "OH MY GOD! That looks SO complicated!" But actually, if you know
> a little algebra, you discover that this contraption is actually quite
> straight forward.
Although very well known and easy I managed to have a proposition in my
thesis on this formula. Which, I admit, no one could understand unless
they knew what was not in my thesis (we are talking about an audience of
approximately just below one). ;)
>> I just think that if you have the brain to understand all of the
>> constructs Haskell provides and why they're cool or interesting, you
>> have the capability to do the same with any other language, especially
>> a commonly used one.
>
> Yes - because "commonly used" = "it's very easy". Oh, wait... :-P
Some people study physics because they have not such a good memory, but
can remember if it makes sense. OTOH some people study medicine because
they can remember things but you don't have to understand (most of) it.
More people are studying medicine than physics, but that does not imply
that I could.
>>> I already *know* Java. ;-)
>>
>> Oh; aren't there Java programming jobs around?
>
> My problem is that I'm not finding *any* programming jobs, for *any*
> language. (Or rather, I can find a few jobs with titles like "senior
> systems architect" and "lead developer", but I'm not finding anything
> like "trainee programmer" or "graduate Java developer".)
I did not contribute to this thread, because I had the feeling this
subject was beaten to death already. I case you forgot, I still think
that you should have stayed in research.
>>>> Why don't you put the time into it?
>>> What makes you think I haven't?
>>
>> The fact that you haven't learned C++ yet. =)
>
> FWIW, I also failed to learn Latin. And that's *supposed* to be easy!
who told you that? Or is that because it can't be hard if they did it
already two thousand years ago?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] dev null> wrote:
> > How could it use one generic function for all possible data types,
> > given that the data types can have different sizes and even have completely
> > different implementations for their operators, etc?
> Plain ordinary OOP manages to do this without difficulty.
At the cost of increased memory consumption (by a rather large factor)
and decreased performance. Plus it's difficult to make it work for native
types (at least with any kind of efficiency).
> ...so templates are like a kind of less-stupid macro expansion system?
I suppose you could think of them like that. Of course it's not the
whole story.
(One example of templates being different from preprocessor macros
is that when you instantate a template function or class, it creates
an actual type, with a type name which the linker will see. Preprocessor
macros don't do that.)
> > It depends on the compiler. Some compilers do insert checks in debug
> > mode.
> Mmm, OK. Well my only experience with writing C is Borland's C compiler
> for MS-DOS. (Actually, that's a lie. It was a C++ compiler, but we only
> wrote C.)
For example Visual C++ adds lots of checks into the compiled code in
debug mode (for example iterator range checks, vector bounds checks, etc).
Not every memory error can be caught with it, though. But then you can
use a good profiler for the rest.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> Well, I guess there are probably people who look at something like
> x = (-b +- Sqrt(b^2 - 4ac)/2a
> and go "OH MY GOD! That looks SO complicated!" But actually, if you know
> a little algebra, you discover that this contraption is actually quite
> straight forward.
I wouldn't call this straightforward:
fibs = 0 : 1 : zipWith (+) fibs (tail fibs)
Short? Yes. Clever? Yes. Easy for a non-haskell-programmer
non-mathematically-oriented person to understand? No.
(The curious thing about that is that it's easy to convince a layman
that it works, but the more (procedural) programming you know, the harder
it will be to understand *why* it works (and isn't, for example, an infinite
recursion that never terminates, as there doesn't seem to be any kind of
termination condition). Also understanding why it procudes the correct
result may be difficult.)
> Possibly a dump question, but... can you actually call a C interface
> from C++?
That's the whole idea.
> At any rate, presumably you can completely forget Warp's
> "don't use pointers" rule if you want to talk to OpenGL - or any other
> API designed for C. ;-)
I don't recall OpenGL requiring that many pointers either. Just tons
of straight function calls.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> At any rate, presumably you can completely forget Warp's "don't use
>> pointers" rule if you want to talk to OpenGL - or any other API
>> designed for C. ;-)
>
> I don't recall OpenGL requiring that many pointers either. Just tons
> of straight function calls.
OpenGL returns lots of IDs for all kinds of stuff, but they are more like
handles.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I wouldn't call this straightforward:
>
> fibs = 0 : 1 : zipWith (+) fibs (tail fibs)
OK, well how about this:
while (TRUE) { cont = (*cont)(); }
I wouldn't exactly call that straightfoward either. It's not *actually*
complicated, but it sure *looks* pretty baffling.
Alternatively,
while(*v++ = *s++);
I mean, what THE HELL...?
>> At any rate, presumably you can completely forget Warp's
>> "don't use pointers" rule if you want to talk to OpenGL - or any other
>> API designed for C. ;-)
>
> I don't recall OpenGL requiring that many pointers either. Just tons
> of straight function calls.
Mmm, actually... yes, doesn't it tend to refer to thing by numerical
indecies rather than actual pointers?
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Invisible" <voi### [at] devnull> wrote in message
news:48ca3efa$1@news.povray.org...
>
> while(*v++ = *s++);
>
> I mean, what THE HELL...?
>
I doubt that's the recommended way of copying an array any longer
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> while(*v++ = *s++);
>>
>> I mean, what THE HELL...?
>>
>
> I doubt that's the recommended way of copying an array any longer
I doubt that was *ever* the "recommended" way. And yet I, a person who
doesn't know C very well, am aware of this example. What does that tell
you? ;-)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-Sep-08 13:01, Gail wrote:
>
> "Invisible" <voi### [at] devnull> wrote in message
> news:48ca3efa$1@news.povray.org...
>
>>
>> while(*v++ = *s++);
>>
>> I mean, what THE HELL...?
A nice example of language design inspired by hardware (and vice versa).
May result in very fast code.
>>
>
> I doubt that's the recommended way of copying an array any longer
I don't think it is a problem as long as the string is known to be null
terminated. Don't put it in a library though. These are bound to be used
by people who have never heard of the concept of preconditions. Or
yourself in a weak moment after midnight.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> > I wouldn't call this straightforward:
> >
> > fibs = 0 : 1 : zipWith (+) fibs (tail fibs)
> OK, well how about this:
> while (TRUE) { cont = (*cont)(); }
> I wouldn't exactly call that straightfoward either. It's not *actually*
> complicated, but it sure *looks* pretty baffling.
But the haskell code is normal, regular haskell. Your C example is
not code any sane person would write.
> Alternatively,
> while(*v++ = *s++);
> I mean, what THE HELL...?
At least it's easy to understand what it does (and why it works) when
it's explained. The haskell example isn't.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
