 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Mmm, and you think any sane Haskell programmer would implement the
> Fibonaci numbers that way in a real program? It's an interesting
> teaching example, but seriously, if you *want* Fibonacci numbers for
Thank you for repeating what I've said a few times already. The ugly
C/C++ code you're accustomed to are also "interesting teaching
examples". They teach you all that stuff with pointers and character
arrays because they want to make sure the students understand how things
work in a computer (and for good reason). It's not how programmers do
stuff typically.
--
Lisa: Oedipus killed his father and married his mother.
Homer: Who payed for THAT wedding?
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawaz org<<<<<<
anl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mueen Nawaz <m.n### [at] ieeeorg> wrote:
> And besides, in C you have the STL which makes such operations somewhat
> easier. Not as nice as C++, perhaps, but more manageable.
How can you have a standard template library in C, given that C has
absolutely no support for templates?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> I guess it works differently with a real OS. I've only ever compiled C
> code under MS-DOS, and there you don't get "segfaults", you get "my
> program does something really weird which may even require me to reboot
> the whole PC to fix".
So let me get this straight: You are comparing C in a 10+ years old MS-DOS
system to higher-level programming languages (such as Java and Haskell) in
modern systems with modern OSes and modern compilers, and based on this you
have decided that C sucks?
(Don't get me wrong: C does suck. It's just that your comparison is not
completely fair.)
> >> Ditto for EOF
> >
> > You mean reaching the end of the file is such a fatal error, that the
> > program must be terminated with an exception?
> Well, it beats producing random garbage, surely?
Since when has the EOF value been "random garbage"? In standard C the EOF
value is -1 (integer, not char), and a file read past the end of file will
always return -1. How is that "random garbage"?
Besides, reaching the end of file (and getting that -1) is *not* an error.
It's a completely normal situation which all programs reading files have to
handle. How do you even detect the end of a file without a normal EOF
situation? If reaching the end of the file would cause a fatal error which
terminates the program, that would mean 90% of programs out there would not
work.
Sure, some programming languages might have libraries or other systems
which signal the program the end of file in some other ways, but it's still
not an error to reach the end of the file.
> >> array index out of bounds
> >
> > Unless you use a proper debugger.
> I've never seen a C debugger.
Thus you base all your prejudices on non-knowledge.
> Nor would I know where to find one.
Any decent compiler will have one.
> >> (And you don't have to memorise whether 0 is true or false.
> >
> > I see how that's such a hard thing to memorize.
> There are two possibilities which are apparently equally valid. It's
> very difficult to remember which one of them was arbitrarily selected by
> the language designers.
Luckily haskell doesn't have any arbitrarily selected features in it
which you need to memorize (such as for example some function names).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez <nic### [at] gmailcom> wrote:
> Orchid XP v8 wrote:
> > I guess it works differently with a real OS. I've only ever compiled C
> > code under MS-DOS, and there you don't get "segfaults"
> MS-DOS has no memory protection at all. If you write into address 0x0000,
> you might overwrite the operating system.
What operating system?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> >> What insane nutcase thought that making assignment an expression as a
> >> good idea? Seriously, WTF? That's excellent. So if I say "if (x = 5)..."
> >> then my program will silently fail to work correctly, and I'll probably
> >> spend hours if not days trying to figure out why.
> >
> > Use a proper compiler.
> How does that help?
The compiler warns you that the sentence looks suspicious.
> >> Boolean operators and bitwise operators. Which is which? Which ones are
> >> the short-circuit ones, and which aren't? I can never remember.
> >
> > Says the person who has probably memorized over half of the most
> > obscure functions and tricks in haskell.
> In Haskell, 1) you don't need the non-shortcut versions at all, and 2)
> if you use a bitwise operator where a Boolean operator is expected (or
> vice versa), you'll get a compile-time error telling you of your
> mistake.
You missed my point.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel <a_l### [at] hotmailcom> wrote:
> > Because Haskell is not imperative and doesn't use modules. Haskell uses
> > a paradigm which does not correspond to how normal people think.
> Which really is simply because it is not taught at school.
Usually no programming languages are taught in normal school (unless
you specialize), but imperative OO languages still correspond better to
how people naturally think of tasks.
People don't think of tasks with recursive mathematical definitions.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 13-Sep-08 9:42, Warp wrote:
> andrel <a_l### [at] hotmailcom> wrote:
>>> Because Haskell is not imperative and doesn't use modules. Haskell uses
>>> a paradigm which does not correspond to how normal people think.
>
>> Which really is simply because it is not taught at school.
<restored context>
>> There is no reason for that other than tradition. Trust me,
>> it can be learned and be as natural as Boolean algebra, base eight
>> (http://jp.youtube.com/watch?v=a81YvrV7Vv8) or finite state machines,
>> none of which is taught at highschool nowadays (anymore*).
</restored context>
>
> Usually no programming languages are taught in normal school (unless
> you specialize), but imperative OO languages still correspond better to
> how people naturally think of tasks.
>
> People don't think of tasks with recursive mathematical definitions.
>
They do to some extend, about as much as they naturally think in solving
equations*. Much of what we learn at maths and physics is some sort of
formalization of things we do when solving problems. The techniques and
theories we learn at school are just an arbitrary selection of the
available knowledge. Whether something was natural or not has not been a
reason to include something in the curriculum. If the teachers two or
more generations later try to suggest otherwise, they are more trying to
justify themselves than historically accurate.
Actually part of the motivation of the functional programming designers
was that functional programming better matches to mathematics than
imperative programming. More or less the same holds for declarative
languages that are meant to be a formalization of our logic reasoning.
In short: imperative, declarative, and functional programming (etc.) all
are meant to capture (parts of) normal human reasoning. If you think one
is more natural to people than another that mainly shows that you have
more experience in that style than in others.
*Which may be much more than you normally realize.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> So let me get this straight: You are comparing C in a 10+ years old MS-DOS
> system to higher-level programming languages (such as Java and Haskell) in
> modern systems with modern OSes and modern compilers, and based on this you
> have decided that C sucks?
As far as I'm aware, C hasn't changed in 20 years, never mind 10.
>>> You mean reaching the end of the file is such a fatal error, that the
>>> program must be terminated with an exception?
>
>> Well, it beats producing random garbage, surely?
>
> Since when has the EOF value been "random garbage"? In standard C the EOF
> value is -1 (integer, not char), and a file read past the end of file will
> always return -1. How is that "random garbage"?
Really? I had assumed that after you read past the end of the file, it's
behaviour is simply undefined. I wasn't expecting the C standard to
actually bother to define the result of an operation you're not supposed
to perform.
> Besides, reaching the end of file (and getting that -1) is *not* an error.
No, reaching EOF is not an error - failing to check for EOF is an error.
>> I've never seen a C debugger.
>
> Thus you base all your prejudices on non-knowledge.
Yes - because having a debugger would make function names easier to
remember and pointer syntax less baffling and printf() would work
right... oh, wait...
>> Nor would I know where to find one.
>
> Any decent compiler will have one.
I would imagine so, yes.
>> There are two possibilities which are apparently equally valid. It's
>> very difficult to remember which one of them was arbitrarily selected by
>> the language designers.
>
> Luckily haskell doesn't have any arbitrarily selected features in it
> which you need to memorize (such as for example some function names).
Well at least you can easily look up Haskell function names.
Maybe that's part of the problem - I don't have any C programming
resources where I can actually look things up. So if something doesn't
work, there's the Borland C++ help file, or there's experimentation.
Neither of these things help terribly much.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Imperative OO languages still correspond better to
> how people naturally think of tasks.
>
> People don't think of tasks with recursive mathematical definitions.
No, they don't. Generally.
However, people quite often do think in set-based terms. Most people
don't have too much of a problem learning SQL, for example. (Although
having said that, some people insist on processing tasks row by row
rather than using a set-based solution...)
Haskell makes set-based thinking quite easy and natural.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Orchid XP v8" <voi### [at] devnull> wrote in message
news:48cb8646$1@news.povray.org...
>
> Maybe that's part of the problem - I don't have any C programming
> resources where I can actually look things up. So if something doesn't
> work, there's the Borland C++ help file, or there's experimentation.
> Neither of these things help terribly much.
>
Such a pity that no free C/C++ language guide exists...
http://www.google.com/search?hl=en&q=C+language+guide
http://www.google.com/search?q=C%2B%2B+language+guide
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
