Kilon: This is revelation to me. I am enduring 10 minute turnaround for every edit I make in *.java, xml, jsp, js files. 4 minute compile and 6 minute web server update. How can I get that shortened to 10 seconds say? What links can help? What search terms to google?
Thanks, Aik-Siong Koh > On May 10, 2017, at 3:20 AM, kilon.alios [via Smalltalk] > <ml+s1294792n4946404...@n4.nabble.com> wrote: > > Just to remind people here that all languages with long compile times can be > avoided live coding style through the use of dynamically linked libraries > known as DLLs on windows, shared libraries on linux (*.so) and macos > (*.dylib) . Also Swift in particular comes with a live coding environment > called "Playgrounds" which is also very flexible. > > Haskell do not know if they have something similar to Playgrounds but I will > be surprise if they do not have something at least inferior. All languages > support DLLs including ours. > > Live coding is actually super easy to implement and believe me I was > sceptical about it at first and if I had read this post I am making now I > would call me crazy. But after implementing live coding in python, C and C++ > , now I am a believer. Of course the real question here is if its that easy > why people do not use it . From what I have found out, it has not occurred to > them as it did not occur to me. > > Why C++ coders still endure long compile times when they could test code in > an instant through live coding ? Well in games C++ live coding is actually > very popular, so some are already aware of the huge advantages of live > coding. > > I think this is an advantage of Pharo , that introduces to live coding, a so > simple idea yet so essential without you having to think about it yourself or > be already aware of it. > > With other language you will have to find a tutorial or article that mentions > this ability. > > Another shock for me is how simple it is to implement an image file format > for other languages. The shock was that the OS already uses image files like > pharo image that calls them "memory mapped files" they are used for sharing > memory which in turn is what is used for DLLs. The advantage over the pharo > image is that it crash prone, because it is handled by the OS and not the > language or the VM. Which means that even if your app crashes the image is > still saved and you lose no live data which is not the case with pharo image. > The disadvantage is that of course they are not OOP friendly as the pharo > image is and they are not language specific as pharo image is. > > Again I would not have known any of this if I had not been playing with > shared memory as an IPC and I also see coders rarely if ever mentioning them. > > > >> On Wed, May 10, 2017 at 4:09 AM Pierce Ng <[hidden email]> wrote: >> On Tue, May 09, 2017 at 06:59:08PM +0200, Stephan Eggermont wrote: >> > I don't know. I do know that I can't use something with the >> > ridiculous compile times of Haskell or Swift. That just kills flow >> > and productivity. >> >> You could hop onto an office chair and engage your colleague in sword >> fighting. >> That's a plus! :-) >> >> Pierce >> > > > If you reply to this email, your message will be added to the discussion > below: > http://forum.world.st/Smalltalkers-will-eventually-win-So-says-this-old-C-programmer-tp4945895p4946404.html > To unsubscribe from Smalltalkers will, eventually, win. So says this old C++ > programmer., click here. > NAML -- View this message in context: http://forum.world.st/Smalltalkers-will-eventually-win-So-says-this-old-C-programmer-tp4945895p4946427.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
