Sell me smalltalk
Locked
 
|
Hello All, Im a dev and the Co. I work for is engaged with a research organisation that uses smalltalk for part of its modelling. I have yet to get my hands dirty in smalltalk, but it looks interesting so Im on my way. My question to the group goes something like: if some guy came to you and said "hey build me some cool stuff in smalltalk" what would be any emerging features of the language/technology that you would run with and what would you steer clear of or, is everything just beautiful as it is? Next selfish Q is: do you think that there is longevity as a smalltalk developer in the industry or would you be hedging your bets with other modelling technologies. No offence meant in any way to smalltalk lovers, I'm just trying to get a feel for things. Many thanks Micah You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. Visit this group at http://groups.google.com/group/va-smalltalk. For more options, visit https://groups.google.com/d/optout. |
|
|
Micah,
-- you are not offending anybody, but you expect the wrong thing. Smalltalk is not in the special effects department ;-) Am Mittwoch, 11. Februar 2015 03:46:24 UTC+1 schrieb MicahJ:
You already mention of the areas in which Smalltalk shines: explorative development. This means if you need to write a piece of software for an area in which there is not much knowledge (either globally or just in your team), you have to be able to test hypotheses and modify them easily. Smalltalk is great in this area, because you are working on live objects, can dive into the running system and modify it on the fly at any time. Due to dynamic typing, change doesn't necessarily mean spending half a day making the comiler hapy before you can come back to working on your initial idea.
No. Smalltalk -I'd say each individual implementation - has had its decade of completely missing what's going on in the world around it. So there's a lot to catch up on for each and every Smalltalk vendor/project. Smalltalk on mobile devices - nothing serious around. Eye-opening, revoltionary end-user-GUIs - nope, sorry. Best-in-town NoSQL connectivity - well, err, no (GemStone is an absolute exception here - as an OODBMS it is probably the world-leading product). So if you're looking for the killer feature of Smalltalk, which will enable you to impress people so much that they throw their underwear or project budgets at you, please walk on. There's nothing there for you. If what you are after is the fastest way to build a first version of a new killer web application or the next generation of a mobile application, you are better off looking at alternatives. The the bang you are looking for is not in the Smalltalk world and will probably not be here in the next few years, maybe never. The picture completely changes if you look at the complete life cycle of a project: Smalltalk is unmatched in its openness for change. There are lots of tools and techniques to change a system even down to some of the basic initial design principles while ensuring you don't break everything or completely miss budget and quality goals. Most systems live a lot longer than its creators think. They need to be maintained for a decade and longer. I've worked on systems that had 15 year old code 10 yeras ago and they still run multi-billion businesses every single day, are adopted to new requirements all the time. The tragedy here is that Smalltalk is an excellent implementation technology for phases in the life cycle of a project that most people regard as the boring part - maintenance. But we all know that maintenance is where the cost and risk in a project lies. You can build almost anything and make it work somehow in relatively short time. Some technologies make you even faster and more productive by making compromises (e.g. convention over whatever), and more often than not, these compromises are what make maintenance of a system hard and expensive. Not using Smalltalk is like renting a subsidzed mobile phone from your carrier: you pay a lot more for the phone, but NOT NOW. It is stupid once you take out your calculator and do the math. But who does that if they can have the coolest gear now fur just a few bucks a month?
Asking the queston on this list means you know the answer, right? Smalltalk never hurts on your CV. And you'll learn a lot about good design and coding, even if you won't be the highest paid, sexiest rockstar app-coder on the planet. If you work for the money or for getting the cheerleaders, go JavaScript or Swift or learn a new language every 8 months. You'll never be good in one of them, but know them all ;-) You CV will look more impressive to most recruiters. I guess it also depends on what you are after personally. If you like following the trends and always be on the cool side and if you are fascinated by how cool all those new wheels are being invented all the time, go for it. The easy money is on that side of the market, both as an employee and as a vendor. If it is longevity and reliability you are after, Smalltalk is far from being the wrong choice. HTH Joachim You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. Visit this group at http://groups.google.com/group/va-smalltalk. For more options, visit https://groups.google.com/d/optout. |
Administrator
|
In reply to this post by MicahJ
On Tuesday, February 10, 2015 at 6:46:24 PM UTC-8, MicahJ wrote:
--
Actually, there are a lot of cool things in Smalltalk. The problem is that most companies regard their Smalltalk systems as trade secrets. Recent modern arrivals include YesPlan (http://yesplan.be/en/) and NoRizzk (http://norizzk.com/). Some of the longest lasting applications on the planet were written in the 90s and are still going strong. TI, the semiconductor manufacturer, runs a number of fabrication lines using Smalltalk - they have a 1/2 hour per year downtime. JP Morgan Chase uses Smalltalk to manage risk with their Kapital system, a system that generates substantial profits for them. There are many other stories out there. More important than a Who's Who directory is the economics. Joachim already mentioned time to market. What he didn't mention is that Smalltalk systems tend to require far fewer people to build, maintain, and operate them. It's not quite as low as 1/10th, but when the major cost of systems is the staff to build and maintain them, getting more for less sounds like a pretty good idea, even worth paying a slight wage premium for. Smalltalk was designed for school children to learn, use, and interact. It is worth checking out some of the things those "guinea pigs" did back in the 70s. Good Smalltalk code reads almost like plain English and easily supports implementations that directly reflect the business' terminology. Many other languages keep going back to the Smalltalk well and dipping out new ideas, but never quite understanding the gestalt that makes Smalltalk unlike anything else. There is one major reason to avoid Smalltalk. Once you really understand it, you will never want to work in any other lesser language. That's certainly my experience: 23 years and loving (almost) every minute of it. p.s. I now work for the GemStone/S development team. Now, there's a database! No impedance mismatch, no ORM, no schizoid thinking, just pure objects, everywhere. You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. Visit this group at http://groups.google.com/group/va-smalltalk. For more options, visit https://groups.google.com/d/optout. |
|
|
In reply to this post by jtuchel
Joachim/Richard
-- Thanks for getting back to me and thanks for your considered thoughts.. . that totally outstripped my expectations - I can see the passion in there...Anyhoo, thanks for that, I stand enlightened and I will be taking my next steps... If school kids can do it then what the hell. Thanks again On Wednesday, February 11, 2015 at 8:17:06 PM UTC+13, Joachim Tuchel wrote:
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. Visit this group at http://groups.google.com/group/va-smalltalk. For more options, visit https://groups.google.com/d/optout. |
|
|
Hi Micah,
-- Joachim and Richard have given you very good answers. I would like to add some small detail level stuff that at first glance may not seem very important. In Smalltalk everything is an object, everything, characters numbers blocks of code, everything. In the early days this got Smalltalk a reputation for being slow (running slowly). Back then it was deserved, it isn't any more. People liked objects but didn't like the fact that Smalltalk was slow. So, some people who, IMHO, didn't really understand the full power of everything being an object, started designing languages where most things are objects but not everything. This allowed them to gain some speed but at a greater loss that I think they realized. For example, strings were no-longer arrays of character objects. Block of code were no-longer object and couldn't be passed around as parameters. Others solved the speed problem by improving the VM and not making everything an object until it needed to be. For example, strings are arrays of characters not character objects but if you access a character in a string ('abcdef'' at: 3) you get a character object. I won't go into any more detail on speed improvements but Smalltalk is as fast as any of its derivatives where not everything is an object. Studies have shown that languages where not everything is an object take about twice as much code and twice as long to accomplish the same thing as Smalltalk. You mentioned modeling. Lets say you need to do something with fuzzy logic or some other objects that have math defined for them. With Smalltalk you can define classes that can have instances added to each other and you may want to use the "+" as a message to do that. This is very natural. But in many object languages you can't use "+" and have to use something like "plus:". My last example is blocks of code not being objects. This seems like no big deal. But blocks of code being objects and being able to be passed as parameters in messages makes a lot of code much simpler. Take callbacks, exceptions and what to do when one is thrown. In some other languages, you have to define a whole class just to hold a little code to handle an exception. Well, that's enough of me bragging about Smalltalk. Good luck with whatever you do and if it is to get involved in Smalltalk please come back and ask questions. Also, take a look at Squeak. Lou You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. Visit this group at http://groups.google.com/group/va-smalltalk. For more options, visit https://groups.google.com/d/optout. |
|
Administrator
|
On Friday, February 13, 2015 at 2:44:57 PM UTC-8, Louis LaBrunda wrote:
--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. Visit this group at http://groups.google.com/group/va-smalltalk. For more options, visit https://groups.google.com/d/optout. |
|
|
In reply to this post by MicahJ
Hey Louis
-- Many thanks for the background and context. You mentioned squeak. I had a look at the sites for squeak and also pharo and they look like really active communities. To what sort of extent does industry use open source v commercial implementations such as va-smalltalk ... and maybe why would'nt everyone just run with the open source projects? No offence to va-smalltalk.. Cheers Micah On Wednesday, February 11, 2015 at 3:46:24 PM UTC+13, MicahJ wrote:
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. Visit this group at http://groups.google.com/group/va-smalltalk. For more options, visit https://groups.google.com/d/optout. |
Re: Sell me smalltalk
|
|
Hi Micah,
just imagine this: Your task is to travel from the west coast of America to the east coast of America in a straight as possible line. You are provided with two vehicles to choose from. A battle tank and a hyper modern, just released, electric, super light weight car with air conditioning and internet connection as well as GPS. What would you choose? I would choose the battle tank, because this would make sure I could accomplish the task to cross America in a straight line. The electric car might be a better choice if I would have had to deliver a pizza within L.A. . Do you think the currently available electric cars will still be the same in 10 years from now? Do you think battle tanks will be more or less the same in 10 years from now? An insurance company needs to keep contracts for over 30 years in access,... How old is your oldest email address? Do you use Facebook, Twitter or Slack more then email meanwhile? This is more or less the difference of view points you encounter with Smalltalk. Some parties try to invent the future, others need to support long lasting interests without the hype on their side. Where will VASmalltalk be in 10 years from now? Well this is a question that I'd like to be answered, too ;-D Sebastian On 2015-02-16 12:27 AM, MicahJ wrote:
-- You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. Visit this group at http://groups.google.com/group/va-smalltalk. For more options, visit https://groups.google.com/d/optout. |
|
|
Hi,
-- I must say I immediately had a smile on my face when I read Sebastians comparison between a tank and an e-car. But it is not bad after all. He surely nailed it when he mentioned the longevity and long-term support of commercial Smalltalks. VA ST is quite young on the commercial Smalltalk market, just above 20 years old ;-) When Instantiations took VAST over from IBM, they made two very important decisions: * They'd keep their versions downward compatible to the last IBM version for a while (this still stands true, after 9 years) * They'd provide support in their support contracts for all existing versions of VisualAge and VA Smalltalk, so that even if you don't upgrade to VAST 8.6, you'll still get help from INstantiations for your VisualAge 4.5 code (just an example) This is very important for commercial customers, and has been for a number of our customers as well. Some of them never used newer VAST versions, but still renew their VAST support contracts every year. They had hard times in the days when top management wanted everything reimplemented in Java. These projects, however, had to deliver new features on mini-budgets for ten years or more, before even the top management realized they'd have to ramp up their budgets and teams again, because the rewrite never actually happened or never worked (not always for technical reasons). Support is the keyword here. Pharo and Squeak are communities in which some projects just are reinventions of wheels, because somebody thought "well, wouldn't it be cool if...", and instead of researching available code or concepts just wrote stuff. SOme of these lead to great sub-projects, some were just dropped in favor of something else. This is not bad per se, because that is what evolution is all about. But if you as a user decided to use such a dead-end, you are in trouble and will probably run into even more trouble if a new version of the IDE simply doesn't host the old code well. You will be cut off the innovation until you migrate a potentially big pile of code. With commercial support, decisions will be made more cautious and definitely slower, because the vendor has to guarantuee that their customers can use their code for a number of years. Switching to something new that replaces something old has to be made feasible and as easy as possible, because customers would complain a lot. There have been examples in the Smalltalk world where commercial vendors made exactly this mistake: make a decision, postulate something as the future and after a few years let it drop like a hot potato. Customers were upset, because they had been financing something that never made it into the product, had to live with postponed fixes and extensions of old code, because the vendor said "our now thing will solve this problem anyways", and so on. So commercial Smalltalks move slower, but give you safety. On the other hand, nowadays there are lots of open source projects that get ported from, say, Pharo to VA. There are lots of great stuff coming from the Pharo community especially, and many of them will stay, for sure! One thing that I hope will happen in the near future is that we'll also be able to give code and stuff back into the open source community, not just harvest from it. But that is not so much a technical problem, but a political one in the customer base of commercial Smalltalk implementations... Joachim Am Montag, 16. Februar 2015 10:38:17 UTC+1 schrieb Sebastian Heidbrink:
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. Visit this group at http://groups.google.com/group/va-smalltalk. For more options, visit https://groups.google.com/d/optout. |
|
|
In reply to this post by MicahJ
Hi Micah,
-- On Monday, February 16, 2015 at 3:27:01 AM UTC-5, MicahJ wrote:
Your welcome.
Sebastian and Joachim have answered this question very well. I would add that there is also a question of how you want your end product to "look and feel" and another question of how you want to package it. If you want your GUI program to look like any other Windows program, VA Smalltalk does that, not so much for Squeak. If you want to package a relatively clean and small image, VA Smalltalk has the tools for that, again not so much for Squeak (Although I think Squeak is improving). Now people do use Squeak and Pharo for commercial projects, especially Seaside. Also, if you want to target an Arm device, I don't think there is any way VA Smalltalk would work. So there are good reasons to choose either commercial or open source, you just need to define your needs. I brought up Squeak because there is a lot of fun stuff going on there and they do have an active community (probably larger than ours) and at least as willing to to help as we are. Lou You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. Visit this group at http://groups.google.com/group/va-smalltalk. For more options, visit https://groups.google.com/d/optout. |
«
Return to Instantiations
|
1 view|%1 views
| Free forum by Nabble | Edit this page |