Missing libraries
Locked
 
|
Hi
I would really like to know what are the libraries you are missing to grow your business. Stef _______________________________________________ Pharo-business mailing list [hidden email] http://lists.pharo.org/mailman/listinfo/pharo-business_lists.pharo.org |
|
|
Having Roassal on the web is high priority for us, and we are actively working on it. We should soon release what we have.
I am not sure if this will generate more income or not, but having Pharo that works well on iphone and ipad would be great. This would open new range of applications. Alexandre On Mar 6, 2014, at 10:17 AM, Pharo4Stef <[hidden email]> wrote: > Hi > > I would really like to know what are the libraries you are missing to grow your business. > > Stef > _______________________________________________ > Pharo-business mailing list > [hidden email] > http://lists.pharo.org/mailman/listinfo/pharo-business_lists.pharo.org -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-business mailing list [hidden email] http://lists.pharo.org/mailman/listinfo/pharo-business_lists.pharo.org |
Re: Missing libraries
|
|
On Mar 8, 2014, at 11:06 AM, Sebastian Sastre <[hidden email]> wrote:
Which brings us to: _______________________________________________ Pharo-business mailing list [hidden email] http://lists.pharo.org/mailman/listinfo/pharo-business_lists.pharo.org |
|
|
Hi guys!
On 03/10/2014 09:54 PM, Sebastian Sastre wrote: >>> Can we develop a Pharo app to run native stuff of OS X? >> >> which in turn was asked at stackoverflow here: >> http://stackoverflow.com/questions/1139378/is-smalltalk-a-viable-development-language-for-mac-os-x My guess is that the current pursued option that has the most momentum and is fresh is Mars, see: http://marsonpharo.wordpress.com http://smallworks.com.ar/web/projects/mars AFAIK Mars is built to be able to use different backends - and uses Gtk and Cocoa now? Not sure. > Which brings us to: > http://www.wxsqueak.org/ > > Has anybody used it on Pharo? I think wxSqueak is fairly dead - BUT... it was quite impressive so it is very unfortunate. Cees de Groot built a full blown application with it. Now... I have been interested in native UIs and cross platform toolkits for a long time. I even started the first GtkPlugin once, although I didn't get that far at the time. These days we have more bases covered, like NBFFI, SWIG, TalkFFI, various improvements for callbacks etc etc. But... glue libraries tend to *die*. I mean, like they all *DIE*! Just like wxSqueak did and many, many, many similar projects have. Many. Every time. They die. Ok, you get the point :) IMHO the *only* path to be able to "keep up" is a fully automated binding - either completely generated, or completely dynamic using some kind of runtime reflection. As soon as you start to hand code glue - it will end up rotting and the project will die, die, die! ...or... another INSANE idea I had the other day: - Embed the mono runtime as a plugin. Thus creating a Mono bridge! Sure, building a full bridge is a bit of work, but the payback would be HUGE. And it can be done, OpenQwaq includes a full Python bridge in the same manner btw: http://squeakingalong.wordpress.com/2011/05/04/openqwaq-python-integration/ Sidenote: That is actually a full CPython interpreter embedded as a plugin with a very strong integration. If people are interested in that I guess we could contemplate relicensing it, right Ron? ...so why would I want a mono bridge? Because Mono is currently very strong in cross platform development with native UIs on both Linux, Windows, Mac, Android and iPhone/iPad. See xamarin.com. No, I mean it, look at it! It is very, very impressive and Xamarin is the Mono guys, its just mono and monodevelop rebranded with addons. Its a long story, but essentially the mono guys added AOT compilation (= regular compilation) to the mono runtime. This means it can compile .Net programs (C# and some other langs) into regular native binaries, and libraries too. And this was needed for practical use with performance on iPhone etc, because Apple does not allow JIT. So having a mono-bridge-plugin we could leverage TONS of Mono libraries, including native UIs and we would get a UI builder etc for free! Mono is very embeddable, and its really fast these days. And C# is actually quite decent as a language too and Xamarin track iOS *same day*: http://blog.xamarin.com/ios-7.1/ regards, Göran _______________________________________________ Pharo-business mailing list [hidden email] http://lists.pharo.org/mailman/listinfo/pharo-business_lists.pharo.org |
|
|
> - Embed the mono runtime as a plugin. Thus creating a Mono bridge! > > Sure, building a full bridge is a bit of work, but the payback would be HUGE. And it can be done, OpenQwaq includes a full Python bridge in the same manner btw > http://squeakingalong.wordpress.com/2011/05/04/openqwaq-python-integration/ This is nice but this is not a simple project. And having a dependency on Python… is far from ideal. > > Sidenote: That is actually a full CPython interpreter embedded as a plugin with a very strong integration. If people are interested in that I guess we could contemplate relicensing it, right Ron? > > ...so why would I want a mono bridge? Because Mono is currently very strong in cross platform development with native UIs on both Linux, Windows, Mac, Android and iPhone/iPad. See xamarin.com. No, I mean it, look at it! It is very, very impressive and Xamarin is the Mono guys, its just mono and monodevelop rebranded with addons. > > Its a long story, but essentially the mono guys added AOT compilation (= regular compilation) to the mono runtime. This means it can compile .Net programs (C# and some other langs) into regular native binaries, and libraries too. And this was needed for practical use with performance on iPhone etc, because Apple does not allow JIT. Yes this is what we can do for NB but we will not ave the resources. > So having a mono-bridge-plugin we could leverage TONS of Mono libraries, including native UIs and we would get a UI builder etc for free! well you have to install mono and all the rest + cairo + + + > Mono is very embeddable, and its really fast these days. And C# is actually quite decent as a language too and Xamarin track iOS *same day*: > > http://blog.xamarin.com/ios-7.1/ > > regards, Göran > > _______________________________________________ > Pharo-business mailing list > [hidden email] > http://lists.pharo.org/mailman/listinfo/pharo-business_lists.pharo.org _______________________________________________ Pharo-business mailing list [hidden email] http://lists.pharo.org/mailman/listinfo/pharo-business_lists.pharo.org |
Re: Missing libraries
|
|
In reply to this post by Göran Krampe-4
Interesting question.
Firsts some abstraction to guide the thinking: Even minerals abide by Natural Selection so is not libraries but everything that will decay. Things that are ignored? They decay faster. Automating a port is the maintainer’s dream. While I don’t think such a thing exists, it would be awesome if it does to lower the costs/effort of the maintained feature. Secondly, about the concrete proposals: - wxSqueak is frozen yes, and the useful thing is to talk about how much effort to port/upgrade because wxWdgets seems to be healthy maintaned by its community - About xamarin, the idea is great but (a) it sounds too bloated, the promise is big so there is a discount there but still (b) it would be a commercial based dependency with very strong political ties and (c) I’m guessing the effort doesn’t pay off because one might be able to achieve more or less same goals with Titanium SDK and Amber - Mars sounds interesting an a fresh, what is it missing for it to become serious and start prototyping native apps? Some inspiration: A general strategy for Pharo, or any other technology for the matter, is to be of high/strategic value for artists and people on the audivisual industry This is an example: And, be jealous, here is another in which Python seems to be doing quite well and is even more business friendly than the previous one: Creating personal and technological ties with artists is an open opportunity to thrive on On Mar 11, 2014, at 5:52 AM, Göran Krampe <[hidden email]> wrote: Hi guys! _______________________________________________ Pharo-business mailing list [hidden email] http://lists.pharo.org/mailman/listinfo/pharo-business_lists.pharo.org |
|
|
Hi!
On 03/11/2014 02:04 PM, Sebastian Sastre wrote: > Interesting question. > > Firsts some abstraction to guide the thinking: > > Even minerals abide by Natural Selection so is not libraries but > *everything* that will decay. Things that are ignored? They decay faster. > > Automating a port is the maintainer’s dream. While I don’t think such a > thing exists, it would be awesome if it does to lower the costs/effort > of the maintained feature. SWIG is exactly "such a thing". And I don't mean a "port" that is automated, but the glue. > Secondly, about the concrete proposals: > > - wxSqueak is frozen yes, and the useful thing is to talk about how much > effort to port/upgrade because wxWdgets seems to be healthy maintaned by > its community Dunno. I do know he did some small hacks to the VM to get callbacks to work, but these days we should cope better. > - About xamarin, the idea is great /but /(a) it sounds too bloated, the > promise is big so there is a discount there but still (b) it would be a > commercial based dependency with very strong political ties and (c) I’m > guessing the effort doesn’t pay off because one might be able to > achieve more or less same goals with Titanium SDK and Amber Bloated? Why so? And no, Xamarin is a commercial entity, true - and their offering is commercial BUT that is just the *addon* to mono and monodeveloper (the IDE) for being able to target iOS and Android. Mono itself and Monodeveloper open source all the way. Do note these components are already being used in things like Unity3D etc. Finally I hardly think you can compare it with a webview approach (modulo my slightly low understanding of Titanium). I love Amber though. > - Mars sounds interesting an a fresh, what is it missing for it to > become serious and start prototyping native apps? No idea :) regards, Göran _______________________________________________ Pharo-business mailing list [hidden email] http://lists.pharo.org/mailman/listinfo/pharo-business_lists.pharo.org |
|
|
In reply to this post by sebastianconcept@gmail.co
_______________________________________________ Pharo-business mailing list [hidden email] http://lists.pharo.org/mailman/listinfo/pharo-business_lists.pharo.org |
|
|
In reply to this post by sebastianconcept@gmail.co
I’m sad in fact because it looks quite cool. Stef _______________________________________________ Pharo-business mailing list [hidden email] http://lists.pharo.org/mailman/listinfo/pharo-business_lists.pharo.org |
|
|
In reply to this post by pharo4Stef@free.fr
Libraries are not the big issue. Cohesion is. I'm fed up with the titles like "Ruby and Rails successor", "MeteorJS killer". This is simply not true. I don't care I have to use the 30 year old command line and text editor. It works; I can implement and deploy an API in a matter of minutes with Rails or Sinatra. The winning part is that the framework guides to a point where you do not need to think about architecture (to a certain extent of course), I can pickup any Rails project of my office mates and start develop feature because the code is always laid out the same. Everything has been decided for you, if you follow the conventions and best practices, you're good to go.
Of course the full stack provided is not the best and that's why people have customised the default libraries to suit their needs. But the default are usually quite adequate.
On the other side when I start a Pharo project, it's always the same: 0. Oh shit this image needs PharoV2.sources. Where the hell is it? 1. Loading Seaside. Mmm. Where is the configuration? Oh, there are three different repos that looks all the same.
2. Seaside is loaded. How will I manage persistence? With experience, "in memory" persistence is a bad idea as soon as you need to deploy. And boy, deploying your project on a staging server should be done on day one (and every day that follows).
3. How should I structure my packages ? I now have my own best practices that I've built by looking at other people code and by trial-and-errors. 4. How do I commit my external files? I have loads of js, css and images. Monticello will take forever every time I commit.
5. You get the point. It's questions that I shouldn't have to ask all the way down. Those points have nothing to do with Pharo per se. The picture is bigger than just the language/environment.
I continue to develop in Pharo because I like it. It's going in the right direction and people doing business and sharing their architecture and technical decisions is what we need. So far we all have or scripts on our machine and a newcomer will be overwhelmed to do everything by himself.
For the kind of projects I'm doing, Command line improvements + Git are a huge step forward pragmatism without sacrificing Smalltalk tools. Sorry for the noise,
Francois On Thu, Mar 6, 2014 at 2:17 PM, Pharo4Stef <[hidden email]> wrote: Hi _______________________________________________ Pharo-business mailing list [hidden email] http://lists.pharo.org/mailman/listinfo/pharo-business_lists.pharo.org |
Re: Missing libraries
|
|
On Mar 13, 2014, at 5:50 AM, Francois Stephany <[hidden email]> wrote:
Sorry? Noise? Man.. we need to print your checklist, put a frame and hang it on the wall. Thanks for sharing! What you did there is sharing your thought process while (simulating) using Pharo to hack around a prototype of a web app which is a very popular demand. BTW, that is the kind of notes you extract from usability tests! Our mantra for this year should be: "Conveniences, conveniences, conveniences” I wrote something about that a while ago: _______________________________________________ Pharo-business mailing list [hidden email] http://lists.pharo.org/mailman/listinfo/pharo-business_lists.pharo.org |
|
|
In reply to this post by Francois Stephany
Hi François,
I agree 300% with what you just said. Thank you. I was monitoring this thread and thinking of a way to express exactly what you wrote down. Building a business requires the ability to focus on that business and get the least amount of friction from what you use in your technology stack. It's all about picking your fight and not trying to win on all possible fronts. Right now, there is probably too much friction because of a lack of up-to-date documentation, which is what your points are all about. In some way, Pharo's innovation goal contradicts this (aka "no backwards compatibility"), so it's never going to be a smooth ride, but that is *OK* when the award is large. Sure, there are missing libraries in Pharo itself, but if I want fancy visualizations, word document generation, etc.., I will just pick another technology that has the best library for that and integrate it in my project. I think everyone knows this, but we (including myself!) need a little kick in the butt from time to time ;-) cheers Johan On 13 Mar 2014, at 09:50, Francois Stephany <[hidden email]> wrote: > Libraries are not the big issue. Cohesion is. > > I'm fed up with the titles like "Ruby and Rails successor", "MeteorJS killer". This is simply not true. > > I don't care I have to use the 30 year old command line and text editor. It works; I can implement and deploy an API in a matter of minutes with Rails or Sinatra. > > The winning part is that the framework guides to a point where you do not need to think about architecture (to a certain extent of course), I can pickup any Rails project of my office mates and start develop feature because the code is always laid out the same. Everything has been decided for you, if you follow the conventions and best practices, you're good to go. > > Of course the full stack provided is not the best and that's why people have customised the default libraries to suit their needs. But the default are usually quite adequate. > > On the other side when I start a Pharo project, it's always the same: > > 0. Oh shit this image needs PharoV2.sources. Where the hell is it? > 1. Loading Seaside. Mmm. Where is the configuration? Oh, there are three different repos that looks all the same. > 2. Seaside is loaded. How will I manage persistence? With experience, "in memory" persistence is a bad idea as soon as you need to deploy. And boy, deploying your project on a staging server should be done on day one (and every day that follows). > 3. How should I structure my packages ? I now have my own best practices that I've built by looking at other people code and by trial-and-errors. > 4. How do I commit my external files? I have loads of js, css and images. Monticello will take forever every time I commit. > 5. You get the point. It's questions that I shouldn't have to ask all the way down. > > Those points have nothing to do with Pharo per se. The picture is bigger than just the language/environment. > > I continue to develop in Pharo because I like it. It's going in the right direction and people doing business and sharing their architecture and technical decisions is what we need. So far we all have or scripts on our machine and a newcomer will be overwhelmed to do everything by himself. > > For the kind of projects I'm doing, Command line improvements + Git are a huge step forward pragmatism without sacrificing Smalltalk tools. > > Sorry for the noise, > Francois > > > > > On Thu, Mar 6, 2014 at 2:17 PM, Pharo4Stef <[hidden email]> wrote: > Hi > > I would really like to know what are the libraries you are missing to grow your business. > > Stef > _______________________________________________ > Pharo-business mailing list > [hidden email] > http://lists.pharo.org/mailman/listinfo/pharo-business_lists.pharo.org > > _______________________________________________ > Pharo-business mailing list > [hidden email] > http://lists.pharo.org/mailman/listinfo/pharo-business_lists.pharo.org _______________________________________________ Pharo-business mailing list [hidden email] http://lists.pharo.org/mailman/listinfo/pharo-business_lists.pharo.org |
|
|
In reply to this post by Francois Stephany
> I'm fed up with the titles like "Ruby and Rails successor", "MeteorJS killer". This is simply not true. > > I don't care I have to use the 30 year old command line and text editor. It works; I can implement and deploy an API in a matter of minutes with Rails or Sinatra. > > The winning part is that the framework guides to a point where you do not need to think about architecture (to a certain extent of course), I can pickup any Rails project of my office mates and start develop feature because the code is always laid out the same. Everything has been decided for you, if you follow the conventions and best practices, you're good to go. Thanks this is a nice point. > Of course the full stack provided is not the best and that's why people have customised the default libraries to suit their needs. But the default are usually quite adequate. We are working on a tutorial on the Pharo Web Stack Model Magritte Mongo Voyage Seaside Tide to really do that. > On the other side when I start a Pharo project, it's always the same: > > 0. Oh shit this image needs PharoV2.sources. Where the hell is it? > 1. Loading Seaside. Mmm. Where is the configuration? Oh, there are three different repos that looks all the same. > 2. Seaside is loaded. How will I manage persistence? With experience, "in memory" persistence is a bad idea as soon as you need to deploy. And boy, deploying your project on a staging server should be done on day one (and every day that follows). > 3. How should I structure my packages ? I now have my own best practices that I've built by looking at other people code and by trial-and-errors. > 4. How do I commit my external files? I have loads of js, css and images. Monticello will take forever every time I commit. > 5. You get the point. It's questions that I shouldn't have to ask all the way down. > > Those points have nothing to do with Pharo per se. The picture is bigger than just the language/environment. This is a nice point. I understand it. > I continue to develop in Pharo because I like it. It's going in the right direction and people doing business and sharing their architecture and technical decisions is what we need. So far we all have or scripts on our machine and a newcomer will be overwhelmed to do everything by himself. > > For the kind of projects I'm doing, Command line improvements + Git are a huge step forward pragmatism without sacrificing Smalltalk tools. > > Sorry for the noise, No this is really interesting. _______________________________________________ Pharo-business mailing list [hidden email] http://lists.pharo.org/mailman/listinfo/pharo-business_lists.pharo.org |
|
|
In reply to this post by sebastianconcept@gmail.co
But at the end of the day, you guys have to help because we cannot work on the rest and everything else.
_______________________________________________ Pharo-business mailing list [hidden email] http://lists.pharo.org/mailman/listinfo/pharo-business_lists.pharo.org |
|
|
In reply to this post by Johan Brichau-3
Hi Johan and others
What is important to realise is that - This is not compiler experts that will be able to make sure that DB or web frameworks run smoothly out of the box. - We are working on a catalog and the validation of packages to make sure that the deployment is smooth. The proposal sent to Inria is currently not accepted so this means that we will not have engineers to help us to build that. - For the documentation: you should realise that the documentation of frameworks have never been this good. It is steadily improving. Now if people writing systems/frameworks do not write doc it takes a lot more time for others to write it. Stef > Hi François, > > I agree 300% with what you just said. Thank you. I was monitoring this thread and thinking of a way to express exactly what you wrote down. > > Building a business requires the ability to focus on that business and get the least amount of friction from what you use in your technology stack. > It's all about picking your fight and not trying to win on all possible fronts. > > Right now, there is probably too much friction because of a lack of up-to-date documentation, which is what your points are all about. > In some way, Pharo's innovation goal contradicts this (aka "no backwards compatibility"), so it's never going to be a smooth ride, but that is *OK* when the award is large. > > Sure, there are missing libraries in Pharo itself, but if I want fancy visualizations, word document generation, etc.., I will just pick another technology that has the best library for that and integrate it in my project. > > I think everyone knows this, but we (including myself!) need a little kick in the butt from time to time ;-) > > cheers > Johan > > On 13 Mar 2014, at 09:50, Francois Stephany <[hidden email]> wrote: > >> Libraries are not the big issue. Cohesion is. >> >> I'm fed up with the titles like "Ruby and Rails successor", "MeteorJS killer". This is simply not true. >> >> I don't care I have to use the 30 year old command line and text editor. It works; I can implement and deploy an API in a matter of minutes with Rails or Sinatra. >> >> The winning part is that the framework guides to a point where you do not need to think about architecture (to a certain extent of course), I can pickup any Rails project of my office mates and start develop feature because the code is always laid out the same. Everything has been decided for you, if you follow the conventions and best practices, you're good to go. >> >> Of course the full stack provided is not the best and that's why people have customised the default libraries to suit their needs. But the default are usually quite adequate. >> >> On the other side when I start a Pharo project, it's always the same: >> >> 0. Oh shit this image needs PharoV2.sources. Where the hell is it? >> 1. Loading Seaside. Mmm. Where is the configuration? Oh, there are three different repos that looks all the same. >> 2. Seaside is loaded. How will I manage persistence? With experience, "in memory" persistence is a bad idea as soon as you need to deploy. And boy, deploying your project on a staging server should be done on day one (and every day that follows). >> 3. How should I structure my packages ? I now have my own best practices that I've built by looking at other people code and by trial-and-errors. >> 4. How do I commit my external files? I have loads of js, css and images. Monticello will take forever every time I commit. >> 5. You get the point. It's questions that I shouldn't have to ask all the way down. >> >> Those points have nothing to do with Pharo per se. The picture is bigger than just the language/environment. >> >> I continue to develop in Pharo because I like it. It's going in the right direction and people doing business and sharing their architecture and technical decisions is what we need. So far we all have or scripts on our machine and a newcomer will be overwhelmed to do everything by himself. >> >> For the kind of projects I'm doing, Command line improvements + Git are a huge step forward pragmatism without sacrificing Smalltalk tools. >> >> Sorry for the noise, >> Francois >> >> >> >> >> On Thu, Mar 6, 2014 at 2:17 PM, Pharo4Stef <[hidden email]> wrote: >> Hi >> >> I would really like to know what are the libraries you are missing to grow your business. >> >> Stef >> _______________________________________________ >> Pharo-business mailing list >> [hidden email] >> http://lists.pharo.org/mailman/listinfo/pharo-business_lists.pharo.org >> >> _______________________________________________ >> Pharo-business mailing list >> [hidden email] >> http://lists.pharo.org/mailman/listinfo/pharo-business_lists.pharo.org > > > _______________________________________________ > Pharo-business mailing list > [hidden email] > http://lists.pharo.org/mailman/listinfo/pharo-business_lists.pharo.org _______________________________________________ Pharo-business mailing list [hidden email] http://lists.pharo.org/mailman/listinfo/pharo-business_lists.pharo.org |
|
|
You're right. That's why the scope of the discussion is much broader than the people working on the Pharo "Core". The progress that has been achieved is already huge.
I feel this mailing list is the right place to discuss between businesses using Pharo. Not only for the business side but also for the technical stack and tools we use in production. On Thu, Mar 13, 2014 at 4:21 PM, Stéphane Ducasse <[hidden email]> wrote: Hi Johan and others _______________________________________________ Pharo-business mailing list [hidden email] http://lists.pharo.org/mailman/listinfo/pharo-business_lists.pharo.org |
|
|
> You're right. > > That's why the scope of the discussion is much broader than the people working on the Pharo "Core". The progress that has been achieved is already huge. > > I feel this mailing list is the right place to discuss between businesses using Pharo. Not only for the business side but also for the technical stack and tools we use in production. Yes! Motivate people to act :) Stef _______________________________________________ Pharo-business mailing list [hidden email] http://lists.pharo.org/mailman/listinfo/pharo-business_lists.pharo.org |
«
Return to Pharo Business
|
1 view|%1 views
| Free forum by Nabble | Edit this page |