 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
http://cdsmith.wordpress.com/2007/07/29/37-reasons-to-love-haskell-playing-off-the-ruby-article/
You don't really need to even click that, do you?
Well, maybe you do... Basically there's a "37 reasons to love Ruby"
article, so this guy did a copy for Haskell. While I applaud this, some
of the "facts" are rather dubious...
#3. "It's dynamic. Lots of Haskell applications feature dynamic code
loading." Er, yeah... if you have the damned compiler installed! What
you *can't* do is compile a module and then dynamically link it in
later. You *must* have the actual compiler available. And it's _very_
hackish and awkward to get it to work. It's not a compiler feature, it's
a low-level C library that somebody hacked together which sort-of works.
It's a nightmare to use it though!
#6. "It's multi-platform." Yeah, but unfortunately the Windows version
is running under Cygwin using the GNU toolchain (e.g., GCC, GAS, LD),
and almost all libraries involving binding to a C library spectacularly
fail to compile on Windows. All the APIs are fairly POSIX-centric so you
generally can't access Windows-specific functionallity. And so forth.
#8. "It's innovative." Well, perhaps. I love the way he cites a whole
bunch of features and "these are rare in other languages". Er, but *all*
the features you cited are features of the type checker! :-P (Why not
mention, say, concurrency and parallelism?)
#10. "It has a smart GC." Er... looks pretty primitive compared to
Smalltalk, actually.
#11. "It's a scripting language." You have *got* to be kidding me! Sure,
many things in Haskell are one-liners. But typically anything that
involves talking to the outside world has lots of small but fiddly
details that take heaps of code to sort out. Hardly a nimble scripting
language!
#15. "It's intuitive." Hahahaha... nice! (The argument does kinda make
sense - the learning curve is steep because you really do have to learn
new stuff, not just new syntax for doing the same old thing. And the
Haskell syntax is as intuitive as it can be considering that. But
still... stretching it a little, eh?)
#16. "It handles exceptions well." You... have... GOT to be kidding me!
If you try to read a non-existent directory, there is *no way* to
distinguish from a "this filename is invalid" error and a "this file
doesn't exist" error and a "there was a hardware error" error. (You
*can* at least distinguish "access denied".) Asynchronus errors are a
nightmare with lazy evaluation too!
#17. "It has advanced array types." Ha...haha...hahahaha! You've got to
be kidding me! The API is *horrid*! There is mile after mile of
functionallity missing. And there are all kinds of inconsistencies in
function names, etc.
#25. "It pays attention to details." I can't even determine what the
hell he's talking about here...
#27. "It has a rich set of libraries." Oh come *on*!! You cannot be
serious! That ball was on the line! Er, I mean... Haskell lacks
libraries for just above every possible task you can name! Want to read
a GIF file? Sorry, can't do that. Want to send a PGP-encrypted email?
Sorry, no SMTP support, no PGP support. Want to compute a CRC32
checksum? Sorry, no library for that. Want to play an AVI animation?
Guess what? No library.
But best of all: What libraries do exist do *not* work on Windows. Ever.
There are 12 database libraries, and none of them compile on Windows.
There's a wxWidgets library - doesn't run on Windows (in spite of the
special Windows-specific setup routine). There's a libSDL library... can
you guess? Doesn't work on Windows.
Haskell - Great language, just don't try to communicate with anything.
#28. "It has a debugger." Finally. It took long enough. And it's a ****
to use.
Overall though, I still thing Haskell is a great language. But then we
have this:
http://intoverflow.wordpress.com/2009/01/13/why-haskell-is-beyond-ready-for-prime-time/
Reading this, you'd think Haskell has the most awsome tools EVER! Sadly,
it's not true...
"Availability of quality libraries"
Only on Linux. And even then with huge gaps. And the overwhelming
majority of libraries were once somebody's one-man project, and lay
long-forgetted. And most of them utterly lack any documentation at all.
Oh, and Hackage is really quite clunky to use.
"Project Management"
Setting Haddoc up in such a way that it works properly is seriously
hard. (OTOH, it now comes with the compiler, which should radically
improve this!)
GHC is "the most advanced compiler anywhere", is it? Sure, I'm
enthusiastic about it, but this seems over the top to me.
(E.g., you can't compile different parts of the same program with
different versions of the compiler. Therefore *all* libraries must be
shipped in source-code form because the compiled versions only work with
one release of the compiler. Not so "advanced" now, eh?)
"Technology"
"[Haskell] stands alone in its simultaneous support for many language
features that the mainstream world probably won’t see for at least
another 10 years."
"This stuff isn’t just syntactic sugar, either. Haskell probably has
better support for concurrency than any other language[...]"
Wow, calm down there partner! Let's not get carried away here. Haskell
is an impressive language, but I'm sure somewhere there's something that
beats it in functionallity terms.
"To get a sense for how wildly amazing Haskell-related technology, check
out Automatic generation of free theorems — a tool that, given a
function’s type signature, can *write a function for you that has the
correct signature!* You won’t find this kind of thing anywhere else."
Except that it doesn't work. Nice try though...
"Community"
"Lastly we come to one of the most special features that Haskell offers:
its unique developer community."
I really can't comprehend where this myth that Haskell has a great
community keeps comming from. It isn't true!
If you ask an easy question, you will get 200 replies before you can hit
the send/receive button. If you ask a hard question, or a less
interesting one, you get silence. And if you *dare* to suggest that
calling something an epimorphism is a bad idea, you'll get flamed off
the planet!
Sure, generally the people are quite friendly. This is hardly unique to
Haskell though. The POV-Ray community has always been quite friendly,
but you don't find them calling themselves "unique".
"Haskell programmers generally feel like they’ve caught on to something
very special. Every day there are new developments in the community that
push the boundaries of technology, enabling people to write
sophisticated programs in less time and with greater reliability. There
really is a sense that we’re playing with the toys of the future, which
have somehow been gifted to us today."
Again, I don't think Haskell has ever done anything that can be called
truly "ground-breaking". If anybody knows different, let me know...
- We didn't invent pure-functional proramming with lazy evaluation and
automatic type inference. (Indeed, Haskell was designed because there
were already *too many* such languages, and they wanted to replace them
all with just one.)
- We didn't invent curried functions, high-order functions, maps and
folds, and all the other high-tech stuff that abounds in Haskell. This
stuff appears in any half-decent functional language. (E.g., I imagine
Lisp probably did it years before us.)
- We didn't invent algebraic datatypes. Those existed for decades before
us. (Although they're fairly rare in real programming languages.)
- We didn't invent type classes. It's an unusual feature, but it was
around long before Haskell.
- We didn't invent monads either. We borrowed them from category theory.
- We certainly didn't invent parallelism annotations. (As I understand
it, even languages as backward and retarded as C have those now.)
- We didn't invent Software Transactional Memory either. That was an
idea that researchers thought was cool, and it eventually got borrowed
by Haskell.
- We didn't invent Nested Data Parallelism - that's another exciting
research project somebody else did years ago that recently got
integrated into Haskell.
Indeed, I'm having trouble finding anything that Haskell itself actually
created or perfected. Arguably we have the best G-machine
implementation, but all that means is we have a compiler that produces
fast code. It's not a language feature.
Even more amusing are some of the comments:
- There's no IDE for Haskell, but "I don't think an IDE is really
necessary". Well *sure* you don't. Because you haven't got one yet! :-P
- Some guy rightly complained that you can't [easily] define two
datatypes which have fields with the same name. This is obviously a
pretty silly limitation. I love the reply "but that's good though". Uh,
yeah, lotta logic there.
- Most significantly: "Haskell will be 'ready' for 'the real world' when
we start seeing real, large-scale applications written with it. Until
then, nobody is going to care." I think this just about sums it up,
really...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> I really can't comprehend where this myth that Haskell has a great
> community keeps comming from. It isn't true!
>
> If you ask an easy question, you will get 200 replies before you can hit
> the send/receive button. If you ask a hard question, or a less
> interesting one, you get silence. And if you *dare* to suggest that
> calling something an epimorphism is a bad idea, you'll get flamed off
> the planet!
Well sit on my head and call my Harley... it seems there are people
ralleying to my latest call for less opaque terminology! o_O
I guess I'm not as hated as I thought...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> #25. "It pays attention to details." I can't even determine what the
> hell he's talking about here...
I can give you examples of what "paying attention to details" means. Dunn
o
if it's the sort of thing this guy's talking about, but...
Remember a decade ago, when people were making scripting languages
implemented in C? Lots of those languages had strings that were,
internally, null-terminated. But since they were also GCed, you didn't ge
t
the memcpy/memset sorts of functions, only the strcpy sorts of functions,
so
you couldn't actually work with binary data in a string.
And then they'd have stuff where a string literal starting with a zero is
octal. And someone would read a string from a form or the keyboard or
whatever that's supposed to be a postal (zip) code, and the user would ty
pe
09375, and the program would barf, because 9 isn't a valid octal digit.
Using a leading 0 to always mean "octal" only works if you have source co
de
compiled separately from the user input.
Working around this sort of lamebrainness is necessary if the language
designers don't pay attention to detail. (These are both examples from Tc
l,
incidentally. :-)
> "To get a sense for how wildly amazing Haskell-related technology, chec
k
> out Automatic generation of free theorems — a tool that, given
a
> function’s type signature, can *write a function for you that h
as the
> correct signature!* You won’t find this kind of thing anywhere
else."
Aren't there lots of functions that have the same signature? I mean, wha
t's
it going to write for
f :: [a] -> (a -> Bool) -> [a]
> - We didn't invent algebraic datatypes. Those existed for decades befor
e
> us. (Although they're fairly rare in real programming languages.)
Do you actually have algebraic datatypes in Haskell? Kewl.
> - There's no IDE for Haskell, but "I don't think an IDE is really
> necessary". Well *sure* you don't. Because you haven't got one yet! :-P
Heh. Funny how that works, isn't it?
--
Darren New, San Diego CA, USA (PST)
Why is there a chainsaw in DOOM?
There aren't any trees on Mars.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Orchid XP v8 wrote:
>> #25. "It pays attention to details." I can't even determine what the
>> hell he's talking about here...
>
> I can give you examples of what "paying attention to details" means.
> Dunno if it's the sort of thing this guy's talking about, but...
>
> Remember a decade ago, when people were making scripting languages
> implemented in C? Lots of those languages had strings that were,
> internally, null-terminated. But since they were also GCed, you didn't
> get the memcpy/memset sorts of functions, only the strcpy sorts of
> functions, so you couldn't actually work with binary data in a string.
>
> And then they'd have stuff where a string literal starting with a zero
> is octal. And someone would read a string from a form or the keyboard or
> whatever that's supposed to be a postal (zip) code, and the user would
> type 09375, and the program would barf, because 9 isn't a valid octal
> digit. Using a leading 0 to always mean "octal" only works if you have
> source code compiled separately from the user input.
>
> Working around this sort of lamebrainness is necessary if the language
> designers don't pay attention to detail. (These are both examples from
> Tcl, incidentally. :-)
Um... ouch! o_O
> Aren't there lots of functions that have the same signature? I mean,
> what's it going to write for
> f :: [a] -> (a -> Bool) -> [a]
Logically speaking, given a function and a list, you can either do any
of the following:
- Throw an exception. (And function with any type signature can do that!)
- Ignore the arguments and return an empty list.
- Ignore the function and return the input list.
- Rearrange the elements of the list and return that.
- Apply the function to the list in some way to decide which elements to
return.
Actually, both "filter", "takeWhile" and "dropWhile" have almost exactly
the type signature above, and they do different jobs. (One filters on
the condition, the others filter "runs" of elements matching it [or not].)
>> - We didn't invent algebraic datatypes. Those existed for decades
>> before us. (Although they're fairly rare in real programming languages.)
>
> Do you actually have algebraic datatypes in Haskell? Kewl.
Um... yes?
data Either x y = Left x | Right y
There you go. That's a sum type of product types, i.e. an algebraic data
type. (ADT - not to be confused with *abstract* data type...)
>> - There's no IDE for Haskell, but "I don't think an IDE is really
>> necessary". Well *sure* you don't. Because you haven't got one yet! :-P
>
> Heh. Funny how that works, isn't it?
Much like the "Haskell doesn't need a debugger because programs work
correctly first time". Until we got a debugger... and now it's "hey, we
have a debugger!"
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> Um... ouch! o_O
You learned to work around it, just like any other language limitation. You
occasionally got caught once or twice, then figured it out.
> Logically speaking, given a function and a list, you can either do any
> of the following:
Right. I was asking what code it generated given a signature.
>> Do you actually have algebraic datatypes in Haskell? Kewl.
>
> Um... yes?
> data Either x y = Left x | Right y
Oh, OK. Can you do something more complex, like say a stack?
Hmmm... Maybe essentially all user types in Haskell are ADTs, and I just
never thought of it that way before?
> (ADT - not to be confused with *abstract* data type...)
ADT used to mean "abstract data type", until OO started calling objects
that, and they had to change the terminology. :-)
> Much like the "Haskell doesn't need a debugger because programs work
> correctly first time". Until we got a debugger... and now it's "hey, we
> have a debugger!"
Oddly enough, a lot of projects created by nerds are like that.
--
Darren New, San Diego CA, USA (PST)
Why is there a chainsaw in DOOM?
There aren't any trees on Mars.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
>> Logically speaking, given a function and a list, you can either do any
>> of the following:
>
> Right. I was asking what code it generated given a signature.
And I was just agreeing that more than one function has that type.
However, the website says:
The theorem generated for functions of the type
f :: forall a . [a] -> (a -> Bool) -> [a]
in the sublanguage of Haskell with no bottoms is:
forall t1,t2 in TYPES, R in REL(t1,t2).
forall (x, y) in lift{[]}(R).
forall p :: t1 -> Bool.
forall q :: t2 -> Bool.
(forall (z, v) in R. p z = q v)
==> ((f x p, f y q) in lift{[]}(R))
The structural lifting occurring therein is defined as follows:
lift{[]}(R)
= {([], [])}
u {(x : xs, y : ys) |
((x, y) in R) && ((xs, ys) in lift{[]}(R))}
Reducing all permissible relation variables to functions yields:
forall t1,t2 in TYPES, g :: t1 -> t2.
forall x :: [t1].
forall p :: t1 -> Bool.
forall q :: t2 -> Bool.
(forall y :: t1. p y = q (g y))
==> (map g (f x p) = f (map g x) q)
I have absolutely *no clue* what the hell any of that means. But try it
yourself here:
http://linux.tcs.inf.tu-dresden.de/~voigt/cgi-bin/ft/ftonline.cgi
>>> Do you actually have algebraic datatypes in Haskell? Kewl.
>>
>> Um... yes?
>> data Either x y = Left x | Right y
>
> Oh, OK. Can you do something more complex, like say a stack?
>
> Hmmm... Maybe essentially all user types in Haskell are ADTs, and I just
> never thought of it that way before?
Indeed, all Haskell types are ADTs. Except things like integers,
arguably. OTOH, you could claim that Integer is defined as
data Integer = 1 | 2 | 3 | 4 | ...
As for "like say a stack", I'm not really sure what you mean.
>> Much like the "Haskell doesn't need a debugger because programs work
>> correctly first time". Until we got a debugger... and now it's "hey,
>> we have a debugger!"
>
> Oddly enough, a lot of projects created by nerds are like that.
I wonder if this is why Linux doesn't "need" a defrag tool?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> I have absolutely *no clue* what the hell any of that means. But try it
> yourself here:
That makes sense except to the extent that I don't know what LIFT{[]} means.
> Indeed, all Haskell types are ADTs. Except things like integers,
> arguably. OTOH, you could claim that Integer is defined as
>
> data Integer = 1 | 2 | 3 | 4 | ...
An abstract data type has to define the operators also.
> As for "like say a stack", I'm not really sure what you mean.
Well, an ADT has to define the type in terms of the operations on that type,
not in terms of a list of values/literals. So the ADT for "Either" would be
something like
Left (Left x) = x
Right (Right x) = x
where the first word in each is a function call and the second is a data
constructor.
A stack is usually defined as something like
new :: -> Stack // Give me a new stack
empty :: Stack -> Bool // Tell me if stack is empty
push :: (Stack, Value) -> Stack // Give me a new stack with the value pushed
pop :: Stack -> Stack // Remove value from top of stack
top :: Stack -> Value // Tell me what's on top
empty(new) // New stacks are always empty
not empty(push(S, V)) // Nothing with something pushed is empty
S = pop(push(S, V)) // pop is inverse of push on all stacks for all values
V = top(push(S, V)) // top returns most recent thing pushed
// And I think there's one other rule you need to make it work, but
// I forget what it is. I could look it up if you care.
// It might involve showing that top(new) and pop(new) are bottom.
In other words, for an ADT, there is no indication at all of the
representation of values. The value of the stack with 1, 2, and 3 pushed is
actually
push(push(push(new,1),2),3)
and not some list expression. *That* is an ADT.
The advantage is that you can prove things about the behavior without
understanding what it's "supposed" to do. For example, you can see it's
impossible to pop an empty stack, or to look at the top element of an empty
stack, because there's no matching expression for top(new). You can also do
things like prove you've covered all the possibilities, prove that one ADT
is a superset of another, and so on.
> I wonder if this is why Linux doesn't "need" a defrag tool?
That and a number of other things like that, methinks. I wasn't trying to
turn it into a Linux bash, tho, since a lot of other environments do this too.
--
Darren New, San Diego CA, USA (PST)
Why is there a chainsaw in DOOM?
There aren't any trees on Mars.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> I wonder if this is why Linux doesn't "need" a defrag tool?
It depends on what you do to your disk.
The problem is that *if* you get it fragmented (which seems to be less
likely on Linux than on Windows, but still), there is no defragmenter tool
you can use...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
>
> I wonder if this is why Linux doesn't "need" a defrag tool?
It's not a about Linux, it's about filesystems. How many times you have
actually managed to measure any benefit from defragging NTFS partition?
-Aero
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Eero Ahonen wrote:
> It's not a about Linux, it's about filesystems. How many times you have
> actually managed to measure any benefit from defragging NTFS partition?
I have, in very rare cases. But that's when I've created a file in a way
that (for example) made 300,000 fragments of it, which happens very rarely.
(It was screwing up some other disk analysis tool which apparently decided
to allocate fixed memory blocks for stuff and not check they were big enough.)
The thing is, the files don't fragment if you don't write to them, and the
files that you want to read fast and sequentially are generally things like
programs or images or something like that, where you write them all in one
chunk to start with. Who cares if your mailbox file is fragmented? Plus,
Windows has had for a long time an API to preallocate files, so if you're
doing something like copying files, it doesn't get fragmented anyway.
One good way to get fragments is to compress a file. Since it's on-the-fly
compression, what happens is that you write a (I think) 64K segment of file,
and when you move away from it, it gets compressed down to however many 4K
segments it'll fit into, then rewritten (either in the same place or
elsewhere). So if you compress a big file after the fact, you'll find it
has bunches of fragments. They're all right near each other, but they're
fragments because there's gaps in between someone else can now use.
One of the things Windows does interesting is that it'll rearrange *where*
on the disk files are as it defrags, based on usage (and based on the defrag
tool you use, of course). So it's not just "defragging files", but "putting
an EXE close to its DLLs" and "putting programs you run at login all close
together" and stuff like that.
--
Darren New, San Diego CA, USA (PST)
Why is there a chainsaw in DOOM?
There aren't any trees on Mars.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Invisible wrote:
>> I have absolutely *no clue* what the hell any of that means. But try
>> it yourself here:
>
> That makes sense except to the extent that I don't know what LIFT{[]}
> means.
>
>> Indeed, all Haskell types are ADTs. Except things like integers,
>> arguably. OTOH, you could claim that Integer is defined as
>>
>> data Integer = 1 | 2 | 3 | 4 | ...
>
> An abstract data type has to define the operators also.
Yeah, I was talking about *algebraic* data type when I said "all Haskell
types are ADTs". ;-)
>> As for "like say a stack", I'm not really sure what you mean.
>
> Well, an ADT has to define the type in terms of the operations on that
> type, not in terms of a list of values/literals.
I think we're still talking about two different meanings of ADT. ;-)
> In other words, for an ADT, there is no indication at all of the
> representation of values. The value of the stack with 1, 2, and 3 pushed
> is actually
> push(push(push(new,1),2),3)
> and not some list expression. *That* is an ADT.
>
> The advantage is that you can prove things about the behavior without
> understanding what it's "supposed" to do. For example, you can see it's
> impossible to pop an empty stack, or to look at the top element of an
> empty stack, because there's no matching expression for top(new). You
> can also do things like prove you've covered all the possibilities,
> prove that one ADT is a superset of another, and so on.
I always wandered what a abstract data type actually is...
The Eiffel guy had a chapter implementing a stack and "proving" that it
matches the spec. (He attempted to claim that the code *is* the spec.) I
think he was trying to counter the old "there is no mathematical theory
to OOP".
At the time, I believed him. Having seen Haskell, and its evil twin the
Lambda Calculus, I now understand what they mean by "no theory of OOP"...!
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
>> An abstract data type has to define the operators also.
>
> Yeah, I was talking about *algebraic* data type when I said "all Haskell
> types are ADTs". ;-)
Sorry. I get them mixed up, since the definitions changed since I studied
them. I don't hold that "objects" or "classes" are "abstract data types" at
all, so the two terms mean the same for me.
>>> As for "like say a stack", I'm not really sure what you mean.
>>
>> Well, an ADT has to define the type in terms of the operations on that
>> type, not in terms of a list of values/literals.
>
> I think we're still talking about two different meanings of ADT. ;-)
Possibly.
> I always wandered what a abstract data type actually is...
That's what it is. There's even a programming language called "ACT.ONE" (or
maybe "ACT.1", I forget which) that really has abstract/algebraic data
types, in that you (for example) don't give actual sequential steps for
pushing and popping, but you actually wrote the kind of thing that I wrote.
> The Eiffel guy had a chapter implementing a stack and "proving" that it
> matches the spec.
That's actually impossible to do, since Eiffel isn't a formal language.
There's no definition for what "X = Y" means in the language (as in
assignment operator) so he can't mathematically prove it matches the spec.
> (He attempted to claim that the code *is* the spec.)
Well, it's the spec for what his code does, but that's trivially true of any
safe language.
> I think he was trying to counter the old "there is no mathematical theory
> to OOP".
And for the most part there isn't. There's hand-waving mathematics, but not
something precise enough you can automate it.
> At the time, I believed him. Having seen Haskell, and its evil twin the
> Lambda Calculus, I now understand what they mean by "no theory of OOP"...!
Yep, exactly. ADTs are the sorts of high-level data types you build out of
lambda-calculus type rewrite rules. LOTOS is the only actual programming
language I know of that goes all the way down to that level of mathematical
detail.
--
Darren New, San Diego CA, USA (PST)
Why is there a chainsaw in DOOM?
There aren't any trees on Mars.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> The Eiffel guy had a chapter implementing a stack and "proving" that
>> it matches the spec.
>
> That's actually impossible to do, since Eiffel isn't a formal language.
> There's no definition for what "X = Y" means in the language (as in
> assignment operator) so he can't mathematically prove it matches the spec.
The Eiffel assignment operator is actually ":=", with "=" representing
(value) equality. But hey, I wouldn't know a "formal lanuage" if it hit
me...
>> I think he was trying to counter the old "there is no mathematical
>> theory to OOP".
>
> And for the most part there isn't. There's hand-waving mathematics, but
> not something precise enough you can automate it.
It's more the point that every OOP language has a slightly different
idea about the precise definition of "object", "class", "inheritance",
and so forth. (Some have SI, some have MI, some have class methods, some
don't, some have private methods, some don't, some allow public
attributes, some don't...)
>> At the time, I believed him. Having seen Haskell, and its evil twin
>> the Lambda Calculus, I now understand what they mean by "no theory of
>> OOP"...!
>
> Yep, exactly. ADTs are the sorts of high-level data types you build out
> of lambda-calculus type rewrite rules. LOTOS is the only actual
> programming language I know of that goes all the way down to that level
> of mathematical detail.
Even Haskell doesn't actually possess a denotational semantics - what
ever the hell *that* means!
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> The Eiffel assignment operator is actually ":=", with "=" representing
> (value) equality. But hey, I wouldn't know a "formal lanuage" if it hit
> me...
A formal language is one with semantics defined by rewrite rules, for
example. I.e., one concrete enough you can actually prove things about it.
Eiffel's pre and post conditions are a first step towards that.
>>> I think he was trying to counter the old "there is no mathematical
>>> theory to OOP".
>>
>> And for the most part there isn't. There's hand-waving mathematics,
>> but not something precise enough you can automate it.
>
> It's more the point that every OOP language has a slightly different
> idea about the precise definition of "object", "class", "inheritance",
> and so forth.
That's not really the problem, as long as you define it precisely.
> Even Haskell doesn't actually possess a denotational semantics - what
> ever the hell *that* means!
I need to go watch some football with the wife, but I'll give you an example
of LOTOS's semantics later, if you remind me. :-)
--
Darren New, San Diego CA, USA (PST)
Why is there a chainsaw in DOOM?
There aren't any trees on Mars.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Even Haskell doesn't actually possess a denotational semantics - what
>> ever the hell *that* means!
>
> I need to go watch some football with the wife, but I'll give you an
> example of LOTOS's semantics later, if you remind me. :-)
Or, perhaps *I* need to go watch some football or something? Depending
on how you look at it... o_O
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> Or, perhaps *I* need to go watch some football or something? Depending
> on how you look at it... o_O
That too. Speaking of American football (aka gridiron or olive ball), I was
highly amused to see the defense players doing teabagging guestures while
celebrating a particularly effective sack.
--
Darren New, San Diego CA, USA (PST)
Why is there a chainsaw in DOOM?
There aren't any trees on Mars.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> A formal language is one with semantics defined by rewrite rules, for
Of course, wikipedia already has pages on it.
http://en.wikipedia.org/wiki/Process_calculus
See especially the "reduction" part.
http://en.wikipedia.org/wiki/Algebra_of_Communicating_Processes
See especially the "formal axioms" part.
I'm sure a bright guy like you can see how this could develop
into something that would allow you to (for example) prove
that deadlock can't develop, or that some sequence of states
is always possible, and so on.
--
Darren New, San Diego CA, USA (PST)
Why is there a chainsaw in DOOM?
There aren't any trees on Mars.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Eero Ahonen wrote:
>> It's not a about Linux, it's about filesystems. How many times you have
>> actually managed to measure any benefit from defragging NTFS partition?
>
> I have, in very rare cases. But that's when I've created a file in a
> way that (for example) made 300,000 fragments of it, which happens very
> rarely. (It was screwing up some other disk analysis tool which
> apparently decided to allocate fixed memory blocks for stuff and not
> check they were big enough.)
Ever seen an NTFS partition with 0 bytes free space on it? ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Ever seen an NTFS partition with 0 bytes free space on it? ;-)
Only by accident! :-)
Any FS is going to fragment if you fill it up.
--
Darren New, San Diego CA, USA (PST)
Why is there a chainsaw in DOOM?
There aren't any trees on Mars.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Invisible wrote:
>> Ever seen an NTFS partition with 0 bytes free space on it? ;-)
>
> Only by accident! :-)
>
> Any FS is going to fragment if you fill it up.
Er, yeah. Majorly. And having a defra tool suddenly becomes wildly useful.
I still miss the old days when you could take a filesystem offline to
defrag it properly... :-(
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> I still miss the old days when you could take a filesystem offline to
> defrag it properly... :-(
You mean, back in DOS days, when you couldn't run anything but the defrag
tool while the machine's running? :-) What's "improper" about the
defragging it does now?
--
Darren New, San Diego CA, USA (PST)
Why is there a chainsaw in DOOM?
There aren't any trees on Mars.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
>
> You mean, back in DOS days, when you couldn't run anything but the
> defrag tool while the machine's running? :-) What's "improper" about
> the defragging it does now?
>
You can't stop users from doing work and look as important anymore? :P
-Aero
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I still miss the old days when you could take a filesystem offline to
>> defrag it properly... :-(
>
> You mean, back in DOS days, when you couldn't run anything but the
> defrag tool while the machine's running? :-) What's "improper" about
> the defragging it does now?
People can be refragmenting the files as you're trying to defrag them?
(Also this is presumably why every defrag tool known to man fails to
defrag certain parts of the filesystem.)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> People can be refragmenting the files as you're trying to defrag them?
Most defragmenters either lock the file while it's being defragged or they
stop defragging if you open the file for writing while they're defragging it.
> (Also this is presumably why every defrag tool known to man fails to
> defrag certain parts of the filesystem.)
That's more because bits of the kernel keep physical locations of files in
memory (like swap, or root directory, or whatever). Also, if you have the
file open for writing (like the registry, say), then it's rough to defrag
while it's being written. Which is why (for example) the "page file
defragmenter" runs during boot rather than live.
--
Darren New, San Diego CA, USA (PST)
Why is there a chainsaw in DOOM?
There aren't any trees on Mars.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> (Also this is presumably why every defrag tool known to man fails to
>> defrag certain parts of the filesystem.)
>
> That's more because bits of the kernel keep physical locations of files
> in memory (like swap, or root directory, or whatever). Also, if you
> have the file open for writing (like the registry, say), then it's rough
> to defrag while it's being written. Which is why (for example) the
> "page file defragmenter" runs during boot rather than live.
Indeed. If you could run a defragger with the filesystem unmounted, you
could move around anything you like.
Still, Windows doesn't seem to support the concept of mounting and
unmounting filesystems at will...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> Indeed. If you could run a defragger with the filesystem unmounted, you
> could move around anything you like.
With suffient information about what is where, everything but hardcoded
blocks could be moved around, yes.
> Still, Windows doesn't seem to support the concept of mounting and
> unmounting filesystems at will...
Of course it does. There are just some file systems you can't unmount
because the kernel is using files there.
--
Darren New, San Diego CA, USA (PST)
Why is there a chainsaw in DOOM?
There aren't any trees on Mars.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
>> Still, Windows doesn't seem to support the concept of mounting and
>> unmounting filesystems at will...
>
> Of course it does. There are just some file systems you can't unmount
> because the kernel is using files there.
Well you can't unmount the second partition on your harddrive, defrag
it, and then remount it (for example).
Of course, under Linux you can mount and unmount things at will - you
just can't defrag anything at all! :-}
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> Well you can't unmount the second partition on your harddrive, defrag
> it, and then remount it (for example).
Sure you can. You have to write your own defrag tool, but you can certainly
unmount the second partition, do raw I/O to it, and then remount it[1]. If
you had a defrag tool that would work on an unmounted partition, you could
do this. The one that is built into Windows assumes you want your system
live while doing this, so it deals with it, handling the fact that you're
moving the file transparently to the users.
> Of course, under Linux you can mount and unmount things at will
No you can't. You can't unmount a file system with open files on it under
Linux either. You can defrag it (or fsck it) while it's mounted, but
that'll just corrupt it, most likely.
[1] For example, try "chkdsk d: /x" from an administrator command line.
--
Darren New, San Diego CA, USA (PST)
Why is there a chainsaw in DOOM?
There aren't any trees on Mars.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Yeah, I was talking about *algebraic* data type when I said "all
>> Haskell types are ADTs". ;-)
>
> Sorry. I get them mixed up, since the definitions changed since I
> studied them.
>
>> I think we're still talking about two different meanings of ADT. ;-)
>
> Possibly.
So, now do you agree that "all Haskell types are algebraic data types"? ;-)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> So, now do you agree that "all Haskell types are algebraic data types"? ;-)
I don't know. I'm thinking not, but perhaps so. I don't know the details of
Haskell well enough, but it's possible, yes.
--
Darren New, San Diego CA, USA (PST)
"Ouch ouch ouch!"
"What's wrong? Noodles too hot?"
"No, I have Chopstick Tunnel Syndrome."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
