6 ms·

Smalltalk a good option?

• henning 18y ago
  What turns people off about Smalltalk is it doesn't talk to the rest of the world the way you're used to so it takes getting used to. You're certainly not going to have much luck using Smalltalk for prototyping novel image processing algorithms.
  • jrockway 18y ago
    Sorry about that, I accidentally downmodded you. I guess there is no undo here. (I modded up some of your other comments to make up for the karma loss. But it sucks that I can't just undo it :( )
    • Jesin 18y ago
      Yes, really. Undo probably wouldn't be too hard to implement (this already keeps track of who has voted on what), and it would be a helpful feature. Why can't we undo upmods/downmods?
    • icey 18y ago
      I added a "free" upmod (i.e. one I wouldn't have otherwise given) just to undo your mistaken downvote jrockway.
      • Jesin 18y ago
        Ahh, but what if you're not the first person to do that? Be careful about overcompensation.
        • jrockway 18y ago
          Until we can cash in our karma for fame, fortune, and hot babes... I doubt we need to worry about overcompensating :)
  • pc 18y ago
    It doesn't talk to the rest of the world the way you're used to. Well, it can now -- we ported Thrift to Smalltalk for Auctomatic, so that we can easily interoperate with code written in other languages.
    • zemariamm 18y ago
      sweet!
  • avibryant 18y ago
    There are image processing algorithms and then there are image processing algorithms, but: we do some very simple image processing in Dabble DB and were surprised by how much library support Squeak had for it. http://blog.dabbledb.com/2007/04/white--or-green.html http://blog.dabbledb.com/2007/04/white--or-green.html
    • zemariamm 18y ago
      Pretty neat! Actually image processing was just an example. I just don't want to be caught inside a system were I'll have to spend a lot of time implementing stuff already granted for free in other frameworks (I'm short in time :D ).
• jrockway 18y ago
  FWIW, I think Seaside with Magritte is The Way (tm) to do web apps. But you're not going to find many libraries with Smalltalk. My recommendation is to just port those to another language, then use that :) I'm currently working on a port of Magritte to Perl called Ernst, and a new web framework called Kiiteh. Both are very in-progress right now, so I don't recommend even imagining that they exist. In a few months, though, that will be the One True Way. Decent language, phenomenal library support, and a nice way of easily writing web apps. :)
  • systems 18y ago
    hey, you are that dude who wrote the catalyst book (http://www.packtpub.com/catalyst-perl-web-application/book http://www.packtpub.com/catalyst-perl-web-application/book) Nice to see you're into hacker news, anyway. I would like to recommend Groovy and Grails, the main advantage of these over Perl/Catalyst for me was portability, Groovy/Grails or GG just work better on windows and SQL Server 2005. They were way easier to install, run and getting started with. For example with Perl/Catalyst, Perl doesn't have a DBD::MSSql, I think one can use JDBC or DBD::JDBC, but JDBC is at version 0.1 and DBD::JDBC is also old DBD::Sybase, is well Sybase! DB support of GG via hibernate is just way more robust. Java have many many more active projects which GG relies on and can depend on. Perl's CPAN is for sure fantastic, but CPAN is just not as portable as Java's project, so with GG you know, and I know, that it will run on windows, with Perl, there is no guaranty Finally the moral is, with open source, you really have to consider a project popularity. Project that are too centralized, that do not rely on other popular project are doomed to get in your way! Catalyst relies on CPAN modules, this alone, assure me it is a better option than RoR, because a lot more people are working on the different pieces idependently, the work is better distributed, DBD::JDBC is usefull for a lot more project, not only Catalyst, this suggest it will better survive and evolve, RoR is full stack, so do evolve it will add a lot more work for its developer, and its open source, so no guaranty you will find one to do the work! GG situation is even better than catalyst, it relies on an even more popular and solid foundation. New Open Source Poject should always trie to introduce the least amount of new code! I do believe that the future for Ruby, Tcl, Python and Perl should be on either Parrot or the JVM this will make it easier for new project to rely on other people's work, will improve portability etc ... I will not drop Perl/Catalyst from my knowledge efforts, I very strongly believe in the Perl community, and that the current problems will be solved in ways that will even push Perl beyond Java Hope i was clear
• musiciangames 18y ago
  Qwaq, which recently raised $7M, is also Squeak/Smalltalk/Croquet: http://qwaq.com/company/press_releases/pr-2007_11_27.php http://qwaq.com/company/press_releases/pr-2007_11_27.php Qwaq has put a lot of its developments back into Croquet. A few more ventures using Squeak could cause the (already high) productivity of the environment to take off.
• giles_bowkett 18y ago
  I can't find it in Gmail, but IIRC one of the Auctomatic guys told me they were on Seaside, and they didn't understand why the whole world wasn't on Seaside too. I would be working in Seaside if I had more time, but there's the huge Rails job market, the fact that I've been working with Rails a bunch, and the fundamental fish-out-of-water feeling of being without my Unix security blanket. I'm going to the OSCON tutorial on Seaside soon, though, and Steven Baker told me he has a cool Seaside app to show off at RailsConf. In addition to programming I devote serious amounts of time to acting and music. If programming were my only thing, I would be working in Seaside. I really enjoy Ruby immensely, but Seaside's very impressive. It even makes everything else look a little silly.