| Re: approaches to PHP-based application interface? [message #176730 is a reply to message #176729] |
Fri, 20 January 2012 11:34   |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma:
|
Senior Member |
|
|
Erwin Moller wrote:
> On 1/20/2012 12:04 PM, The Natural Philosopher wrote:
>> Erwin Moller wrote:
>>> On 1/20/2012 11:05 AM, M. Strobel wrote:
>>>> Am 20.01.2012 10:43, schrieb crankypuss:
>>>
>>> <snip>
>>>
>>>> > Thank you for your opinion, but I've done "true GUI programming" and
>>>> > I've had a
>>>> > bellyful of talking paper-clips and wiggling icons.
>>>>
>>>> Yeah. But the forced limitations in web design is not the solution.
>>>
>>> Hi Strobel,
>>>
>>> You cannot say that in such general terms.
>>> If you are fluent in PHP and web-related technics, it is very tempting
>>> to want more and develop desktop-apps using those technologies.
>>> I know I want to.
>>> Comparing them to slow M$ stuff makes no sense.
>>> M$ seldom do things right.
>>>
>>
>>
>> Look in philosophical terms what you are saying here is more or less 'I
>> want to use a browser and associated web server as my GUI API rather
>> than the underlying native GUI API'
>>
>
> Exactly.
> That is exactly what I am saying.
>
>
>>
>> Which is all fine and dandy if that GUI suits the application.
>
> Of course.
> That goes without saying, I presumed.
> If it didn't another approach would be advisable.
>
>>
>> And is one accepts platform independent and WAN ready from the word 'go'.
>>
>> BUT is not always the optimal paradigm, and usually means writing in
>> rather badly implemented and poor languages, that are deliberately
>> crippled for security reasons - javascript/PHP and the like.
>
> "optimal paradigm" can mean anything, depending on the situation.
> In case you need speed: Go C(++), or even assembly, and write smart fast
> code.
> In case you need supersmall memory footprint (like sometimes in embedded
> software): Go assembly.
> In case you want a very high level to approach a problem: Throw in some
> framework, or do it yourself in some high level language.
> etc.etc.
>
> And I do not understand why you deem PHP a "deliberately crippled
> language for security reasons", because it isn't.
>
well in the sense that apache or whatever invokes it with apaches own
privileges and the concept of a users own privileges is not inherent in it.
> Also, Javascript isn't crippled at all.
Perhaps you need to write more of it. It cannot access much at all. It
has no concept of full system access.
It cant even access a local printer..
> I think you are confusing Javascript implementation in browsers with the
> language itself.
> Of course the browser must "cripple" the language by not exposing
> everything on the computer to the language.
>
Of course thats what I mean. The language on its own as an intellectual
abstraction is as worthless as piece of used toilet paper when what you
have is a browser running (a usually highly buggy) implemenation of it.
> Your way of thinking is like saying: "No animal can fly because I know
> of a dog who cannot fly."
> Javascript isn't a crippled language. It's implementation is browsers is
> (luckily) "crippled". Big difference.
>
No, My stance is more 'pigs may fly, in theory, but I have yet to find
one that did'
>
>>
>> That's not to say you can't write web apps but it is possibly making a
>> rod for your own back if you do.
>
> I am not sure what you mean by that.
>
I am saying that when all you decide to use is a hammer, you may find
watchmaking a difficult task.
> Regards,
> Erwin Moller
>
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]