" I know about it. However it would be nice to have some categorized catalog of the packages available for Pharo?"
I am considering making such a tool, I call it "Tartara" and it was always in my mind because my project Ephestos is a collections of tools and I wanted package manager that was more sophisticated than Catalog Browser. "Now, I'm really a bit puzzled about Roassal' capabilities. :-)" Roassal is a well design vector graphics API that specializes in data visualisation. "Well, the point is that e.g. I know people who tried to do similar apps in Python and it was too slow, they abandoned it and went to C++. That's the reason why I was primarily exploring statically-compiled languages. Julia *might* be interesting since it is higher-level language with fantastic, close to C performance when one helps compiler by annotating data types. In short, I want to avoid fiddling with low-level languages, otherwise it would be simple to just use C/GTK or C++/Qt. (Java could probably also do the job, but I simply do not like it.) For the most critical part of the application, I anyway plan to use 3rd party C lib which does calculate planetary ephemeris, but for the custom libs using it, I want to use higher-level and type-safer language." The only reason to go C++ is that you want from the first till the last millisecond of your application to have super performance, but if you want to go nuclear performance then languages like CUDA and OpenCL that take advantage of GPUs superior parallelism , provided you do the same calculation over myriads of instances of DATA, will give you easily from 3-100 times faster than C/C++ code execution. So that means you can use something like pyCuda to easily outperform C++. Also tools like cython that offer very close to python syntax can even outperform C/C++ mainly because of the optimizations that VM is doing and the ability to Cython to produce optimised C code. The reality is that pure C++ project become rarer and rarer , for example I use Blender, its 1.4 million lines of code, python is around 13% and if we turn it to equivalent C lines of code it must be around 25% and I suspect another 30% is Cuda / OpenCL, and we talking here about super performance 3d application. Still only 50% is built in C/C++/ObjC. https://www.openhub.net/p?ref=homepage&query=blender In the end its easy to port parts that are not fast to C and call them from Pharo. I remember also that there was a library to use OpenCL from Pharo too. So speed wise you are covered. Pharo even has something similar to cython called Slang that is used to create the Pharo VM. "Right, it's just that Julia provides more 'traditional' dev work-flow, while with Pharo one has to unwrap one's head a bit. :-)" Absolutely and I wont lie to you this definetly increase the learning curve, but frankly it worths it because you come to realize that the traditional way is actually weird and not a very "natural" way of thinking. If C++ is high level, python is higher level then Pharo is highest level language. It maps to the brain completely ignoring the machine architecture. But that takes time to get used to , however if you are interested in such approach I promise you will love pharo. "When I say 'business' app, it is most in the sense of typical 'desktop outlook', while the app itself is falling more into 'science' app, but it depends how one sees astronomy/astrology. :-)" well astrology is not science, astronomy is. An example of a pharo astronomy app is here http://astares.blogspot.gr/2014/04/astrocloud-using-pharo-smalltalk-and.html take also a look at this http://forum.world.st/Pharo-and-Astronomy-tp3027615p3042834.html On Sun, Jan 3, 2016 at 11:12 AM John Pfersich <jpfers...@gmail.com> wrote: > > > Sent from my iPad > > > On Jan 2, 2016, at 23:57, Saša Janiška <g...@atmarama.com> wrote: > > > >> On Sub, 2016-01-02 at 23:27 +0000, Dimitris Chloupis wrote: > >> > >> there is an an SQlite wrapper for pharo > > > > I know about it. > > > > However it would be nice to have some categorized catalog of the > > packages available for Pharo? > > > > +1 > I find that I just browse the Configuration Browser to see what's out > there and then google the name to see if I can find any documentation. > > And it would be nice to have a wiki like Squeak's. > > >> the screenshot you shared as Tudor said can be accomplished via > >> Roassal and Morphic. > > > > Now, I'm really a bit puzzled about Roassal' capabilities. :-) > > > >> Personally I find the whole performance question kinda irrelevant > >> because if you really want to squeeze the most performance code those > >> parts in C and call them from Pharo via its FFI. Not even Julia will > >> able to outperform that since itself relies on C code for performance > >> and its quite restrictive how you use its dynamic types to achieve > >> high performance. > > > > Well, the point is that e.g. I know people who tried to do similar apps > > in Python and it was too slow, they abandoned it and went to C++. > > > > That's the reason why I was primarily exploring statically-compiled > > languages. Julia *might* be interesting since it is higher-level > > language with fantastic, close to C performance when one helps compiler > > by annotating data types. > > > > In short, I want to avoid fiddling with low-level languages, otherwise > > it would be simple to just use C/GTK or C++/Qt. (Java could probably > > also do the job, but I simply do not like it.) > > > > For the most critical part of the application, I anyway plan to use 3rd > > party C lib which does calculate planetary ephemeris, but for the custom > > libs using it, I want to use higher-level and type-safer language. > > > >> In any case there are always 3 rules, profile, profile and profile. > >> When it comes to performance assume nothing. In the vast majority of > >> cases Pharo JIT VM should be more than enough. > > > > Let me see... > > > >> And if all you want to do is a business app I dont even know why you > >> worry about performance. Business apps they are very low demand on > >> performance. > > > > When I say 'business' app, it is most in the sense of typical 'desktop > > outlook', while the app itself is falling more into 'science' app, but > > it depends how one sees astronomy/astrology. :-) > > > >> Pharo libraries dont get irrelevant because the language is so simple > >> it barely changes and the changes usually dont brake compatibility. > > > > Pharo's simplicity of the language is huge 'pro'. ;) > > > >> Pharo can do REPL via the playground, the whole deal is that is a lot > >> more than that. > > > > Right, it's just that Julia provides more 'traditional' dev work-flow, > > while with Pharo one has to unwrap one's head a bit. :-) > > > >> GUI wise you can do some pretty awesome stuff with morphic. > > > > That I still have to learn... > > > > > > Sincerely, > > Gour > > > > -- > > A person is said to be elevated in yoga when, having renounced > > all material desires, he neither acts for sense gratification > > nor engages in fruitive activities. > > > > > > > > > > > >
