[Pharo-users] Lawsuit Tracker app
kilon.alios at gmail.com
Sun Jan 3 04:52:42 EST 2016
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
"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.
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
take also a look at this
On Sun, Jan 3, 2016 at 11:12 AM John Pfersich <jpfersich at gmail.com> wrote:
> Sent from my iPad
> > On Jan 2, 2016, at 23:57, Saša Janiška <gour at 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?
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-users