I do view Bigloo as this interesting batteries-included take on Scheme (much like Racket). I don't think being a non-scheme is a great, (and it doesn't work, any scheme discussion make sense to include Racket) I would love to see R7RS support in Bigloo (and much like guile, it could just be syntactic-sugar around the Bigloo-way, since feature wise, it's very similar). This doesn't preclude highlighting or including its unique features. Make sense to me, to call things Scheme's or Scheme+'s. Many schemes fall into the latter category and it's often in this same space that they differentiate themselves from one another in user-land, and create issues moving from one scheme system to another. This isn't a unique issue with bigloo and I like that prototyping things is super easy in bigloo because it has everything.
What I think would help popularizing Bigloo is: * A better website (new one looks nice and removes a lot of dead links so this seems to be addressed) * Updated docs (music player docs use the old API for example, I tried running some java swing examples and couldn't get them to work) If the Racket-like approach is taken on the "branding" of Bigloo then I think, Biglook or Java swing support should be improved and updated as UI programming is the big battery missing compared to Racket. (Can't get biglook working because I can't get GTK1.2 working) Julian Herrera ________________________________ From: [email protected] <[email protected]> on behalf of Joseph Donaldson <[email protected]> Sent: Friday, June 19, 2020 6:32 PM To: Bigloo Mailing List <[email protected]> Subject: [bigloo] How do you perceive Bigloo? Hello, All, How do you perceive Bigloo? Do you see it as just an implementation of scheme or as its own language, albeit heavily based on/inspired by scheme? I ask because, personally, I am increasingly seeing it as a separate language and am wondering if it would be beneficial to promote it as such. For example, although it is generally straight forward to port scheme code to Bigloo, it often is sub-optimal without modification to properly support Bigloo's module system, macros support (especially when used with libraries), and type system. Additionally, some traditional scheme features, such as call/cc, are inefficiently supported in Bigloo making code relying on them impractical. Conversely, code targeting Bigloo in my experience is difficult to move to other scheme systems unless it forfeits all of the extensions (modules, type annotations, object systems, etc...) that make Bigloo a practical language for my development needs. Further, by claiming to be a scheme, Bigloo is often compared to other scheme implementations in a manner which fails to highlight its strengths. For example, https://ecraven.github.io/r7rs-benchmarks/ compares the performance of a number of scheme implementations, and while Bigloo ranks fairly well, I am confident that if the Bigloo versions of the benchmark programs were written in a more idiomatic Bigloo style, leveraging type annotations and eschewing call/cc, it would have an even better showing. So, would distancing Bigloo from scheme in a manner similar to what Racket has done open opportunities for differentiating, growing, and popularizing Bigloo? I am curious to hear your thoughts. Best Regards, Joseph Donaldson
