SitePoint Sponsor

User Tag List

Page 1 of 4 1234 LastLast
Results 1 to 25 of 87
  1. #1
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Lightbulb Defining the Perfect Web Language / Platform (pointless discussion alert)

    Forked thread from here carrying Marcus's warning;

    Quote Originally Posted by lastcraft
    You kidding? Passing up a chance to spend days in pointless discussion - no way!
    Now where I'm coming from was pointed at by Jeff's remark;

    Quote Originally Posted by selkirk
    Where are the pretty urls and RESTful goodness?
    The problem

    Here's my basic postulate;

    Today's languages (PHP / Perl / Java / whatever) make it hard to take advantage of HTTP / REST.

    Illustration

    To an extent, this is illustrated by a discussion I had with someone at php zurich - they had an application generating a lot of dynamic content on every request (and we're talking a lot of requests, thanks to use of AJAX). Ideally they would have liked to use some smart server side and HTTP caching but in reality, the coding effort to do so meant it made more sense just to throw hardware / bandwidth at the problem and leave the content dynamic.

    Whatever the specifics of the problem were, I think this illustrates a failing in PHP - the easiest / default path is to be purely dynamic and say "what the heck" to HTTP caching etc. Although caching can be done, doing so is a massive effort.

    Designing a better cage

    So the question that raises is can a language / platform be designed which makes doing the right thing by HTTP the easier / default development path?

    Specific to PHP, one way to look at it is to say it's a platform + a language. Some people even go so far to say that PHP is a web framework (but a very "generic" one). If I stick to the platform + language distinction, I think it can be said that "PHP the platform" does the right thing by HTTP (shared nothing etc.) but "PHP the language" doesn't.

    Language Self Awareness

    Now one angle is to get existing languages to be fully "self aware" so that they can "re-compile" themselves into a more efficient form. In PHP terms, that might be for a given request like http://site.com/shop/catalog/toys , the code is able to re-construct itself into a "raw" spagetti form containing only the logic needed to handle that request, but still leaving you to write in cleanly abstracted forms - mused this before here here.

    The problem is first getting you're language fully "self aware" - in PHP evals, variable variables and other stuff make this very hard. It's taken Python a long time and Python is in much better shape than PHP for this kind of task. Then, once you're "self aware" further work is needed to generate something useful from that awareness.

    A different language

    The other angle on this is inventing a new language that makes it possible to do the right thing by default. Now I'm not yet clear what that means yet and I'm not a language designer but some random thoughts;

    Marcus's list is not what I mean. These are cool imperative language features but instead I'm thinking a language containing a bunch of declarative statements where imperative syntax is used as a "fallback" for when the declarative part couldn't support you're specific use case.

    For example it might be "strongly typed" but the types themselves are not "int", "float", "array" etc but rather types that a useful / relevant to the medium. For example;

    Content-Type types: text/xml, text/plain, text/html etc. - this allows for the platform to determine the correct Content-Type header

    Volatility - types which have their frequency of change attached to them - e.g. "never changes", "always changes", "may change depending on..." - with this information (however it's declared) the platform should be able to work the correct caching headers to send to a browser, perhaps executing a callback to resolve "may change depending on..." types.

    Also, picking up Jeff's point, nice URL mapping including support for content negotiation.

    Another aspect might be code structure - that it helps you organise yourself around HTTP methods (GET, POST etc.). With that is an implication to allow for re-use - block of code "X" should be able to to call the "GET" section of block of code "Y" internally (without making an extra HTTP request) in a manner that is indistinguishable from a client making a direct GET request to block of code "Y".

    Also errors should have a direct relationship to HTTP status codes.

    Anyway just random thoughts as to how it might look like and a long way from complete. This is basically describing a mini-language for handling the server side of HTTP, backed with imperative syntax for when what you want to do falls outside of the scope of the declarative features.

    Pointlessness?

    And exactly how pointless is this discussion? Well recently ran into neko - this could be a useable platform. It comes with a language but not one you'd code in directly but rather one you'd generate from another, "higher level" language. In other words (given plenty of time to burn), you could invent you're own language, parse it and generate neko code. You're parser / generator could be written in PHP but in practice, it's probably smarter to pick a language well suited to this - I find Haskell convincing given things like pugs (which will probably be closest Perl ever gets to Perl 6) and Write Yourself a Scheme in 48 Hours.

  2. #2
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Just thought I'd repost the list so that people don't have to hop threads...

    Ideal web development language:

    1) PHP like syntax, that is $variables and nice string handling. PHP is proven to be the easiest language to use for web development. Classes should be optional.
    2) Continuations. No need for MVC. Also see 9.
    3) Blocks. No need for visitors and iterators.
    4) Exceptions. With a finally clause.
    5) Simple namespaces. Also, no need for $this over and over again, please.
    6) Operator overloading. Non OO people should be able to use objects that look like arrays.
    7) Support for tainted data.
    8) Perl regex support built in to strings (but without the =~ syntax or a $matches array).
    9) Good support for script interrupts within the same script, such as the cancel button, AJAX events, etc.
    10) Enterprise database and XML support, including SOAP/BPEL.
    11) Built in web browser.
    12) Secure by default.
    13) C++ extension support.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  3. #3
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    You've obviously been thinking about this a long time. Because I cannot take everything you have said on in one go, I'm going to pick up on a small detail and expand. I agree about a domain type system...

    Quote Originally Posted by HarryF
    Volatility - types which have their frequency of change attached to them - e.g. "never changes", "always changes", "may change depending on..." - with this information (however it's declared) the platform should be able to work the correct caching headers to send to a browser, perhaps executing a callback to resolve "may change depending on..." types.
    ...but I reckon that can still be implemented as libraries.

    I wouldn't want to see hiearchical types. The relational people taught us that hiearchies are bad news when it comes to declarations. Lets instead have a tagging or mixin system and dump conventional inheritance.

    Just playing a bit...
    Code:
    $home = <html>
        Hello world    
    </html> : Cacheable('24H');
    show($home);
    It's kind of fun watching a language develop as you are forced to write it down...

    1) Suppose <html>...</html> is a HTML fragment (actually a template as a named block).
    2) I've added a mixin of Cacheable and it's contructor is given '24H'.
    3) All this site ever does is show the home page. There are no exits yet.
    4) There is an implicit front controller and application controller.

    There is nothing here to stop the show() function sending a "cache for 24 hours" header. That's the smallest figure it's been given. No continuation is needed, because no data has come in.

    The Cacheable() mixin is easy to "write". Say...
    Code:
    class Cacheable : Reflection {
        constructor($$time_to_live = 'no-cache') { } 
    
        function timeToLive() {
            $time = Cacheable:toSeconds($$time_to_live);
            foreach (myVariables() as $variable) {
                try {
                    $time = Math().min($time, $variable.timeToLive())
                }
            }
            return $time;
        }
    
        function toSeconds() { ... }
    }
    So now I have...
    5) Each dollar raises the scope. Using $$ in the parameter list causes automatic assignment. No need to chain.
    6) Cacheable implies the mixin of Reflection.

    So now I can tag every variable with some kind of volatility. Assuming the template is aggressively preparsed, then we can just take the cache time as the lowest of the template variables...
    Code:
    $this_hour = time('H') : Cacheable('5min');
    $home = <html>
        This hour was roughly $this_hour.
    </html> : Cacheable('24H');
    The catch is highly dynamic, progressivle painted pull templates...
    Code:
    $home = <html>
        Your advice for the day is ${fetchDynamicContent()}.
    </html>
    ...but you wouldn't be caching this anyway.

    I don't see that continuations have to break REST either. We can tag a template with a session type, such as thread ID (the Seaside approach), Cookie based if session like behaviour has started, but pages are basically static, or none at all if no state is in scope at the time of the template call.

    I should say that I have never built a serious programming language ever .

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  4. #4
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    For intelligent caching, perhaps the Wheat approach in having a every object has a URI.

    Then retrival becomes ...
    $customer = $foo->get('/customer/1');
    and saving back
    $foo->put($customer);

    Wether thats using a RDBMs or even performing actual HTTP requests we dont really care.

    Usage analysis of get() calls would show an objects dependancies. So that a put() would cause any cached item(s) with dependancy on the object changed would expire.

    A problem would be the (N+1) get()s similar to what ORMs have atm, with 1:N relationships.

  5. #5
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You've obviously been thinking about this a long time. Because I cannot take everything you have said on in one go
    Well... haven't thought that hard about it - more likely badly explained

    I wouldn't want to see hiearchical types. The relational people taught us that hiearchies are bad news when it comes to declarations. Lets instead have a tagging or mixin system and dump conventional inheritance.
    OK. Although the question with your example is has this made the default development path lead to "caching done right"? Perhaps there isn't a good way that doesn't involve people using their brain but then again...

    What influences the "cacheability" of a given URL? A rough list might be;

    - Data Sources
    ---- DB
    ---- Filesystem
    ---- Memory
    ---- Remote

    - Input that came with the request

    - Anything done within the code based on time or random numbers

    [- Anything else?]

    If we can tag all these as early as possible with their cacheability, we should be able determine the HTTP cache headers automatically, based on what's been used to build up the response.

    Is this hierarchical? Kindof - perhaps more of a sum of parts.

    For example if one of the inputs in "Remote" and we are unable to gain any information about how volatile it is, then we have to tag it as "no-cache" and assume it changes each time we access it. That trumps everything else leading to a "no-cache" HTTP header.

    At the same time, if a "Remote" source is "composed" into a "Filesystem" source (we've cached the remote input to a file which we flush, say, every 30 minutes), there's the opportunity to do a conditional get based on the age of the cache file.

    There may also be the opportunity to terminate server side execution early - once we've resolved that "nothings changed" the response must be the same so why re-evaluate everything?

    I don't see that continuations have to break REST either. We can tag a template with a session type, such as thread ID (the Seaside approach), Cookie based if session like behaviour has started, but pages are basically static, or none at all if no state is in scope at the time of the template call.
    Interestingly neko already has some support for this it seems (but also more to do) - see note here on entry points and somewhere on the mailing list there was talk about support for continuations

  6. #6
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ren
    For intelligent caching, perhaps the Wheat approach in having a every object has a URI.
    Something like that would certainly be cool methinks. Sadly wheat seems to have died a death but that was good.

    Quote Originally Posted by HarryF
    What influences the "cacheability" of a given URL? A rough list might be;

    - Data Sources
    ---- DB
    ---- Filesystem
    ---- Memory
    ---- Remote

    - Input that came with the request

    - Anything done within the code based on time or random numbers

    [- Anything else?]
    Further pondering there - the implication is this language should be very careful when allowing access to any of these things and require cacheability information

    For example rather simply exposing a backtick operator to execute something via the shell, perhaps the backtick operation should require a mixin on the type Marcus used up there to identify cacheability (or you get a compile time error) - ...

    PHP Code:
    $result = `ls -al` : Cacheable( ? )

    // ...and something that checks the mtime on the directory for conditional get 

  7. #7
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi.

    How important is cacheability outside of a website? Most commercial sites want to track user activity so as to optimise the site. They want to be informed of every page traversed. This means part of the request is never cached. This could be a one pixel image attached to the page (so as not to slow the page response) or just delivering internally cached pages.

    One technical solution is for proxies to pass on the the request as some kind of "was cached" header. That way the owning site knows that a page was requested, even though it was delivered in a timely fashion upstream. They don't do that yet (or do they?).

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  8. #8
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Continuation Server

    Could be of interest to some I suppose

  9. #9
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well guess if want to track usage you'd have to use conditional gets exclusively.

    Or have a proxy that essentially reads the cache control headers, and uses those values for its caching, and sends conditional gets to browsers. With the proxy doing logging you'd still have user tracking.

  10. #10
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    I don't see that continuations have to break REST either. We can tag a template with a session type, such as thread ID (the Seaside approach), Cookie based if session like behaviour has started, but pages are basically static, or none at all if no state is in scope at the time of the template call.
    I have trouble understanding this claim? Continuations stores the state at the server, so unless you want to keep all sessions forever, I don't see how you could bookmark a page and come back at a later point ?
    The only real solution I can see, is that all statefull pages are served over POST to indicate that it's a temporary resource.

    I don't have any actual experience with continuations, but I'm intrigued by the idea - especially cocoon has caught my attention, mostly because flowscript is a ecmascript variant, and I like ecmascript.

  11. #11
    Bad Ass Mother F#$%^& Devious's Avatar
    Join Date
    Feb 2005
    Location
    New Orleans LA (504) 812-8971
    Posts
    539
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I feel I must interject here...

    We are light years away from developing a 'perfect platform'.

    Web software companies are incompetent and cannot even include working instruction manuals / tutorials; Cannot make a stable versions; Cannot commit themselves to serve purpose in a common interest... Honestly, I do a hell of a lot better hand coding HTML than screwing with PHP and SQL tables. I'm not going into details, but I'm sure we can all rule out PHP as a MAJOR paid in the @ss.

    BECAUSE:

    The perfect platform must user friendly.
    You want a website to do what? In no particular order:

    1) Look good.
    2) Load fast.
    3) Serve a purpose.

    And how do you get that? By any means possible with the tools on your table. When cheap tools are worse than no tools, you don't need any tools to code HTML. HTML has the basis for the perfect platform, but I think something along the lines of BB Code could do bigger damage if it utilizes a language that everyone understands: ENGLISH.

    Hate to crash the party, but everything is moving toward the WYSIWYGDGAD environment. And I know a lot of you don't want to hear it, because that empowers talentless n00bs to do the work we train for years to learn, but by that time, it will be the work of the past.

    Think about it. Professional in the recording industry use 1 program: Pro Tools and it is loathed by recording engineers. It's was a WYSIWYG before WYSIWYG was even WYSIWYG. No more splicing tape. No more wasting reels. No more loss of quality and it's simple. The "Record" button is not called "tween" or "action frame" or any other stupid made up fantasy term that the monkeys at Macromedia dreamt up when they were high.

    Professional in the motion picture industry use Avid. Yea, Final Cut was up there for a while, but then came King Kong and everything's back to normal. Same thing as Pro Tools only you're working with video and audio: Cut and past the parts where you want them and then you master your tracks.

    The old-school hard heads who considered software to be "cheating" had to come to terms that the music of the past is over and this is the red-book industry standard. And that's where developers (from one end of the spectrum to the other) will be when Dreamweaver get's their act together. Because it's really not cheating, it's worker-bee work. Both genius and knuckle head can type <a href="http://...> but it doesn't mean we want too. Take that load off your hands and you'll be able to focus on more important aspects of development.

    And there will be old-school people from our world who will not accept that. And they'll be out of jobs. Employers are not going to argue with you and your philosophy when the obedient, sharp, minimum wage, high school graduate comes looking for your job. I have 3 of those guys working at my shop. They smoke me in every aspect of development and they are what ultimately keeps me in business. Midieval programmers constantly apply, but I cannot use them. They're slow and want too much money to not listen to me.

    The perfect platform starts with the perfect program that allows you to choose your ideal platform (or combination of) upon project completion. Just like Avid, Pro Tools or writing a thesis paper: You put the puzzle together, then you publish it.

    Because of it's language and overall simplicity, the kids say "HTML and CSS ponds you"
    Last edited by Thyrium; Mar 30, 2006 at 14:11.
    Logo Design & Identity Branding Consultant.

  12. #12
    SitePoint Evangelist
    Join Date
    Jun 2003
    Location
    Melbourne, Australia
    Posts
    440
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Thyrium
    [INDENT]Web software companies are incompetent and cannot even include working instruction manuals / tutorials;
    Thyrium is annoyed because PHP and MySQL installers don't have manuals. Well, they do, but apparently Thyrium can't follow them.

    Most of this stuff is free and is developed by people in their free time. The trade-off is that you don't always get documentation, or, at least, documentation that newbies with a total lack of Unix/Linux and web development can understand.
    PHP as a MAJOR paid in the @ss.
    You've appeared on a forum about advanced PHP programming (it actually used to be called that too). As Snaily might put it, we're all PHP "fan boys"... and you breeze in and say that!?
    The perfect platform must user friendly.
    You want a website to do what? In no particular order:

    1) Look good.
    2) Load fast.
    3) Serve a purpose.
    PHP has nothing to do with any of those per se. It's up to you to use its features to achieve those things.
    Think about it. Professional in the recording industry use 1 program: Pro Tools and it is loathed by recording engineers.
    I've never met an engineer who loathed Pro Tools. They might wish for certain features in it or dislike some behaviours, but overall most consider it to be great. And the rest of your paragraph seems to be praising Pro Tools or at least the central idea behind it-- that is, non-destructive editing. You couldn't make less sense.

    Still, if anyone here would like to assess Thyrium's ability to make an informed contribution to this thread, I refer them to this.
    Zealotry is contingent upon 100 posts and addiction 200?

  13. #13
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Thyrium
    (...)
    That was quite possibly the most incoherent piece of rant I've ever laid my eyes on. In a word: huh?

  14. #14
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Also, if have a compilation step, which its appears to be in neko, would like to be able to have a sort of macro ability

    One example would be to perform regular expression compliation at compile time.
    Code:
    $re = new Re2C('/[A-Za-z0-9_-]+/');
    if ($re->isMatch($string))
    {
    ...
    }
    So the regular expression is compiled into the output, like re2c.

  15. #15
    SitePoint Addict dek's Avatar
    Join Date
    Oct 2004
    Location
    UK
    Posts
    352
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    For me, I think perfection would be a little easier to obtain than for many. At work, I use ColdFusion, at home I use PHP (because I know it) - and one of these days I'll get around to Ruby (because I like the look of it). Outside of a web context, I've worked with or played with a reasonable set of languages over time (the usual: C, C++, Java, Pascal, Smalltalk, Javascript etc etc)

    The CF / PHP contrast is an interesting one. Syntactically speaking, CF is an appalling infuriating obscenity of a 'language'. It does however have some features that I wish to God PHP had, and its hand-holding philosophy makes it better for rapid prototyping.

    Ultimately though, all I want is a decent, reasonably powerful, structured programming language. PHP will do fine. Even ColdFusion will do once I've enhanced it a bit with some decent libraries.

    I'm not fussed about continuations. But I want ColdFusion's scoping system (especially the Application scope. I sorely miss this in PHP.)
    I want the usual run of external extensions - db connectivity, xml tools, graphical manipulation tools etc etc, all the things that should basically be taken 'as read' in any modern web environment.

    Anything else I'll write myself, chiefly because I very often find myself writing web applications which don't play by any rules that I've come across before - and so don't fit into any existing frameworks,
    Only dead fish go with the flow

  16. #16
    SitePoint Addict artemis's Avatar
    Join Date
    Sep 2003
    Location
    London
    Posts
    295
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    I am not a programmer but how about something that was modular so that new solkutions can be added to a central server on a regular basis.

  17. #17
    is_empty(2); foofoonet's Avatar
    Join Date
    Mar 2006
    Posts
    1,000
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Moderator, Moderator! Get this guy outa here...

    Come on, this was an interesting thread...

  18. #18
    SitePoint Evangelist
    Join Date
    Apr 2005
    Posts
    485
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    [INDENT]I feel I must interject here...

    We are light years away from developing a 'perfect platform'.


    agreed. thi sis complex business. there is a simple solution to every complex problem... and it is always *wrong*.

    i'd argue there is no perfect platform b/c people do different things with the web.

    Web software companies are incompetent and cannot even include working instruction manuals / tutorials;

    http://www.geocities.com/operationsengineer1/

    the instructions work and if you have a decent understanding of computers, you'll get it done. i do agree, though - it was painful for me to get things working. *painful*. these instructions make it pretty straightforward, though.

    Cannot make a stable versions;

    i don't have stability problems. dom was giving me problems on php4 so i upgraded to php5... no more problems. dom is new functionality, and you have to expect some challenges to get new functionality working.

    my comment? i give a big "thank you" to the developers that get this stuff done.

    Cannot commit themselves to serve purpose in a common interest... Honestly, I do a hell of a lot better hand coding HTML than screwing with PHP and SQL tables.

    i do both. you do know that html can't do what php does, right? have you ever gotten a switch statement to work in html? have you used the dom to wirte out and display xml files? if so, let us all know how, arlighty?

    I'm not going into details, but I'm sure we can all rule out PHP as a MAJOR paid in the @ss.

    BECAUSE:

    The perfect platform must user friendly.


    remember - what are simple solutions to complex problems?

    You want a website to do what? In no particular order:

    1) Look good.
    2) Load fast.
    3) Serve a purpose.

    And how do you get that? By any means possible with the tools on your table.


    agreed.

    When cheap tools are worse than no tools, you don't need any tools to code HTML.

    people don't use php to replace html. you sound like you need, as the kid's say, a CLUE-PON.

    html can't do what i need to get done. php can. i'musing the tools to get done what i need to get done.

    HTML has the basis for the perfect platform,

    logic, presentation and content. do yuo know the difference? html is good for content and framing presentation (css does the actual presentation). i use logic, do you? i use presentation - and html SUCKS for presentation without css. it is HORRID (note - i learned css first)!

    but I think something along the lines of BB Code could do bigger damage if it utilizes a language that everyone understands: ENGLISH.

    i don't knwo bb, so no comment.

    Hate to crash the party, but everything is moving toward the WYSIWYGDGAD environment. And I know a lot of you don't want to hear it, because that empowers talentless n00bs to do the work we train for years to learn, but by that time, it will be the work of the past.

    again, wysiwig can't do what i need to get done. btw, i do appreciate good wysiwyg tools that don't screw up the code - good code is job 1. so i code by hand. i thought you said you code by hand, too. why? all those wysiwygs don't impress you, either?

    maybe one day, but not today - and that is the day in which i live.

    you said all the web companies sucked, so what makes you think they will ever produce a wysiwyg that produces clean code?

    Think about it. Professional in the recording industry use 1 program: Pro Tools and it is loathed by recording engineers. It's was a WYSIWYG before WYSIWYG was even WYSIWYG. No more splicing tape. No more wasting reels. No more loss of quality and it's simple. The "Record" button is not called "tween" or "action frame" or any other stupid made up fantasy term that the monkeys at Macromedia dreamt up when they were high.

    Professional in the motion picture industry use Avid. Yea, Final Cut was up there for a while, but then came King Kong and everything's back to normal. Same thing as Pro Tools only you're working with video and audio: Cut and past the parts where you want them and then you master your tracks.

    The old-school hard heads who considered software to be "cheating" had to come to terms that the music of the past is over and this is the red-book industry standard. And that's where developers (from one end of the spectrum to the other) will be when Dreamweaver get's their act together. Because it's really not cheating, it's worker-bee work. Both genius and knuckle head can type <a href="http://...> but it doesn't mean we want too. Take that load off your hands and you'll be able to focus on more important aspects of development.


    agreed. as soon as someone can easily produce clean code in a wysiwyg environment, i'm on board.

    And there will be old-school people from our world who will not accept that. And they'll be out of jobs. Employers are not going to argue with you and your philosophy when the obedient, sharp, minimum wage, high school graduate comes looking for your job. I have 3 of those guys working at my shop. They smoke me in every aspect of development and they are what ultimately keeps me in business. Midieval programmers constantly apply, but I cannot use them. They're slow and want too much money to not listen to me.

    so, the kids don't listen to you and keep you in business? why should we listen to you? -lol-

    The perfect platform starts with the perfect program that allows you to choose your ideal platform (or combination of) upon project completion. Just like Avid, Pro Tools or writing a thesis paper: You put the puzzle together, then you publish it.

    Because of it's language and overall simplicity, the kids say [I]"HTML and CSS ponds you"


    i don't even know what this means. ponds you? what? btw, css and cross browser compatibility is a freaking NIGHTMARE. i know you just didn't call it simple. oh, your kids don't code for cross browser support?

    now things are starting to make sense...

  19. #19
    SitePoint Addict bwdow's Avatar
    Join Date
    Feb 2006
    Posts
    343
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I will save this thread. Good information collected.

  20. #20
    Bad Ass Mother F#$%^& Devious's Avatar
    Join Date
    Feb 2005
    Location
    New Orleans LA (504) 812-8971
    Posts
    539
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by skeeterbug
    i'd argue there is no perfect platform b/c people do different things with the web.
    And I will agree, but we talking about a platform that has yet to bee invented. My perfect platform would be... well, perfect.

    Quote Originally Posted by skeeterbug
    i do both. you do know that html can't do what php does, right? have you ever gotten a switch statement to work in html? have you used the dom to wirte out and display xml files? if so, let us all know how, arlighty?
    I understand that, but in my perfect platform, there are 2 key elements:
    1) HTML/CCS (the basic of all things) has incorporated the functions of php, java, etc...
    2) Site are developed on a program of virtually unlimited capacity with the ability to turn php into HTML and water into wine.

    I'd give it 15 years for something of this magnitude.
    Quote Originally Posted by skeeterbug
    html can't do what i need to get done. php can. i'musing the tools to get done what i need to get done.
    Again, we're definining a perfect platform, not debating which is the best current platform. If that was the case, I wouldn't even know where to start.

    Quote Originally Posted by skeeterbug
    again, wysiwig can't do what i need to get done.
    Imagine a program with a monumental library of php commands/scripts. Instead of billions of foo's and echo's we're looking at something like this: <?php include("site.com/vbulletin.php");
    ?>
    and the rest is history...

    Ancient history. So old, it would be spoke of like such:
    "You know Wilber, they used to have to type this stuff by hand"
    "Really, you mean I couldn't say 'Computer, make a blue and purple forum script.'"
    "Are you kidding? Computers we're still slaves back then. They had yet to develop free thought."
    Logo Design & Identity Branding Consultant.

  21. #21
    SitePoint Guru silver trophy Luke Redpath's Avatar
    Join Date
    Mar 2003
    Location
    London
    Posts
    794
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thyrium it sounds like you want the computer to do everything for you...are you sure you are in the right industry?

    One thing for sure is that one language or one platform that tries to everything and be all things to all people would be a disaster - history has shown that things like this never work. Its just not possible to do everything well - all you are left with is something bloated and half-arsed. Its better to have a language or platform or piece of software that does one or two things really well rather than many things really poorly.

    Its fine to talk about what would be the perfect platform but I also feel its important to be realistic. Also, I thought the original point of this thread was to discuss the perfect development language/framework from a developers point of view rather than an end users point of view which is what you seem to be getting at Thyrium.

  22. #22
    SitePoint Evangelist
    Join Date
    Jun 2003
    Location
    Melbourne, Australia
    Posts
    440
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Luke Redpath
    Thyrium it sounds like you want the computer to do everything for you...are you sure you are in the right industry?
    Based on my previous, less than amicable, interactions with Thyrium, I suspect he/she wants PHP and MySQL to work like Dreamweaver and Photoshop. Here lies the problem, because they're not applications in that sense. They're more like services that the OS provides so you have to work at a much more abstract and, dare I suggest it, basic level. That is, there's not as much stuff going on in the background as when you, say, select a Gaussian Blur from Photoshop's filters menu. One might say that you actually have to code the background!

    It may be that Thyrium actually does understand this, but the ranting and misuse of words doesn't reveal it. (For example, "loath" does not mean "love", which I now realise is what made the Pro Tools rant nonsensical.)
    Zealotry is contingent upon 100 posts and addiction 200?

  23. #23
    SitePoint Guru
    Join Date
    Aug 2005
    Posts
    986
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    1) PHP like syntax, that is $variables and nice string handling. PHP is proven to be the easiest language to use for web development. Classes should be optional.

    Tcl? - I don't think this is the ideal solution. Variables should be without $. Not PHP/C like syntax, it's too hard to write. The syntax has to be extensible to create good frameworks.

    2) Continuations. No need for MVC. Also see 9.

    ??? Continuations do not solve the same problem as MVC. Continuations capture the call stack of a computation. They CAN be used to save a callstack, and execute it later. (see the Seaside framework, written in smalltalk)

    3) Blocks. No need for visitors and iterators.

    True, but blocks are just first class functions / lambdas. I think it should be possible to pass them as parameters just like other values (like in smalltalk/lisp)

    4) Exceptions. With a finally clause.

    Yep. Maybe a condition system?

    5) Simple namespaces. Also, no need for $this over and over again, please.



    6) Operator overloading. Non OO people should be able to use objects that look like arrays.

    Operators should be equivalent to methods/functions

    7) Support for tainted data.

    Hmm, don't see the benefits of this.

    8) Perl regex support built in to strings (but without the =~ syntax or a $matches array).

    =~ syntax is pretty nice? It's short and readable. No strange $2 etc variables though

    9) Good support for script interrupts within the same script, such as the cancel button, AJAX events, etc.

    Yes.

    10) Enterprise database and XML support, including SOAP/BPEL.

    REST?

    11) Built in web browser.

    ?? don't see the point. Shouldn't you be able to use your own?

    12) Secure by default.

    Sure.

    13) C++ extension support.

    Why not C? Most libraries are written in C.

    I'll add 14:

    It should be a modular system: you should be able to replace modules with you own. If you want to use your own template engine/database wrapper, you can.

  24. #24
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Fenrir2
    Not PHP/C like syntax, it's too hard to write. The syntax has to be extensible to create good frameworks.
    Even if C-syntax is hard to write, it's defacto standard. I think that outrules most arguments, however reasonable they may be.

    Quote Originally Posted by Fenrir2
    True, but blocks are just first class functions / lambdas. I think it should be possible to pass them as parameters just like other values (like in smalltalk/lisp)
    That would be very nice indeed, but it would totally change the language. Have a look at the javascript forum. There's at least one question a day, where people are confused about the "this" keyword. I'm not sure, but I suppose that blocks are an attempt to avoid theese problems.

    That said, I really like javascript mix of functional/oo paradigms, I just don't think it's everybodys cup of tea, and it's definately going to smother the newbies.

    Quote Originally Posted by lastcraft
    9) Good support for script interrupts within the same script, such as the cancel button, AJAX events, etc.
    I don't understand exactly what this means, unless it's another variation over the continuations theme. Care to elaborate ?

  25. #25
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Interrupts are an electronic signal that interrupts the processor every 50 thousandth of a second, to allow you to do something else, for example, to keep proper time; You access them directly from assembler language - not sure you can access them directly from C (compiler)

    Closer to home, these interrupts are what gives you your client side Javascript event handling, but how that would pan out with server side development I have no idea, unless Marcus was referring to something else...

    Threading perhaps?


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •