[racket-users] Re: performance: Racket vs Julia
On Sat, 2 Feb 2019 18:10:31 -0500 Matthias Felleisen wrote: > It is rare that I have to somewhat-contradict Matthew here, but so it > goes. :-) > Use Racket for what you have in mind. It’s obviously the superior > language :-) That makes the deal. Thank you very much for your input as well as work done on Racket! Sincerely, Gour -- But for one who takes pleasure in the self, whose human life is one of self-realization, and who is satisfied in the self only, fully satiated — for him there is no duty. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[racket-users] Re: performance: Racket vs Julia
On Sat, 2 Feb 2019 18:24:47 -0500 Neil Van Dyke wrote: > Yes, I did another look for Racket last year, and desktop GUI toolkit > options generally seem to have have actually gotten fewer and worse > since the move of most of the money to Web and handheld apps. Yes, very sad. :-( > We need to advertise this selling point for Racket: "Our syntax is > not too strange!" :) Maybe it's, for some, strange, but, otoh, it is simple and I always appreciate simplicity as general value. :-) > What I've done recently, as aggregations of existing components, for > a retro smartphone UI, seemed mostly straightforward (and in this > case was mostly a kind of coding that one can do for hours without > having to think hard, so maybe it's a relaxing evening after a day of > intense high-stakes software engineering :) (unreleased, for now) > https://www.neilvandyke.org/postmarketos/ This sounds encouraging! Sincerely, Gour -- The humble sages, by virtue of true knowledge, see with equal vision a learned and gentle brāhmana, a cow, an elephant, a dog and a dog-eater. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Re: performance: Racket vs Julia
Matthias Felleisen writes: > It is rare that I have to somewhat-contradict Matthew here, but so it goes. > > One of my colleagues, Jan Vitek, has studied Julia with a special > focus on performance. As many have said, Julia is good at numerics > because its compiler can specialize certain cases really well. More I'd really like to see something like Julia as a special-purpose language in a general-purpose language ecosystem such as Racket. Having to choose between numerical performance and good support for non-numerical stuff such as user interfaces is a real pain. Given that performance almost always trumps everything else in number crunching, the result is that number crunching software is always bad from every point of view other than performance. Konrad. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Re: performance: Racket vs Julia
Gour wrote on 2/2/19 3:55 PM:
Many languages simply do not pass 'GUI criteria' and, imho, Racket is very much
deprived of its glory by providing first class GUI option for all those not so
enamored with JS/browser stuff.
Yes, I did another look for Racket last year, and desktop GUI toolkit
options generally seem to have have actually gotten fewer and worse
since the move of most of the money to Web and handheld apps.
(Regarding Web, right now it's dominated by snooping, and by
brochure/tabloid HCI. And, on handhelds and moving back to desktop, one
could even wonder whether certain handheld UX designs being pushed on
some developers for all apps are actually motivated not entirely by
traditional HCI usability goals, but also against the users' interests,
such as for combating the cognitive/perceptual filtering of ad
placements that users learned almost immediately in the late-'90s, or to
promote impulsive consumption of media "content".)
Some languages were simply excluded without even slight consideration like {C,
C++, Java}, some are uninspiring (Go) or have (too) strange syntax etc.
We need to advertise this selling point for Racket: "Our syntax is not
too strange!" :)
I understand the appeal of Racket, though of course there are good
things to say about each of those languages you mentioned, both for
novel PL merit and for practical application. (I used the first 3
heavily, in industry and/or research, and recently looked at the 4th,
and would be happy using/developing it with the added incentive of gobs
of money, though I currently prefer Racket for most purposes.)
1) is there a plan to fill the gap with the 'missing' widgets in the
foreseeable future? (Iirc, someone once mentioned to me 'tree widget' which is
not included out of the box.)
A core Racket person can speak about any plans for core.
What is super-useful for the community is when people develop some parts
of their system as high-quality reusable components that are
loosely-coupled with their application, and share those components as
documented Racket packages. This includes new GUI widgets.
2) how difficult is, in general, to add new widgets?
What I've done recently, as aggregations of existing components, for a
retro smartphone UI, seemed mostly straightforward (and in this case was
mostly a kind of coding that one can do for hours without having to
think hard, so maybe it's a relaxing evening after a day of intense
high-stakes software engineering :) (unreleased, for now)
https://www.neilvandyke.org/postmarketos/
Another option for implementing new widgets in Racket is arbitrary
drawing on a 2D or 3D canvas. Or mixing arbitrary drawing and existing
widgets (like you might want to do in a scalable editable
spreadsheet/table widget, for example). I haven't done this with Racket
in a long time, but I think it's still reasonable, and you can look for
examples in the Racket source code that don't proxy native toolkit
components (e.g., the plot snip?). But, by comparison, the JS widgets
I've had to do from scratch more recently were a headache to make work
well and be portable.
--
You received this message because you are subscribed to the Google Groups "Racket
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Re: performance: Racket vs Julia
It is rare that I have to somewhat-contradict Matthew here, but so it goes. One of my colleagues, Jan Vitek, has studied Julia with a special focus on performance. As many have said, Julia is good at numerics because its compiler can specialize certain cases really well. More generally, it does well when a programmer commits to the effort of writing down performance-enhancing types. [1] BUT, there’s an incredible pitfall associated with this approach. If the programmer is a bit off with the types (not wrt correctness but wrt to narrowness or forgets to specify a type somewhere), the compiler still succeeds except that the program will be rather slow when uses certain paths [2]. So your performance experience with Julia could be quite varied. Use Racket for what you have in mind. It’s obviously the superior language :-) — Matthias p.s. If there’s interest, I can dig out Jan’s draft paper. [1] Julia is gradually typed but it should really be considered optionally typed. The types are about performance, so they are more like C types than ML type.s [2] Julia’s compiler is tailor-made for an application of Vincent St-Amour’s dissertation research on feature-specific profiling. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[racket-users] Re: performance: Racket vs Julia
On Sat, 2 Feb 2019 08:04:36 -0700 Matthew Flatt wrote: > It's possible that the someone talked to me. I recall offering the > opinion to someone at RacketCon/ICFP/StrangeLoop that Racket would not > be as fast as Julia for the case that Julia is designed for --- > specifically numerics --- due to the way the Julia compiler > specializes programs to numeric types and hands off to LLVM as its > back end. Hey, but that's not fair!! The 'quote' is pulled out of the context. :-( > But I agree with others that Racket is likely to be faster on most things. Thank a million!! It does help me very much to make a decison. ;) Sincerely, Gour -- Whenever and wherever there is a decline in religious practice, O descendant of Bharata, and a predominant rise of irreligion — at that time I descend Myself. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[racket-users] Re: performance: Racket vs Julia
On Sat, 2 Feb 2019 04:53:33 -0500
Neil Van Dyke wrote:
> That's an unusual shortlist of candidates.
Well, yes and no. Many languages simply do not pass 'GUI criteria' and, imho,
Racket is very much deprived of its glory by providing first class GUI option
for all those not so enamored with JS/browser stuff.
Some languages were simply excluded without even slight consideration like {C,
C++, Java}, some are uninspiring (Go) or have (too) strange syntax etc.
> Does this desktop app do heavy numeric computation?
Yes, it's supposed to crunch the numbers, but I plan to use 3rd party C library
for that and then just provide higher-level bindings to if from the host
language and write custom libraries which use functions from the C lib on top
of that.
> Or is your organization already invested i n Julia for numeric, and you'd
> like to also use it for GUI if you can?
No, it is supposed to be open-source hobby project, so there must be some fun
doing it. I also would like to avoid "2 language problem" in regard to GUI.
> Maybe a year or two ago, I asked about Julia for systems-ish
> programming (like low-level operating systems code, and
> high-performance server I/O), and, at the time, it sounded like the
> performance for that was not there -- Julia was initially focused on
> numeric performance.
It also seems that Julia does not want to be too 'general programming
language'. :-)
> Note that a few things DrRacket does are more compute-intensive than most
> desktop apps (such as evaluating child programs with debugging info), but you
> can get an idea.
Ohh, that's very helpful. Thank you very much for this insight.
> 2. Look in the Racket documentation for what the cross-platform GUI
> toolkit (and the separate "Framework" stuff) provide. They provide
> th e usual basic widgets, plus some non-usual DrRacket editor
> functionality, but they don't have as much widgets as some toolkits
> have (so make sure it has what you need, or be prepared to code
> what's missing). https://docs.racket-lang.org/gui/Widget_Gallery.html
> https://docs.racket-lang.org/gui/Windowing_Classes.html
> https://docs.racket-lang.org/framework/index.html
Two questions in regard:
1) is there a plan to fill the gap with the 'missing' widgets in the
foreseeable future? (Iirc, someone once mentioned to me 'tree widget' which is
not included out of the box.)
2) how difficult is, in general, to add new widgets?
> If you have numeric performance requirements (if that's why you're
> looking at Julia),
Julia seems to me as interesting language - in the past I was also looking at
Dylan - and numeric performance is not the main reason behind my interest, but
e.g. Python is certainly too slow as proved by some people trying to
write similar apps and abandoning it to eventually go e.g C++.
> Or do you want to try coding those functions in Typed Racket?
Based on what I read, Typed Racket is something I want to explore.
> That's when someone says "Challenge accepted." :)
:-)
Thank you for shedding the light on this issues.
Sincerely,
Gour
--
As fire is covered by smoke, as a mirror is covered by dust,
or as the embryo is covered by the womb, the living entity is
similarly covered by different degrees of this lust.
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[racket-users] Re: performance: Racket vs Julia
On Sat, 2 Feb 2019 01:41:17 -0800 (PST) Yvan Godin wrote: > I have played with Julia as a language it's a good compromise between Common > Lisp with Python syntax and C performance > > but build an autonomous prog. come with a lot of pain That's good to know. Thank you! > their Gtk is far to be well finished and polished as many other libraries > but this is a matter of time OK. > so I continue to love Racket even if will remain for long time a little bit > less performant but that depend on your needs :-) > only my feeling and sorry for my low skilled English ;-) I dіdn't notice it and your message went through. ;) Sincerely, Gour -- But for one who takes pleasure in the self, whose human life is one of self-realization, and who is satisfied in the self only, fully satiated — for him there is no duty. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[racket-users] Re: performance: Racket vs Julia
Hello I have played with Julia as a language it's a good compromise between Common Lisp with Python syntax and C performance but build an autonomous prog. come with a lot of pain Racket come with an excellent battery include Julia is based on LLVM witch is very very big Julia provide a real 'live coding' that's not the case for Racket Julia libraries space is much more oriented for heavy scientific calculation but there not good general programing tools, their Gtk is far to be well finished and polished as many other libraries but this is a matter of time so I continue to love Racket even if will remain for long time a little bit less performant but that depend on your needs only my feeling and sorry for my low skilled English ;-) Le samedi 2 février 2019 10:04:22 UTC+1, Gour a écrit : > > Hello, > > I've to decide between Racket and Julia as language of choice for writing > desktop app. Racket's advantage is that its GUI support is provided out of > the > box, while in Julia I'd probably have to use Gtk.jl as the best supported > package since I do not want to use Electron or some other > JS/browser-based > things. > > Leaving aside other language features' pros/cons, I was a bit surprised > when someone in Julia's channel responded to me with: "Racket is pretty > amazing, but I stopped looking into it after I figured, that it can't > really be made fast language...I just talked at some point with some of > the core devs, and they told me that racket may never be julia fast > (some of them actually know julia quite well)". I received some > feedback on it in Slack's channel, but curious to receive some more > here. iow. whether "Racket may never be Julia fast" can be taken in > general or it is just a question from case to case? > > > Sincerely, > Gour > > -- > As the embodied soul continuously passes, in this body, > from boyhood to youth to old age, the soul similarly passes > into another body at death. A sober person is not bewildered > by such a change. > > > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
