| Re: approaches to PHP-based application interface? [message #176729 is a reply to message #176728] |
Fri, 20 January 2012 11:24   |
Erwin Moller
Messages: 228
Registered: September 2010
Karma:
|
Senior Member |
|
|
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.
Also, Javascript isn't crippled at all.
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.
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.
>
> 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.
Regards,
Erwin Moller
--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]