Tim Roberts schrieb:
> Joachim Durchholz <[EMAIL PROTECTED]> wrote:
>
>>> Xah Lee <[EMAIL PROTECTED]> wrote:
>>>> [...] PHP and Perl are practically identical in their
>>>> high-levelness or expressiveness or field of application (and
>&g
> Xah Lee <[EMAIL PROTECTED]> wrote:
>> [...] PHP and Perl are practically identical in their
>> high-levelness or expressiveness or field of application (and
>> syntax),
That must have been a very, very distant point of view with narrowly
squinted eyes.
Regards,
Jo
--
http://mail.python.org/ma
John Thingstad schrieb:
> Skrev Joachim Durchholz <[EMAIL PROTECTED]>:
>
>> However, for web applications, I found a far easier variant: I just
>> reload the page being debugged. (I have to make sure that the backend
>> is in the same state when reloadi
Paul Rubin schrieb:
> Joachim Durchholz <[EMAIL PROTECTED]> writes:
>> Indeed. An additional case is interactive applications where setting
>> up the situation to be tested requires several time-consuming steps.
>
> At least for web development, there are a lot of a
George Neuner schrieb:
> I know not everyone
> works in RT, but I can't possibly be alone in developing applications
> that are hard to restart effectively.
Indeed. An additional case is interactive applications where setting up
the situation to be tested requires several time-consuming steps.
R
I don't know all three languages, but I know you won't get a useful
answer unless you say what purpose you want to learn any of these
languages for. To expand your mental scope? To improve your CV? To use
as a new workhorse for your daily work? If it's the latter: what kind of
work do you do?
Marc Espie schrieb:
> Apart from the fact that Knuth wrote a book series that is still THE
> definitive series on computer algorithms
I don't wish to diminish Knuth's work, but it's definitely not timeless.
For an alternative, see Sedgewick's "Algorithms in C/Pascal/whatever".
Not as rigorous ab
Wildemar Wildenburger schrieb:
> Joachim Durchholz wrote:
>> And yes, it sucks in major ways.
>>
> Oh my God, I don't want to, but I just have to ask: Why?
First of all, irregularities.
http://en.wikipedia.org/wiki/TeX#The_typesetting_system:
"[...]almost all of TeX&#
George Neuner schrieb:
>> 5. This is arguable and trivial, but i think TeX judged as a computer
>> language in particular its syntax, on esthetical grounds, sucks in
>> major ways.
>
> No one except you thinks TeX is a "computer language".
But it is.
It's Turing-complete.
And yes, it sucks in maj
Lew schrieb:
> I am afraid that your conclusion is quite mistaken. Knuth is, if
> anything, a huge success in the field of software engineering, whether
> you rate it as making a contribution to the art, or as being paid to
> perform the art.
Well, sort of.
Some of the code given is unreadable
Twisted schrieb:
> On Jun 11, 5:36 pm, Tim Bradshaw <[EMAIL PROTECTED]> wrote:
>> I think it's just obvious that this is the case. What would *stop*
>> you writing maintainable Perl?
>
> For starters, the fact that there are about six zillion obscure
> operators represented by punctuation marks,
Twisted schrieb:
> On Jun 11, 2:42 am, Joachim Durchholz <[EMAIL PROTECTED]> wrote:
>> It is possible to write maintainable Perl.
>
> Interesting (spoken in the tone of someone hearing about a purported
> sighting of Bigfoot, or maybe a UFO).
>
> Still, extraordinar
Twisted schrieb:
> After all, you can't really take a language seriously if
> it's either impossible to write unmaintainable code in it
That's true for any language.
Substitute "not straightforward" for "impossible", and you have a
condition that actually distinguishes languages.
> OR impossibl
Tim Peters schrieb:
>
> O() notation isn't being used
I was replying to Gabriel's post:
> In fact it's the other way - losing a factor of 2 is irrelevant,
> O(2N)=O(N). The logN factor is crucial here.
Regards,
Jo
--
http://mail.python.org/mailman/listinfo/python-list
Tim Peters schrieb:
> [Joachim Durchholz]
>>>> Wikipedia says it's going from 2NlogN to N. If a sort is massively
>>>> dominated by the comparison, that could give a speedup of up to 100%
>>>> (approximately - dropping the logN factor is almost irrelevan
Gabriel Genellina schrieb:
> At Tuesday 29/8/2006 07:50, Joachim Durchholz wrote:
>
>> Wikipedia says it's going from 2NlogN to N. If a sort is massively
>> dominated by the comparison, that could give a speedup of up to 100%
>> (approximately - dropping the logN fact
Jim Gibson schrieb:
>
> The problem addressed by what is know in Perl as the 'Schwartzian
> Transform' is that the compare operation can be an expensive one,
> regardless of the whether the comparison uses multiple keys. Since in
> comparison sorts, the compare operation will be executed N(logN) t
Marshall schrieb:
> No. The variable is the table, not the records.
In your examples, yes.
> Relations are not arrays.
They are, in all ways that matter for aliasing:
They are a collection of mutable data, accessible via selector values.
> Records are not lvalues.
Agreed, but they have identi
Marshall schrieb:
> Chris Smith wrote:
>> Joachim Durchholz <[EMAIL PROTECTED]> wrote:
>> I *think* I understand Marshall here. When you are saying "assignment",
>> you mean assignment to values of attributes within tuples of the cell.
>> When Marsha
Rob Warnock schrieb:
> Joachim Durchholz <[EMAIL PROTECTED]> wrote:
> +---
> | INSERT cannot be expressed in terms of assignment. INSERT creates a new
> | record; there's no way that assignment in a language like C can create a
> | new data structure!
Chris Smith schrieb:
> David Hopwood <[EMAIL PROTECTED]> wrote:
>> Chris Smith wrote:
>>> If checked by execution, yes. In which case, I am trying to get my head
>>> around how it's any more true to say that functional languages are
>>> compilable postconditions than to say the same of imperativ
Marshall schrieb:
> Joachim Durchholz wrote:
>> Marshall schrieb:
>>> Good point. Perhaps I should have said "relational algebra +
>>> variables with assignment." It is interesting to consider
>>> assignment vs. the more restricted update operators: in
Marshall schrieb:
>
> Good point. Perhaps I should have said "relational algebra +
> variables with assignment." It is interesting to consider
> assignment vs. the more restricted update operators: insert,
> update, delete.
Actually I see it the other way round: assignment is strictly less
power
Marshall schrieb:
> Joachim Durchholz wrote:
>> Marshall schrieb:
>>> I would say, records in SQL have value, and their
>>> identity is exactly their value.
>>
>> Definitely not. You can have two equal records and update just one of
>> them, yieldin
Marshall schrieb:
> Joachim Durchholz wrote:
>> As I said elsewhere, the record has an identity even though it isn't
>> explicit in SQL.
>
> H. What can this mean?
>
> In general, I feel that "records" are not the right conceptual
> level to thin
Marshall schrieb:
> Joachim Durchholz wrote:
>> You can have aliasing without pointers; e.g. arrays are fully sufficient.
>> If i = j, then a [i] and a [j] are aliases of the same object.
>
> I am having a hard time with this very broad definition of aliasing.
> Would we
Marshall schrieb:
> Joachim Durchholz wrote:
>> Marshall schrieb:
>>> What about my example of SQL? Mutation, no pointers, no aliasing.
>>> Yet: useful.
>> Sorry, but SQL does have aliasing.
>
> Well. I suppose we do not have an agreed upon definition
&
Marshall schrieb:
> Joachim Durchholz wrote:
>> It's just that I know that it's viable to give up destructive updates.
>> Giving up pointers is a far more massive restriction.
>
> Oddly, I feel the opposite. While it's true there are many domains
> for w
Marshall schrieb:
> By your definition, "pointer" and "variable" are synonyms. That doesn't
> seem like a good idea to me. (What if i and j end up in registers?
> I have not heard it said that registers have addresses.)
There are no registers in the JVM ;-P
More specifically, where Joe said "poin
Marshall schrieb:
> void foo() {
> int i = 0;
> int j = 0;
> j = 1;
> i = 2;
> // check value of j here. It is still 1, no matter what you filled
> // in above.
> // The assignment to i cannot be made to affect the value of j.
> }
>
> Those two local primitive variables cannot be ma
Marshall schrieb:
> What about my example of SQL? Mutation, no pointers, no aliasing.
> Yet: useful.
Sorry, but SQL does have aliasing.
E.g. if you have records that have name="John", surname="Doe", the
statements
SELECT * FROM persons WHERE name = "John"
and
SELECT * FROM persons WHERE na
Marshall schrieb:
> Mutability by itself does not imply identity.
Well, the implication certainly holds from identity to mutability.
The only definition of identity that I found to hold up for all kinds of
references (pointers, shared-memory identifiers, URLs etc.) is this:
Two pieces of data ar
Marshall schrieb:
> David Hopwood wrote:
>> This property is, after all, not something that the program should depend on.
>> It is determined by how good the static checker currently is, and we want to
>> be
>> able to improve checkers (and perhaps even allow them to regress slightly in
>> order t
Darren New schrieb:
> Joachim Durchholz wrote:
>> Actually, in a functional programming language (FPL), you write just
>> the postconditions and let the compiler generate the code for you.
>
> Certainly. And my point is that the postcondition describing "all valid
>
Marshall schrieb:
> Joachim Durchholz wrote:
>> Marshall schrieb:
>>> Joachim Durchholz wrote:
>>>> Marshall schrieb:
>>>>> I can see the lack of a formal model being an issue, but is the
>>>>> imperative bit really all that much of an o
Darren New schrieb:
> There are also problems with the complexity of things. Imagine a
> chess-playing game trying to describe the "generate moves" routine.
> Precondition: An input board with a valid configuration of chess pieces.
> Postcondition: An array of boards with possible next moves for
Marshall schrieb:
> Joachim Durchholz wrote:
>> Marshall schrieb:
>>> I can see the lack of a formal model being an issue, but is the
>>> imperative bit really all that much of an obstacle? How hard
>>> is it really to deal with assignment? Or does the iss
Marshall schrieb:
> So, what exactly separates a precondition from a postcondition
> from an invariant? I have always imagined that one writes
> assertions on parameters and return values, and those
> assertions that only reference parameters were preconditions
> and those which also referenced ret
Marshall schrieb:
> I can see the lack of a formal model being an issue, but is the
> imperative bit really all that much of an obstacle? How hard
> is it really to deal with assignment? Or does the issue have
> more to do with pointers, aliasing, etc.?
Actually aliasing is *the* hard issue.
Just
Darren New schrieb:
> As far as I understand it, Eiffel compilers don't even make use of
> postconditions to optimize code or eliminate run-time checks (like null
> pointer testing).
That's correct.
I think a large part of the reasons why this isn't done is that Eiffel's
semantics is (a) too c
Marshall schrieb:
> Joachim Durchholz wrote:
>> Marshall schrieb:
>>> Now, I'm not fully up to speed on DBC. The contract specifications,
>>> these are specified statically, but checked dynamically, is that
>>> right?
>> That's how it's done
Marshall schrieb:
> Now, I'm not fully up to speed on DBC. The contract specifications,
> these are specified statically, but checked dynamically, is that
> right?
That's how it's done in Eiffel, yes.
> In other words, we can consider contracts in light of
> inheritance, but the actual verificat
Marshall schrieb:
> Joachim Durchholz wrote:
>> Chris Smith schrieb:
>>> For example, I wrote that example using variables of type int. If we
>>> were to suppose that we were actually working with variables of type
>>> Person, then things get a little mo
Chris Smith schrieb:
> I think
> there's something fundamentally important about information hiding that
> can't be given up.
Indeed.
Without information hiding, with N entities, you have O(N^2) possible
interactions between them. This quickly outgrows the human capacity for
managing the inter
Chris Smith schrieb:
> For example, I wrote that example using variables of type int. If we
> were to suppose that we were actually working with variables of type
> Person, then things get a little more complicated. We would need a few
> (infinite classes of) derived subtypes of Person that fu
Andreas Rossberg schrieb:
> AFAICT, ADT describes a type whose values can only be accessed by a
> certain fixed set of operations. Classes qualify for that, as long as
> they provide proper encapsulation.
The first sentence is true if you associate a semantics (i.e. axioms)
with the operations.
Oliver Bandel schrieb:
> Matthias Blume wrote:
>
>> Tin Gherdanarra <[EMAIL PROTECTED]> writes:
>>
>>
>>> Oliver Bandel wrote:
>>>
こんいちわ Xah-Lee san ;-)
>>>
>>> Uhm, I'd guess that Xah is Chinese. Be careful
>>> with such things in real life; Koreans might
>>> beat you up for this. Stay alive
Chris Uppal schrieb:
> Joachim Durchholz wrote:
>
>>> This is implementation-defined in C. A compiler is allowed to accept
>>> variable names with alphabetic Unicode characters outside of ASCII.
>> Hmm... that could would be nonportable, so C support for Un
Matthias Blume schrieb:
> Erlang relies on a combination of purity, concurrency, and message
> passing, where messages can carry higher-order values.
>
> Data structures are immutable, and each computational agent is a
> thread. Most threads consist a loop that explicitly passes state
> around.
Tim Roberts schrieb:
> "Xah Lee" <[EMAIL PROTECTED]> wrote:
>> C ? No.
>
> This is implementation-defined in C. A compiler is allowed to accept
> variable names with alphabetic Unicode characters outside of ASCII.
Hmm... that could would be nonportable, so C support for Unicode is
half-baked at
Paul Rubin schrieb:
> It starts to look like sufficiently powerful static type systems are
> confusing enough, that programming with them is at least as bug-prone
> as imperative programming in dynamically typed languages. The static
> type checker can spot type mismatches at compile time, but the
Anton van Straaten schrieb:
> Joachim Durchholz wrote:
>> Anton van Straaten schrieb:
>>> There's a close connection between latent types in the sense I've
>>> described, and the "tagged values" present at runtime. However, as
>>> type
Darren New schrieb:
> Marshall wrote:
>> Also: has subtyping polymorphism or not, has parametric polymorphism or
>> not.
>
> And covariant or contravariant.
That's actually not a design choice - if you wish to have a sound type
system, all input parameters *must* be contravariant, all output
pa
Andrew McDonagh schrieb:
> Joachim Durchholz wrote:
>> Chris Smith schrieb:
>>> Joachim Durchholz <[EMAIL PROTECTED]> wrote:
>>>> Sorry, I have to insist that it's not me who's stretching terms here.
>>>>
>>>> All textbook
Pascal Costanza schrieb:
>> Another observation: type safeness is more of a spectrum than a
>> clearcut distinction. Even ML and Pascal have ways to circumvent the
>> type system, and even C is typesafe unless you use unsafe constructs.
>> IOW from a type-theoretic point of view, there is no real
[EMAIL PROTECTED] schrieb:
> Gabriel Dos Reis wrote:
>> |
>> | (Unfortunately, you can hardly write interesting programs in any safe
>> | subset of C.)
>>
>> Fortunately, some people do, as living job.
>
> I don't think so. Maybe the question is what a "safe subset" consists
> of. In my book, it e
[EMAIL PROTECTED] schrieb:
> Joachim Durchholz write:
>> Another observation: type safeness is more of a spectrum than a clearcut
>> distinction. Even ML and Pascal have ways to circumvent the type system,
>
> No. I'm not sure about Pascal,
You'd have to use a
Chris Smith schrieb:
> Joachim Durchholz <[EMAIL PROTECTED]> wrote:
>> Sorry, I have to insist that it's not me who's stretching terms here.
>>
>> All textbook definitions that I have seen define a type as the
>> set/operations/axioms triple I mention
Andreas Rossberg schrieb:
>
> Luca Cardelli has given the most convincing one in his seminal tutorial
> "Type Systems", where he identifies "typed" and "safe" as two orthogonal
> dimensions and gives the following matrix:
>
> | typed | untyped
>---+---+--
>safe
Anton van Straaten schrieb:
>> It seems we have languages:
>> with or without static analysis
>> with or without runtime type information (RTTI or "tags")
>> with or without (runtime) safety
>> with or without explicit type annotations
>> with or without type inference
>>
>> Wow. And I don't think
Marshall schrieb:
> It seems we have languages:
> with or without static analysis
> with or without runtime type information (RTTI or "tags")
> with or without (runtime) safety
> with or without explicit type annotations
> with or without type inference
>
> Wow. And I don't think that's a complete
Anton van Straaten schrieb:
> Marshall wrote:
>> Can you be more explicit about what "latent types" means?
>
> Sorry, that was a huge omission. (What I get for posting at 3:30am.)
>
> The short answer is that I'm most directly referring to "the types in
> the programmer's head".
Ah, finally th
Darren New schrieb:
> John W. Kennedy wrote:
>> 360-family assembler, yes. 8086-family assembler, not so much.
>
> And Burroughs B-series, not at all. There was one "ADD" instruction, and
> it looked at the data in the addresses to determine whether to add ints
> or floats. :-)
I heard that the
mind if there exists a way of perfoming the computation that requires
>> tags, the tag was there and that tag has been eliminated.
>
> Joachim Durchholz replied:
>> On a semantic level, the tag is always there - it's the type (and
>> definitely part of an axiomatic defi
[EMAIL PROTECTED] schrieb:
> Joachim Durchholz wrote:
>> > A type is the encoding of these properties. A type
>>> varying over time is an inherent contradiction (or another abuse of the
>>> term "type").
>> No. It's just a matter of definition,
Dimitri Maziuk schrieb:
> That is the basic argument in favour of compile time error checking,
> extended to runtime errors. I don't really care if it's the compiler
> or runtime that tells the luser "your code is broken", as long as it
> makes it clear it's *his* code that's broken, not mine.
You
George Neuner schrieb:
> The point is really that the checks that prevent these things must be
> performed at runtime and can't be prevented by any practical type
> analysis performed at compile time. I'm not a type theorist but my
> opinion is that a static type system that could, a priori, preve
Andreas Rossberg schrieb:
> (Btw, Pascal did not have it either, AFAIK)
Indeed.
Some Pascal dialects have it.
Regards,
Jo
--
http://mail.python.org/mailman/listinfo/python-list
Andreas Rossberg schrieb:
> Joachim Durchholz wrote:
>>>
>>>> It's worth noting, too, that (in some sense) the type of an object
>>>> can change over time[*].
>>>
>>> No. Since a type expresses invariants, this is precisely what may
>
Marshall schrieb:
> immutable = can't change
> vary-able = can change
>
> Clearly a contradiction in terms.
Not in mathematics.
The understanding there is that a "variable" varies - not over time, but
according to the whim of the usage. (E.g. if a function is displayed in
a graph, the parameter
Andreas Rossberg schrieb:
> Chris Uppal wrote:
>
>> It's worth noting, too, that (in some sense) the type of an object can
>> change over time[*].
>
> No. Since a type expresses invariants, this is precisely what may *not*
> happen.
No. A type is a set of allowable values, allowable operations
Pascal Costanza schrieb:
> Static type systems potentially change the semantics of a
> language in ways that cannot be captured by dynamically typed languages
> anymore, and vice versa.
Very true.
I also suspect that's also why adding type inference to a
dynamically-typed language doesn't give
Matthias Blume schrieb:
> Joachim Durchholz <[EMAIL PROTECTED]> writes:
>
>> Matthias Blume schrieb:
>>> Joachim Durchholz <[EMAIL PROTECTED]> writes:
>>>
>>>> Matthias Blume schrieb:
>>>>> Perhaps better: A language is static
Chris Uppal schrieb:
> Chris Smith wrote:
>> I think Marshall got this one right. The two are accomplishing
>> different things. In one case (the dynamic case) I am safeguarding
>> against negative consequences of the program behaving in certain non-
>> sensical ways. In the other (the static ca
Pascal Costanza schrieb:
> (It's really important to understand that the idea is to use this for
> deployed programs - albeit hopefully in a more structured fashion - and
> not only for debugging. The example I have given is an extreme one that
> you would probably not use as such in a "real-wor
Matthias Blume schrieb:
> Joachim Durchholz <[EMAIL PROTECTED]> writes:
>
>> Matthias Blume schrieb:
>>> Perhaps better: A language is statically typed if its definition
>>> includes (or ever better: is based on) a static type system, i.e., a
>>> sta
Andreas Rossberg schrieb:
> Rob Thorpe wrote:
>> Hmm. You're right, ML is no-where in my definition since it has no
>> variables.
>
> Um, it has. Mind you, it has no /mutable/ variables, but that was not
> even what I was talking about.
Indeed. A (possibly nonexhaustive) list of program entitie
Chris F Clark schrieb:
> In that sense, a static type system is eliminating tags, because the
> information is pre-computed and not explicitly stored as a part of the
> computation. Now, you may not view the tag as being there, but in my
> mind if there exists a way of perfoming the computation th
Matthias Blume schrieb:
> Perhaps better: A language is statically typed if its definition
> includes (or ever better: is based on) a static type system, i.e., a
> static semantics with typing judgments derivable by typing rules.
> Usually typing judgmets associate program phrases ("expressions") w
Torben Ægidius Mogensen schrieb:
> That's not really the difference between static and dynamic typing.
> Static typing means that there exist a typing at compile-time that
> guarantess against run-time type violations. Dynamic typing means
> that such violations are detected at run-time.
Agreed.
Raffael Cavallaro schrieb:
> On 2006-06-16 17:59:07 -0400, Joachim Durchholz <[EMAIL PROTECTED]> said:
>
>> I think it's easier to start with a good (!) statically-typed language
>> and relax the checking, than to start with a dynamically-typed one and
>> add
Darren New schrieb:
> Joachim Durchholz wrote:
>> Give a heterogenous list that would to too awkward to live in a
>> statically-typed language.
>
> Write a function that takes an arbitrary set of arguments and stores
> them into a structure allocated on the heap.
If
Raffael Cavallaro schrieb:
> There is a very large class of software where user inputs are
> unpredictable and/or where input data comes from an untrusted source. In
> these cases run-time checks are going to be needed anyway so the
> advantages of static type checking are greatly reduced - you
Sacha schrieb:
>
> Many lists are heterogenous, even in statically typed languages.
> For instance lisp code are lists, with several kinds of atoms and
> sub-lists..
Lisp isn't exactly a statically-typed language :-)
> A car dealer will sell cars, trucks and equipment..
> In a statically typed
Raffael Cavallaro schrieb:
> On 2006-06-14 15:04:34 -0400, Joachim Durchholz <[EMAIL PROTECTED]> said:
>
>> Um... heterogenous lists are not necessarily a sign of expressiveness.
>> The vast majority of cases can be transformed to homogenous lists
>> (though these
Rob Thorpe schrieb:
>
> If a language can express constraints of one kind that is an increase
> in expressiveness.
Agreed.
> If a language requires constraint to be in one particular way thats a
> decrease in expressiveness.
Unless alternatives would be redundant.
Having redundant ways to expre
Raffael Cavallaro schrieb:
> On 2006-06-14 09:42:25 -0400, [EMAIL PROTECTED] (Torben Ægidius
> Mogensen) said:
>
>> It takes longer for the average
>> programmer to get the program working in the dynamically typed
>> language.
>
> Though I agree with much of your post I would say that many here
Torben Ægidius Mogensen schrieb:
> For example,
> if you have to code everything as natural numbers, untyped pure lambda
> calculus or S-expressions, there is a good chance that you can get
> nonsense past the compiler.
Also past peer review and/or debugging runs. And, most importantly, past
your
Ilias Lazaridis schrieb:
> crossposted to 5 groups, which are affected by this case.
>
> followup not applicable.
Actually, in this case, yes.
> It _seems_ that Mr. Xah Les's account was terminated by dreamhost.com
> because of
>
> a) the inability of several people to detect the interconnectio
[EMAIL PROTECTED] schrieb:
> "This is where K starts to set itself from apart from most of the
> common programming languages in use today. You rarely write loops in K
> (KDB is 100% loop-free), instead you use adverbs. An adverb modifies a
> function, returning another function, changing the way
[EMAIL PROTECTED] wrote:
> K!
> http://en.wikipedia.org/wiki/K_programming_language
>
> Interesting.
> Looking at your program, they are so short. I don't know if they are
> full implementation or what...
That's no surprise: list and tree processing are often built right into
more expressiv
91 matches
Mail list logo
