Computers:

Page 9 of 17 Previous  1 ... 6 ... 8, 9, 10 ... 13 ... 17  Next

View previous topic View next topic Go down

Every 10 years we need a new programming language paradigm

Post  Shelby on Sun Feb 06, 2011 9:38 am

http://creativekarma.com/ee.php/weblog/about/

In 1975 I started using “structured programming” techniques in assembly language, and became a true believer.

In 1983 a new era dawned for me as I started doing some C programming on Unix and MS-DOS. For the next five years, I would be programming mixed C/assembly systems running on a variety of platforms including microcoded bit-slice graphics processors, PCs, 68K systems, and mainframes. For the five years after that, I programmed almost exclusively in C on Unix, MS-DOS, and Windows.

Another new era began in 1994 when I started doing object-oriented programming in C++ on Windows. I fell in love with OO, but C++ I wasn’t so sure about. Five years later I came across the Eiffel language, and my feelings for C++ quickly spiraled toward “contempt.”

The following year, 2000, I made the switch to Java and I’ve been working in Java ever since.

About now, it time for the one that follows Java (the virtual machine, garbage collection, no pointers, everything is an object) paradigm.

Shelby
Admin

Posts: 3107
Join date: 2008-10-22

View user profile http://GoldWeTrust.com

Back to top Go down

Copute influenced by

Post  Shelby on Sun Feb 06, 2011 1:41 pm

The Wikipedia page for each computer language, lists the languages that it was influenced by.

Copute influenced by in chronological ascending order:

C++
PHP
JavaScript
HaXe
Haskell
Scala

Copute influenced by degree of importance/influence descending order:

HaXe
Haskell
Scala
JavaScript
PHP
C++


P.S. I misread the charts at indeed.com are "percentage growth", not "percentage rate of growth". Thus the 2500% growth of Scala jobs and -50% loss of Cobol jobs, is cumulative, not a variable rate of growth (i.e. distance not 1st derivative = velocity). Looks like Scala's 2500% growth was (afair) primarily in the past 2 years, so it is still an astronomic rate, if sustained, but in any case, the # of years would be significantly more than I computed previously. Also the rate of growth may be slowing already (I would need to back and study the chart carefully).

Shelby
Admin

Posts: 3107
Join date: 2008-10-22

View user profile http://GoldWeTrust.com

Back to top Go down

Doug Pardee rebuttal

Post  Shelby on Sun Feb 06, 2011 3:04 pm

http://creativekarma.com/ee.php/weblog/comments/death_to_the_liskov_substitutability_principle/

The problem is not to reuse monoliths but to make interfaces granular enough to reuse the components of the monoliths.

http://creativekarma.com/ee.php/weblog/comments/static_typing_and_scala/

Although I agree that to some extent Scala has some syntax and paradigm complexity overload, afaics you missed the key point that although imperative code does not impact the referential transparency (mutability) of its containing function, FP code is required to obtain parallelism:

http://goldwetrust.up-with.com/t112p90-computers#4061

I think much of Scala's perceived complexity is the way Scala has been explained so far has been very obtuse, the syntax is just different enough from the C++/Java genre to make it hard to read (takes the mind years to become as comfortable reading a new syntax as it did learning to drive a manual transmission), and many paradigms in Scala are not unified (e.g. lazy vals and by-name parameters are really both just automatic function closures). I am working on improving these issues for Copute and adding referential transparency.

http://copute.com/dev/docs/Copute/ref/intro.html


Last edited by Shelby on Sat Aug 06, 2011 2:14 am; edited 4 times in total

Shelby
Admin

Posts: 3107
Join date: 2008-10-22

View user profile http://GoldWeTrust.com

Back to top Go down

Compare explanations of mixins

Post  Shelby on Mon Feb 07, 2011 12:19 am

My explanation:

http://copute.com/dev/docs/Copute/ref/class.html#Inheritance

Creator of Scala's explanations:

http://www.scala-lang.org/node/117
pg 5, 2.2 Modular Mixin Composition section of Scalable Component Abstractions, Odersky & Zenger, Proceedings of OOPSLA 2005, San Diego, October 2005 (note Copute reverses the inheritance list order).

Which one is more complete, concise, and comprehensible? Don't answer in this thread please.

Here is a worse explanation from out of on the web:

http://debasishg.blogspot.com/2006/04/scala-compose-classes-with-mixins.html

P.S. I post to my goldwetrust.up-with.com forum, so I have copies of my thoughts to refer back to, so I won't lose the information. It has nothing to do with wanting to target a programmer audience of readers. I don't want a lot of questions and attention from programmers right now, that will just slow me down with their confusion about what I am trying to design. I get plenty enough design input by reading voraciously what others have done and research papers.

Shelby
Admin

Posts: 3107
Join date: 2008-10-22

View user profile http://GoldWeTrust.com

Back to top Go down

thoughts about the Halting problem with respect to Copute

Post  Shelby on Tue Feb 08, 2011 11:51 am

I think they will find flaws in my work, but hopefully it will only be flaws that I know exist, because they are matters owned by God, e.g. the ability to predict the future. This is why the Halting Theorem says that it is "undecidable" whether a program will ever halt. It means we can't know the answer. Examples are very simple programs called Cellular Automa. They are very simple rules, maybe only 2 or 3, yet the only way to know what value they will create on the trillionth iteration, is to run them a trillion times. We don't know if they will ever halt or reduce the same pattern. Some produce a repeated pattern for a long time, then start producing another pattern. They have patterns within patterns within patterns, that are revealed only as you run them longer.

We can prove that some programs halt, and that is because they are not Turing complete logic machines. They are limited in what they can express.

My job is now is to give the language a way to express that the futures contracts do not exist in portions of the program. Once we isolate where the futures contracts are, we can isolate those portions that can not be composed freely and will always have bugs and will be "undecidable".

P.S. Remember my work where space-time is just a perception. The the mimic octopus illustrates how we can be fooled by our space-time senses.


Last edited by Shelby on Sat Feb 19, 2011 1:36 am; edited 1 time in total

Shelby
Admin

Posts: 3107
Join date: 2008-10-22

View user profile http://GoldWeTrust.com

Back to top Go down

Copute does not repeat the "Billion Dollar Mistake"

Post  Shelby on Tue Feb 08, 2011 2:27 pm

Copute has an orthogonal Maybe type, not automatically unboxed if not checked.

Other languages default types to nullable, which can cause an unchecked exception on every use of every type.

Shelby
Admin

Posts: 3107
Join date: 2008-10-22

View user profile http://GoldWeTrust.com

Back to top Go down

Was Knuth wrong about coroutines?

Post  Shelby on Wed Feb 09, 2011 12:40 pm

Tangentially, Donald Knuth is like an idol to many in computer science. He seems to be a very humble, likable, productive, and super intelligent person.

Regarding his statement about coroutines, "Subroutines are special cases of ... coroutines.". He also wrote the following:

Coroutines are analogous to subroutines, but they are symmetrical with respect to caller and callee: When coroutine A invokes coroutine B, the action of A is temporarily suspended and the action of B resumes where B had most recently left o

Afaics, does he have it backwards, or is the statement arbitrary? Afaics, coroutines are special cases of subroutines.

Think about it. A subroutine which is referentially transparent, will return the same value for the same inputs.

Thus all a coroutine is doing is restructuring the algorithm such as that each "yield" is a return value from a subroutine. I had made this observation earlier:

http://code.google.com/p/copute/issues/detail?id=24

Let me give an example of a coroutines:

Code:
function TwoDimensionWalk( m, n )
{
  for( i = 0; i <= m; ++i )
      for( j = 0; j <= n; ++i )
      {
        // do any thing here
        yield to Consume
      }
}

function Consume()
{
  // do any thing here
  yield to TwoDimensionWalk
}

Here it is with subroutines

Code:
function TwoDimensionWalk( m, n )
{
  for( i = 0; i <= m; ++i )
      for( j = 0; j <= n; ++i )
      {
        NextJ()
        Consume()
      }
}

function NextJ()
{
  // do any thing here
}

function Consume()
{
  // do any thing here
}


Last edited by Shelby on Sat Feb 19, 2011 1:33 am; edited 1 time in total

Shelby
Admin

Posts: 3107
Join date: 2008-10-22

View user profile http://GoldWeTrust.com

Back to top Go down

Scala was 22,000 to 48,000 LOC to implement

Post  Shelby on Fri Feb 11, 2011 11:10 am

http://lambda-the-ultimate.org/node/1233#comment-13870

Typical programmer will average around 30 delivered, production read LOC per day.

Considering that I might be above average, and considering I might work 50% longer per day, I am looking at on the order of 7 to 26 months to complete Copute's compiler.

Shelby
Admin

Posts: 3107
Join date: 2008-10-22

View user profile http://GoldWeTrust.com

Back to top Go down

Tax strategy

Post  Shelby on Fri Feb 11, 2011 12:09 pm

http://esr.ibiblio.org/?p=2931#comment-296156

>I don’t think a “forgone license fee” counts as a loss under any accounting system.

Yeah, there’s no way the IRS would buy that. MS has been able to get massive write-offs by giving away copies of their products to schools and charities, but I don’t think NOK counts as a charity yet.

Shelby
Admin

Posts: 3107
Join date: 2008-10-22

View user profile http://GoldWeTrust.com

Back to top Go down

Lower middleman cost "App Store" is needed?

Post  Shelby on Sat Feb 12, 2011 10:59 am

I think my business model for Copute might be needed by the market from the perspective of both the developers and the users (customers).

http://esr.ibiblio.org/?p=2931#comment-296323

Jacob Hallén Says:
February 12th, 2011 at 11:12 am

With Symbian the customer is owned by the operator. For an app to work (without tons of tedious warnings) , it needs to have a certificate signed by the operator. In exceptional circumstances you can get your certificate signed by the phone manufacturer, but most of the time this doesn’t happen, because the phone manufacturer wants to stay buddies with the operator and get him to subsidise the manufacturers phones.
As an app developer you are stuck in certification hell. It is tedious and damned expensive.

Enter the IPhone. The customer is owned by Apple. They will lease the customer to you on fairly decent terms. You no longer need to deal with hundreds of operators or manufacturers that see you as a threat to their business. This is a large part of the success of Apple in the market. It beats the pants off the Symbian model, because users can get the apps they want with any operator they care to use and the developers have one target to develop for. However, Apple charges a high price for the convenience.

Google sees this and is also worried about being kept out of the walled garden with their ads. They put Android on the market, making it free and making the apps self certified. This casts the users free from the control of both operators and handset manufacturers. It makes the devlopers happy, because they are no longer under the control of Apple.

http://esr.ibiblio.org/?p=2931#comment-296332

# Some Guy Says:
February 12th, 2011 at 12:27 pm

> Apple charges a high price for the convenience.

I wouldn’t call it a high price at all. 30% is quite typical for what we had to pay to distributors back in the days of software in boxes on retail shelves, and we don’t have to deal with the cost of implementing a payment system, etc.


http://esr.ibiblio.org/?p=2931#comment-296341

# Morgan Greywolf Says:
February 12th, 2011 at 2:01 pm

I wouldn’t call it a high price at all. 30% is quite typical for what we had to pay to distributors back in the days of software in boxes on retail shelves, and we don’t have to deal with the cost of implementing a payment system, etc.

But we no longer live in a world of boxed software. These days most of us who do buy software do so online. That means the only middle men that are of any consequence are the credit card processors and the transaction clearinghouses. Why do we need Apple? Oh, I forgot, because they make us.

http://esr.ibiblio.org/?p=2931#comment-296345

# tmoney Says:
February 12th, 2011 at 4:05 pm

>Why do we need Apple? Oh, I forgot, because they make us.

And the examples of independent Android developers making their millions without using Android market place are…

http://esr.ibiblio.org/?p=2931#comment-296365

@Some Guy:

Certainly, there are examples of people getting rich off Apple’s app store, just like there are people getting rich from football, from singing, etc.

A lot of people make the assumption that paid apps are the way to go, because it’s easier to make good money with them than via advertising. That makes sense if the average developer can, in fact, make good money on the average app through Apple’s store.

I haven’t checked out this guy’s assumptions or math or numbers, but he goes into great detail, and concludes that the median paid app in Apple’s store earns $682 for its developer.

Wow! So that means a granular contribution monetization model might be much more realistic way to be involved for programmers! Yeah!!!!


Last edited by Shelby on Sat Feb 12, 2011 7:50 pm; edited 1 time in total

Shelby
Admin

Posts: 3107
Join date: 2008-10-22

View user profile http://GoldWeTrust.com

Back to top Go down

Decided to code the Copute compiler in Scala instead of HaXe

Post  Shelby on Sat Feb 12, 2011 11:00 am

Scala is a superset of Copute's planned feature set, except for pure functions:

http://copute.com/dev/docs/Copute/ref/intro.html#Scala

Which means it will drastically simplify the first iteration of the Copute compiler, because I can just do a literal AST translation of the grammar and output Scala code, with no post parsing analysis needed. Meaning I don't have to do any semantic analysis, just do a surjective mapping of the AST, sort of akin to a regex search and replace. This should mean I can have something working within about 3 months, assuming I don't take any time off.

Whereas, the HaXe compiler can't do numerous things, so I would have to do considerable semantic analysis to output HaXe code:

http://copute.com/dev/docs/Copute/ref/intro.html#HaXe

Also if I write the initial compiler code in Scala, I will have all the planned features of Copute (except pure functions) at my disposal, and then translating that code back to Copute code later, will also be a simple regex search and replace. Coding in HaXe, although benefits from a more familiar C-like syntax, will be burdened by the critical features missing in HaXe.

Also HaXe has no debugger, and Scala has at least three integrated Java development environments with debuggers:

http://www.scala-lang.org/node/91#ide_plugins

Not having a debugger makes working in HaXe impractical.

Also if Copute outputs Scala code as one of its output targets, then it means Copute also has a debugger. Although it won't be debugging in native Copute, at least it will be in the surjective Scala code.

And Java is the main language of Google Android (and smartphones just passed PCs in global unit sales in Q4 2010!), and so Scala runs on any platform that runs Java. So then Copute would too! Imagine Copute could become the most popular way to code Andriod applications.

So then what is the point of creating Copute, if Scala has everything except pure functions?

Several reasons:


  1. Copute more optimized type erasure.
  2. Pure functions (from Haskell) are the critical feature needed for widescale contribution composability & reuse, as well as concurrency for more CPU cores coming.
  3. Most programmers can not wrap their mind around Scala (and the better ones need months to grasp it). I was able to grasp Scala in a fews days, but I am apparently far above average and have a lot of knowledge of Haskell, HaXe, etc.. So Copute's syntax will be more familiar (C-like) and it will remove some of the unnecessary generality that makes Scala obtuse, yet retain all the necessary power of expression. So as one market (of several I forsee), I am viewing Copute as a faster way to write Scala code!
  4. Scala has the ability to throw and catch an exception. I am tentatively trying to eliminate even throwing an exception in Copute, except in a dynamic function.
  5. Dynamic coding is extremely popular and it will require massive boilerplate in Scala. Dynamic coding in Copute will be the same (thus concise) as the most popular language in world JavaScript.
  6. Scala can mix implementation in an interface (called "trait" in Scala), which causes semantic errors. I have disallowed this in Copute's inheritance model.
  7. Scala allows structural subtyping, which I have disallowed in Copute, because it can cause semantic errors.
  8. Scala allows "override" runtime virtual inheritance, which can cause semantic errors.
  9. Scala allows abstract and higher-kind types (as well as other things such as hiding closures in Unit type arguments, etc), that make reading Scala code like trying to read treasure map. Copute code is more transparent and straightforward, without losing necessary capabilities.
  10. The intent is for Copute to target more languages, e.g. JavaScript, PHP, Python, etc.. Copute will be able to do this more easily because it doesn't have those unnecessary, academic super generality types that Scala has. Scala appears to be tied to the Java (and maybe Microsoft .Net) platforms for the time being.
  11. Copute has an EBNF defined LL(3) context-free grammar (CFG) already completed, so easier for others to write Copute tools. I am not sure if Scala has a BNF CFG specification (I need to research this).
  12. K.I.S.S.
  13. If Copute's compiler code will be simpler than Scala's (which it should be, since less unnecessary generality), then I should be able to innovate faster than Scala with more contributors, as they will be able to more readily understand the code.
  14. there are probably more reasons....


Last edited by Shelby on Sat Aug 06, 2011 2:17 am; edited 4 times in total

Shelby
Admin

Posts: 3107
Join date: 2008-10-22

View user profile http://GoldWeTrust.com

Back to top Go down

Type erasure versus reified generics

Post  Shelby on Sat Feb 12, 2011 2:57 pm

Here follows the Wikipedia comparison for Java's type erasure versus Microsoft C#'s reification, which I have expanded to include Scala's improvements over Java, and Copute's proposed method to obtain full reification via various planned output targets. The rows from the Wikipedia table which seemed unimportant, appear as empty rows below.

Btw, I find this summary of differences between Java and Scala, very useful.

So far, it seems to me that type erasure is more efficient than reification, because it does not require unnecessary multiple runtime versions of generic code, and that the problems with type erasure are because the JVM (Java Virtual Machine) has poorly understood "use-site" variance declaration (versus Copute and Scala's "definitions-site" site variance declaration), and JVM erases the order and number of type parameters and the bounds of the type parameters, so there is much unnecessary casting (i.e. reflection) and other problems.

Java Microsoft C# Scala Copute
Type checks and downcasts are (implicitly) injected into client code (the code referencing the generics). Compared to non-generic code with manual casts, these casts will be the same[11]. But compared to compile-time verified code which would not need runtime casts and checks, these operations represent a performance overhead. Note such casts are not injected when the type parameter has a bound (the type that is erased to) which is the expected type. C#/.NET generics guarantees type-safety and is verified at compile time and no extra checks/casts are necessary at runtime. Hence, generic code will run faster than non-generic code (and type-erased code) which require casts when handling non-generic or type-erased objects. Scala implicitly injected these casts whether it runs on virtual machine is generics ignorant (i.e. requires type erasure), e.g. Java Virtual Machine (JVM), or on a virtual machine which has reification, e.g. Microsoft .Net Copute is a chameleon and these casts will only be implicitly injected when type erasure is required by the output target. And note that dynamically typed language output targets such as JavaScript and Python, do not need casts (although they suffer speed because they do hashtable lookup for each object member access).
Cannot use primitive types as type parameters; instead the developer must use the wrapper type corresponding to the primitive type. This incurs extra performance overhead by requiring boxing and unboxing conversions as well a memory and garbage collection pressure because the wrappers will be heap allocated as opposed to stack allocated. Primitive and value types are allowed as type parameters in generic realizations. At runtime code will be synthesized and compiled for each unique combination of type parameters upon first use. Generics which are realized with primitive/value type do not require boxing/unboxing conversions. Even though all primitive types are classes in Scala, these are implemented as primitive types where possible in the JVM["Step 8"]. Thus, due to type erasure Scala suffers the same boxing performance penalty as Java when a primitive type is used as a type parameter. However, there exist libraries and experimental compiler features to help with optimization but they introduce boilerplate tsuris. Copute is a chameleon and will at least achieve at least the performance of its output target. Additionally, Copute may apply implicit optimizations (that require no boilerplate) to improve performance on output targets that otherwise employ boxing.
Generic exceptions are not allowed[12] and a type parameter cannot be used in a catch clause[13]. Can both define generic exceptions and use those in catch clauses. ? Copute is discouraging, or hopefully eliminating, user code exceptions. Exceptions may be generated implicitly by primitive types, e.g. integer overflow.
Static members are shared across all generic realizations[14] (during type erasure all realizations are folded into a single class). Note this is only a problem for mutable static members, e.g. those not final or a method. Note that it is not allowed to make a static member which is not a function (nor method) and has the type of, or that is parametrized by, a class type parameter, because these would present a type mismatch between two generic realizations. Static members are separate for each generic realization. A generic realization is a unique class. Scala's singleton object is shared across all type parameter realizations of the companion class, and it can not be type parametrized, but each method of a singleton object can be orthogonally parametrized (see next row of this table), which is essentially what is needed. Thus this is only a problem for mutable members of object, e.g. those that are var (not val or def), because they can not be type parametrized. Although it is difficult to think of a case where there is benefit when static members are separate for each type parameter realization (why is a list of string differentiated from a list of integer for a static?), Copute could achieve this on output targets which use type erasure by creating a unique singleton object for each realization, but only necessary for those that have mutable static members. It is not yet decided if there are use cases that justify this, since afaics it is only necessary for a static member which is not a function (nor method) and has the type of, or that is parametrized by, a type parameter, because these would otherwise present a type mismatch between two generic realizations, but mutable statics are bad design.
Type parameters cannot be used in declarations of static fields/methods or in definitions of static inner classes. No restrictions on use of type parameters. Each function (or method) in the singleton object can declare type parameters which are orthogonal to, or duplicates of, any type parameters of the companion class. Any companion class type parameters can be accessed, by inputting an instance of the companion class to the static function (or method), then calling a method in the companion class-- because there is no use for the concrete companion class type parameters without an instance of the companion class. As stated in prior row of this table, mutable static non-functions (a/k/a 'fields') can not be type parametrized, and they can't be allowed because they cause type mismatch between generic realizations (and are undesirable bad design any way). Inner classes are correctly orthogonally parametrized and the type parameters can be specified on each generic realization. Ditto as per Scala, except this is done with 'static' keyword instead of singleton 'object' declaration. It would also be possible to simulate type parametrized mutable static non-functions (a/k/a 'fields'), per the prior row of this table, but probably undesirable.
Cannot create an array where the component type is a generic realization (concrete parameterized type).
Code:
object tenPairs =
    new Pair<Integer, String>[10];
A generic realization is a 1st class citizen and can be used as any other class; also an array component.
Code:
object tenPairs =
    new Pair<int, string>[10];
"Scala does not know such a restriction, although it uses erasure."
Code:
var tenPairs =
    new Array[Pair[Integer, String]](10);
Copute does not have such restriction.
Cannot create an array where the component type is a type parameter.
Code:
class GenericArrayTest<T>{
  public <T> T[] returnArray(){
    return new T[10];
  }
}
}
Type parameters represent actual, discrete classes and can be used like any other type within the generic definition.
Code:
public class Lookup<TKey, TValue> {
    public TValue[] GetEmptyValues(TKey key) {
        return new TValue[0]; // ok
    }
}
"Scala does not know such a restriction, although it uses erasure."
Code:
class GenericArrayTest[T]{
  def returnArray: Array[T] = {
    return new Array[T](10);
  }
}
Copute does not have such restriction.
There is no class literal for a concrete realization of a generic type. Thus instanceof and cast on a parametrized type are impossible.
Code:
List<T> o
o instanceOf List<String>
(List<String>)o
A generic realization is an actual class. There is no class literal for a concrete realization of a type parameter. Thus isInstanceOf, asInstanceOf, and pattern matching a parametrized type are impossible.
Code:
List[T] o
o.isInstanceOf[List[String]]
o.asInstanceOf[List[String]]
It is difficult to think of a case where there is a benefit to isInstanceOf, asInstanceOf, or pattern matching on a parametrized type, because it would be impossible to know a priori all the possible class literals to expect and this would not be checked at compile-time. An equivalent functionality can be checked at compiled-time by employing function overloading, which is compatible with output targets that do type erasure. Although isInstanceOf and pattern matching could be provided by storing reflection data in each instance, or otherwise providing reflection, it is the implementation of asInstanceOf which would be more complex as it would require casts on every use of the erased type parameter, e.g. T as String erased to Object.
instanceof is not allowed with type parameters or concrete generic realizations. The is and as operators work the same for type parameters as for any other type. See prior row of this table. See prior row of this table.
Cannot create new instances using a type parameter as the type. With a constructor constraint, generic methods or methods of generic classes can create instances of classes which have default constructors. Cannot create new instances using a type parameter as the type. It is poor design to instantiate explicit class literals (i.e. use new), so proper design will have all types implement a static type parametrized factory interface, then any type parameter which is upper bound on that interface, can be instantiated by calling the interface's factory method. This boilerplate could be automated in Copute for every concrete class that has an implicit (i.e. no explicit) or constructor without formal parameters. The concrete class could override factory method to provide custom behavior. Such a solution works with output targets that do type erasure.
The unbounded type(s) of the parametrized type are erased during compilation. Special extensions to reflection must be used to discover the original type. Type information about C# generic types is fully preserved at runtime, and allows complete reflection support as well as instantiation of generic types. The unbounded type(s) of the parametrized type are erased during compilation. It is difficult to think of a case of benefit from reflection for reading the unbounded type(s) of a parametrized type. It could be done if we can think of a justified use case.


Last edited by Shelby on Wed Feb 16, 2011 12:23 am; edited 28 times in total

Shelby
Admin

Posts: 3107
Join date: 2008-10-22

View user profile http://GoldWeTrust.com

Back to top Go down

Proving the Halting Problem, by Dr. Suess

Post  Shelby on Sat Feb 12, 2011 6:17 pm

The following is relevant to Copute, but it is also relevant to everything, including all science, religion, philosophy, and any search for truth and knowledge.

Recursion is a key feature of a Turing complete machine (i.e. a computer).

Russell's Paradox: there is no rule for a set that does not cause it to
contain itself, thus all sets are infinitely recursive.

The is also a feature of Russell's Paradox, which says that any set also contains itself (that nothing can be non-recursive, any such false barrier, will be brittle and fail due to Coase's Theorem).

And follows all the other theorems which all derive and relative to the 2nd law of thermodynamics which says the universe is always trending to maximum disorder (i.e. maximum possibilities):

* Liskov Substition Principle: it is an undecidable problem that subsets
inherit.

* Linsky Referencing: it is undecidable what something is when it is
described or perceived.

* Coase Theorem: there is no external reference point, any such barrier
will fail.

* Godel's Theorem: any formal theory, in which all arithmetic truths can
be proved, is inconsistent.

* 1856 Thermo Law: entire universe (a closed system, i.e. everything)
trends to maximum disorder.


http://ebiquity.umbc.edu/blogger/2008/01/19/how-dr-suess-would-prove-the-halting-problem-undecidable/

Scooping the Loop Snooper
an elementary proof of the undecidability of the halting problem

Geoffrey K. Pullum, University of Edinburgh

No program can say what another will do.
Now, I won’t just assert that, I’ll prove it to you:
I will prove that although you might work til you drop,
you can’t predict whether a program will stop.

Imagine we have a procedure called P
that will snoop in the source code of programs to see
there aren’t infinite loops that go round and around;
and P prints the word “Fine!” if no looping is found.

You feed in your code, and the input it needs,
and then P takes them both and it studies and reads
and computes whether things will all end as they should
(as opposed to going loopy the way that they could).

Well, the truth is that P cannot possibly be,
because if you wrote it and gave it to me,
I could use it to set up a logical bind
that would shatter your reason and scramble your mind.

Here’s the trick I would use – and it’s simple to do.
I’d define a procedure – we’ll name the thing Q -
that would take any program and call P (of course!)
to tell if it looped, by reading the source;

And if so, Q would simply print “Loop!” and then stop;
but if no, Q would go right back to the top,
and start off again, looping endlessly back,
til the universe dies and is frozen and black.

And this program called Q wouldn’t stay on the shelf;
I would run it, and (fiendishly) feed it itself.
What behaviour results when I do this with Q?
When it reads its own source, just what will it do?

If P warns of loops, Q will print “Loop!” and quit;
yet P is supposed to speak truly of it.
So if Q’s going to quit, then P should say, “Fine!” -
which will make Q go back to its very first line!

No matter what P would have done, Q will scoop it:
Q uses P’s output to make P look stupid.
If P gets things right then it lies in its tooth;
and if it speaks falsely, it’s telling the truth!

I’ve created a paradox, neat as can be -
and simply by using your putative P.
When you assumed P you stepped into a snare;
Your assumptions have led you right into my lair.

So, how to escape from this logical mess?
I don’t have to tell you; I’m sure you can guess.
By reductio, there cannot possibly be
a procedure that acts like the mythical P.

You can never discover mechanical means
for predicting the acts of computing machines.
It’s something that cannot be done. So we users
must find our own bugs; our computers are losers!

================

Let me make the proof more simple for you. If I write a function that returns either "Stops" or "Does not stop" when it analyzes any other function. Now I have my function call that function, so that function analyzes my function and returns "Does not stop", because there is an infinite loop.

The point is that any function can be called. The set of functions always contains itself.

Shelby
Admin

Posts: 3107
Join date: 2008-10-22

View user profile http://GoldWeTrust.com

Back to top Go down

Mixins are just single-inheritance folding

Post  Shelby on Sat Feb 12, 2011 10:31 pm

I wrote some public comments today

http://www.codecommit.com/blog/scala/scala-for-java-refugees-part-5/comment-page-1#comment-5284

#

@Cedric

You missed the point of mixins. They completely solve the diamond problem because only duplicate methods which are from the EXACT SAME trait are resolved automatically. Any duplicates from different traits have to be resolved by the superclass in the single-inheritance chain (i.e. analogous to “Class::” in C++).

You can’t do “Class::” specific method call from a trait (you must use the less specific “super.” instead), this because mixin order can insert an mixin in middle of the inheritance hierarchy of another mixin. For example, given mixin A (B) and mixin C (B), then mixin D (C,A) would effectively cause mixin C (A,B), because the B in mixin C (B) is already in the inheritance tree of mixin A (B), and thus not repeated. A more detailed explanation can be found at top, left of page 7 in the Super subsection of the 2.2 Modular Mixin Composition section of Scalable Component Abstractions, Odersky & Zenger, Proceedings of OOPSLA 2005, San Diego, October 2005.

http://www.scala-lang.org/sites/default/files/odersky/ScalableComponent.pdf

So I want you to realized that “Class::” specific method invocation can never be as flexible as mixins.

I studied this deeply for the design of my Copute language.
Shelby Moore III Sunday, February 13, 2011 at 2:12 am
#

typo: I meant “…have to resolved by the subclass…”
Shelby Moore III Sunday, February 13, 2011 at 2:14 am
#

@Cedric

Don’t conflate some programmer’s insufficient separation-of-concerns in the design of a trait with the Diamond Problem.The Diamond Problem is a specific problem of how to resolve multiple inheritance name spaces (scope).

Also please realize that Scala is a single-inheritance language, with the apparency of multiple inheritance of traits. In reality, traits get folded into that single-inheritance chain in a specific order and are NOT multiply inherited.
Shelby Moore III Sunday, February 13, 2011 at 2:24 am

Shelby
Admin

Posts: 3107
Join date: 2008-10-22

View user profile http://GoldWeTrust.com

Back to top Go down

RegExp in 100 lines of code!

Post  Shelby on Sun Feb 13, 2011 12:32 am

http://michid.wordpress.com/2010/12/06/regular-expression-matching-in-100-lines-of-code/

Shelby
Admin

Posts: 3107
Join date: 2008-10-22

View user profile http://GoldWeTrust.com

Back to top Go down

Page 9 of 17 Previous  1 ... 6 ... 8, 9, 10 ... 13 ... 17  Next

View previous topic View next topic Back to top


Permissions in this forum:
You cannot reply to topics in this forum