My boss and I believed that in '87, it is (IMHO) far better than C++, and at the time it had a great chance. Obj-C was a great language for the time, probably the most advanced practical OO language of the time. Sadly it never got any traction until NeXT.
Sadder still is the fact that it didn't keep up with the time. It is still state of the art for the late 80s/early 90s; but languages moved on and improved. If they eliminated the need for separate header files (including getting rid of the declaration/implementation divide), added keywords to get rid of the need for the CPP, added autoboxing, and improved runtime errors; it would be a world class language (again).
As an aside Cocoa is a wonderful and powerful class library, with one major flaw: needlesslyLongAndOverSpecific method names. Where Smalltalk was content with anArray getAt: someIndex NeXT decided to drive in the fact that you were getting an object: [anArray objectAtIndex: someIndex], despite the fact that a NSArray can only old objects. That is a mild example, but the power in the library is amazing.
Sadly the stewards of Obj-C still seem to think the language is fine as it is, which is a shame. The lamdbas are nice though...
Now he's tarred as a pedophile sympathizer for life...
Well he is, at least of consensual pedophilia. We can quibble about what the Age Of Consent should be — it isn't even consistant in the US, let alone the world — but it is based on one founding principal: There is an age, below which, a child cannot give their consent on their own, because we, as a society, feel they cannot fully understand the implications and consequences.
Again, argue all you want about what age that should be, but the principal has been in law for an exceptionally long time; and you have to look long and hard to find someone who disagrees with the principal. This holds true of both the average person and those who are experts in the subject.
Now perhaps RMS believes that when he said pedophilia, he meant 16 (some states in the US), or 15 (no states in the US), or 12, or perhaps he means no age in particular. Maybe he means that consent means that it should be determined on a case by case basis; based on the emotional maturity of the child.
We simply don't know, he doesn't clarify or stipulate in any way, and this is a man who is capable of going on at great length on almost any subject her cares about.
So until he does, I at least, am forced to take him at his word. He may not be personally interested in "conceptual pedophilia" but he does believe it should be legal. And that does make him sympathizer, kinda by definition.
I think you misunderstand the meaning of “not for profit”. It doesn't mean you can't make money, or turn a profit, it means that those profits must be reinvested in the activities of the company.
So of course a not for profit like like Raspberry Pi can have “room for expansion”, and while they cannot have investors who expect dividends or to get a share of the profit; they can have backers who will invest in the company in exchange for access to the IP, or for more favorable sales terms, etc.
UM OK but that is about the Apple App Sore, and its terms and restrictions. The TFA us about MS's App Store and how they do accept GPL. I am challenging the poster I replied to back up his post with proof. Maybe the situation will be the same, and ultimately not possible, maybe it won't. I don't know, he doesn't know, and yet asserted it as a "FACT", but without a shred of evidence.
And how is the fact that the PSN is a walled guarden related to you link? It isn't. That was an external attack that could have happened to any garden (to stretch the metaphor) open or closed. If the attack vector had been though content available with PSN that had been embedded with malware, and that there was a history of similar in the past, AND that Sony was unable to do anything to prevent it; THEN that might have been a relevant example.
He was kicked out for violating the TOS. Which is part of the point of a walled garden. So in that sense it worked. Apple has never claimed that their system is 100%, but that it deals with malware when it finds it, and does what it can to prevent it from getting into the store in the first place.
I am not arguing for or against them. I am just saying that the poster made a bold claim with no proof.
Maybe that is his reason for wanting the device to be rooted, maybe it isn't. He doesn't say, so it is dangerous to assume why he wants it prerooted. Maybe it is for freedom, maybe it is for flexibility (freedom isn't always flexible), maybe (as I assumed when I read the OP) he thinks his list of requirements will require the device be rooted. But the point is we don't know why he wants the device to be rooted.
And I really wish he had said. Because then we could actually answer his deeper question more accurately. Because I am not even sure he really need rooting, I suspect (but cannot prove, and thus will not assert) that he really wants the ability to side load. In which case just about any 7" Android device will do. The list of things you need to root a tablet to do isn't that large, and none of it indicated by his list of requirements.
For the love of... have you bothered to actually read the agreement? Citing from wikipedia:
3.3.2 — An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple’s Documented APIs and built-in interpreter(s).
So yes you can embed an interpreter, and run that code; but you cannot download code that isn't part of the app and then run that. Even at the worst Apple put a restriction on what API's interprete code could call, but never banned it.
But even if what you were saying were true, it is trivial to embed a UIWebView, and add JavaScript entry points. Meaning that you could use JavaScript as a scripting language that could then call APIs in your app.
No skulduggery needed, see my other post to bradgoodman (I wasn't logged in, so it is an AC), but programming environments are allowed on iOS. There are fair number of examples in the App Store already
The problem with Guile is that most people do not want to work in Lisp. I am glad you are a "Rabid lisper" -- though insulting other people is not a great way to win other people to your cause -- but even you have to admit that most people are not interested in learning Lisp. And the point of a scripting language is to provide a relatively easy way to extend the functionality of a program, even to relative novices, and people who are not professionals.
As such, I stick by my statement, Lisp is not a good fit.
I do not disagree. But the Guile supporters -- like RMS -- says we shouldn't chase the flavor of the moment, and instead use guile and have implementations in that. My point is that approach hasn't worked.
Oh I agree, my point was to point out the state of ECMAScript support in Guile. The point was always that Guile could support other languages though language transcompiled into Guiled, or to the Guile Bytecode; but that has not really happened by and large. And the community doesn't seem to have provided much support or encouragement for it. As that entry in the manual clearly indicates
I think you are referring to Robert Morris' Viaweb (later bought by Yahoo), which was partially implemented in Lisp. But they weren't exposing raw lisp to the users and expecting them to use it. They used it because they were experts, it was something they were very comfortable with, and thus could get things done very quickly. Of course this also dramatically reduced the talent pool they had to draw on for new hires as well.
Lisp (and derivatives) is an amazing language and great for many problems, but it is far from mainstream. While it has it's fans (and they are rabid), it isn't a great general purpose solution. As a much younger man I went though a lisp phase, and I look back at my code (for which I was chided for being to verbose and blatant in my coding) and frankly cannot understand much of it. Compare that to old C, Forth, 6502 assembly, etc and I have little or no problem.
But the problem with Guile is not just that it is Lisp, but that it is trying to impose a single hammer, and then say you have to reimplement your other tools in that hammer. As such there is a partial implementation of ECMAScript 3.1, a early stage Lua port, a proof of concept TCL implementation (which I can't find on the web easily). So your only real option is to use Guile's implementation of Sceme.
As I have said elsewhere, it would have been far better to have created a standard API for linking up apps, to pluggable scripting engines. That way there would have been a standard way for apps to make themselves scriptable (ala COM, AppleEvents, the Java Scripting API, etc etc), and then a variety of scripting language (using the actual implementation of those languages) to choose from; and Guile could have been one of them.
ECMAScript was not the first non-Schemey language implemented by Guile, but it was the first implemented for Guile's bytecode compiler. The goal was to support ECMAScript version 3.1, a relatively small language, but the implementor was completely irresponsible and got distracted by other things before finishing the standard library, and even some bits of the syntax. So, ECMAScript does deserve a mention in the manual, but it doesn't deserve an endorsement until its implementation is completed, perhaps by some more responsible hacker.
In the meantime, the charitable user might investigate such invocations as,L ecmascript and cat test-suite/tests/ecmascript.test.
Because it partially supports JavaScript. not supports it. And it doesn't (the last time I looked) provide much of the common JavaScript libraries. Making it a PITA and minefield to use
In their defense (and I am no fan of LISP like languages or of Guile) is that you could use Guile as a kind of common VM, with transcompilers to transform the syntax of Lua, JavaScript, Python, or whatever into Guile and be executed at runtime.
The problem is that never really happened in any kind of satisfactory way. There is a partial implementation of JavaScript, they are "working on" Lua; etc. None of the efforts have felt very satisfactory to date. And part of the reason is that a language is a lot more than syntax. Unless people are willing to port the core libraries and make sure they run well, then Python (or whatever) with a different runtime and libraries isn't going to feel right.
A far better solution (IMHO) is to do what Java and.NET do and have a common infrastructure for scripting language and then let anything that conforms to it play. So your app has a common API for exposing its internals and entry points, and then scripting can be done in any supported language. It is easier because these are VM languages, but it wouldn't be hard to do for compile languages either. Then we could use the real languages, and not some kind of simulacra...
Working on being the core term. Not have, not encouraging people to use, not bragging about compatibility, but working on. Wake me when it is ready, like their JavaScript support. It will make a nice break from waiting on Hurd.
Perhaps if GNU had adopted TCL, then it would have stayed popular. Or what if GNU had provided a common backbone for extension so then it would be easy to plug in scripting languages (perhaps at run time)?
The simple fact is that paren languages are a really had sell outside of their niche. There is a hardcore who loves them, but the majority do not. Scheme is like the cilantro of languages -- you love it, or you hate it, but there isn't much of a middle ground. The Guile folk made all kinds of promises back in the day of supporting lots of syntaxes, but like Hurd what has come out has been very late, or comes no where near expectations.
And of course the fact that Emacs still hasn't adopted it, isn't a ringing endorsement either.
So give up on a single fixed scripting language, and provide an extension architecture so lots of options can be used... including Guile
Slashdot Mirror
LongAndComplexCamelCasedNamesImpeedUnderstanding
My boss and I believed that in '87, it is (IMHO) far better than C++, and at the time it had a great chance. Obj-C was a great language for the time, probably the most advanced practical OO language of the time. Sadly it never got any traction until NeXT.
Sadder still is the fact that it didn't keep up with the time. It is still state of the art for the late 80s/early 90s; but languages moved on and improved. If they eliminated the need for separate header files (including getting rid of the declaration/implementation divide), added keywords to get rid of the need for the CPP, added autoboxing, and improved runtime errors; it would be a world class language (again).
As an aside Cocoa is a wonderful and powerful class library, with one major flaw: needlesslyLongAndOverSpecific method names. Where Smalltalk was content with anArray getAt: someIndex NeXT decided to drive in the fact that you were getting an object: [anArray objectAtIndex: someIndex], despite the fact that a NSArray can only old objects. That is a mild example, but the power in the library is amazing.
Sadly the stewards of Obj-C still seem to think the language is fine as it is, which is a shame. The lamdbas are nice though...
Well he is, at least of consensual pedophilia. We can quibble about what the Age Of Consent should be — it isn't even consistant in the US, let alone the world — but it is based on one founding principal: There is an age, below which, a child cannot give their consent on their own, because we, as a society, feel they cannot fully understand the implications and consequences.
Again, argue all you want about what age that should be, but the principal has been in law for an exceptionally long time; and you have to look long and hard to find someone who disagrees with the principal. This holds true of both the average person and those who are experts in the subject.
Now perhaps RMS believes that when he said pedophilia, he meant 16 (some states in the US), or 15 (no states in the US), or 12, or perhaps he means no age in particular. Maybe he means that consent means that it should be determined on a case by case basis; based on the emotional maturity of the child.
We simply don't know, he doesn't clarify or stipulate in any way, and this is a man who is capable of going on at great length on almost any subject her cares about.
So until he does, I at least, am forced to take him at his word. He may not be personally interested in "conceptual pedophilia" but he does believe it should be legal. And that does make him sympathizer, kinda by definition.
I think you misunderstand the meaning of “not for profit”. It doesn't mean you can't make money, or turn a profit, it means that those profits must be reinvested in the activities of the company.
So of course a not for profit like like Raspberry Pi can have “room for expansion”, and while they cannot have investors who expect dividends or to get a share of the profit; they can have backers who will invest in the company in exchange for access to the IP, or for more favorable sales terms, etc.
UM OK but that is about the Apple App Sore, and its terms and restrictions. The TFA us about MS's App Store and how they do accept GPL. I am challenging the poster I replied to back up his post with proof. Maybe the situation will be the same, and ultimately not possible, maybe it won't. I don't know, he doesn't know, and yet asserted it as a "FACT", but without a shred of evidence.
Well if it is a FACT, perhaps you could provide some proof?
And how is the fact that the PSN is a walled guarden related to you link? It isn't. That was an external attack that could have happened to any garden (to stretch the metaphor) open or closed. If the attack vector had been though content available with PSN that had been embedded with malware, and that there was a history of similar in the past, AND that Sony was unable to do anything to prevent it; THEN that might have been a relevant example.
He was kicked out for violating the TOS. Which is part of the point of a walled garden. So in that sense it worked. Apple has never claimed that their system is 100%, but that it deals with malware when it finds it, and does what it can to prevent it from getting into the store in the first place.
I am not arguing for or against them. I am just saying that the poster made a bold claim with no proof.
The person who makes the claim is the one who needs to back it up with facts. Not the other way around
Interesting theory. Show you work...
If it were that, perhaps he would have actually described them. Something the Tizen site hasn't managed to do...
Maybe that is his reason for wanting the device to be rooted, maybe it isn't. He doesn't say, so it is dangerous to assume why he wants it prerooted. Maybe it is for freedom, maybe it is for flexibility (freedom isn't always flexible), maybe (as I assumed when I read the OP) he thinks his list of requirements will require the device be rooted. But the point is we don't know why he wants the device to be rooted.
And I really wish he had said. Because then we could actually answer his deeper question more accurately. Because I am not even sure he really need rooting, I suspect (but cannot prove, and thus will not assert) that he really wants the ability to side load. In which case just about any 7" Android device will do. The list of things you need to root a tablet to do isn't that large, and none of it indicated by his list of requirements.
For the love of... have you bothered to actually read the agreement? Citing from wikipedia:
So yes you can embed an interpreter, and run that code; but you cannot download code that isn't part of the app and then run that. Even at the worst Apple put a restriction on what API's interprete code could call, but never banned it.
But even if what you were saying were true, it is trivial to embed a UIWebView, and add JavaScript entry points. Meaning that you could use JavaScript as a scripting language that could then call APIs in your app.
No skulduggery needed, see my other post to bradgoodman (I wasn't logged in, so it is an AC), but programming environments are allowed on iOS. There are fair number of examples in the App Store already
The problem with Guile is that most people do not want to work in Lisp. I am glad you are a "Rabid lisper" -- though insulting other people is not a great way to win other people to your cause -- but even you have to admit that most people are not interested in learning Lisp. And the point of a scripting language is to provide a relatively easy way to extend the functionality of a program, even to relative novices, and people who are not professionals.
As such, I stick by my statement, Lisp is not a good fit.
I do not disagree. But the Guile supporters -- like RMS -- says we shouldn't chase the flavor of the moment, and instead use guile and have implementations in that. My point is that approach hasn't worked.
Oh I agree, my point was to point out the state of ECMAScript support in Guile. The point was always that Guile could support other languages though language transcompiled into Guiled, or to the Guile Bytecode; but that has not really happened by and large. And the community doesn't seem to have provided much support or encouragement for it. As that entry in the manual clearly indicates
I think you are referring to Robert Morris' Viaweb (later bought by Yahoo), which was partially implemented in Lisp. But they weren't exposing raw lisp to the users and expecting them to use it. They used it because they were experts, it was something they were very comfortable with, and thus could get things done very quickly. Of course this also dramatically reduced the talent pool they had to draw on for new hires as well.
Lisp (and derivatives) is an amazing language and great for many problems, but it is far from mainstream. While it has it's fans (and they are rabid), it isn't a great general purpose solution. As a much younger man I went though a lisp phase, and I look back at my code (for which I was chided for being to verbose and blatant in my coding) and frankly cannot understand much of it. Compare that to old C, Forth, 6502 assembly, etc and I have little or no problem.
But the problem with Guile is not just that it is Lisp, but that it is trying to impose a single hammer, and then say you have to reimplement your other tools in that hammer. As such there is a partial implementation of ECMAScript 3.1, a early stage Lua port, a proof of concept TCL implementation (which I can't find on the web easily). So your only real option is to use Guile's implementation of Sceme.
As I have said elsewhere, it would have been far better to have created a standard API for linking up apps, to pluggable scripting engines. That way there would have been a standard way for apps to make themselves scriptable (ala COM, AppleEvents, the Java Scripting API, etc etc), and then a variety of scripting language (using the actual implementation of those languages) to choose from; and Guile could have been one of them.
Quoting from the Guile Manual
That is hardly a ringing endorsement...
Because it partially supports JavaScript. not supports it. And it doesn't (the last time I looked) provide much of the common JavaScript libraries. Making it a PITA and minefield to use
In their defense (and I am no fan of LISP like languages or of Guile) is that you could use Guile as a kind of common VM, with transcompilers to transform the syntax of Lua, JavaScript, Python, or whatever into Guile and be executed at runtime.
The problem is that never really happened in any kind of satisfactory way. There is a partial implementation of JavaScript, they are "working on" Lua; etc. None of the efforts have felt very satisfactory to date. And part of the reason is that a language is a lot more than syntax. Unless people are willing to port the core libraries and make sure they run well, then Python (or whatever) with a different runtime and libraries isn't going to feel right.
A far better solution (IMHO) is to do what Java and .NET do and have a common infrastructure for scripting language and then let anything that conforms to it play. So your app has a common API for exposing its internals and entry points, and then scripting can be done in any supported language. It is easier because these are VM languages, but it wouldn't be hard to do for compile languages either. Then we could use the real languages, and not some kind of simulacra...
Working on being the core term. Not have, not encouraging people to use, not bragging about compatibility, but working on. Wake me when it is ready, like their JavaScript support. It will make a nice break from waiting on Hurd.
Perhaps if GNU had adopted TCL, then it would have stayed popular. Or what if GNU had provided a common backbone for extension so then it would be easy to plug in scripting languages (perhaps at run time)?
The simple fact is that paren languages are a really had sell outside of their niche. There is a hardcore who loves them, but the majority do not. Scheme is like the cilantro of languages -- you love it, or you hate it, but there isn't much of a middle ground. The Guile folk made all kinds of promises back in the day of supporting lots of syntaxes, but like Hurd what has come out has been very late, or comes no where near expectations.
And of course the fact that Emacs still hasn't adopted it, isn't a ringing endorsement either.
So give up on a single fixed scripting language, and provide an extension architecture so lots of options can be used... including Guile
Rabbits aren't rodents...
So really free to software engineers, not to regular people...