December 2017 - Pharo-users

Re: [Pharo-users] A playground for Markdown?

by Sean P. DeNigris

Offray Vladimir Luna CÃ¡rdenas-2 wrote > a versatile Playground that supports several syntax > highlighting (and some supporting behavior) That actually could be amazing because sometimes I'm forced to use other syntaxes (especially markups nowadays) and I'd probably be much happier editing Markdown in Pharo than in the GH web UI! This actually just reminded me of Lukas' Helvetia and Language Boxes. Offray, I have no idea if it's relevant or useful (the project was from 2009), but you may want to have a look. Here's one link: http://scg.unibe.ch/research/helvetia ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Dec. 31, 2017

Re: [Pharo-users] A playground for Markdown?

by Offray Vladimir Luna CÃ¡rdenas

Hi, On 31/12/17 05:13, Stephane Ducasse wrote: >> from one format to another, text is parsed by a reader into pandocâs >> intermediate representation of the documentâan âabstract syntax treeâ or >> ASTâwhich is then converted by the writer into the target format. The pandoc >> AST format is defined in the module Text.Pandoc.Definition in pandoc-types. >> >> A âfilterâ is a program that modifies the AST, between the reader and the >> writer: >> >> INPUT --reader--> AST --filter--> AST --writer--> OUTPUT >> >> Filters are âpipesâ that read from standard input and write to standard >> output. >> """ > FYI Pillar has the following architecture > > Input --Reader -> AST -> (Transformer -> AST)* -Outputers (visitor) -> Save > > So nothing new under the sun. Notice that we can do several > transformation passes > like expansions. Cool. As I said in this thread in response to Stephan Eggermont, my concern is not about new under the sun, but in bridging cultural practices. > >> BTW you did not say: >> Ok guys I want to write a Markdown parser (to contribute to >> pillar, which would be cool.) >> You said I want to have a playground to edit markdown. This is >> quite different to me. >> >> >> Because the second thing (Markdown support inside the Playground) is the one >> I want to contribute to Pharo(!), not to Pillar. Contributing should not be >> so hard, but each time I bring this theme is an uphill battle in just >> getting the initial exploration questions answered (because they're about >> Markdown and not about Pillar). > So you will code your own text Model, AST, and visitor? > Did you see that GT people are using Pillar model for the their editor? > I don't need to. I will use CommonMark and PettitParser. I imagine GT-Tools can use the models there in the Playground. > Go ahead and learn. Wow! Finally! > >> About the not invented syndrome remarks, why then don't we drop Pharo? >> Now if each time we want to install pharo we should install Python, >> why not installing lua and Ruby and a bit of Javascript in case. >> >> >> Because is not an all or nothing proposal and it has never been. It's about >> Pharo *playing well with* others, not about *being replaced by* others. I >> don't see any worth in taking this stuff to the extremes. When someone >> advise me Pharo, I don't think that he/she is advising me to drop my >> operative system and to run Pharo from bare metal because you go the Pharo >> way or the No Way(!). > > You are exagerating That was precisely my point. To show the absurd of exaggeration. I don't think that proposing a versatile Playground that supports several syntax highlighting (and some supporting behavior) is the same as proposing to install everything, kill Pillar efforts or anything like that. In the same way that using Pharo doesn't mean stop using anything else. But proposing anything distinct from Pillar as a documentation *alternative* in Pharo is faced time and again with overreactions. > and more important under estimating the COST of > using multiple systems. > Let me take four simple cases > > - We spend hours debugging Yaml to embedd bash into a travis (no > debugger of course) and we failed > while we try to understand why the validator went wrong and did not > like space (we tried many many combinations of `"' and more. > And gave up. Guille is much better than me and Andrew on bash and we > all three failed. > > - Pillar was using external mustache unix based library and I forced > them at that time to use Norbert implementation > and we can debug it. We can avoid to have bugs because converting a > stream into a file then invoking make then reloading the file. > > - Looking during two days for a bug in bash script that tells that > eveyrthing is ok while one package that should have been loaded > was dropped. Now we use metacello instead relying on bash now. > Do you want more... I have tons of them like that ... > Each time you have a different stack you had another level of > complexity and it is not linear but exponential. > This is the same with servers and processes. > > Pillar archetypes were zipped on a Jenkins server that may be blocked > from time to time. Smalltalkhub may be slow and the bash > will continue without failing and your installation breaks. So we are > flushing everything. > > No more mustache on disc, no more spurious metadata, no more separate > server, no more make (see below I was not even able to add one entry > to the help), no more > cp -r (that is not compatible on different OSes!!!). Just plain pharo > as much as possible. > I use just plain Pharo as much as possible in Grafoscopio. I don't have any external bash, config, yaml file to produce a document. Jus plain Pharo dictionaries and dynamic arrays stored *inside* the notebook. I use Pandoc to import/export to several formats (a place where it is superb and without any closer competitor), we started to use some Lua scripts (which are already supported in Pandoc) to query/script its document model and I have thought in using Pharo Mustache to program the Pandoc Templates. So in my "borg approach" I glue Pharo to existing ecosystems (including techs and communities) to improve them, while making bridges between what they already know and what Pharo has to offer. > > > > > # Some shell magic to auto-document the main targets. To have a target appear in > # the output, add a short, one-line comment with a double ## on the same line as > # the target. > # > # See http://marmelab.com/blog/2016/02/29/auto-documented-makefile.html I document targets as a "%metadata" node inside the Grafoscopio notebook. No shell magic beyond Pandoc one line flags. >> You are under estimating the effort that we put in Pillar. We >> extracted pillar from pier to be able to have an autonomous document >> system with which we can write good pdf and good HTML for >> documentation point of view. Because people did not like to write in >> LaTeX. >> Now if we would stop something each time somebody mention something >> else we would be doing python, Javascript or ... >> all the time. >> >> >> I don't underestimate anyone's work. Nor in Pillar, nor in Pharo, nor in >> Pandoc. In fact trying to make them work better together and giving back to >> this community by making software with Pharo and teaching people Pharo (for >> free) are clear examples of my appreciation for the work done in several >> fronts, inside and outside Pharo. The choice of LaTeX and HTML in your case, >> shows practical appreciation for those formats and I don't think that we >> should reimplement them in Pharo (despite of several advantages of live >> objects as documents instead of dead-files). Instead of putting valuations I >> have never done on me, I would advice to try seeing worth in the reasons >> behind a lot of people outside this community is using (Pandoc's) Markdown >> for documentation and the added value that adding Markdown support brings by >> having more people exposed to Pharo ecosystem, ideas, community, values and >> technology. > The argument that Coca cola is good because many people drink it > does not hold. You see Pythoners have their own systems with their own > syntax. So what? I'm not using such ad-populum argument. I'm talking about *bridges* to what people is already using (in the backend) so we can show and use Pharo with them (in the front end) for data storytelling. > Pandoc is the same as Pillar. Maybe in the technical side, but with a more diverse and agile community devoted exclusively to think about light markup languages. Bridging with other communities shouldn't be seen as negative. > I do not care about the Pillar syntax. > I care that this is implemented in Pharo. > Now I will not write a markdown parser myself because I have what I need. > if other people propose a not super complex parser for markdown then > we can integrate it and let people use their own. > Well I just want Markdown syntax highlighting in the Playground (besides the current Smalltalk one). It amaze me how much resistance about what I want to explore and can be able to contribute, it's faced every time. > > >> So yes I'm dense and I focus on my stuff and my stuff is Pharo. >> And yes I do not care about pandoc because I want to write my >> exporters and tools in Pharo and I will fight for that. >> >> >> But we don't need to fight for that. > Yes because we should do the web in Javascript and the math in R and .... > This is always like that. > Well is not. Having bridges with R (like the ones we have now) doesn't preclude or diminish the work in Polymath. Or having Garage to bridge with external data bases doesn't preclude any work in native OODBs or bridges with JSON don't preclude any work STON. Having bridges with Pandoc/Markdown, doesn't preclude/diminish any work with Pillar. I have told this since the first thread about this subject, but you insist in a confrontational approach. I will not engage in it when both can coexist and be helpful for this and other communities. > I value your decisions and work and I >> think that is healthy to ask for reciprocity and build from that, instead of >> wasting time because we don't think the same. Diversity is healthy in a >> community. The only thing I'm asking for (besides such reciprocity) is >> pointers to start *my* exploration. > > Then explore. > You can also learn from Pillar :) > If you want to have a look the pipeline in version 5 is obscrure and > in the new pipeline guille dramatically cleaned it. > and we will continue. I will start my exploration with PetitParser and CommonMark. >> This is why I want to use Scale instead of *&%*^)&%^ bash. >> And this is why I spent most of time trying to improve Pharo because >> it is not at the level I want but I can contribute >> and make it better. >> >> Stef >> >> >> I don't use bash or Json config files for anything related with >> documentation in Grafoscopio. Just plain Pharo inside an interactive >> "%metadata" playground node in the Grafoscopio notebook. Spoon, Coral, >> Scale, would be welcomed when integration with them is ready. I spent good >> time also trying to make my contributions and improvements to Pharo. We >> don't need to fight because our ways of contribution are different. > Ok try and learn. > That's all I want: explore and learn. I finally have pointers to where to start. It just be more fluent if I don't have to fight an uphill battle anytime Markdown support is mentioned. Cheers, Offray

Dec. 31, 2017

Re: [Pharo-users] Is there a way to stop arrays sorting automatically?

by Denis Kudriashov

Hi. 2017-12-31 14:47 GMT+01:00 Andy Burnett <andy.burnett(a)knowinnovation.com>: > > > Thanks Ben, > That is really interesting. I had completely misunderstood the problem. > Checking the items in oc2 shows that they are literally the same object. > So, it would seem that I have to run copy, or some other method to get a > unique object. > > I can see that this would make sense from an efficiency perspective. > Reusing the same object would presumably save memory space. However, it > would probably be good to update the comment to let people know that this > will happen. > > What is the process for submitting suggested improvements to class > comments? > It's same as any other code. Just follow instructions https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo. It is now simplified a lot. > > Cheers > Andy >

Dec. 31, 2017

Re: [Pharo-users] A playground for Markdown?

by Offray Vladimir Luna CÃ¡rdenas

On 31/12/17 07:59, Stephan Eggermont wrote: > Offray Vladimir Luna CÃ¡rdenas > <offray.luna(a)mutabit.com> wrote: > >> Pandoc consists of a set of readers and writers. When converting a >> document from one format to another, text is parsed by a reader into >> pandocâs intermediate representation of the documentâan âabstract syntax >> treeâ or ASTâwhich is then converted by the writer into the target >> format. The pandoc AST format is defined in the module >> |Text.Pandoc.Definition| in pandoc-types >> <https://hackage.haskell.org/package/pandoc-types>. >> >> A âfilterâ is a program that modifies the AST, between the reader and >> the writer: >> >> |INPUT --reader--> AST --filter--> AST --writer--> OUTPUT| >> >> Filters are âpipesâ that read from standard input and write to standard >> output. > Perhaps just reading the original Pier and Magritte thesis work by Lukas > Renggli would be helpful then. Anything new or better in Pandoc? > > Stephan > I will read it. Knowing that both, Pandoc and Pillar share kind of a similar approach would allow me to connect their AST (I mentioned such idea before, but now the path is more clear). The issue I care in this case is not about hot new stuff, but about bridges between cultural practices, ie, people who is using LMLs for documentation and discussing them extensively and people in the Pharo community. I need such bridges myself and I know enough people that could use them. Cheers, Offray

Dec. 31, 2017

Re: [Pharo-users] Is there a way to stop arrays sorting automatically?

by Andy Burnett

Ben wrote >>> Its not so much that your first example sorted the permutations, but that the collection contained only one permutation. I've swapped the order of your examples and downsized them to the simplest case to observe. Something seems broken. It works as expected if the "copy" is uncommented. Transcript clear. oc1 := OrderedCollection new. oc2 := OrderedCollection new. Transcript crShow:'a---'. (1 to: 3) permutationsDo: [ :each | Transcript crShow: each. oc1 add: each asOrderedCollection]. Transcript crShow:'b---'. (1 to: 3) permutationsDo: [ :each | Transcript crShow: each. oc2 add: each "copy"]. Transcript crShow:'c---'. Transcript crShow: { oc1 asSet size. oc2 asSet size}. Transcript crShow:'d---'. oc2 do: [ :x | Transcript crShow: x ]. ==> a--- #(1 2 3) #(1 3 2) #(2 1 3) #(2 3 1) #(3 2 1) #(3 1 2) b--- #(1 2 3) #(1 3 2) #(2 1 3) #(2 3 1) #(3 2 1) #(3 1 2) c--- #(6 1) d--- #(1 2 3) #(1 2 3) #(1 2 3) #(1 2 3) #(1 2 3) #(1 2 3) cheers -ben <<< Thanks Ben, That is really interesting. I had completely misunderstood the problem. Checking the items in oc2 shows that they are literally the same object. So, it would seem that I have to run copy, or some other method to get a unique object. I can see that this would make sense from an efficiency perspective. Reusing the same object would presumably save memory space. However, it would probably be good to update the comment to let people know that this will happen. What is the process for submitting suggested improvements to class comments? Cheers Andy

Dec. 31, 2017

Re: [Pharo-users] A playground for Markdown?

by Offray Vladimir Luna CÃ¡rdenas

Hi, On 31/12/17 06:47, Dimitris Chloupis wrote: > Â > > I have argued time and again and in length about Markdown support > in Pharo, so I will not do it again. I'll just repeat that, in > order to make Pharo less isolated, Git support for managing > software source code has the strategic importance, in the same way > that Markdown support for managing documentation source code has > strategic importance. This doesn't preclude support for > native/alternative DVCS in the software front (Monticello, Fossil, > etc) or markup languages in the documentation one (Pillar, > Dokuwiki, t2tags, etc). > > > It's kinda funny because me and Esteban have been very early on huge > supporters of git and github when the rest of the community was mildly > interested to passionately against it.Â I have been very vocal about > it, to the point of annoying people and being accused of just > supporting a overhyped product. 4 years later working with git is the > official way of doing things and we even have our very own github > client in the image. Well it's kinda funny to experience the same resistance in the documentation front that we have in the Git/GitHub, even using the same old arguments. I don't like Git/GitHub, but I understand the strategic importance of it for the community. In the documentation front, each time Markdown is mentioned (with any external tool that works with it) we restart from zero to have the same old arguments (just look at the current thread). [...] > > My personal opinion on this is that using syntax for documentation in > 2017 feels to me like stone age. We did not even do this in 1980. I > will dare to predict and you can bookmark this post that Markdow will > slowly disappear to be replaced with the proper way of doing > documentation and that is through a dedicated documentation editor > like Libreoffice.Â Even Google docs seem to return in favour of Markdown. In 1980 we don't have Wikipedia and more that 5 million of articles written using a light markup language (LML). We didn't have GitHub and several devs communities writing collaboratively documentation using same kind of languages. We didn't have Ulysses[2], Ghost[3] and other apps directed towards non-devs, but bloggers and writers, using/advocating plain text and LMLs to keep you focused on writing (not typography or margins) and being able to write in small form factor screens. So I see the return in favor of LML as a progress over complicated and bloated XML files or cumbersome verbose markup languages for documentation (and their supporting GUIs). [1] https://en.wikipedia.org/wiki/Wikipedia:Size_of_Wikipedia [2] https://ulyssesapp.com/ [3] https://ghost.org/ > > The wide range of documentation formats take only a tiny fraction of > the market. Adobe may have lost the war with Flash but when it comes > to PDF they have won and won it easily.Â > > EPub for example is the least relevant format nowadays, it used be > widely popular format, nowhere near to pdf but popular indeed at the > time of PDAs but then iPhone came out and killed it together with > Flash. Nowdays is used mostly on Kindle which is also another device > that has lost most of its popularity. ePub is still important for librarians working on public access to several works, in places where people (fortunately) doesn't have and iPhone, like in the wide Global South, from Mexico to Patagonia and beyond. In fact, recently we have a talk in the Grafoscopio mailing list about exporting to ePub the Data Driven Journalist Handbook (with the Pandoc source it was just matter of changing one parameter and voilÃ ). > > I consider myself an expert on documentation because my day job is > being a lawyer and basically what we do is we write complex technical > documentation for courts. Especially my kind of lawyer that do not do > criminal law. I am writing legal documentation in a week what takes > our community to write in years.Â > I have been also close to documentation since 2002 (and I like to write long before that). From 2004 to 2008 we have the biggest wiki collection of Spanish recipes and how-to's about FLOSS with 4000 community articles. Of course this was a project in the "Global South", so nobody noticed it then, and now it slept lost in the cyberspace and somebody's offline backup. I was the main translator of TeXmacs[4] documentation to Spanish. An interactive mathematical documentation system with multiple backens long before Jupyter. So yes, I'm pretty sure that this community contains a lot of expertise in the documentation front. [4] http://texmacs.org/ > Microsoft Office has been monopolising our field to an extreme extend > and I must be one of those rare exceptions that I use Libreoffice and > quite frankly I dont blame them because it has its issues.Â > > No I am not a believer in Markdown which usage became relevant only > because Github supported it out of the box. With Github Markdown is > nothing. Well, Markdown has several use cases beyond programmers and beyond GitHub, as shown above (most programmers fail to see this). > > I am not a believer in LaText again, another specialised software that > is used by a very specific community.Â Â > I think its syntax is too verbose, but you don't need it all the time. You could write in (Pandoc's) Markdown (or Pillar) and tweak the parts you need using only LaTeX in the places you want, leveraging decades of experience in layout, templates, typography or kerning, without paying upfront expertise you don't need. So combining LML with LaTeX and its engines is pretty powerful (that's the approach used in most LML systems to produce PDFs). > I am not a believe in Pandoc, why bother with a million formats when > only 2 dominate the market ? Because people use them, and fortunately reality is not only about market dominance dictate and its simplistic view. To the wikipedians, the format that dominates their reality is the one in their wiki, as happens with any wiki engine user, with their particular syntax. A lot of small communities are better serve by their particular LML despite of the "global market" efforts to reduce reality to the two oligopolistic "options". [...] > > Why ? > > Because either they are unnecessary hard to use or limited to what > they can do.Â > You can have a combination of extensible LML that combine with HTML, LaTeX or YAML, so they're easy to learn and not so limited. > If it was up to me, Libreoffice would have been our official way of > documentation and the only alternative would have been an in image > editor probably leveraging the existing Libreoffice API. > > I am a GUI guy, anything that helps me type less and visualise more > its far better option to the alternatives.Â > Fortunately this was a community decision and not up to a single person. Good luck with a XML diff for a document wrote among several authors(!). TeXmacs for me had a lot of potential: WYSIWYM edition, math typography, diverse interactive backends, S expression all the way down, Lisp (Guile) scripting. But, because of the time it started, the toolkit was kind of isolated with a lot of ad-hoc, in-house solutions in a small community (at the end some Qt front-end was implemented). With Pharo we have the advantage of a continuum between the app, the IDE, the document, and that's something nobody has so evolved until now (not even the people at Mathematica or Jupyter Lab) and that makes a huge difference in the future of the application and its adaptability to the future/context. > But I have never stopped anyone from doing anything nor I tried to > discourage.Â > > I can guarantee to you the same people that have not embraced Pillar > is extremely unlikely they will embrace Markdown and Pandoc. There are > two things that coders hate a) Writing documentation b) Creating GUIs. > This is not going to change any time soon. Well not this millennium at > least.Â > > In any case whatever your goal I wish you very good luck. You are > going to need it.Â Â Coders are not my target and I'm already having luck, because our small diverse local community is already using LML for documentation.Â They're librarians, students, philosophers, historians, teachers, journalist, and even we have coders using it. So your millennium of skepticism and resistance have already expired, at least locally :-), which is why I bet on serendipity instead of luck (the encounter of luck, opportunity and preparation). Cheers, Offray

Dec. 31, 2017

Re: [Pharo-users] Best wishes for 2018

by Norbert Hartl

I want to second that. It has been another amazing year for pharo. And I think things have changed significantly. So 2018 should be really great! I matched my personal not-to-serious goal # ps aux | grep pharo | wc -l 59 So I have 59 pharo images in production. Next step will be to exceed 100 in 2018! And yes, Iâm definitely interested in a bootstrapped image ;) Thank you all for your amazing work. We are a great community! Norbert > Am 29.12.2017 um 09:39 schrieb Torsten Bergmann <astares(a)gmx.de>: > > Only a few days left for 2017. Thanks to all who helped shaping Pharos future. > May the lighthouse be with you in 2018 as well: > > World backgroundImage: > (ZnEasy > getJpeg: 'https://spotlight.it-notes.ru/wp-content/uploads/2017/08/02c48424be88ee36d5…') > layout: #scaled > > Have fun! > > Bye > T.

Dec. 31, 2017

Re: [Pharo-users] [Pharo-dev] Best wishes for 2018

by Norbert Hartl

> Am 29.12.2017 um 10:27 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > > Thanks Torsten, > I was about to write a similar mail. > > Thanks to everybody for allow me to be your âguy to hateâ :) > I will continue doing my best to make Pharo a better place for everybody, one step at a time. > You are still by far the nicest âguy to hateâ Iâve ever encountered ;) > happy new year! happy new year to you, too! Norbert > Esteban > >> On 29 Dec 2017, at 09:39, Torsten Bergmann <astares(a)gmx.de> wrote: >> >> Only a few days left for 2017. Thanks to all who helped shaping Pharos future. >> May the lighthouse be with you in 2018 as well: >> >> World backgroundImage: >> (ZnEasy >> getJpeg: 'https://spotlight.it-notes.ru/wp-content/uploads/2017/08/02c48424be88ee36d5…') >> layout: #scaled >> >> Have fun! >> >> Bye >> T. >>

Dec. 31, 2017

Re: [Pharo-users] A playground for Markdown?

by Stephan Eggermont

Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > Pandoc consists of a set of readers and writers. When converting a > document from one format to another, text is parsed by a reader into > pandocâs intermediate representation of the documentâan âabstract syntax > treeâ or ASTâwhich is then converted by the writer into the target > format. The pandoc AST format is defined in the module > |Text.Pandoc.Definition| in pandoc-types > <https://hackage.haskell.org/package/pandoc-types>. > > A âfilterâ is a program that modifies the AST, between the reader and > the writer: > > |INPUT --reader--> AST --filter--> AST --writer--> OUTPUT| > > Filters are âpipesâ that read from standard input and write to standard > output. Perhaps just reading the original Pier and Magritte thesis work by Lukas Renggli would be helpful then. Anything new or better in Pandoc? Stephan

Dec. 31, 2017

Re: [Pharo-users] A playground for Markdown?

by Offray Vladimir Luna CÃ¡rdenas

I like also the Borg approach and having Pharo ideas and tech glued/enhancing not only to other techs, but also to other cultural practices, like writing . That's why I'm supporting (Pandoc's) Markdown and data storytelling in Pharo. They connect us to several communities beyond programmers: activists, journalists, (not computer science) scientists and researchers. Cheers, Offray On 30/12/17 22:41, Kjell Godo wrote: > i like Pharo > Â Â Â and i want Pharo to do well and i want to use Pharo > Â Â Â and i like very much all the work being done on Pharo yes > Â Â Â Â Â Iâm very impressed and hopefulÂ > Â Â Â and i would not wish for that to slow down > but can Pharo do everything by itself? i donât think so > i used to feel like i could not leave Smalltalk > Â Â Â and andyâs comments and bullet proof correctnessÂ > Â Â Â because the outside world was such a barrier to entry > Â Â Â and the outside world was always missing something > Â Â Â that makes Smalltalk essential and so i felt like iÂ > Â Â Â could not use those other things > but if Smalltalk could be added to those other things > Â Â Â then they could be ok Â Â and i could see using them > Â Â Â like Racket clojure CommonLisp Shen Coq Haskell SwiPrologÂ > Â Â Â StrawberryProlog Pixie Forth Factor etc Â Ruby except itâs got a > hell of a syntax > Â Â Â erlang > Â Â Â if Smalltalk could be added to them then they could be ok > Â Â Â but without Smalltalk they look just like hell Â Â Â to me Â what a > travesty > Â Â Â unusableÂ > i donât like anything that smells like C all the C like like java etc > Â Â Â although turbo C was very nice Â Â so they had to kill it Â get > rid of it > Â Â Â because itâs like they are so inferior and yet everybodyâsÂ > Â Â Â first language is just like the quick sand you sink right into > Â Â Â never to be heard from again because God forbid you > Â Â Â should have to go through that again once is enough > Â Â Â so you sink right in never to be heard from again in any other venue > Â Â Â and itâs like these were just the langs that worked first > Â Â Â they got the network effect first and became the monopoly > Â Â Â and thatâs why people use them because God forbid > Â Â Â for bid that you should learn something new we all say > if Smalltalk could be like the front end of some other things > Â Â Â Racket CommonLisp Shen etc then That is what i want > and Smalltalk could be a back end too for things that it > Â Â Â does well like i want to use gemstone etc > > let everything do what it does best and let them all talk > Â Â Â to each other is what i want > thatâs the BorgLisp idea

Dec. 31, 2017