The Prototyping nature of Smalltalk as the strength of Amber
Locked
 
|
Time and time again the Smalltalk tools and methods have benefited the software developer. Pharo and the modernizing efforts to build a Smalltalk for the 21 century is a great effort to keep Smalltalk fresh, Amber is a similar effort for Smalltalk to the web browser and web apps. The use of Smalltalk is obvious to the small group of programmers that deal poorly specified problems where we us the generic Smalltalk classes to prototype a solution and refine the specification in an iterative fashion
"A Oral History of Adele Goldberg" https://www.youtube.com/watch?v=IGNiH85PLVg
From Wikipedia: https://en.wikipedia.org/wiki/Adele_Goldberg_%28computer_scientist%29 - Goldberg began working at PARC in 1973 as a laboratory and research assistant, and eventually became manager of the System Concepts Laboratory where she, Alan Kay, and others developed Smalltalk-80...
After considering Goldberg's remarks about the use of Smalltalk by the CIA (Analysis of Photos) and Chrysler (Payroll) I conclude Smalltalk is good for prototyping software and modeling complex systems. I would often choose Smalltalk to model complex important tasks where getting the model exactly right was the important job. It is the ability to prototype and model these kinds of difficult tasks where Smalltalk is the most useful. This type of work and tasks will never really go away this is the core places where Smalltalk shines.
It is not just the tool (or language) but the use of that tool that matters. The Use Cases for Smalltalk are for solving of complex problems. Once a solution is found Smalltalk can be re factored or a specification can be written for the implementation in another language. The importance is not the popularity of the language in the wider programming world but it's applicability and useability is the difficult area of prototyping solutions.
We should focus on the useful problem solving, prototyping nature of Smalltalk as the strength of Amber.
You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
Re: The Prototyping nature of Smalltalk as the strength of Amber
|
Hi Tom, all you said is correct. Actually I’m trying to do something about exactly that. Anyway.. I’m not sure if you are familiar with the Lean Startup method (which roughly is the Toyota production methods applied to know-how based products). In that method there is a word for what you mention: validation Yes Smalltalk can be very successful in searching and potentially anticipating business/product validation. And yet… That depends on productivity. As long as the Smalltalk productivity is higher (or better... way higher) than other technologies, the competitive advantage in this crucial area is real, making your point stronger. At the same time, if the productivity goes down, then the value of using Smalltalk dilutes. Even completely dilutes. Conclusion? If we screw up the UI and UX bad enough (actually as we are doing it* since years), it will start to make more sense to use just JavaScript for the exact same purpose of rapid business validation. We are in no lack of interesting JavaScript frameworks with great productivity. *Dolphin Smalltalk is the only exception I make about Smalltalk UI/UX. The Dolphin’s IDE user experience and hence the productivity you achieve with it remains largely unbeatable. What are some of our current UX problems? An overwhelming multitude. Detecting what are the most important ones is easy: Take a fresh guy familiar to javascript or phyton or dart and expose it to our environment with a tutorial and take notes. Actually listening to what those guys have to say is the hard part because most experts are blinded by they already acquired knowledge and they forgot how they used to think before they knew. In short, they are viced on their own expertise. If 2015 brings some miracle and we turn out to be good listeners, we would have a door to good design and Smalltalk might actually have a chance. Here are some of my notes for Amber: 1. We don’t have a stepper debugger. Which is probably the main single reason to justify the extra effort that costs using a non JavaScript language at the frontend. While developing webapps, there are bugs that are actually harder to find in Smalltalk than in plain JavaScript (have in mind that Chrome’s debugger, more or less, can step and inspect JavaScript code already). 2. The IDE requires many additional clicks and steps to do the same things you do without them in file-based frameworks/libraries which completely erodes all the advantages that the language initially gave to you. 3. Helios has many usability problems. Lack of easy search, lack of drag and drop, terrible navigation of code, fragmented hierarchy views only. And the friction to solve these problems is high dramatically lowering the chances to get anything better. To elaborate on this, if you check the commits the fixes moves at less than a glacial peace, in part to hyper perfection levels of rigor on how the git commits should and should not look like. In practical, terms this eventually might completely sterilise or even kill its evolution.
-- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
Re: The Prototyping nature of Smalltalk as the strength of Amber
|
|
sebastian wrote: > Hi Tom, > > all you said is correct. > > Actually I’m trying to do something > <http://www.slideshare.net/sebastianconcept/flow-39897704> about > exactly that. > > Anyway.. I’m not sure if you are familiar with the Lean Startup > <http://en.wikipedia.org/wiki/Lean_startup> method (which roughly is > the Toyota production methods applied to know-how based products). In > that method there is a word for what you mention: /validation/ > > Yes Smalltalk /can be/ very successful in searching and potentially > anticipating business/product validation. > > And yet… > > That depends on productivity. > > /As long as/ the Smalltalk productivity is higher (or better... way > higher) than other technologies, the competitive advantage in this > crucial area is real, making your point stronger. > > At the same time, if the productivity goes down, then the value of > using Smalltalk dilutes. Even completely dilutes. > > Conclusion? > > If we screw up the > since years), it will start to make more sense to use just JavaScript > for the exact same purpose of rapid business validation. We are in no > lack of interesting JavaScript frameworks with great productivity. > > *Dolphin Smalltalk is the only exception I make about Smalltalk UI/UX. > The Dolphin’s IDE user experience and hence the productivity you > achieve with it remains largely unbeatable. > > What are some of our current UX problems? > > An overwhelming multitude. Detecting what are the most important ones > is easy: Take a fresh guy familiar to javascript or phyton or dart and > expose it to our environment with a tutorial and take notes. > > Actually /listening/ to what those guys have to say is the hard part > because most experts are blinded by they already acquired knowledge > and they forgot /how they used to think before they knew/. In short, > they are viced on their own expertise. > > If 2015 bri > would have a door to good design and Smalltalk might actually have a > chance. > > Here are some of my notes *for Amber:* > > 1. We don’t have a stepper debugger. Which is probably the main single > reason to justify the extra effort that costs using a non JavaScript > language at the frontend. While developing webapps, there are bugs > that are actually harder to find in Smalltalk than in plain JavaScript > (have in mind that Chrome’s debugger, more or less, can step and > inspect JavaScript code already). > > 2. The IDE requires many additional clicks and steps to do the same > things you do without them in file-based frameworks/libraries which > completely erodes all the advantages that the language initially gave > to you. > > 3. Helios has many usability problems. Lack of easy search, lack of > drag and drop, terrible navigation of code, fragmented hierarchy views > only. And the friction to solv > lowering the chances to get anything better. To elaborate on this, if > you check the commits > <https://github.com/amber-smalltalk/helios/commits/master> the fixes > moves at less than a glacial peace, in part to hyper perfection levels > of rigor on how the git commits should and should not look like. In I respectfully disagree. Commit rigor has nothing to do with it. The problem is, people just don't contribute to Helios (if they do and their commits are badly structured, of course I'll ask them to fix it; in all other projects, maintainer do the same to me if I am the contributor; that's just normal and how it should be). But problem of Helios is somewhere else - it's probably the combination of being second-class product (compared to Amber itself) and steep learning curve if one wants to contribute to its code (as no one except Nicolas probably knows the big picture and how it is composed and from what - certainly I don't). I gave a few calls to bring people to contributing to Helios, but to no avail. There is not enough critical mass of people with knowledge who can keep the train going and help contributors to join (not a problem of Amber). Herby -- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
Re: The Prototyping nature of Smalltalk as the strength of Amber
|
|
Having had a look at Helios code, it takes a while to understand it... So, first focusing on Amber core and then on tools looks like the way to go. The best would be to do a commercial project using Amber. This usually motivates to solve annoying chatacteristics of tools... Phil You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
Re: The Prototyping nature of Smalltalk as the strength of Amber
|
|
[hidden email] wrote: > > Le 3 janv. 2015 20:44, "Herby Vojčík" <[hidden email] > <mailto:[hidden email]>> a écrit : > > > > > > > > sebastian wrote: > >> > >> 3. Helios has many usability problems. Lack of easy search, lack of > drag and drop, terrible navigation of code, fragmented hierarchy views > only. And the friction to solv > > > > e these problems is high dramatically > >> > >> lowering the chances to get anything better. To elaborate on this, > if you check the commits > <https://github.com/amber-smalltalk/helios/commits/master> the fixes > moves at less than a glacial peace, in part to hyper perfection levels > of rigor on how the git commits should and should not look like. In > > > > > > I respectfully disagree. Commit rigor has nothing to do with it. The > problem is, people just don't contribute to Helios (if they do and their > commits are badly structured, of course I'll ask them to fix it; in all > other projects, maintainer do the same to me if I am the contributor; > that's just normal and how it should be). But problem of Helios is > somewhere else - it's probably the combination of being second-class > product (compared to Amber itself) and steep learning curve if one wants > to contribute to its code (as no one except Nicolas probably knows the > big picture and how it is composed and from what - certainly I don't). I > gave a few calls to bring people to contributing to Helios, but to no > avail. There is not enough critical mass of people with knowledge who > can keep the train going and help contributors to join (not a problem of > Amber). > > Having had a look at Helios code, it takes a while to understand it... > > So, first focusing on Amber core and then on tools looks like the way to go. > > The best would be to do a commercial project using Amber. This usually > motivates to solve annoying chatacteristics of tools... +1 ;-) > Phil > > > > Herby -- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
Re: The Prototyping nature of Smalltalk as the strength of Amber
|
|
Yes, I agree that 'the prototyping nature of Smalltalk is the strength
of Amber. ' I just finished an app in Amber. The deployment as a single file 'the.js' was great. Now with the prototype in existence and thus with the insight gained into the problem domain I realize that I can do the same thing in JavaScript only for general consumption if needed. --Hannes On 1/3/15, Herby Vojčík <[hidden email]> wrote: > > > [hidden email] wrote: >> >> Le 3 janv. 2015 20:44, "Herby Vojčík" <[hidden email] >> <mailto:[hidden email]>> a écrit : >> > >> > >> > >> > sebastian wrote: >> >> >> >> 3. Helios has many usability problems. Lack of easy search, lack of >> drag and drop, terrible navigation of code, fragmented hierarchy views >> only. And the friction to solv >> > >> > e these problems is high dramatically >> >> >> >> lowering the chances to get anything better. To elaborate on this, >> if you check the commits >> <https://github.com/amber-smalltalk/helios/commits/master> the fixes >> moves at less than a glacial peace, in part to hyper perfection levels >> of rigor on how the git commits should and should not look like. In >> > >> > >> > I respectfully disagree. Commit rigor has nothing to do with it. The >> problem is, people just don't contribute to Helios (if they do and their >> commits are badly structured, of course I'll ask them to fix it; in all >> other projects, maintainer do the same to me if I am the contributor; >> that's just normal and how it should be). But problem of Helios is >> somewhere else - it's probably the combination of being second-class >> product (compared to Amber itself) and steep learning curve if one wants >> to contribute to its code (as no one except Nicolas probably knows the >> big picture and how it is composed and from what - certainly I don't). I >> gave a few calls to bring people to contributing to Helios, but to no >> avail. There is not enough critical mass of people with knowledge who >> can keep the train going and help contributors to join (not a problem of >> Amber). >> >> Having had a look at Helios code, it takes a while to understand it... >> >> So, first focusing on Amber core and then on tools looks like the way to >> go. >> >> The best would be to do a commercial project using Amber. This usually >> motivates to solve annoying chatacteristics of tools... > > +1 ;-) > >> Phil >> > >> > Herby > > -- > You received this message because you are subscribed to the Google Groups > "amber-lang" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [hidden email]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
Re: The Prototyping nature of Smalltalk as the strength of Amber
|
|
Glad to hear Hannes. Can you elaborate on what makes that Amber app to be not suitable for general consumption? You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
Re: The Prototyping nature of Smalltalk as the strength of Amber
|
|
In reply to this post by Herby Vojčík
Please don’t let the point about getting stuck by commit rigor shadow the importance of the other points.
Commit rigor is the easiest of the problems to fix, is the other ones that are bringing us down Having more commercial Amber apps would be the the best signal but just mentioning it won’t make them happen. In the other hand, we might have some control on how easy or hard is to create one and that would actually make a difference
You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
Re: The Prototyping nature of Smalltalk as the strength of Amber
|
|
In reply to this post by sebastianconcept
On 1/4/15, sebastian <[hidden email]> wrote:
> >> On Jan 4, 2015, at 4:56 AM, H. Hirzel <[hidden email]> wrote: >> >> Yes, I agree that 'the prototyping nature of Smalltalk is the strength >> of Amber. ' >> >> I just finished an app in Amber. The deployment as a single file >> 'the.js' was great. >> >> Now with the prototype in existence and thus with the insight gained >> into the problem domain I realize that I can do the same thing in >> JavaScript only for general consumption if needed. >> >> --Hannes > > Glad to hear Hannes. > > Can you elaborate on what makes that Amber app to be not suitable for > general consumption? 1) Maintenance In case somebody else needs to maintain it. However there are many cases where a prototype is fine and may be used for a long time. And if people are happy with me as maintainer there is no problem. 2) Amber helped to analyse the problem / explore the problem domain. After that is done implementation in JavaScript is not difficult. Amber is much faster for writing an explorative prototype. Though for example the Firefox (FF34) scratchpad is slowly becoming a kind of Smalltalk workspace like place. > > -- > You received this message because you are subscribed to the Google Groups > "amber-lang" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [hidden email]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
Re: The Prototyping nature of Smalltalk as the strength of Amber
|
|
yeah great points.
Just to add something to what you said.. about 1 (maintenance) there is also the option of preparing the team for the client, they might not have smalltalkers at hand to maintain and you might not be the maintainer but I see that is totally fine for someone like you to offer a consultant service to put in place the client’s team working on Amber itself (that would be actually the best of the options for the ecosystem). About 2, I agree that javascript is catching up fast. So scratchpad is like a workspace and ECMA6 is bringing more OOP features. Those two things might end up rendering Amber redundant. Or… Amber's UX is so freaking superior that it makes it a winner tool. <— I don’t feel this is happening and it totally could be happening! Is something to think about
You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
| Free forum by Nabble | Edit this page |