Cool, I haven't seen that resource yet. Thanks for the pointer. I'm currently getting up to speed on graph databases.
Sent from my iPad > On Jan 3, 2016, at 01:54, Dimitris Chloupis <kilon.al...@gmail.com> wrote: > > there is no Pharo wiki too, but we have plenty of books and documentation > that can be found here > > https://github.com/SquareBracketAssociates > >> 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. >> > >> > >> > >> > >> >
