Computers:

Page 11 of 17 Previous  1 ... 7 ... 10, 11, 12 ... 17  Next

View previous topic View next topic Go down

Simultaneous maximization of both CR and CTR is Google's Achilles heel

Post  Shelby on Fri Feb 25, 2011 11:45 pm

http://esr.ibiblio.org/?p=2975&cpage=4#comment-297888

Estimate the impact on Android, especially vs. iPhone, if Google's ad revenue was declining?

Observe Google's primary Achilles heel being the often unattainable simultaneous maximization of both CR and CTR, or that paid and unpaid ads are not co-mingled. Eliminating this tension derives from a fundamental epiphany.

I have documented the algorithm in a private forum. And it seems a possible outcome would be to diminish Facebook's lack of anonymity, if not seriously impact Facebook's valuation, because would make it impossible to control what others see connected to any given page on the Web.


Last edited by Shelby on Sat Mar 05, 2011 7:03 am; edited 1 time in total

Shelby
Admin

Posts: 3107
Join date: 2008-10-21

View user profile http://GoldWeTrust.com

Back to top Go down

Actors are not magic

Post  Shelby on Wed Mar 02, 2011 10:25 am

http://lambda-the-ultimate.org/node/4200#comment-64604

Shelby wrote:
Carl Hewitt, PhD MIT wrote:Arbiters can be constructed so they are physically symmetrical and then strongly isolated from the environment. So it is hard to imagine a source of bias.

Coase's Theorem

Any artificial barrier ultimately fails. For example, your arbiter doesn't have infinite memory and thus there is bound to how much it can buffer while waiting to confirm delivery of the data it arbitrates.

Bottom line is the data and control flow of the algorithm has to be concurrent, and no amount of STM, Actor, other hocus pocus will magically make it so.

Actors provide a low-level model of concurrency, but there still need to be high-level concurrent programming paradigms on top of that model, else the low-level model will fail.

This is related to the prior posts I have made about why a computer can never challenge human creativity, and my recent posts about Continuum hypothesis. What Hewitt is forgetting is that the computer is a finite countable device, with finite number of programs, not a continuum process like the human brain or other natural processes in the universe.

Shelby
Admin

Posts: 3107
Join date: 2008-10-21

View user profile http://GoldWeTrust.com

Back to top Go down

Importance of Higher kinded generic types

Post  Shelby on Wed Mar 02, 2011 12:01 pm

http://www.codecommit.com/blog/ruby/monads-are-not-metaphors/comment-page-2#comment-5336

Shelby wrote:
Scala's higher-kinded types enabled the paradigm of Haskell's type classes, as Daniel did with Monad. See section 7.2 Encoding Haskell’s type classes with implicits of Generics of a Higher Kind.

Notably section 6.1 Implementation explains why it may be difficult (if not impractical) to implement higher-kinded types for languages without type erasure, such as .Net languages, e.g. C#.

Shelby
Admin

Posts: 3107
Join date: 2008-10-21

View user profile http://GoldWeTrust.com

Back to top Go down

Are variance annotations useless (or only useless to Haskell programmers)?

Post  Shelby on Wed Mar 02, 2011 2:25 pm

http://blog.tmorris.net/critique-of-oderskys-scala-levels/#comment-70483

Shelby wrote:
Tony Morris, author of Scalaz library wrote:
First, I will get a couple of nitpicks out of the way. Martin’s L2 specifies that variance annotations will be used at this level. I (we: scalaz) propose that there is another level again, where you come to the realisation that variance annotations are not worth their use in the context of Scala’s limited type-inferencing abilities and other details. Instead, prefer a short-hand version of fmap and contramap functions.

Could that be because in Scalaz you are implementing the monad "bind" and "map" as duck typing type classes (the Haskell way), instead of as a supertype interface (trait) of the monad subtype, as I proposed here.

Or here for a more readable version.

Duck typing breaks Liskov Substitution Principle.

Of course Haskell doesn't have subtyping and uses duck typing exclusively. This of course violates SPOT and separation-of-concerns which impacts on the Expression Problem, code readability, and maintenance. Extension by duck typing can break existing code, when there are unintended collisions.

Composability is very important, but doesn't exist without referential transparency, which of course Haskell has and Scala does not enforce.

I haven't had time to study your Scalaz versus the Scala standard libraries, so I can comment on the relative merits.

Tangent: I found Edward Kmett's attempt to add variance annotations to structural typing Monad implementation strategy. I still think my proposed subtyping strategy may be superior.

Well Tony Morris proved himself to be lacking integrity, because he had replied to the above saying basically that I was a confused idiot, that he is using inheritance of "an interface", that he was emulating Haskell's ad hoc polymorphism, and he didn't know why I mentioned "duck typing", so I made the following replies. So then he deleted his reply and deleted both the reply above and the other two below. I can see all three of these replies now waiting moderation, when the one above had already been publicly displayed on his blog, and he had already replied calling me an idiot. So this shows the man can not accept when he has been proven wrong. To censor rational debate is the antithesis of a search for knowledge. Note Tony Morris has a history of being obstinate, you can review his replies and topics to others in the threads mentioned in this post as evidence, also this thread full of obscenities, and also his comments in this thread by Gilad Bracha, one of the designers of Java.

http://blog.tmorris.net/critique-of-oderskys-scala-levels/#comment-70509

Shelby wrote:
Exactly as a I expected, I am looking at your code here, and instances of List[T] do not inherit from Monad[M[_]]. Instead you are using implicits to simulate inheritance using structural typing (a/k/a duck typing, “if it quakes like a duck, it must be a duck”). This is the Scala way of emulating Haskell’s type class, see section 7.2 Encoding Haskell’s type classes with implicits of Generics of a Higher Kind. The link I provided in my prior post using the similar construct, so apparently you didn’t bother to click it.

There is no distinction between ad-hoc polymorphism and structural typing w.r.t to the point I was making about extensibility issues.

You are confused and rude.

http://blog.tmorris.net/critique-of-oderskys-scala-levels/#comment-70512

Shelby wrote:
I see my rebuttal is awaiting you to release it from moderation.

Given my rebuttal, my original point remains, which is that of course you don’t get any benefit from variance annotations when you structure your inheritance using implicit to emulate Haskell’s type class, instead of the subtyping way I proposed in the link of my first comment.

You are apparently trying to do Haskell in Scala, instead of leveraging Scala’s subtyping strengths, no wonder you are so frustrated and lashing out. Scala can’t do Haskell’s strengths, because Haskell doesn’t have subtyping, thus I understand that type inference is much simpler in Haskell.

Here is screen capture as evidence.



==================
Another Thread
==================

We see the same pattern from Tony Morris here. He had approved the first comment below, he had replied saying I was an idiot and that I needed to better learn my "stupid language Java". Now he removed his reply and both of my comments have disappeared from his blog, except that I can see they are "awaiting moderation". I know how WordPress works, this means he banned me from posting to his blog and retroactively moved all my comments back to spam. This clear evidence is he deleted his reply. Unfortunately I did not think to capture his reply before he deleted it.

http://blog.tmorris.net/java-is-pass-by-value/#comment-70462

Shelby wrote:
Tony is wrong of course, because he is thinking what happens low-level inside the JVM, not the semantics of the Java language.

The pointer of a reference is always passed-by-value, but this is irrelevant since it not accessible. The reference can only access the instance it points to. When the reference is passed, the instance may passed-by-reference or by-value. The primitive types pass-by-value.

Read about call-by-sharing, to get some insight:

http://stackoverflow.com/questions/4790050/can-scala-call-by-reference/5012338#5012338

http://blog.tmorris.net/java-is-pass-by-value/#comment-70510

Shelby wrote:
No Tony, you are wrong.

Where is the pointer type in Java? Everything is an object in Java. You are dead wrong.

Java has no notion of a “pointer”, such as in C. You can’t increment a reference or do any operations on it. In Java, a reference is semantically synonymous with an object. Thus it is passing the objects by-reference. You are correct, the pointers are being passed-by-value behind the scenes, but a pointer is not a type in Java.

But you have no ground to stand on, to be attacking people on this issue. It is semantically correct to say that Java passes the objects by-reference and everything is an object in Java.

P.S. Java isn’t my language, I have never compiled a single line of Java in my life.

Here is screen capture as evidence.



=================
One More Thread
=================

This post had appeared publicly on his blog, and now banished back to moderation as shown in the screen capture below.

http://blog.tmorris.net/applicative-functors-in-scala/#comment-70507

Shelby wrote:
Can’t you use (None : Option[Int]) in place of none? Seems I read somewhere that Scala has that compile-time cast for aiding type inference.



Last edited by Shelby on Fri Mar 04, 2011 10:42 am; edited 16 times in total

Shelby
Admin

Posts: 3107
Join date: 2008-10-21

View user profile http://GoldWeTrust.com

Back to top Go down

How Google figures out so quickly, what you meant to type

Post  Shelby on Wed Mar 02, 2011 3:03 pm

http://blog.notdot.net/2007/4/Damn-Cool-Algorithms-Part-1-BK-Trees

Shelby
Admin

Posts: 3107
Join date: 2008-10-21

View user profile http://GoldWeTrust.com

Back to top Go down

Applicative functor

Post  Shelby on Fri Mar 04, 2011 6:40 am

http://www.codecommit.com/blog/ruby/monads-are-not-metaphors/comment-page-2#comment-5338

Shelby wrote:
There is a fascinating discussion about the practical utility of monads for mainstream programming. That discussion morphs from an initial hypothesis that monads vs. actors can be used to interopt imperative and functional programming, to one of recognition that monads provide abstraction of widespread programming paradigms, e.g.

http://gbracha.blogspot.com/2011/01/maybe-monads-might-not-matter.html?showComment=1295992148701#c6727611476735111271

Perhaps an even more widely used abstraction is the Applicative, which is a supertype of a pure monad:

http://gbracha.blogspot.com/2011/01/maybe-monads-might-not-matter.html?showComment=1295998124929#c138376235115429371
http://blog.tmorris.net/applicative-functors-in-scala
http://blog.tmorris.net/monads-do-not-compose/

It might not be easy for some to grasp Applicative from that research paper, and I have a layman's concise tutorial, but I will wait to provide a link once my implementation is complete, because the tutorial uses my syntax. I promise it won't be incomprehensible for Java laymen.

Applicative is a neat pattern, because it allows the application of a function distributed (curried) over the wrapped elements of a tuple of Applicative, and unlike Monad#bind, the function is always called and can not be short-circuited by the computation and/or state of the wrapping.

However, and the main reason I make this post here, is that an empty container is incompatible with Applicative, if the emptiness is not a type parameter of the container, because the empty container can not provide an empty element to the function application, if the function is not expecting it (i.e. does not accept an empty type). This means that Nil for an empty List type is incompatible with Applicative. Only List[T] extends Applicative[Option[T]] will suffice. In my prior comments on this page, I had mentioned I expected problems with Nil and prefer to use Option[T] return type on element access to model an empty container.

The prior linked research paper seems to conflict with my assertion, wherein it shows how to implement the Applicative#ap (apply) for monads on page 2, and the statements that every monad is an Applicative in section 5 and conclusion section 8. However, what I see is that although the Monad#ap can return the same value as the Applicative#ap, the side-effects are not the same. The Applicative#ap will always call the input function (with empty elements as necessary) and the Monad#ap will return an empty value and short-circuit calling the function. The research paper alludes to this in discussion of the differences in evaluation tree in section 5. The research paper I think is coming from the mindset of Haskell ad-hoc polymorphism (i.e. tagged structural typing) where there is no subtyping, thus Monad#ap is not expected to honor the semantic conditions of the Liskov Substitution Principle, i.e. Monad is not a subtype of Applicative in Haskell. This is real-world an example of why I am against ad-hoc polymorphism and structural typing. Of course, side-effects are not supposed to matter in a 100% pure language such as Haskell.

Any way, back to the point that Nil is incompatible with Applicative side-effects semantics (when either the container is not monad or Applicative#ap does not always input a pure function to apply), perhaps this might be one example of Tony Morris's (author of Scalaz) criticism of Scala's libraries, given that in Scalaz apparently Monad is a subtype of Applicative. I am not taking a stance yet on the general criticism, because my library implementation is not complete, so I do not yet know what I will learn.

http://www.codecommit.com/blog/ruby/monads-are-not-metaphors/comment-page-2#comment-5341

Shelby wrote:
@Horst
Correction: I have just clarified in my linked documentation translated as follows.

The semantics of Applicative[T]#ap do not allow a subtype which is non-invertible to an unwrapped T, i.e. empty container not allowed, unless there is a subtype of the subtype (or a subtype of T) that represents the null state (e.g. the subtype, or T, is an Option type).

Perhaps that is implicit in the four laws for Applicative. I will check that next.

Thus I think Applicative#ap can implemented for an empty container using Nil in Scala, by returning a (Nil : List[B]), where I assume that is the correct Scala syntax for compile-time cast of List[Nothing] (a/k/a Nil) to the expected return type B of the curried function.

Alternatively Applicative#ap could be implemented for an empty container using Option elements, by returning the wrapped curried function with (None : Option[B]). This requires every possible composition function to input Option. So now I am seeing some good justification for the Nil strategy of Scala's library.

Also studying the situation more, I realize there is no difference between the side-effects of the Applicative#ap and Monad#ap. I think I was conflating in my mind with Monad#bind.

So I no longer see any problem, nor a requirement for pure function per to solve it.

Hopefully I have helped explain Applicative and provide further insight in how to simplify the explanation of Monad.

Thus I don't yet know an example of why Morris is dissatisfied with the Scala libraries.

P.S. note in the linked docs in my prior comment, I am currently using Maybe as synonymous to Option.

http://www.codecommit.com/blog/ruby/monads-are-not-metaphors/comment-page-2#comment-5343

I still don't like Nil (extends List[Nothing]), because unlike None (extends Option[Nothing]), a Nil can throw an exception on accessing head or tail. In general for all programming, I want to always force unboxing and make throwing an exception illegal (for the scalable composition reason explained in an early comment on this page).

So I realized there is a third way to represent an empty list (or in general a container), which never throws an exception and I think it is the optimum one compared against the two alternatives I presented in the prior comment.

trait OptionList[+T]
case class List[+T] extends OptionList[T]
case object Nil extends OptionList[Nothing]
(or case class Nil[T] extends OptionList[T])

The point is that when you have a List, then it can't be empty and no need to unbox, and when you have an OptionList, you must unbox (i.e. match-case) it before you can access any members of List, e.g. head or tail. If you get a case Nil upon unboxing, then it has no members from List that would throw an exception in Scala's current Nil, e.g. head and tail.

Now I need to discover why Scala didn't do their Nil this way? Maybe there is an important tradeoff I am not aware of yet.

Shelby
Admin

Posts: 3107
Join date: 2008-10-21

View user profile http://GoldWeTrust.com

Back to top Go down

temporaryokay

Post  Shelby on Sat Mar 05, 2011 8:43 am

http://us.cnn.com/2011/TECH/gaming.gadgets/03/04/nintendo.apple.games/index.html?hpt=Sbin

Developers are going to need to reuse code and get paid across all the myriad of apps that use their snippets, in order to be able to have an economic ROI for programming.

The "everybody bakes their own from scratch" model doesn't work, when diversity explodes.

This is exactly what I envisioned and why I have been trying to find (and now creating) something like Copute since 2008.

Shelby
Admin

Posts: 3107
Join date: 2008-10-21

View user profile http://GoldWeTrust.com

Back to top Go down

Origin of the word "blog"

Post  Shelby on Sun Mar 06, 2011 1:22 pm

1953 Dr. Seuss, but in context of sweet frogs:

http://www.bookofjoe.com/2005/03/the_origin_of_t.html

1997 as "weblog":

http://en.wikipedia.org/wiki/Blog

1999 as "blog":

http://groups.google.com/group/deja.comm.weblogs/browse_thread/thread/6c235f317e9967/dc5b0aea621df713?q=blogging&_done=%2Fgroups%3Fhl%3Den%26lr%3Dlang_en%26ie%3DUTF-8%26safe%3Doff%26num%3D20%26q%3Dblogging%26qt_s%3DSearch+Groups%26as_drrb%3Db%26as_mind%3D1%26as_minm%3D1%26as_miny%3D1999%26as_maxd%3D31%26as_maxm%3D12%26as_maxy%3D1999%26&_doneTitle=Back+to+Search&&d#dc5b0aea621df713


Shelby
Admin

Posts: 3107
Join date: 2008-10-21

View user profile http://GoldWeTrust.com

Back to top Go down

Web 2.0 suicide machine

Post  Shelby on Sun Mar 06, 2011 9:16 pm

Remove your data from every major web2.0 app:

http://suicidemachine.org/

Facebook sent them Cease & Desist order:

http://suicidemachine.org/download/Web_2.0_Suicide_Machine.pdf

Some people alledge that Facebook is thought to be cooperating with CIA to ID everyone in the world. The internet is a giant intelligence gathering operation, that is why the govt will never kill the internet.

Shelby
Admin

Posts: 3107
Join date: 2008-10-21

View user profile http://GoldWeTrust.com

Back to top Go down

Leveled Garbage Collection superior to GGC

Post  Shelby on Mon Mar 07, 2011 1:01 pm

http://lambda-the-ultimate.org/node/4220

Shelby wrote:
I had suggested an idea for improving Haskell's handling of space "leaks", with a similar preference for paging fault load as the metric of promotion.

Note LtU censors all my submissions, so the above was submitted but probably never displayed.

Once we get pagedirt.com working, we can put an end to censorship on the web.


Last edited by Shelby on Mon Mar 07, 2011 5:15 pm; edited 2 times in total

Shelby
Admin

Posts: 3107
Join date: 2008-10-21

View user profile http://GoldWeTrust.com

Back to top Go down

My "eliminate all exceptions" is beautiful code

Post  Shelby on Mon Mar 07, 2011 5:02 pm

I couldn't be more ecstatic with the elegant, concise, and complete (no corner cases) way the code turned out:

http://copute.com/dev/docs/Copute/ref/std/SignedState.copu

Here are the links to my prior announcement of a major breakthrough, for which the code above is the implementation:

http://copute.com/dev/docs/Copute/ref/intro.html#Convert_Exceptions_to_Types
http://goldwetrust.up-with.com/t112p135-computers#4249

Shelby
Admin

Posts: 3107
Join date: 2008-10-21

View user profile http://GoldWeTrust.com

Back to top Go down

Facebook continues to encourage bigger govt intrusion and encourage censorship

Post  Shelby on Fri Mar 11, 2011 5:37 pm

http://www.techradar.com/news/internet/report-facebook-bullying-to-friends-with-latest-safety-feature-934835

Shelby
Admin

Posts: 3107
Join date: 2008-10-21

View user profile http://GoldWeTrust.com

Back to top Go down

How to launch Copute.com (not language) immediately as "cooperative coding" platform?

Post  Shelby on Sun May 22, 2011 11:31 pm

I welcome frank feedback from anyone, I love feedback, even negative.

Copute.com is an awesome domain name, and it is not being used in a popular site yet. My CoolPage.com also has potential if I can ever find a great site concept for it.

As I had explained in prior posts in this thread, the open source programming model is designed to foster contribution and sharing, which has been much more successful than a closed source code model. The examples of open source defeating closed source are numerous. Firefox is better then Internet Explorer, MySQL is more popular than the closed source databases (Oracle, Microsoft SQL server, etc), Google Android is killing Apple iPhone and Microsoft phones and eventually will replace Windows.

A fundamental problem with open source is that there is no way for an individual contributor to get paid independently. You can't just go dig in and write some code snippets, upload them, and wait to get paid as they are used by the market. There is no such market and marketing for building blocks of code contribution. You instead have to go build a complete software product of sufficient scale and market it, something very few people in world can do successfully (this is why iPhone and Amazon AppStores are growing so phenomenally, but the individual programmer contributors are not even recovering their time invested, because of dozens or 100s of duplicate and silly applications). Imagine if it could be that simple and efficient to contribute to world economy and profit in your home office? Imagine all those unemployed (or underemployed in terms of pay, interesting projects, and satisfaction) millions of Chinese and Indian engineer graduates living at their parents house. To get paid to work on open source, you need to join a company that wants to pay you to work on open source. I wish I could change this, so that millions of individual contributions could be incentivized. I see huge untapped sources of programmers in India and China, who are highly underpaid and who don't gain enough experience because they are not exercising their abilities enough in a free market.

Originally I started Copute with a focus on making a better computer language that would interopt better technologically and thus foster more reusable modules of code. I am glad I did, as I learned a lot of new technology and made a lot of progress from Dec. 17 2010 to March 15 2011. I still think this is necessary, and I want to find a way to complete the Copute computer language concept. However, I realized that what the world probably needs first, is the free market to trade reusable code in. If such a free market become popular, the problems inherent in existing computer language reusability would become more apparent, and would drive demand for a new computer language such as Copute.

So I am now spending some time thinking about how such a free market might work. Remember originally I had proposed that all code would be profiled (meaning use would be tracked) and then contributions would be paid on % of CPU time used by their code basis. I have since decided this is a non-starter for numerous reasons. The world is rightfully resistant to use tracking (privacy and tethering issues), and dictating a relative price based on relative CPU use, is one-size-fits-all concept of value, which is the antithesis of a free market.

Issues:


  1. How do we make users pay? Any one distributing code from our system much use an installation program that interacts with our database. Or they must track installations and be willing to open books to 3rd party audit if we question their royalty payments. This is policed by the contributors of code to our free market system (this is why I prefer to prioritize client side applications first, not server side). The code will be copyrighted. Unlike for pirated music, there won't be much incentive to pirate our code, because the people distributing software products employing our code, will likely be giving away the software for free and making money via advertising and/or service subscriptions. The people who distribute the code (e.g. if Firefox uses some of our code one day, or Google uses it), will pay us for all their user activations. In other words, our business model is B2B (business-to-business) and we aim to employ thousands or millions of programmers. Note I think the license should state the installation program should ensure our database is incremented for each time a copy of the code is "installed" on a client computer, so for JavaScript browser apps that means setting cookie (or user signup if login is always required).

    Philosophical tangent: Many people have argued against copyright, but they were actually arguing against closed source. The Bible says thou shall not steal. Jason Hommel who is against patents, says you can't give away something that isn't free, for free. That would be socialism, and it ends in failure. No one wants to use the courts to enforce copyright, but the Bible says that we get the government we deserve, so those who steal end up with a government to steal from them.
  2. How to price code contributions? The contributor must set his/her price and be able to adjust it based on market results. We should probably offer several standard pricing models to choose from, but the contributor sets the pricing within the chosen model. For example, a model that might make a lot of sense if the code is free for the first say 1000 users, then a sliding price discounted by volume. This encourages adoption of the code and wide use, and even when the price kicks in, it only applies to the 1001th user, so the price is increasing rather slowly as divided by 1001, and then the volume discounts kick in. The point is that the price paid is a no brainer for the person who wants to utilize the code in their project, as by the time they scale, the price is negligible to their own profit model.
  3. How do we enable bug fix and refinement contributions? The contributor of the bug fix or refinement has to set a price as % or fixed $ that is added to the existing pricing of the code being fixed or refined. The market will choose whether to adopt this new code or not. The contributor of the original code will decide whether to lower his price to accommodate the new fix at the original price or not. Both contributors will be free to adjust their pricings as they observe what each other do. It is online negotiation proxy.
  4. How do we stop duplication or theft of code? This is not users getting access to code for free, but rather stopping contributions which are basically just ripoffs of existing contributions. If such ripoff is posted outside our system, we can use copyright law to go after it, if we feel it is blatant. If the ripoff is within our system, we will have an online reporting process, and these will be judged by experts. The reporter has to pay for this upfront, but if the accused loses, then the accused is liable to pay this in our system (we can deduct from his/her earning, etc). Outside our system, we will go after excessive abuses at our discretion, but the contributor may also go fight in the courts. Within our system, we are the final judge and the contributor waves rights to go to extern court. This will all be in our Terms of Service contract on signup.
  5. Why would anyone pay when so much free open source exists? You get what you pay for. If you want quality and well supported code, the person doing the coding needs to be earning an income. Most of that free stuff is not readily reusable as it is undocumented, virtually unsupported spaghetti.


This looks pretty easy and no brainer. Has no one already attempted this?

The closest I see so far is BountySource and Donations (both appeared to have failed), which allows some users to band together to offer a reward for improvements to code, which does not have the same force as my described model above:
http://en.wikipedia.org/wiki/Comparison_of_free_software_hosting_facilities#Features
http://en.wikipedia.org/wiki/BountySource

Reference: Mechanism Design to Promote Free Market and Open Source Software Innovation

Open-source economics

Law professor Yochai Benkler explains how collaborative projects like Wikipedia and Linux represent the next stage of human organization. By disrupting traditional economic production, copyright law and established competition, they’re paving the way for a new set of economic laws, where empowered individuals are put on a level playing field with industry giants.

What this picture suggests to us is that we’ve got a radical change in the way information production and exchange is capitalized. Not that it’s become less capital intensive, that there’s less money that’s required, but that the ownership of this capital, the way the capitalization happens, is radically distributed. Each of us, in these advanced economies, has one of these (grabs nearby computer), or something rather like it — a computer. They’re not radically different from routers inside the middle of the network. And computation, storage, and communications capacity are in the hands of practically every connected person — and these are the basic physical capital means necessary for producing information, knowledge, and culture, in the hands of something like 600 million to a billion people around the planet.

What this means is that for the first time since the Industrial Revolution, the most important means — the most important components of the core economic activities — remember, we are in an information economy — of the most advanced economies, and there more than anywhere else, are in the hands of the population at large. This is completely different than what we’ve seen since the Industrial Revolution.

So we’ve got communications and computation capacity in the hands of the entire population, and we’ve got human creativity, human wisdom, human experience — the other major experience, the other major input. Which unlike simple labor -stand here turning this lever all day long — is not something that’s the same or fungible among people. Any one of you who has taken someone else’s job or tried to give yours to someone else, no matter how detailed the manual, you cannot transmit what you know, what you will intuit under a certain set of circumstances. In that, we’re unique, and each of us holds this critical input into production, as we hold this machine.


Last edited by Shelby on Sat May 28, 2011 5:25 am; edited 2 times in total

Shelby
Admin

Posts: 3107
Join date: 2008-10-21

View user profile http://GoldWeTrust.com

Back to top Go down

Android does not currently support Java applets (so no Scala in the browser)

Post  Shelby on Mon May 23, 2011 11:25 am

Also Scala -> JavaScript conversion links herein too:

http://code.google.com/p/android/issues/detail?id=7884#c8

However, Scala can be used to code Android applications.

Shelby
Admin

Posts: 3107
Join date: 2008-10-21

View user profile http://GoldWeTrust.com

Back to top Go down

Human language versus computer language writing & copyright implications

Post  Shelby on Tue May 24, 2011 12:35 pm

Shelby,

If I understand correctly, I think you are trying to gain royalties on programming work, and help others get that too. I think that's probably the wrong model.

If I compare programming to writing, what's the Biblical model? Hard to say. Today's model requires copywriting protections, which I see as fraudulent and anti Biblical. Writing is not property. What if the gospel writings were property? They were, but only in the sense that the actual scrolls were costly to make and produce, and copies cost a lot of money to make.

So, yes, I gain from my writings, via the internet, since my writings stand and remain as long term search engine landing pages for people who may be interested in buying bullion.

All the time we get buyers who buy because they know I'm a Christian, and because they agree with what I've written online.

So, that is a form of residual, but it's free market based. There is a "back room" upsell, via jhmint, that makes it work.

Of course, I did this for free anyway, for years, with bibleprophesy.org, but it did not produce immediate fruit. In fact, the lack of the kind of fruit that a person needs to live drove me away from prophecy, and into precious metals.

Think of ways, instead, to help the programmers get fruit quicker, and thus, the rewards will be more economically motivating for more people.

Not so many men like us can think of long term rewards as motivating factors.

In fact, I hope that the majority of my reward does not come in this lifetime, as this part of life is very short, compared to eternity.

Jason,

Writing and computer programming are different in a very crucial way-- the latter can only be read by about 3 people (average # of developers of open source code base uploaded to GitHub or the like).

It takes, even an expert such as myself, days of dedication to read another person's code, load it all up in my head, and eventually comprehend it. And the lesser programmers will be even more discouraged, and they are 1/10 of 1% of the world's population. 99.9% percent are unable to read the code.

So the fundamental difference is that writing speaks directly to the user and thus can build/profit off derivative upsell effects.

As loneranger said, programming sucks because for most (average, who don't get in early on the rare lucky startup that goes IPO) programmers, they slave away, but 99% of the fruits go to the large corporation which controls the access to the users. Because the users don't see your modules of code, they only see the final product, and not as code, but as a working appliance.

What I am trying to do is fix the integration economy-of-scale problem, so that the fruits go more proportionally to the programmers. I am aiming to expand their fruits orders-of-magnitude.

The reason copyright is needed, is because since the end users don't read the code, then code theft completely hides any upsell benefit to the original code author. If a programmer spends weeks writing, customer supporting, & debugging some 1000 lines of code (average is 30 lines per day, debugged), then someone can steal his work in seconds.

I am not proposing to enforce copyright. I have said that up to 1000 end users (per program created), the code should be free. So people can freely copy, but if they get into business level volumes, then they need to pay. If programmers don't get paid for their independent work, then they have to go work as slaves for large corporations who take 99% of the fruit. God does not want that system, as it is retarding progress on spreading knowledge.

There is no restriction adding to existing work and incorporating it in new work. The only copyright restriction I proposed, is they must not give away in business volumes, that which is not free. In other words, the big corporations are not allowed to enslave knowledge.

No enforcement will ever be necessary. Corporations don't want to violate copyright, as they lose face in the development community.

I may never need to take a royalty, I may just end up selling my code in the system, and charging perhaps a user subscription fee for access to the system. For sure I won't take more than 10% of the increase in fruits I help create, which is what the Bible says to do.

P.S. Tangentially, one of the problems the Copute language hopes to solve, it to isolate understanding of code to smaller orthogonal modules, to facilitate the efficiency of gaining understanding of code. This orthogonality (referential transparency) also aids in reuse.


Shelby wrote:I am not proposing to enforce copyright. I have said that up to 1000 end users (per program created), the code should be free. So people can freely copy, but if they get into business level volumes, then they need to pay. If programmers don't get paid for their independent work, then they have to go work as slaves for large corporations who take 99% of the fruit. God does not want that system, as it is retarding progress on spreading knowledge.

There is no restriction adding to existing work and incorporating it in new work. The only copyright restriction I proposed, is they must not give away in business volumes, that which is not free. In other words, the big corporations are not allowed to enslave knowledge.

No enforcement will ever be necessary. Corporations don't want to violate copyright, as they lose face in the development community.

Let me clarify. I mean that any person would be able to go create a derivative work, and they would not be liable to pay anything, as long as they distribute that derivative work on Copute.com or to less than 1000 end users outside of Copute.com. They could even create multiple derivative works, and each one would have a 1000 threshold. And multiple people could each create their own derivative works, and each one would have the proposed 1000 threshold. So the point is that the threshold will never be triggered, except for a successful derivative work that is very popular (and thus assumed to generate business revenue, since popularity implies income due to for example Google ad revenue).

So the point is the copyright won't need to be enforced, because those entities that would exceed the derivative work distribution threshold, would also have a strong incentive not to cheat and steal, because they are earning a lot more from the code, than they are spending. And to cut off their lifeblood of code coming from Copute.com and the developer community, would be shooting themself in the foot.

The copyright only exists as a formal way of codifying that society will punish theft. But the actual enforcement is self-enforcement, because the implications of violation are such that cooperation is more attractive economically.


Last edited by Shelby on Tue May 24, 2011 7:59 pm; edited 3 times in total

Shelby
Admin

Posts: 3107
Join date: 2008-10-21

View user profile http://GoldWeTrust.com

Back to top Go down

Page 11 of 17 Previous  1 ... 7 ... 10, 11, 12 ... 17  Next

View previous topic View next topic Back to top


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