My company is planning to build a simulation tool for processing (beverage) and we're currently looking at a half-baked system written in Xojo. I had personally never heard of this language and would appreciate it if anyone could give a quick assessment.
We have no in-house Xojo competence at all and are of course reluctant to bring in a system that would require a big investment in know-how for just one system.
So, we're now looking at our options: Port it to a language we're good at (C# or Java) or continue development in Xojo while building internal skills for the language.
So, what are the big pro's and con's with Xojo?
Cheers
Xojo has been around since the late 1990s, then named RealBasic. Its strength lies in its ability to make native looking and behaving apps for many platforms, mainly OS X but also Win and even Linux. The dev community is fairly small, though. But the company managed to stay in business all this time and isn't looking to end it any time soon.
The language is fairly simple and easy to learn, using long known concepts (its design was based on Visual Basic).
Knowing Java, it should be easy to grasp the language. The bigger hurdle is probably getting familiar with its libary. Many things are much simpler to accomplish in Xojo vs Java, though.
Call me lazy, but that's what I like about Xojo. I also program ObjC in Xcode, but for those little tools that just need to work quickly, Xojo is superior for whipping out a program quickly that that has a decent UI and works on many platforms with little to no tweaks.
If you need x-platform support, give it a try, for sure. If you only need the app to run on a single platform, and if you have skills with other dev systems, I'd advise against starting out with Xojo, to avoid the risks you get when going with such a small company that's offering closed-source software.
In your particular case where you have already a half-working solution, I suggest you take a few days to familiarize yourself to get a feeling for it (you can use Xojo for free as long as you don't build standalone apps with it). It's overall fairly stable and I'm still using a 3-year old version most of the time to develop and build my apps. So, even if Xojo should go out of business suddenly, I'd not be too worried. As long as you stick with the simple functionality (e.g. not use unique features such as XojoScript), you can still convert the app to another language later, but there's also a fair chance you never have to.
If you are looking for someone to take a look at your Xojo project I'd recommend posting on the Xojo Find A Developer page at http://www.xojo.com/support/consultants.php where all Pro developers get it. The consultants that want to talk to you about it will then contact you. (Full disclosure: we, BKeeney Software, are on the list and would be happy to help you figure it all out).
I have wonder that many big applications (e.g. social websites such as facebook) are build with many languages into its platform.
They usually start with AJAX browser support, then scale down to PHP scripting, then move towards a powrful OOP technologie such as Java or .NET, and finally a primitive language to increase performance in crucial operations such as C.
My question is how should I determinate the edge of the layers between languages. When PHP, when Java, when C and so on. And the other question is if should those languages integrate in a vertcal fashion for simplicity and maintanance, or could it be cases when you decide to program on module of your app in Java and the other in native C.
What are the context variables that push me to move to a better performance language? (e.g. concurrency issues due increase of users)
Don't tell me that PHP overlaps .NET and Java Technologies. In a starter point it does, but when the network is overload you start seeing the diferences. I mean how can I achieve Multithreading in PHP as in Java with the same performance. The thing it's hard to answer my wuestion is becasue there is not so much reading about this. You maybe find some good books covering PHP, but few telling how when and why integrate different languages.
Each language was created for different purposes, Python is strong with string operations, Perl very powerful in batch scripting, PHP a very reliable application web server, C the mother of most popular languages.
Best,
Demian.
On one end of the scale, you move to a higher performance language whenever your profiling and measurements tell you that you have a bottleneck that can't be fixed with better algorithms, data structures, or other optimisation.
At the other end, you move to a higher level language (ie. more abstraction, better libraries) whenever your management allow you to do so. ;)
I believe most teams simply use what they are best familiar with.
There are also questions of licensing that can influence the decision.
That is, if you're talking about technologies that compare to each other and solve the problem on the same level (for example ASP.NET/JSF/JSP/PHP...). But you can't compare .NET with C++ for example, they are meant to solve different problems on different abstraction levels.
My criterion for any programming language is "does it help me to get the job done or does it just get in the way?" If the latter, then it's time to move on.
From an economical point of view the answer is easy: on a regular basis just look what will be cheaper. Either continue with the current technology and maybe stretch the envelope a bit more. Or switch to something new. When you compare the two alternatives the cost of the investment already done is not important anymore since you've already spent that money/effort. You only have to look ahead: cost of licenses, education, etc.
Of course this is easier said then done, but just sitting down with a few people, thinking about it, and maybe try to come up with some numbers already helps a lot. I have seen too many projects that continued with technology that really wasn't suited for the job anymore.
Also hard numbers don't tell the whole story. There will be resistance because of unfamiliar technology, experts who are losing their status, etc.
Identify the bottleneck
Solve bottleneck
Go to 1
I'm sure you can imagine that step 2 is the one where decisions like "What programming language do we use" and "where do we put the coffee machine" come into play. That's the basic rule.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
My questions is simple!
Would you start learning Smalltalk if you had the time? Why? Why not?
Do you already know Smalltalk? Why would you recommend Smalltalk? Why not?
Personally I'm a Ruby on Rails programmer and I really like it. However, I'm thinking about Smalltalk because I read various blogs and some people are calling Ruby something like "Smalltalk Light". The second reason why I'm interested in Smalltalk is Seaside.
Maybe someone has made the same transition before?
EDIT: Actually, what got me most excited about Smalltalk/Seaside is the following Episode of WebDevRadio: Episode 52: Randal Schwartz on Seaside (among other things)
If you like Ruby you'll probably like Smalltalk. IIRC Seaside has been ported to the Gemstone VM, which is part of their Gemstone/S OODBMS. This has much better thread support than Ruby, so it is a better back-end for a high-volume system. This might be a good reason to take a close look at it.
Reasons to learn Smalltalk:
It's a really, really nice programming environment. Once you've got your head around it (it tends to be a bit of a culture shock for people used to C++ or Java) you'll find it to be a really good environment to work in. Even a really crappy smalltalk like the Old Digitalk ones I used is a remarkably pleasant system to use. Many of the old XP and O-O guru types like Kent Beck and Martin Fowler cut their teeth on Smalltalk back in the day and can occasionally be heard yearning for the good old days in public (Thanks to Frank Shearer for the citation, +1) - Agile development originated on this platform.
It's one of the most productive development platforms in history.
Several mature implementations exist and there's a surprisingly large code base out there. At one point it got quite trendy in financial market circles where developer productivity and time-to-market is quite a big deal. Up until the mid 1990s it was more or less the only game in town (With the possible exception of LISP) if you wanted a commercially supported high-level language that was suitable for application development.
Deployment is easy - just drop the image file in the appropriate directory.
Not really a reason, but the Gang of Four Book uses Smalltalk for quite a few of their examples.
Reasons not to learn Smalltalk:
It's something of a niche market. You may have trouble finding work. However if you are producing some sort of .com application where you own the servers this might not be an issue.
It's viewed as a legacy system by many. There is relatively little new development on the platform (although Seaside seems to be driving a bit of a renaissance).
It tends not to play nicely with traditional source control systems (at least as of the early-mid 90's when I used it). This may or may not still be the case.
It is somewhat insular and likes to play by itself. Python or Ruby are built for integration from the ground up and tend to be more promiscuous and thus easier to integrate with 3rd party software. However, various other more mainstream systems suffer from this type of insularity to a greater or lesser degree and that doesn't seem to impede their usage much.
Well, since you mentioned me by name, I feel I should chime in.
As I said in that podcast interview, and as I have repeatedly demonstrated in my blog at http://MethodsAndMessages.vox.com/, this is "the year of smalltalk". And having now done Smalltalk advocacy for the past ten months, I can see that it really is happening. More customers are turning to Smalltalk and Seaside, and the Smalltalk vendors are all working hard to capture this new influx of attention. More larger Smalltalk conferences are being planned. More job postings are being posted. More blog postings are being made.
If you turn to Smalltalk today, you are not alone. There are many others who are out there as well.
Edit
Well, a number of years later, I'm now recommending Dart instead. It's a great language originated by Google but now owned by an ECMA committee. It runs serverside in node.js style, but also clientside in modern browsers by transpiling to JavaScript. Lots of good books, blogs, help channels, IDE support, public live pastebin. I think it's definitely got legs... enough so that I'm writing courseware to teach it onsite or online, and I'm pretty sure there's a book or two in the works from me. And Gilad Bracha, an old-time Smalltalker is a major contributor to the design, so there's a lot of Smalltalk in Dart.
Smalltalk is a good language to learn, and the great thing is that it only takes a day to do it. It's a lot more than just an academic language. People are building huge, scalable, replicable applications handling billions of dollars. They just don't talk about it much. See, for instance, GemStone and Orient Overseas Container Lines:
A Shipping Industry Case Study.
Seaside is a good reason to learn Smalltalk, but I don't think you'll find it orders of magnitude better than Rails.
The thing that convinced me was GemStone. I really like Gemstone's GLASS (GemStone, Linux, Apache, Smalltalk, Seaside). The killer part of that is GemStone, which handles all the object persistence for you mostly without you thinking about it. Seeing some of their demos and hearing about what people are doing with GemStone reset my idea of what "big application" meant.
The part that bugs me the most about Rails is the object-relational mapping. That's nothing against Ruby because it sucks just as hard in GLORP (which handles ActiveRecord for Smalltalk), or Perl, or anything else. Mapping objects to database tables is just painful. With GemStone, thinking about the database disappears, so the work with the database disappears too. It's like a huge stone (or a troop of monkeys) is taken off my back.
> couldn't find a Smalltalk development environment that didn't cost both arms and a leg
Google - free smalltalk
Cincom Smalltalk, Squeak, GNU Smalltalk
Learning Smalltalk will give you a grounding in object oriented software development from the perspective of the man who invented OO (Alan Kay). The idea of a overlapping windowing environment came from Smalltalk.
A stumbling block to learning Smalltalk is that it is a message passing system with a strange syntax for flow control like:
i < 60
ifTrue: [ self walk ]
It has a very mature class library that has a consistency I've not seen too many places. The class library in all environments (even commercial Smalltalks) has available source which allows you to learn from the masters of the language. When programming Smalltalk, I always ask the question how is it done in the environment.
Smalltalk is generally implemented in an image which is a live environment for all the objects in your system.
The interactive debugger really seperates Smalltalk from Ruby.
Seaside is the web development framework and has given Smalltalk a new spotlight. It is a continuation based environment that allows for intra-hit debugging and a smooth Rich Client type development experience (top application flow can be designed in a single method). It's integration with script.aculo.us has been done in such a way that it is easily called from within Smalltalk.
Nigel, one quote I have is this:
Although it's now a long time since I did anything with it, I nominate Smalltalk, I still haven't come across anything quite like it for being able to transfer thoughts into computer code. It's not just the language: It's the wonderful browser environment, the libraries, and the culture of writing clear, well-designed code as quickly as anything else can crank out spaghetti. When the participants at JavaOne were extolling how Java was so much more productive than anything else, I needed a brown paper bag. Oh well, back to sorting out my classpaths... -- Martin Fowler (Software Development Magazine, Jan 2001)
I found it here.
Would disagree with the poster who reckons you wouldn’t use Smalltalk for large apps – that’s precisely where it shines. But I have created fairly groovy (note lowercase) prototype apps in under a week too.
I learned OO in ST starting in 92, incredibly glad I did so. It gave me a real background in OO. Thinking in classes. No types. ST has a real emphasis on messaging. If you want to know something send an object a message and get an answer. IMHO, the ethos and the IDE really encourage you to do the right thing with your coupling and cohesion.
In my Java day job, I’m stuck with files, generics, IDE’s like eclipse that are orders of magnitude less productive that any ST IDE. I was using ST the only time I finished a development ahead of schedule. In fact it was so productive, and we got so much reuse I had to be moved off to another project, as I had nothing to do! (Ok, maybe I could have spent time learning to estimate...)
Download squeak, find a good book and play. Only downside is that if your day gig is using Java or C#, you’ll end up wishing you could use ST. You’d get home sooner.
Chris Brooks
I recommend everybody to learn Lisp (Scheme) or Smalltalk.
Smalltalks have wonderful IDEs which you dont want to miss once you got over the culture shock. And yes, there are more than one free ones: Squeak, Dolphin, Smalltalk/X, and Visualworks (Non-Comercial).
Lisp may be even cleaner in its mathematic foundation, though.
regards
PS: actually I recommend learning both !
I do not know Ruby..
Smalltalk is a pure OO language. If you feel the need to really understand OO, and not just the simulated OO of most popular 'OO' languages (like C++, Java, etc), then I would recommend that you play with smalltalk.
In smalltalk everything is an object, with attributes, behavior and meta. In the simulations you have data types that you use in your objects.
I would say play with it, you will only benefit.
I'm totally in your shoes. Im using RoR and looking into Smalltalk land. Here's some pros & cons I find important:
Pros:
Mature & stable environment
Fast development cycle
Makes you think more and write less
Cons:
Requires different thinking
Still didn't quite grasp it
It's quite funny how I got to know about Smalltalk. It was this one thing that keept popping up in Google results when searching for Lisp and Erlang stuff. One day I checked it out and was amazed with nice windows environment. Few moments later I've found Aida/Web framework. I was hooked and started learning Smalltalk through web development with this framework.
Still not quite there, but it's so damn interesting I just can't sit still... :-) I'm having fun again.
Would not start learning it if I had the time. Why not? Because it would be more productive and lucrative financially to learn C# or Java.
On the other hand if your a hobbyist, and would like to go on an archeological dig, then I'd suggest spending some time looking at the What, When, Why and how of smalltalk by researching Alan Kay. Fascinating story and an incredible person (after all, he earned the Turning Award). Then maybe play with squeak a little to get a feeling for the language. After this you might have a newly found respect/understanding of blocks, closures, and Object Oriented principles.
I know and use Smalltalk, have for about 15 years, still maintaining it, and would not recommend Smalltalk to a friend. Why not? Employment is a good thing to have and keep getting. Although you can learn a lot from Smalltalk you can't easily turn that into gainfully being employed in this day and age.
Also, you appeared to be excited over Seaside and I would assume the Seaside/GemStone partnership. I've used GemStone for quite some time and the two together are very appealing. I hope they can get the market share and momentum required to be successful.
Don't! If you really start learning it, you might not want to programm in something else anymore ever.
This may be not true, if you are a lisp programmer.
Absolutely, learn Smalltalk! This is 2015 and Smalltalk is on the rise again, thanks to Pharo. Pharo is FREE. Pharo is evolving quickly into a powerful enterprise tool. At Version 4.0, and soon to be 5.0, it has matured a great deal in just four years!
Then there's Amber, which is Smalltalk for the web. It's also FREE and evolving quickly.
Despite Smalltalk's reputation, this is not your father's Smalltalk. Modern Smalltalk is exciting and promising.
It's true that Smalltalk jobs are not (yet) plentiful. But if enough of you aggregate to a new wave of Smalltalkers, then the industry will adapt to it and we'll see wider adoption of Smalltalk in business. The question is, do you have the vision?
I was taught Smalltalk in one of the first graduate college level Object-Orient Programming courses (circa 1988). The teacher thought it best to start was a "pure" OO langauge,before moving on to a more trendy one (we did a bit of C++ at the end of the semester).
By that measure, it's still best to start with pure OO, although these days we have Java & C#, both of which are "nearly-pure" OO -- close enough that you can get by ignoring the non-OO features of them, and limiting yourself to the Pure-OO subset of the langauges.
If you want a better understanding of Extreme Programming (and even Scrum) I'd say yes.
Why impatient Java programmers need to learn Smalltalk:
http://www.dafydd.net/archive/2010/why-smalltalk-isnt-just-another-language/
I've been a software engineer for quite a few years now. I've heard people bring up Smalltalk a few times, and certainly Smalltalk has been around since about 1980, but it's one of those languages that's never seemed to make it into the software mainstream. Sort of like Objective C, CLIPS, PL/I, etc--something you may have heard of, but something that most folks have never programmed in.
I probably wouldn't take the time to learn Smalltalk unless I needed to for a particular job. I looked at some Smalltalk tutorials and examples briefly a few years back, and it looks like it has some clear advantages for certain aspects of OO programming (like the message concept seems cool). But sadly, it is not mainstream, and doesn't seem to be gaining much momentum.
This thread has become very actual for me. I'm planning for a Software migration to a web-application. It's a database based software. I'm especially checking the alternatives
1) Rails
2) Seaside
If I can get the figures for the Gemstone/S as Database, I'll consider that also. So for me it means I have to learn Smalltalk (better) than before. Because it could be that it will be my work for the next 15 years. You would (and should not) work with software you don't like for that long ;-). I've the impression Gemstone/S is one of the "killer" applications. But persistence of Objects still is a very difficult field....
1) Yes! It's always good to learn a language. If you are going to learn a language, make it a powerful, influential language that can be learnt easily and quickly.
Smalltalk remains a pre-eminent language and environment for learning OO concepts.
It is all objects, all the way down. This makes for a really consistent approach to working.
Integers are instances of Class Integer. Strings are a collection of character objects. Classes are singleton instance objects for the class they define.
Control structures work by sending get messages to instances of Class Boolean.
Even anonymous methods (blocks of code, aka blocks) are objects.
Everything is done by sending a message to an object. The syntax can be fitted on a postcard.
The clarity of the concepts and their implementation in Smalltalk mean that you can develop ways of thought which transfer directly into Java, Ruby and C#. I expect it's true for Python, too.
It's so good for making the concepts clear that a major UK University used Smalltalk to train 5,000 people a year in object-oriented computing.
Squeak 5, has just been released. It has gained major performance increases from its new Cog/Spur VM, which features with progressive garbage-collection.
Pharo 4 has a lovely clean-looking desktop theme. The next version, Pharo 5, will be released soon. It will move to using the Cog/Spur VM, it will have about 5,000 classes in the release, and additional packages of classes are readily available from the net via the Configuration Browser tool.
Squeak 5 is performant even on first-gen Raspberry Pis, and is almost 50% faster on the new $5 Raspberry Pi zero. $99 buys you a Raspberry Pi 2, screen and case - running a mature, fully feature-complete IDE.
Leading edge research is being done on co-ordinated, distributed OO systems in Smalltalk (e.g. Naiad and Spoon).
Some of the world's largest corporate databases are run on Smalltalk - including tracking of 60% of the world's shipping containers, and trading systems in the world's largest bank.
You can use Smalltalk as a sort of super-powered CoffeeScript, writing in Amber Smalltalk and transpiling to JavaScript, running in the browser.
Squeak, Pharo, and Amber are all Free, Open-source, open-licenced languages and environments.
Squeak and Pharo provide write-once, run anywhere facilities for MacOS, Windows and Linux. (Possibly RiscOS, too).
Dolphin Smalltalk is targetted firmly at native Windows look-and-feel, and lets you compile closed .exes of your finished work for distribution to end users. Further development of Dolphin by the vendor has stopped, but it is completely functional, and, like all Smalltalks, designed to be massively extensible. (Did I mention that Pharo now has 5,000 classes, compared to Squeak's 3,000? Pharo is a fork of Squeak 3.9)
**There is a How-to guide for installing and starting Squeak, Amber, Pharo, Cuis and Dolphin at: **
http://beginningtosmalltalk.blogspot.co.uk/2015/11/how-to-get-smalltalk-up-and-running.html
The Seaside web framework runs on Squeak and on Pharo. It's a wonderful mature tool, as is the more traditional AidaWeb framework.
VisualAge, VisualWorks and Gemstone all provide enterprise-grade robust systems. Gemstone provides an infinitely scalable object database with transactions and persistence.
2) Yes - I do already use it.
I learnt it via the Open University, and was immediately productive in Ruby (a copy of the Pickaxe book and the library reference by my side). It helped me enormously with Java, and with Xerox Moo-code.
I have just returned to it to write apps to control manage and distribute responsive, massively multi-platform mobile apps.
I expect that soon I'll be re-writing my JavaScript mobile apps using Amber, too.
I don't really know what you're looking for.
If you are looking for a different language to write in, I'd think that would depend heavily on the libraries available. I know neither Ruby nor Smalltalk, but it seems likely that the most efficient way to write Ruby on Rails-sorts of applications may not be Smalltalk.
If you are looking to learn the ideas behind Ruby, this might be a very good move. I don't have anything quantitative, but I always felt better about using tools (such as language systems) if I knew more than just the tools, if I kmew the ideas behind them or how they worked.
If you want to learn different sorts of object-oriented languages, you might well want to learn Smalltalk (if it differs significantly from Ruby), something like Java or C++, and perhaps also the Common Lisp Object System.
If you just want to learn something different, Smalltalk may well be a good choice. I'd also suggest Common Lisp, and other people will doubtless have other suggestions (can you get a good Forth system nowadays?).
Yes, I'm interested in it. Tried to start once already, but couldn't find a Smalltalk development environment that didn't cost both arms and a leg.
Is it in best interests of the software development industry for one framework, browser or language to win the war and become the de facto standard? On one side it takes away the challenges of cross platform, but it opens it up for a single point of failure. Would it also result in a stagnation of innovation, or would it allow the industry to focus on more important things (whatever those might be).
Defacto standards are bad because they are usually controlled by a single party. What is best for the industry is for there to be a foundation of open standards on top of which everyone can compete.
The web is a perfect example. When IE won the browser war, it stagnated for years, and is only just now starting to improve because it's hemorrhaging marketshare. The Netscape years prior to that weren't much better. The CSS 2.1 standard was released ten years ago and still isn't supported well. As a consequence, web development is a Black Art of hacks and work-arounds to get websites to render consistently.
My job would be a hundred times easier if I could build a website according to web standards and be confident it would display correctly. Just think of all the cool things we could have been working on instead of fixing IE's rendering errors.
I believe whenever there is only 1 option, it will definitely stagnate innovation. If all we had was 1 language, then we wouldn't be able to solve anything but what that language was designed to solve.
Imperative languages like Java and C# solve a certain set of problems pretty well, but it also helps to think in a functional manner sometimes, such as with Haskell and Lisp.
Furthermore, cross platform issues are not an issue if you are talking about a web application, because you control the hardware and software (note, I am talking of the server side code of course, the browser cross platform issue is separate).
Paul Graham wrote a great essay on how the Web lets you as a developer use the tool you think will solve the problem best.
No. Competition is good. It may make a web developers job easier, but I think it's bad for the industry. I personally prefer having choices.
I believe Joel Spolsky's technique of creating his own language (Wasabi) to insulate his company from being platform specific is a good one. I also believe it is a good idea to use products that accomplish similar things that are more targeted at specific problems like JQuery.
I'm gonna have to agree with Mike on this one and say that without competition there is very little incentive to innovate.