Huh? When? What year? The p-system is released around the same time as the microcomputer. Pascal never approaches the ROM/Basic/OS combo those systems defaulted to.
The reason is both the reason for its success and the reason for its failure. The Pascal language makes a lot of compromises in areas of readability and organization to allow for small compilers. In the case of PCs, it was much easier to write a Pascal compiler that ran well off a 128k floppy than a C compiler. That stopped mattering pretty quickly.
Well first off the super computers aren't about the Pascal language but the Pascal chip. I'd disagree that Pascal was all that proven out. It seemed very quickly to have had structural flaws which caused other languages to overtake it. Pascal was fairly low level yet it lacked good low level interfaces. Which is why it lost out to C. Pascal supports admit this and one of the main directions of Turbo Pascal / Delphi was to introduce into Pascal handling for lower level code (example partial compilation).
If you think of Pascal as a higher level language where bad handling of low level code is acceptable it also wasn't competitive. Pascal is strongly typed but has a poor type system without abstractions. Making types difficult to work with under almost all conditions. It had poor handling of static vs. dynamic data including things like abstracting networks or file systems. There are lots of sacrifices in organization for ease in writing small compilers. A very good choice for early 1980s PC compilers that had to run off a floppy not a good choice since. The languages strictness on looping structures tended to result in duplicate code.
Etc... Pascal was a partial success. But it died for good reasons.
Apple from the days of the 128k Mac has discouraged consumer tampering. They want to control the repair eco system. That's not incompetence it is policy.
FWIW the banks are behind the Apple / Google solutions. The people being stodgy are the storefronts that want to keep their equipment costs low. The banks can't afford to alienate them so they side loading this technology into the ecosystem.
Banks? They are highly trusted. They allow for key regeneration / recovery because they have physical locations and can check ID. They are technically savvy when they want to be. They have international and national bodies. They are regulated.
I would agree consistent documentation is not the strong suit. That being said the help topic in mail, "Sign or encrypt messages for increased security" is there.
Giving credit where credit is due. mail.app and keychain make it a breeze. You can drag and drop public keys, sign email, use 3rd party sources or generate keys all with a gui that is rather intuitive.
That's a very good answer. I'm going to digest it for a day or two and think about it. This forum doesn't lend itself to long conversations. But I'll see if it is still open for a response. My initial thinking is your argument seems strong.
I guess the question then is, given your attitude above why do you think even single inheritance is useful? How does the above not argument equally apply in that case? In other words why not do what functional languages do and have polymorphic methods not tied to classes and get rid of base / parent classes entirely?
Inheritance / linking in gives you finer grained control for upgrades. The recompile / link can do abstractions. Think about how Linux applications upgrade with libraries piecemeal.
Interesting point Xest. And phrased politely for a correction as well. I guess it comes down to fundamentally do you view Honda as a collection of cars or do you view Honda as a brand that is applied to cars. I was thinking the former you were thinking the later. I do agree that under the later no reason that brand shouldn't be a property is-a relationship.
Let me ask you the classic GUI examples: button inheriting from rectangle and clickable. How would you unwrap that?
Yes of course my car is a type of Honda. "My car is an Accord" is a perfectly natural thing to say. Similarly among all registered entities in NJ my car is one particular type.
Yes. An interface of small programs and thus keeps design constraints reasonable. The big issue with that is when you have to do complex changes across the system and keep things in sync.
Excellent point. Either everything has to be fairly stateless (expensive) or there has to be a wrapper for state management. I'm thinking something like STM. Question for you is why not do that? Just pas a reference to the state manager and don't manage state within the modules at all?
Well the obvious ones: Common Lisp, Rabbits, Schemes... to modern languages like ML, F#, Haskell the domain in which recursion is far and away the most common looping pattern.
That's an interesting way to handle the problem via. delegation. IMHO you've basically picked up the complexity of multiple inheritance and moved it to the methods. I'm not seeing how that changes things from pure multiple. If you are following I'd love you to expand.
I'd actually say better still is to use a recursion pattern (map-reduce, more generic hylomorphism, paramorphisms....) which can then be optimized for the machine. There is no reason to believe a programmer is going to do a better job writing his own stack handling in most situations.
As for multiple inheritance being bonkers. My car is a Honda and a vehicle registered in NJ. That's two hierarchies.
As for exceptions I agree just citing the article.
See my response above. I mostly agree with you. Though you are over simplifying a bit. For full recursion to work you need infinite time and memory. There are functions which are computable in fixed time and memory recursively but not iteratively.
This is recursion theory. A tail recursive function f is expressible in loop form f' and visa versa (https://en.wikipedia.org/wiki/Tail_call#Relation_to_while_construct). Given any simple recursion that's not tail recursive you can use an explicit stack. So for example quick sort is much easier to implement recursively but it can be implemented with an explicit stack to make it into a loop. To get something that you can't avoid you need something for which the complexity / size of the explicit stack can't be computed.
A church number (see link if you want more: https://en.wikipedia.org/wiki/...) is a function that takes two arguments one a function from a to a, the second of value of a. example three = f ( f ( f z ))) or f(f(f(z))) depending on notation
three (+1) 0 == 3 as would expect. on the other hand if pred n = (\(a,b) -> b) (n (\(a,b) -> (succ a, a)) (zero, zero) where succ n f z = f (n f z) zero f z = z
then you can define a subtraction function on church numbers. minus p q = q pred p with that definition for all church p,q and f, z. (minus (plus p q) q) f z == p f z
That function minus is not expressible as a loop though it uses the recursive structure of the underlying church number q as you can see above.
Slashdot Mirror
https://www.youtube.com/watch?...
https://www.youtube.com/watch?...
That's a longer answer than a single number or range of numbers.
Huh? When? What year? The p-system is released around the same time as the microcomputer. Pascal never approaches the ROM/Basic/OS combo those systems defaulted to.
The reason is both the reason for its success and the reason for its failure. The Pascal language makes a lot of compromises in areas of readability and organization to allow for small compilers. In the case of PCs, it was much easier to write a Pascal compiler that ran well off a 128k floppy than a C compiler. That stopped mattering pretty quickly.
Well first off the super computers aren't about the Pascal language but the Pascal chip. I'd disagree that Pascal was all that proven out. It seemed very quickly to have had structural flaws which caused other languages to overtake it. Pascal was fairly low level yet it lacked good low level interfaces. Which is why it lost out to C. Pascal supports admit this and one of the main directions of Turbo Pascal / Delphi was to introduce into Pascal handling for lower level code (example partial compilation).
If you think of Pascal as a higher level language where bad handling of low level code is acceptable it also wasn't competitive. Pascal is strongly typed but has a poor type system without abstractions. Making types difficult to work with under almost all conditions. It had poor handling of static vs. dynamic data including things like abstracting networks or file systems. There are lots of sacrifices in organization for ease in writing small compilers. A very good choice for early 1980s PC compilers that had to run off a floppy not a good choice since. The languages strictness on looping structures tended to result in duplicate code.
Etc... Pascal was a partial success. But it died for good reasons.
Apple from the days of the 128k Mac has discouraged consumer tampering. They want to control the repair eco system. That's not incompetence it is policy.
FWIW the banks are behind the Apple / Google solutions. The people being stodgy are the storefronts that want to keep their equipment costs low. The banks can't afford to alienate them so they side loading this technology into the ecosystem.
Banks? They are highly trusted. They allow for key regeneration / recovery because they have physical locations and can check ID. They are technically savvy when they want to be. They have international and national bodies. They are regulated.
I would agree consistent documentation is not the strong suit. That being said the help topic in mail, "Sign or encrypt messages for increased security" is there.
Giving credit where credit is due. mail.app and keychain make it a breeze. You can drag and drop public keys, sign email, use 3rd party sources or generate keys all with a gui that is rather intuitive.
That's a very good answer. I'm going to digest it for a day or two and think about it. This forum doesn't lend itself to long conversations. But I'll see if it is still open for a response. My initial thinking is your argument seems strong.
I guess the question then is, given your attitude above why do you think even single inheritance is useful? How does the above not argument equally apply in that case? In other words why not do what functional languages do and have polymorphic methods not tied to classes and get rid of base / parent classes entirely?
Inheritance / linking in gives you finer grained control for upgrades. The recompile / link can do abstractions. Think about how Linux applications upgrade with libraries piecemeal.
Interesting point Xest. And phrased politely for a correction as well. I guess it comes down to fundamentally do you view Honda as a collection of cars or do you view Honda as a brand that is applied to cars. I was thinking the former you were thinking the later. I do agree that under the later no reason that brand shouldn't be a property is-a relationship.
Let me ask you the classic GUI examples: button inheriting from rectangle and clickable. How would you unwrap that?
Yes of course my car is a type of Honda. "My car is an Accord" is a perfectly natural thing to say. Similarly among all registered entities in NJ my car is one particular type.
Yes. An interface of small programs and thus keeps design constraints reasonable. The big issue with that is when you have to do complex changes across the system and keep things in sync.
Quite true but CL has tail recursions which was the questions. Schemes were more academic / functional in their feel.
Excellent point. Either everything has to be fairly stateless (expensive) or there has to be a wrapper for state management. I'm thinking something like STM. Question for you is why not do that? Just pas a reference to the state manager and don't manage state within the modules at all?
Well the obvious ones: Common Lisp, Rabbits, Schemes... to modern languages like ML, F#, Haskell the domain in which recursion is far and away the most common looping pattern.
The ones who use it a lot. I'd say most. Most use recursion schemes: maps, folds, catamorphism... to guarantee they are using tail calls.
That's an interesting way to handle the problem via. delegation. IMHO you've basically picked up the complexity of multiple inheritance and moved it to the methods. I'm not seeing how that changes things from pure multiple. If you are following I'd love you to expand.
Isn't that sort of the point of OO to model?
That's a good rebuttal AC. However from the standpoint of NJ i do throw away the car (i.e. it becomes an out of state car) when I register in NY.
I'd actually say better still is to use a recursion pattern (map-reduce, more generic hylomorphism, paramorphisms....) which can then be optimized for the machine. There is no reason to believe a programmer is going to do a better job writing his own stack handling in most situations.
As for multiple inheritance being bonkers. My car is a Honda and a vehicle registered in NJ. That's two hierarchies.
As for exceptions I agree just citing the article.
See my response above. I mostly agree with you. Though you are over simplifying a bit. For full recursion to work you need infinite time and memory. There are functions which are computable in fixed time and memory recursively but not iteratively.
This is recursion theory. A tail recursive function f is expressible in loop form f' and visa versa (https://en.wikipedia.org/wiki/Tail_call#Relation_to_while_construct). Given any simple recursion that's not tail recursive you can use an explicit stack. So for example quick sort is much easier to implement recursively but it can be implemented with an explicit stack to make it into a loop. To get something that you can't avoid you need something for which the complexity / size of the explicit stack can't be computed.
A church number (see link if you want more: https://en.wikipedia.org/wiki/...) is a function that takes two arguments one a function from a to a, the second of value of a.
example three = f ( f ( f z ))) or f(f(f(z))) depending on notation
three (+1) 0 == 3 as would expect.
on the other hand
if pred n = (\(a,b) -> b) (n (\(a,b) -> (succ a, a)) (zero, zero) where
succ n f z = f (n f z)
zero f z = z
then you can define a subtraction function on church numbers.
minus p q = q pred p
with that definition for all church p,q and f, z.
(minus (plus p q) q) f z == p f z
That function minus is not expressible as a loop though it uses the recursive structure of the underlying church number q as you can see above.