On 21/07/07, Blake <[hidden email]> wrote:
> On Sat, 21 Jul 2007 01:48:11 -0700, sig <[hidden email]> wrote: > > > Even if you done things badly, you must give users a way to easily fix > > that. In most unix-es changing keys layout is just reading a short doc > > and editing a text file. You don't even need to learn any computer > > language to make this. Compare given efforts with those, which windows > > users need for such trivial tasks. > > Apparently, you don't, as Microsoft demonstrates repeatedly. You can do > whatever the hell you want when you have a captive audience. (I'm not > arguing that Windows is a model here, except perhaps in trying to maintain > that captive audience through coercion rather than persuasion. I actually > don't se how Windows is particularly relevant to a discussion on the > merits of third party software except, I guess, that it's crapitude > encourages 3rd party software, right up to the point where MS swallows the > 3rd party.) > > > Simply compare this: > > http://support.microsoft.com/kb/302092 > > and this: > > http://www.linux.com/articles/113715 > > Don't need to. I found a solution in five minutes that didn't involve me > reading at all. Illiteracy (and laziness) will out! Its pretty easy, i know :) I found fast solution, that convenient for me. But its only because of internet. Now turn off your internet connection and try solve a problem with what you have onboard. Actually i wanted to point that its not about how fast you can find solution, its about how well a product, that installed on your PC can be configured(fixed) to satisfy your demands, without involving 3rd party tools, which often costs money. > > > Yes, i agree with what you say, but just tell me, how many topics you > > seen like 'my Win-XP-like controls, for <...>', is this a good way to > > bring something new and shiny to society, but don't leave others a way > > how to reuse it, and forcing those numerous 'XP-like' controls suites > > appear for different languages/dev tools which targeted to run on > > windows XP anyways. > > Actually, both those links include source code with purchase, at least > optionally. > > And it has nothing to do with being "XP-like". The simple fact is, those > components encapsulate a whole lot of technology that I don't have to > program if I use Delphi, that I =do= have to program if I want to use > Squeak. > > The breadth (and occasionally, the depth) of Squeak's third party support > is astounding, frankly. It says a lot about the joy of working with it. > > But grids and graphs aren't going anywhere. They're easy to understand and > use. And the two companies I pointed out are just two of =dozens= that > supply those sorts of things for the relatively minor development > environment that is Delphi. And Delphi comes with both grids AND graphs > =free=. > > It's all very well to be disdainful of people trying to make a living in > niche markets, but that don't put the budget graph in front of the CFO. > forward, make themselves busy by re-engineering things which is already exist, or making a temporary and useless stuff like 'my XP-button'. I see nothing bad to do things like this in real world, but in computer industry this looks like a stagnation to me. I used Delphi myself to develop couple of projects, components e.t.c.. used it from v 1.0 till 2000. And i know very well what efforts required to create such rich set of components. And i'm regret, that after so many years we at the same point where was: reinventing the wheel again and again, everyone busy creating things which was done 1000 times before by others, including current situation with squeak. > Anyway, I think we've gotten way afield here. > _______________________________________________ > Seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Richard Eng
Hi, you need to learn the language before you can truly start to learn a framework. Many people hear the buzz about new technology like Seaside and try to learn it without the necessary requirement of having learned Smalltalk and OOD. Thus, I would invest some time in learning the language first and the framework second. My suggestion isn't directed at you but most of the new Seaside developers coming from languages other than Smalltalk.
Good luck to ALL, -Conrad
On 7/18/07, Richard Eng
<[hidden email]> wrote: I'm not sure I agree with this. I'm a Seaside newbie, but I'm also a *web _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by cbeler
On 7/20/07, Cédrick Béler <[hidden email]> wrote:
You're missing the point entirely of Smalltalk with your example of producing a crappy solution in PHP. If I can write couple lines of code in Smalltalk to implement a feature or a bug fix, this allows me to spend less time doing maintenance activities and more time designing new features for the system. I have done the PHP and it's a maintenance nightmare sometimes to locate bugs and/or add new features to an existing system due to poorly implemented code. I would rather spend 2 hours of writing 2 well crafted lines of code than to write many more lines of code that isn't. I have been on projects where the code base got to a point where it wasn't maintainable after adding both bug fixes and features. Thus, the companies solution to the problem was to redesign the entire system from scratch.
Finding the reward is hard in smalltalk, but I think I've reach the The fun in Smalltalk is being able to implement well designed solutions. BTW, I also do Ruby development for some of my clients and that community is agreement with Smalltalk (
i.e. implementing small methods that's focused on a single objective). Also, there are a few blogs dedicated to design and code re-factoring. What's fun in other languages are the results you get, and in smalltalk I agree with you here 100% here with the addition that one needs to obtain understanding of both the Smalltalk language and OOD. Cédrick _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Jason Johnson-3
Hi Jason,
> -----Original Message----- > From: Jason Johnson [mailto:[hidden email]] > > I understand what you're saying, but I don't see this as a cut-n-dry > "well, we should have stuck with Java" thing. If the technology was > good, why didn't any of the other developers jump on board with their > projects? I don't believe every developer should be able to use a new > language for every project. But I do think those that stop changing > have started dying. :) Just to be clear, we only did some Java work. We did J2EE with a Flash front end, but most of our core applications were in Smalltalk. There was a big benefit of having all of our developers competent to work on all aspects development; we were definitely a Smalltalk shop. The point was that we had to fight to continue using Smalltalk in the face of public company audits and we were considered high risk because of it. For the Java group we hired new people, which looking back was a mistake. The Java group had a lot of trouble because the Smalltalk group was already very comfortable and understood the business domain thoroughly. We would have been better off training everyone to do Java and letting a core group take a crack at something new. I suppose overall I'm ok with change, (I'm learning Python now) but I think that change needs to be well considered within a company. Carefully integrating new technologies and spreading the learning opportunities widely will help long term when applications need to be supported. I also agree with you that any good technology will get used by a number of people and in a number of projects. If the technology has limited scope, in projects or developers and the project could be accomplished using existing tools, it's better to use what you have and know already. Smalltalk has benefits, in development, prototyping, and support that outweigh the risks of limited number of available developers. In my opinion I'd rather have a team of Smalltalk Developers building a Java, Rails, Python, C++, SAP or what ever kind of app is needed. A good group of Smalltalk developers can accomplish anything. Still it's a good idea to commit to the resources needed to add new technology and to do it wisely. A one off app in a new language for one person is a bad idea. Ron Teitelbaum _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Free forum by Nabble | Edit this page |