I think that there are some communities that are more receptive of live coding, beyond programmers. Scientist, journalists, hacktivists, data visualizers, musicians, come to mind and I have a better experience and more openness to live coding with them that with the "classical programmer/coder". With our recent Data Journalism Handbook, adaptation in Grafoscopio [1] and our recurrent Data Week hackathon+workshops[2], we're trying to reach new audiences and communities.
[1] http://mutabit.com/repos.fossil/mapeda/ [2] http://mutabit.com/dataweek/ Cheers, Offray On 07/10/17 07:40, Dimitris Chloupis wrote: > Yes I agree with this > > Pharo is a live coding BASED enviroment. For Pharo live coding is not > just an easy to use feature it based its entire mentality around the > idea of live coding. > > Even though Smalltalk borrowed live coding and image format from Lisp > we are more "pure" in that regard even compared to Lisp. > > But one thing to note here is that live coding is not really that > useful when used always. At least for me I rely a lot on it for > debugging and experimenting. But when I work based on a plan , or code > just works I do not care so much about it. > > So my workflow in the end is semi-live coding because I dont feel I > need live coding 24/7 to be super productive. > > Of course that creates some barriers in the end when tools are not > made to work 24/7 on a live coding context. To that extend Pharo is > definetly superior and a true live coding enviroment. > > You are suprised that you can do live coding in C++ but I was trully > shocked. > > My saga to do live coding in C++ started as a joke, something to use > to mock C++ ugliness and weakness. But oh boy it did slap it back to > my face. > > The process is again simple, you wrap eveything inside a main loop,and > call in this loop functions (C has no objects obvious) or methods if > you use C++ from DLLs. Those DLLs obviously contain 99.9% of your > code. Because a DLL can be reloaded it allows you not to stop > executing and replace code on the fly. The main loop is wrapped inside > an exception to make sure the an error will never crash your > application, C/C++ exceptions are more powerful than Pharo live coding > in that regard because in Pharo if you do anything bad with UFFI and > crash it , it will crash for sure. > > If you keep the DLL small and you use tons of small dlls your compile > times will be almost instantenous. You can also with very view lines > detect date signature change in source file and trigger background > compilation. Again few lines of code. The last mountain is live state, > in this case the executable pass a single pointer and instead of the > executable handling the memory its actually the dlls that handle it > but the executable because it cannot crash or exit will keep the live > state running. You can also use memory mapped file to store live state > as they perform pure memory dumps. > > All in all you will end up with 100 lines of code that can be wrapped > into a library and reused in the next project with zero setup. Its an > one time pain. > > Will I would recommend C++ over Pharo for live coding .... helll > no.... C++ obviously misses a hugely important live coding ingredient > which is reflection. We do live coding because we want to interact > with those objects ask questions about what is going on and why our > code does not work as intended > > However Python has no such limitation following a very similar design > to Smalltalk and being much more powerful language than C++. Python > follow very closely the Smalltalk paradigm even though there is not a > single mention of Smalltalk , anywhere in the Python community or of > live coding. > > Live coding in C++ has become a huge deal in game development mainly > because game development tend to want to change things on the fly and > games are so big with extremely long compile times. Unreal has made a > huge deal over its ability to hot reload C++ code in its editor , > though I do not like its approach so much. > > Bottom line is yes its easy and simple to do live coding in other > languages, not recommended so much in C++ because of its static > compiled nature and lack of reflection but for dynamic language like > Python it can come pretty close and I speak from experience. > > At least I have not found something in Python that made me wish I was > live coding in Pharo so far, but then yes I still think its better to > have a full blown live coding. Also from my limited understanding I > have figured out that pretty much every language out there allows for > reloading code which is pretty much a very large requirement for live > coding. > > So yes you can live code to an extend, lesser in languages like C++ , > more so in language like Python, Ruby etc. Can you get the Pharo > experience ? In a dynamic language with the creation of a live coding > library you could get pretty close but never exactly the same. > > Pharo still is the undisputed king of live coding. > > Why live coding is not a huge thing in coding in general, I am willing > to bet it has more to do with coder mentality than language > limitation. When you are used to "dead code" workflow it difficult to > switch. I struggle a lot to get use to the live coding workflow of > Pharo because I had to rewire my brain. But in the end you cannot > avoid live coding, there will be always scenarios you would want to > change things on the fly, reload code, store live state etc. > > In the end it more a coder flaw than it is a language flaw. I know we > love to blame languages for our mistakes. > > But in our back of our head we all know we debate over languages that > we barely use only 0.000001% of their true potential. We are too lazy > and sometimes we need someone to slam our face to the truth to > actually see it. And by we I dont mean the Pharo community but human > nature by itself. That's exactly what Pharo did for me that motivated > me exploring live coding in other languages. > > If it was not for Pharo I would still be doing the old slow method of > correct, compile, restart and repeat till you hate yourself. > > On Sat, Oct 7, 2017 at 1:57 PM horrido <horrido.hobb...@gmail.com > <mailto:horrido.hobb...@gmail.com>> wrote: > > > My point is that indeed you can do with EASE live coding in a > numerous > languages, at least to my experience. I have tried only Python and > C/C++. > > Until I came upon this thread, I never knew you could do live > coding in > Python and C/C++. And I was a professional C/C++ programmer for > over 15 > years! > > It is certainly a well-kept secret. I have found very little > information on > the web about doing live coding in these languages (in fact, > none). This > leads me to believe that the vast majority of Python and C/C++ > developers > don't know about, or don't do, live coding. > > Whether it's "easy" is rather subjective. I suspect it's not as > easy nor as > convenient as in Pharo. If it were, then live coding ought to be > much more > prevalent in the Python and C/C++ communities. After all, what > developer > doesn't want to improve their productivity or increase their > velocity of > development? > > The key differentiator here, I think, is that live coding is baked > into > Pharo/Smalltalk, thus making it natural to use. It is not natural > for Python > and C/C++ programmers. It would be difficult to convince the IT > industry to > adopt live coding en masse. > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >
