Fair enough. And of course my view from Perl is "I feel lucky if I get an editor w/ syntax highlighting", whereas with Java I'm usually in Eclipse, which does an ok job with that kind of thing. So I can see the potential for your point.
Getting back to some of the original debate... I guess it's always a tradeoff. I think some good engineers tend to (IMO) overestimate the cost of, say, having to duplicate a change across multiple items, and underestimate the "conceptual weight" of working with a system rich enough that it's almost "meta-" about the change you're trying to make, so that it can, in effect, make the change for you across those pages.
AND let you write strongly typed (maintainable) code.
See, I think statements like that show a divide that's tough to cross, a set of assumptions about the value of OO that are deep enough that if someone's not convinced, it takes a lot of discussion... and use of "toy" examples always seems suspect, so that if the doubter doesn't experience some moment of revelation while doing actual work, they just won't believe you. More scariliy, their own preconceived notions might lead them to be Unable to come round to the other point of view.
So: I think it's extremely debatable that strongly typed == maintainable.
I've done a lot of work in Java, but also a lot in Perl and other "duck typed" languages, And very, very rarely do I get burned by "oh damn, the computer used this variable in a way I didn't expect, because of the typing.
Now, where Perl DOES fail is in the syntax for grouping something into objects. And sometimes I really miss that, and there are some personal projects I'd like to do in Perl, but realize the thing would get too messy without a stronger (and more semantically sweet) OO paradigm.
Re:Started with Perl-CGI, went to OO
on
GWT in Action
·
· Score: 1
Took a look at Rails. Clever, but couldn't really wrap my head around its use beyond CRUD...
The "foggy idea of what OO" is is a fairly damning accusation. I've had a decent academic background in the early 90s, and have been doing Java since 2001. So if I don't know it by now... it's also a hard charge to refute, because even a demonstration of an understanding of the basics can lead to "well sure you know that, but you don't REALLY get it"-- and once the other person claims that high ground, they never have to give it up.
(Again, I think http://www.geocities.com/tablizer/oopbad.htm makes the case that OO *is* oversold -- but the idea "more OO is better than less OO" becomes a matter of faith, and so jsut saying "OO is OK" doesn't seem like enough, and you seem like some kind of cretin who just doesn't get it.)
And the thing is, it's not like I think Perl is the end all and be all, and there are times I desperately wish it had a stronger object model... even the syntax for nested arrays etc ain't great, and there are definitely times where delimited strings and hashmaps will reach their limits.
I guess in Wicket I get most bugged by the "parallel hierarchies" of things I've add()ed in the java, and then represented in the HTML. At least that gets me the most stack traces...
Again, it's the background thing. HTTPRequest/Response seems like the most natural thing in the world to me, in part from years of CGI. But hell, from years of using the Web! Click, or submit, and get a page back. Or, nowadays, click, and some part of the page goes and updates, ala Ajax. And the Session model, a simple Map to store things, was the easiesst thing to keep a mental model of (of course, clustering then became an issue, but that's not too surprising, anything cross JVM is a bit dicey)
I guess I don't feel I was easily able to learn most of the framework by poking around my IDE.
I guess I described my homegorwn super-lightweight framework elsewhere.
For reusable page components, I guess the "super lightweight" answer is either JSP includes (which admittedly tends to be dependent on page scope variables), use of Java objects that spit out HTML (which doesn't have to be as big a sin as people pretend), or, a bit more recently, use of custom tags.
So far in my (jaundiced) observation its been about 50/50 like Wicket or dislike. And I do think it's what kind of applications you wrote before, traditional web vs applets or other things where the object doesn't have to go through so much change to get to a visual representation;.
The:enclosure thing is interesting... I don't know a lot about it, which kind of points to one possible source of problems, Wicket doesn't have a lot of non-example and non-javadoc documentation... just that one book and some very basic tutorials.
I haven't seen leaky PKs be too much of an issue. A lot of keys are just local identifiers, or your API should be doing requisite security checks.
Well, are you arguing for Wicket, or for GWT? At this point I'm still willing to give GWT the benefit of the doubt.
I hear your point that you can take my argument to an illogical extreme (lets just toggle panel switches!) but that doesn't mean the opposite is true. I wouldn't want to write an applet by having to control individual pixels either, but the fact is web apps have a pretty good toolset, DHTML, Form Elements, CSS, and in my judgement, unless you embrace a full on JVM-ish approach like GWT, then the easiest way of fiddling with those elements is by manipulating text, and writing your own wrappers as needed.
Apology accepted. I don't troll per se, but sometimes do try to provoke intelligent responses in a slightly ugly way.
And trust me, I'm just as frustrated and confused by people who adore Wicket and say it has a great power/conceptual weight ratio! Especially because I'm concerned it points me to being a curmudgeon before my time, unwilling or unable to learn new things.
The last time I "rolled my own framework", which was just some tools to make "Model Two Plus" (servlets and JSP pairs; esentially MVC w/ lots of Cs) I came up with two things: one was the "FormFieldHolderBean" that made it very easy to populate HTML forms w/o conditional logic in the JSP, much like the ActionForms in Struts that I ran into later. The other concept was, for those multiple Servlets, there should be as LITTLE cut and paste, non-business logic as possible... we really got it down to just 4 or 5 lines per Servlet, by farming repetitive things out to a single superclass or to APIs.
The thing with this approach is, it was VERY easy to know where to look when things went wrong. It was conceptually super light weight, and in general inspecting the URL would bring you to the appropriate servlet or JSP. Compared to the stack traces I've had to sort through in intervening years, I view those days as somewhat of a golden age...
We're finding that while Wicket does let you customize CSS and HTML (but not always easily, yesterday my coworker who's pretty CSS adept couldn't figure out how to stop one of the close to builtin tree controls from having a border) there are still a lot of problems where we have to figure out "ok, the javascript is fairly easy, but what's the Wicket way to do this"? One example was some sortable tagbles w/ selectable rows, preserving the selection across sorts and groupings. We got it, but it seemed less elegant than we would have liked.
I probably do have a text-centric (thanks, Perl) outlook, but even to the extent I see "components", I see them as "DHTML components", and the mapping to Java objects seems forced.
Another problem with all this... Wicket is in desperate need of a few more teaching books and a really good recipe/cookbook.
Yeah, and I might be biased by my years of "Jack of All Trades" homebrew websitery, but yes, I think a web developer SHOULD know CSS, Javascript, and HTML, because most apps are demanding enough that they'll be wading through that stuff anyway.
I also find it easier to import 3rd party javasvript/DHTML widgets when I don't have to sweat wrapping it in Java objects.
Ah, well it might be a thing of terminology... I have no problems with going to outside APIs and libraries for specific bits of functionality, I certainly wouldn't to write PDF or Excel generators at a low level... it's the difference between APIs/libraries vs Toolkits/Frameworks. (We're more talking the most efficient and maintable way to do bread and butter stuff like "make a web application")
The years vs months comparison... I'm not sure I buy it. Especially because usually you're just using a subset of the functionality, but to do it right, have to "pay" for (in terms of learning complexity) much more than that.
That's one reason I love APIs to the heavy lifting, but having a core of the Lowest Common Denominator of control code. For Java, this was Servlet/JSP pairs.
Re:Worse than Wicket?
on
GWT in Action
·
· Score: 2, Interesting
Yeah.
Sometimes I worry that I come up with my philosophy about languages to suit my personal gripes and history, and that ultimately that limits me as a developer, but...
Anytime you borrow someone else's toolkit that adds some kind of organization/abstraction over an existing technology... well, either you're losing bits of the functionality of the lower level, or what you're learning is about as complex as the lower level.
My strong personal preference is to write your OWN, app-specific organization.
The counter argument comes from people who are heavily OO in their outlook. (more specifically, I think a gap tends emerge between people who cut their teeth on simple CGI-wrapping things, and got used to using a HashMap mentality for most client/server interaction, and people who cut their teeth on apps and applets, for whom the gap between Java code and what's physically displayed onscreen seems weird and in need of being abstracted away.) Anyway, these folks say that, look, the organization I want is OO, writing this kind of Object->screen element->response mapping ls a repetitive task, so I'm willing to buy into someone else's approach to do that work. That's where something like Wicket comes in.
My recent semi-revelation for this kind of tool-kit was this: "text" is amazing. It has been the lifeblood of programming for decades, ever since we could get away from punched cards I guess, despite attempts at cutesy visual languages. It's just so powerful, concise, easy to manipulate, easy to automate that manipulation, and in its own way visual (hence the wars over the one true brace style etc) that it will be around for a long long time. But text is, by the way we use it, rather procedural, and while you can do OO in it, that's a new level. But sacrificing the ability to adjust HTML and CSS and Javascript in TEXT on the alter of Objects just seems like too big of a sacrifice to me.
Of course, taking an anti-OO stance is a heresy (see http://geocities.com/tablizer/oopbad.htm ) and you have to be careful so you don't seem like a crazy nut job who hasn't worked on large scale projects. But my latest take on it is this: "People and Programs are both best defined by what they DO, not what they ARE".
Another way of looking at it: in Java, when stuff goes wrong, what's your stack trace like? There's always that boilerplate JVM/Server engine at the bottom, but if the core of what's at the top ain't your code, your debugging is going to be a lot harder, because your mistake is in how you set up the other guy's objects to do the work, not you doing the work yourself. (Assuming the other guy's stuff is solid.)
Re:Worse than Wicket?
on
GWT in Action
·
· Score: 3, Insightful
I just don't see what Wicket - or possibly any web framework - buys you.
Maybe especially core Wicket, which isn't trying to do much but wrap HTML bits as objects. What really is the benefit of that? Nothing seems simpler and it often seems to be getting in the way-- maybe it's a mental gap problem, but often I end up having to put placeholder HTML in the page, and the set visibility = null. And the Ajax support is so-so.
I mean, I think the fact that the static Wicket homepages often produce session timeout exceptions is pretty damning that it encourages poor web programming.
Worse than Wicket?
on
GWT in Action
·
· Score: 3, Interesting
Yeah?
I did an evaluation of it. I kind of liked it, but in general don't like "lets make a servlet environment pretend its an applet", so I didn't endorse.
Now, after months of using Wicket, I wish I had pimped for it more. Seriously. If you're gonna pretend it's an applet, then REALLY do it like GWT does, fake JVM and all. This Wicket stuff.... ugh. keeping the html view and java in synch for anythign complex is SO IRRITATING.
Seriously, after years of Struts and stuff like Wicket, I don't see any real advantage over "Model 2+" (Servlet/JSP pairs) that I started with in 2001. There is a benefit to simplicity and writing HTML in HTML and writing Javascript in Javascript that over-engineers who are, frankly, a little OO-obsessed just don't get.
Maybe years of Perl CGI has bent my brain but The HTTP Request/Response paradigm just doesn't seem so awful that it needs to be (leaky) abstracted away.
Plus, at this point "Steve Jobs doesn't like buttons", so we'll probably continue to see special touching surface behavior (the mighty mouse lean, 2 fingers on a touchpad, the iPhone pinch) instead of an additional physical button.
There are some positive aspects of that, but I'm always worried were going to wind up like that radio outline in Hitchhiker's Guide, where it went from switches to touchpads to cameras, and now you had to sit very still if you wanted to keep listening to the same station...
Anyway, I don't know if the Apple 2 finger thing is reliable, but I hate most "touchpad tricks" like scrollable areas and what not, for exactly the reason you give for hating 2 button trackpads. Personally I think physical buttons are easier to differentiate than software one, but hey.
Guess I have something to try out at the Apple store...
bleh. I'm not a big fan of "trackpad tricks" like that... special scroll zones etc. I find them too easy too do accidentally and too difficult to do on purpose.
Though my iPhone is getting me used to the pinch motion.
I still think it became a matter of dumb pride not to have the second button, even when Windows showed the usefulness of context menus, and even when OSX started to have good support for it...
I still, to this day, play Super Mario Bros. regularly on my original NES (even though both my remotes are falling apart).
Heheh, where do you hail from, that you're an old school gamer and call NES controllers "remotes"?
This isn't to say today's games aren't fun. I enjoy games like Diablo II for the fantasy aspects.
A. Diablo II probably is a bit old to be representative of "today's" games, especially because B. It's mostly just pretty Nethack!
how many "classic gamers" do you think played through Super Mario Bros. for the storyline or the content?
Back in the day, I think people did play SMB for a blend of skill-proving and content... to see what the game would throw at them next, and if they could handle it.
It's a false dichotomy to imply that THE two types of gaming are skill-based and storytelling. I don't think video games are at the leading edge of the either goal: if I wanted to prove my skill, I'd take up bowling or golf or darts, and story-telling wise the medium has its moments, thanks to immersion, but probably ultimately lags movies and books. So I come back to this idea of the one thing video games do the best, which is: novel interactions. Show me some new way of interacting with a system. It doesn't have to be particularly skill-taxing, it just has to be interesting and preferably new. The recent example that sticks in my mind of this is Hulk: Ultimate Destruction, which did a TREMENDOUS job of what being a massive, superpowered, insanely strong, able to clamber over buildings being might feel like. There was also a so-so story, and some challenging bosses, and a gradually unlocked set of powers and abilities.
"Novel Interactions" is an umbrella that covers my old interest in Atari games... this is from an essay I wrote around ten years ago:
And now I know: I play games for the microcosms they create. I love the idea of each cartridge holding a small virtual universe, establishing its rules and laws of physics, populated with artificial beings. Video Games are one of the few forms of Artifical Life that we might encounter on a daily basis.
Classic games, then, appeal to me for two reasons: one is that they're cheap. You can get stacks and stacks of these little universes for just a little money. The second reason is how the graphical and memory constraints of these games forced the designers to be very created in the universes they set up. The NES was plagued by a series of not-very-different side-scrollers, where only the graphics and music varied from game to game. Atari designers didn't have the luxury: they created new universes from the ground up. Game innovation came in the form of new interactions with these electronic microcosms.
So getting back to what you wrote:
Like Starcraft. Great single player, but very easy, and very little sense of accomplishment. Fantastic multiplayer, and tremendously rewarding to the ego (and wallet) in tournament play.
For the record, I didn't find single player Starcraft that easy, I could stuck near the end of Episode III. But then again, you claim its a big egoboost and way of getting cash; for every person like that, there must be ten for whom it's a humiliation and investment of time that they'll never get back...
I've been a classic gamer for a long, long time, I was posting on r.g.v.c. since like '93 or so...
Here's the thing: games now have distinct content, lots of it, not just one playfield or enemy set speeded up.
(Ideally, this content involves new interactions, i.e. involving programmers as well as designers, not just the artists saying "well, here's a 'new city' to 'explore')
So people want to get the game that they pay for. Me, and maybe it's a personal fault throughout many aspects of my life, I don't like challenge for its own sake. I want to play with novel interactions in as economical a way as possible. (And, oddly, the time a game uses is counted both towards its cost and its benefit)
Most games, especially sandbox ones, will have some rewards for the really dedicated and skilled player, or at least have challenges so such a player can self-motivate and have something to do. And now you even have youtube and specialty sites to show off your 'l33t skillz. Quit griping that big chunks of content aren't being created (and tested) just for you and your dedicated little band...
I couldn't find the Usenet reference, but I remember some old rgvc conversation about how Sinistar cheats: it doesn't compute things offscreen nearly as much as you'd think, so those little gatherers and warriors can freely fly without worrying about hitting asteroids...
The rally squad's task is to use their signs and banners as shields between the demonstrators and the main press platform. If the demonstrators are yelling, rally squads can begin and lead supportive chants to drown out the protesters (USA! USA! USA!) As a last resort, security should remove the demonstrators from the event site. The rally squads can include, but are not limited to, college/young republican organizations, local athletic teams, and fraternities/sororities.
I'm not sure which part I find less wholesome, the almost self-parodying use of yelling "USA! USA! USA!" or the idea of importing the local football team and/or frat to act as rhetorical muscle.
Slashdot Mirror
Well, they still have to pick clockwise up or ccw up, eh?
Fair enough. And of course my view from Perl is "I feel lucky if I get an editor w/ syntax highlighting", whereas with Java I'm usually in Eclipse, which does an ok job with that kind of thing. So I can see the potential for your point.
Getting back to some of the original debate... I guess it's always a tradeoff. I think some good engineers tend to (IMO) overestimate the cost of, say, having to duplicate a change across multiple items, and underestimate the "conceptual weight" of working with a system rich enough that it's almost "meta-" about the change you're trying to make, so that it can, in effect, make the change for you across those pages.
See, I think statements like that show a divide that's tough to cross, a set of assumptions about the value of OO that are deep enough that if someone's not convinced, it takes a lot of discussion... and use of "toy" examples always seems suspect, so that if the doubter doesn't experience some moment of revelation while doing actual work, they just won't believe you. More scariliy, their own preconceived notions might lead them to be Unable to come round to the other point of view.
So: I think it's extremely debatable that strongly typed == maintainable.
I've done a lot of work in Java, but also a lot in Perl and other "duck typed" languages, And very, very rarely do I get burned by "oh damn, the computer used this variable in a way I didn't expect, because of the typing.
Now, where Perl DOES fail is in the syntax for grouping something into objects. And sometimes I really miss that, and there are some personal projects I'd like to do in Perl, but realize the thing would get too messy without a stronger (and more semantically sweet) OO paradigm.
Took a look at Rails. Clever, but couldn't really wrap my head around its use beyond CRUD...
The "foggy idea of what OO" is is a fairly damning accusation. I've had a decent academic background in the early 90s, and have been doing Java since 2001. So if I don't know it by now... it's also a hard charge to refute, because even a demonstration of an understanding of the basics can lead to "well sure you know that, but you don't REALLY get it"-- and once the other person claims that high ground, they never have to give it up.
(Again, I think http://www.geocities.com/tablizer/oopbad.htm makes the case that OO *is* oversold -- but the idea "more OO is better than less OO" becomes a matter of faith, and so jsut saying "OO is OK" doesn't seem like enough, and you seem like some kind of cretin who just doesn't get it.)
And the thing is, it's not like I think Perl is the end all and be all, and there are times I desperately wish it had a stronger object model... even the syntax for nested arrays etc ain't great, and there are definitely times where delimited strings and hashmaps will reach their limits.
So this might help explain in Star Trek how all ships are always keeping the same orientation / sense of "up"...
I guess in Wicket I get most bugged by the "parallel hierarchies" of things I've add()ed in the java, and then represented in the HTML. At least that gets me the most stack traces...
Again, it's the background thing. HTTPRequest/Response seems like the most natural thing in the world to me, in part from years of CGI. But hell, from years of using the Web! Click, or submit, and get a page back. Or, nowadays, click, and some part of the page goes and updates, ala Ajax. And the Session model, a simple Map to store things, was the easiesst thing to keep a mental model of (of course, clustering then became an issue, but that's not too surprising, anything cross JVM is a bit dicey)
I guess I don't feel I was easily able to learn most of the framework by poking around my IDE.
I guess I described my homegorwn super-lightweight framework elsewhere.
For reusable page components, I guess the "super lightweight" answer is either JSP includes (which admittedly tends to be dependent on page scope variables), use of Java objects that spit out HTML (which doesn't have to be as big a sin as people pretend), or, a bit more recently, use of custom tags.
So far in my (jaundiced) observation its been about 50/50 like Wicket or dislike. And I do think it's what kind of applications you wrote before, traditional web vs applets or other things where the object doesn't have to go through so much change to get to a visual representation;.
The :enclosure thing is interesting... I don't know a lot about it, which kind of points to one possible source of problems, Wicket doesn't have a lot of non-example and non-javadoc documentation... just that one book and some very basic tutorials.
I haven't seen leaky PKs be too much of an issue. A lot of keys are just local identifiers, or your API should be doing requisite security checks.
Well, are you arguing for Wicket, or for GWT?
At this point I'm still willing to give GWT the benefit of the doubt.
I hear your point that you can take my argument to an illogical extreme (lets just toggle panel switches!) but that doesn't mean the opposite is true. I wouldn't want to write an applet by having to control individual pixels either, but the fact is web apps have a pretty good toolset, DHTML, Form Elements, CSS, and in my judgement, unless you embrace a full on JVM-ish approach like GWT, then the easiest way of fiddling with those elements is by manipulating text, and writing your own wrappers as needed.
Apology accepted. I don't troll per se, but sometimes do try to provoke intelligent responses in a slightly ugly way.
And trust me, I'm just as frustrated and confused by people who adore Wicket and say it has a great power/conceptual weight ratio! Especially because I'm concerned it points me to being a curmudgeon before my time, unwilling or unable to learn new things.
The last time I "rolled my own framework", which was just some tools to make "Model Two Plus" (servlets and JSP pairs; esentially MVC w/ lots of Cs) I came up with two things: one was the "FormFieldHolderBean" that made it very easy to populate HTML forms w/o conditional logic in the JSP, much like the ActionForms in Struts that I ran into later. The other concept was, for those multiple Servlets, there should be as LITTLE cut and paste, non-business logic as possible... we really got it down to just 4 or 5 lines per Servlet, by farming repetitive things out to a single superclass or to APIs.
The thing with this approach is, it was VERY easy to know where to look when things went wrong. It was conceptually super light weight, and in general inspecting the URL would bring you to the appropriate servlet or JSP. Compared to the stack traces I've had to sort through in intervening years, I view those days as somewhat of a golden age...
We're finding that while Wicket does let you customize CSS and HTML (but not always easily, yesterday my coworker who's pretty CSS adept couldn't figure out how to stop one of the close to builtin tree controls from having a border) there are still a lot of problems where we have to figure out "ok, the javascript is fairly easy, but what's the Wicket way to do this"? One example was some sortable tagbles w/ selectable rows, preserving the selection across sorts and groupings. We got it, but it seemed less elegant than we would have liked.
I probably do have a text-centric (thanks, Perl) outlook, but even to the extent I see "components", I see them as "DHTML components", and the mapping to Java objects seems forced.
Another problem with all this... Wicket is in desperate need of a few more teaching books and a really good recipe/cookbook.
Screw you, it was a typo.. or rather, a brain-o.
Read my post (I think as kirkjerk) in the apache mailing list. I know setVisibility takes a boolean. I've been using Wicket solidly for 6 weeks.
Yeah, and I might be biased by my years of "Jack of All Trades" homebrew websitery, but yes, I think a web developer SHOULD know CSS, Javascript, and HTML, because most apps are demanding enough that they'll be wading through that stuff anyway.
I also find it easier to import 3rd party javasvript/DHTML widgets when I don't have to sweat wrapping it in Java objects.
Ah, well it might be a thing of terminology... I have no problems with going to outside APIs and libraries for specific bits of functionality, I certainly wouldn't to write PDF or Excel generators at a low level... it's the difference between APIs/libraries vs Toolkits/Frameworks. (We're more talking the most efficient and maintable way to do bread and butter stuff like "make a web application")
The years vs months comparison... I'm not sure I buy it.
Especially because usually you're just using a subset of the functionality, but to do it right, have to "pay" for (in terms of learning complexity) much more than that.
That's one reason I love APIs to the heavy lifting, but having a core of the Lowest Common Denominator of control code. For Java, this was Servlet/JSP pairs.
Yeah.
Sometimes I worry that I come up with my philosophy about languages to suit my personal gripes and history, and that ultimately that limits me as a developer, but...
Anytime you borrow someone else's toolkit that adds some kind of organization/abstraction over an existing technology... well, either you're losing bits of the functionality of the lower level, or what you're learning is about as complex as the lower level.
My strong personal preference is to write your OWN, app-specific organization.
The counter argument comes from people who are heavily OO in their outlook. (more specifically, I think a gap tends emerge between people who cut their teeth on simple CGI-wrapping things, and got used to using a HashMap mentality for most client/server interaction, and people who cut their teeth on apps and applets, for whom the gap between Java code and what's physically displayed onscreen seems weird and in need of being abstracted away.) Anyway, these folks say that, look, the organization I want is OO, writing this kind of Object->screen element->response mapping ls a repetitive task, so I'm willing to buy into someone else's approach to do that work. That's where something like Wicket comes in.
My recent semi-revelation for this kind of tool-kit was this: "text" is amazing. It has been the lifeblood of programming for decades, ever since we could get away from punched cards I guess, despite attempts at cutesy visual languages. It's just so powerful, concise, easy to manipulate, easy to automate that manipulation, and in its own way visual (hence the wars over the one true brace style etc) that it will be around for a long long time. But text is, by the way we use it, rather procedural, and while you can do OO in it, that's a new level. But sacrificing the ability to adjust HTML and CSS and Javascript in TEXT on the alter of Objects just seems like too big of a sacrifice to me.
Of course, taking an anti-OO stance is a heresy (see http://geocities.com/tablizer/oopbad.htm ) and you have to be careful so you don't seem like a crazy nut job who hasn't worked on large scale projects. But my latest take on it is this: "People and Programs are both best defined by what they DO, not what they ARE".
Another way of looking at it: in Java, when stuff goes wrong, what's your stack trace like? There's always that boilerplate JVM/Server engine at the bottom, but if the core of what's at the top ain't your code, your debugging is going to be a lot harder, because your mistake is in how you set up the other guy's objects to do the work, not you doing the work yourself. (Assuming the other guy's stuff is solid.)
I just don't see what Wicket - or possibly any web framework - buys you.
Maybe especially core Wicket, which isn't trying to do much but wrap HTML bits as objects. What really is the benefit of that? Nothing seems simpler and it often seems to be getting in the way-- maybe it's a mental gap problem, but often I end up having to put placeholder HTML in the page, and the set visibility = null. And the Ajax support is so-so.
I mean, I think the fact that the static Wicket homepages often produce session timeout exceptions is pretty damning that it encourages poor web programming.
Yeah?
I did an evaluation of it. I kind of liked it, but in general don't like "lets make a servlet environment pretend its an applet", so I didn't endorse.
Now, after months of using Wicket, I wish I had pimped for it more. Seriously. If you're gonna pretend it's an applet, then REALLY do it like GWT does, fake JVM and all. This Wicket stuff.... ugh. keeping the html view and java in synch for anythign complex is SO IRRITATING.
Seriously, after years of Struts and stuff like Wicket, I don't see any real advantage over "Model 2+" (Servlet/JSP pairs) that I started with in 2001. There is a benefit to simplicity and writing HTML in HTML and writing Javascript in Javascript that over-engineers who are, frankly, a little OO-obsessed just don't get.
Maybe years of Perl CGI has bent my brain but The HTTP Request/Response paradigm just doesn't seem so awful that it needs to be (leaky) abstracted away.
Plus, at this point "Steve Jobs doesn't like buttons", so we'll probably continue to see special touching surface behavior (the mighty mouse lean, 2 fingers on a touchpad, the iPhone pinch) instead of an additional physical button.
There are some positive aspects of that, but I'm always worried were going to wind up like that radio outline in Hitchhiker's Guide, where it went from switches to touchpads to cameras, and now you had to sit very still if you wanted to keep listening to the same station...
Hey big brave anonymous coward...
(sorry I'm just ticked at the "troll" ranking.)
Anyway, I don't know if the Apple 2 finger thing is reliable, but I hate most "touchpad tricks" like scrollable areas and what not, for exactly the reason you give for hating 2 button trackpads. Personally I think physical buttons are easier to differentiate than software one, but hey.
Guess I have something to try out at the Apple store...
bleh. I'm not a big fan of "trackpad tricks" like that... special scroll zones etc. I find them too easy too do accidentally and too difficult to do on purpose.
Though my iPhone is getting me used to the pinch motion.
I still think it became a matter of dumb pride not to have the second button, even when Windows showed the usefulness of context menus, and even when OSX started to have good support for it...
Heheh, where do you hail from, that you're an old school gamer and call NES controllers "remotes"?
A. Diablo II probably is a bit old to be representative of "today's" games, especially because
B. It's mostly just pretty Nethack!
Back in the day, I think people did play SMB for a blend of skill-proving and content... to see what the game would throw at them next, and if they could handle it.
It's a false dichotomy to imply that THE two types of gaming are skill-based and storytelling. I don't think video games are at the leading edge of the either goal: if I wanted to prove my skill, I'd take up bowling or golf or darts, and story-telling wise the medium has its moments, thanks to immersion, but probably ultimately lags movies and books. So I come back to this idea of the one thing video games do the best, which is: novel interactions. Show me some new way of interacting with a system. It doesn't have to be particularly skill-taxing, it just has to be interesting and preferably new. The recent example that sticks in my mind of this is Hulk: Ultimate Destruction, which did a TREMENDOUS job of what being a massive, superpowered, insanely strong, able to clamber over buildings being might feel like. There was also a so-so story, and some challenging bosses, and a gradually unlocked set of powers and abilities.
"Novel Interactions" is an umbrella that covers my old interest in Atari games... this is from an essay I wrote around ten years ago:
So getting back to what you wrote:
For the record, I didn't find single player Starcraft that easy, I could stuck near the end of Episode III. But then again, you claim its a big egoboost and way of getting cash; for every person like that, there must be ten for whom it's a humiliation and investment of time that they'll never get back...
Do they support right clicking yet?
OSX does, what about the hardware?
Well, it was a highly subjective list, but it didn't pretend not to be.
I appreciated the "game design lessons to be drawn from this" section.
I've been a classic gamer for a long, long time, I was posting on r.g.v.c. since like '93 or so...
Here's the thing: games now have distinct content, lots of it, not just one playfield or enemy set speeded up.
(Ideally, this content involves new interactions, i.e. involving programmers as well as designers, not just the artists saying "well, here's a 'new city' to 'explore')
So people want to get the game that they pay for. Me, and maybe it's a personal fault throughout many aspects of my life, I don't like challenge for its own sake. I want to play with novel interactions in as economical a way as possible. (And, oddly, the time a game uses is counted both towards its cost and its benefit)
Most games, especially sandbox ones, will have some rewards for the really dedicated and skilled player, or at least have challenges so such a player can self-motivate and have something to do. And now you even have youtube and specialty sites to show off your 'l33t skillz. Quit griping that big chunks of content aren't being created (and tested) just for you and your dedicated little band...
I couldn't find the Usenet reference, but I remember some old rgvc conversation about how Sinistar cheats: it doesn't compute things offscreen nearly as much as you'd think, so those little gatherers and warriors can freely fly without worrying about hitting asteroids...
still an amazing technological achievement...
I'm not sure which part I find less wholesome, the almost self-parodying use of yelling "USA! USA! USA!" or the idea of importing the local football team and/or frat to act as rhetorical muscle.